How I spend my first 5 minutes on a server • Hacker News Board

Re: How I spend my first 5 minutes on a server

#331

Post by robomartin » Tue, Mar 05, 2013, 12:44 AM UTC

belorn wrote: post #326

robomartin wrote: post #280

I went through the article and then read every single post on this thread. I am not a security expert so I won't even try to contribute except to say that I see a lot of people offering criticism without taking the extra step of explaining how they would go about hardening a fresh Linux install (or a pile-o-servers in a rack, whatever is applicable). It'd sure be nice for those of us who are not security experts to r…

You are right, and I have some blame here of not including positive criticism in my comments. I do not have a script to offer, but I can go through the process I work by. #1: A good password is a must. During installation, have a second computer generate a good password and either memorize it, or GPG encrypt it somewhere on the second computer. pwgen is decent in generating passwords. 2#, I fully agree with the artic…

> have a second computer generate a good password

Why a second computer?

Re: How I spend my first 5 minutes on a server

#332

Post by tuzakey » Tue, Mar 05, 2013, 12:45 AM UTC

vacri wrote: post #107

kbuck wrote: post #95

Why install fail2ban? You already have SSH password auth disabled, and you only allow SSH connections from your office. Won't this just risk banning your own office if someone's SSH client is misconfigured?

fail2ban is useful for things other than SSH - I've seen it deal handily with people probing our asterisk server.

agreed, you can set up fancy jails for people scanning other services too, someone who probes SMTP/POP/IMAP doesn't need to hit SIP and SSH. Depending on the scenario you could choose to say block an entire netblock from hitting ssh after a single offensive IP probes a few services. Even a 10min jail time will cause most attackers to give up and move along to their next victim (unless you're being targeted.)

Re: How I spend my first 5 minutes on a server

#333

Post by [deleted] » Tue, Mar 05, 2013, 1:11 AM UTC

belorn wrote: post #326

robomartin wrote: post #280

I went through the article and then read every single post on this thread. I am not a security expert so I won't even try to contribute except to say that I see a lot of people offering criticism without taking the extra step of explaining how they would go about hardening a fresh Linux install (or a pile-o-servers in a rack, whatever is applicable). It'd sure be nice for those of us who are not security experts to r…

You are right, and I have some blame here of not including positive criticism in my comments. I do not have a script to offer, but I can go through the process I work by. #1: A good password is a must. During installation, have a second computer generate a good password and either memorize it, or GPG encrypt it somewhere on the second computer. pwgen is decent in generating passwords. 2#, I fully agree with the artic…

[deleted]

Re: How I spend my first 5 minutes on a server

#334

Post by robomartin » Tue, Mar 05, 2013, 1:18 AM UTC

_phred wrote: post #327

robomartin wrote: post #280

I went through the article and then read every single post on this thread. I am not a security expert so I won't even try to contribute except to say that I see a lot of people offering criticism without taking the extra step of explaining how they would go about hardening a fresh Linux install (or a pile-o-servers in a rack, whatever is applicable). It'd sure be nice for those of us who are not security experts to r…

I'm throwing my hat in the ring. I took the author's original post and implemented it as an Ansible playbook in a little less than an hour. http://practicalops.com/my-first-5-minutes-on-a-server.html Happy to answer questions about it. :)

I don't know Ansible. I learned about it through this thread. It sounds very interesting. I'll have to experiment with it as I am getting ready to launch a service that will start out with one server but will probably grow quickly to the five to ten range with a few devs involved.

Towards the end of your page you talk about keeping a manual log file. That's exactly the way I've handled this sort of thing for years. I usually call mine "project-log.txt". These files usually have several sections and it looks like this:

Header: Project name, start date and other relevant details

Date entry: What I did on a particular date

Working on now: Before I do anything I make this entry. After an interruption I usually have no clue what I was working on. By making a habit of writing a note to myself about what I am going to be working on immediately I can task-switch to that phone call or unwelcome question and mentally come back to what I was doing quickly.

To Do: Self explanatory.

Questions: If questions come up I log them here so I don't forget.

Ideas: Sometimes as you are working you say things like "hey I should do x". I log them here and go back to what I was doing.

References: Links, etc.

After launch: There are things that might not be critical at all and can be done after launch. I try to only note must-have's in "To Do".

This file lives at a self-named directory: "~/project-log". I do this because I can also save other relevant files there and keep the entire thing under source control.

  
  
  
  

  --------------------------------------------------------------------- 01MAR13
   format example:
  - Installed Ubuntu 12.04 LTS
  - Installed PHP
  - Installed MySQL
  - Installed Python
  --------------------------------------------------------------------- 02MAR13
  
  --------------------------------------------------------------------- 04MAR13
  

  --------------------------------------------------------------------- WORKING ON NOW
  - Configuring Virtual Hosting

  --------------------------------------------------------------------- TO DO
  - Configure vim for php development
  - Customize bash
  - Install imagemagick
  - Install php5-imagick

  --------------------------------------------------------------------- QUESTIONS
  - How to automate server bring-up and hardening?
  - Firewall or not?
  - Disable SSH?

  --------------------------------------------------------------------- IDEAS
  - Learn Ansible for automated deployment.

  --------------------------------------------------------------------- REFERENCES
  - Ubuntu 12.04 LTS docs
      https://help.ubuntu.com/12.04/  
  - Ansible
      http://ansible.cc/

Re: How I spend my first 5 minutes on a server

#335

Post by _phred » Tue, Mar 05, 2013, 1:54 AM UTC

robomartin wrote: post #334

_phred wrote: post #327

Earlier quoted context omitted.

I'm throwing my hat in the ring. I took the author's original post and implemented it as an Ansible playbook in a little less than an hour. http://practicalops.com/my-first-5-minutes-on-a-server.html Happy to answer questions about it. :)

I don't know Ansible. I learned about it through this thread. It sounds very interesting. I'll have to experiment with it as I am getting ready to launch a service that will start out with one server but will probably grow quickly to the five to ten range with a few devs involved. Towards the end of your page you talk about keeping a manual log file. That's exactly the way I've handled this sort of thing for years. I…

There's nothing like good old plain text. :)

Nowadays I'm downright spoiled and use org-mode[1] to keep my systems journals. Org files are plain text as well, and org-mode takes care of setting up the tree by date. I can also add a journal entry from anywhere in Emacs with just a couple keystrokes, which makes it incredibly low-friction to use.

Like I said, the most important thing is to TAKE NOTES. Even pen and paper. It's one of Limoncelli's big points in Time Management for System Administrators.

Tooling doesn't really matter, the important part is being able to remember what the heck I did and when I did it. Invaluable for troubleshooting.

[1]: http://orgmode.org

Re: How I spend my first 5 minutes on a server

#336

Post by 0xbadcafebee » Tue, Mar 05, 2013, 1:55 AM UTC

jasonlotito wrote: post #241

shizcakes wrote: post #48

The premise of this thing is not good advice. 1) Your first couple minutes on a server should be used to install a configuration management client, if your bootstrap policies somehow don't already install one. 2) Everything else listed in this document should be configured by a configuration management system. 3) "User account sync tools" should have no place in a modern infrastructure, you should use your configurat…

> This stuff isn't hard. It's worth doing right. Can you provide an article as equally succinct as the OP's that provides this information? Your list is painfully devoid of anything of true value. Since it's not hard, and worth doing right, I imagine something should already be written.

First, pick a CM package.

This depends entirely upon your level of masochism and the kind of language youlike scripting in, as literally anything will do. Even shell scripts. Even Makefiles. Whatever you're most comfortable with, just start writing out configs. (you will eventually come to hate your job if you allow non-programmers to script/program in your CM, but blah blah keep shipping blah blah) Break it all out intoa wide hirearchy so you can reuse some bits in other bits.

Hey look, I wrote a crappy one! https://github.com/psypete/public-bin/tree/public-bin/src/si...

Next we implement the OP's comments.

Hey look, I already implemented it in my crappy CM tool! https://github.com/psypete/public-bin/tree/public-bin/src/si...

First push your CM tool and configs to the host:

  scp -r simplecfm-0.2 remote-host:

Then run the main config file which calls the others:

  ssh remote-host "cd simplecfm-0.2/ ; perl simplecfm examples/first-five-minutes/main.scfm"

Aaaaand you're done. Of course I haven't tested these configs and something will probably break (most likely my crappy code) but you'll get the idea from looking at the examples.

Re: How I spend my first 5 minutes on a server

#337

Post by marcosdumay » Tue, Mar 05, 2013, 2:21 AM UTC

npsimons wrote: post #315

marcosdumay wrote: post #293

Earlier quoted context omitted.

> root login should be disabled completely Would you care to explain why?

The foremost reason is that root is carte blanche to ruin a system. This may be fine for a developer seat or even a desktop that is not critical infrastructure (shared), but on a multi-user system (and this includes things such as email and web servers), you really should have a "think twice" prompt, along with logging of who did what and when (eg, sudo). Even if you leave root as ssh key only login, then once an att…

The problem of sudo is that it's so easy to make a mistake in your command (and in sudoers). That's a security flaw in itself.

Also, you can always sudo bash, or sudo su.

You have a point about that extra password. But not about SELinux and RBAC being created because of that, nor in comparing the security of a system with root to one where eveybody is root.

All said, I'm still unconvinced. The logging isn't that usefull (I've tried it), and the extra password isn't relevant enough. Also, none of them will detain a malicious user (Linux has very week defenses against you grabing your own password).

Re: How I spend my first 5 minutes on a server

#338

Post by trotsky » Tue, Mar 05, 2013, 5:05 AM UTC

robomartin wrote: post #280

I went through the article and then read every single post on this thread. I am not a security expert so I won't even try to contribute except to say that I see a lot of people offering criticism without taking the extra step of explaining how they would go about hardening a fresh Linux install (or a pile-o-servers in a rack, whatever is applicable). It'd sure be nice for those of us who are not security experts to r…

The reason nobody shared their one true checklist for security is that it doesn't exist. Well secured systems get owned every day, and tons of bad ones never have trouble due to luck and lack of incentive.

Most extensive security procedures contain a lot of questionable advice and few will prevent human error which most compromise can be traced back to.

The only semi-universal list amounts to 1) use keys for ssh

2) block/turn off everything except your (web) service

3) automated security updates or some sort of failsafe procedure to install security updates very regularly (this is by far the most common error)

4) Learn about web application security threats especially sql injection and consider them at design and implementation and have some kind of regular review (this can be very difficult to get right)

5) Avoid storing anything that makes you a particularly desirable target like bitcoins or secret defense plans as anything can be hacked with enough incentive.

Most everything else probably won't make too much of a difference to you.

Re: How I spend my first 5 minutes on a server

#339

Post by robomartin » Tue, Mar 05, 2013, 5:20 AM UTC

trotsky wrote: post #338

robomartin wrote: post #280

I went through the article and then read every single post on this thread. I am not a security expert so I won't even try to contribute except to say that I see a lot of people offering criticism without taking the extra step of explaining how they would go about hardening a fresh Linux install (or a pile-o-servers in a rack, whatever is applicable). It'd sure be nice for those of us who are not security experts to r…

The reason nobody shared their one true checklist for security is that it doesn't exist. Well secured systems get owned every day, and tons of bad ones never have trouble due to luck and lack of incentive. Most extensive security procedures contain a lot of questionable advice and few will prevent human error which most compromise can be traced back to. The only semi-universal list amounts to 1) use keys for ssh 2) b…

> 3) automated security updates or some sort of failsafe procedure to install security updates very regularly (this is by far the most common error)

This isn't clear. Are you saying you think automating these updates is good or bad?

> 5) Avoid storing anything that makes you a particularly desirable

Well, in some cases your user's uid and pwd is the most valuable chunk-o-data a would be attacker wants.

> Most extensive security procedures contain a lot of questionable advice

List?

> and few will prevent human error which most compromise can be traced back to.

I think this would be the power of having a canonical auto-provision script on Github that many can review and contribute to. The script could certainly take the form of sections that could be commented out as needed. In other words, a well documented and reviewed set of recommendations that someone could edit based on pier-reviewed information in the comments and then use to automatically configure a server. That, I think, could be of value.

Re: How I spend my first 5 minutes on a server

#340

Post by toast0 » Tue, Mar 05, 2013, 5:23 AM UTC

martinced wrote: post #219

I honestly do not understand why you need a deploy account with sudo access. I much prefer a deploy accound which DOES NOT have sudo access. I add firewall rules transparently redirecting 80/443 to non-privileged ports that the webapp is actually listening to. Hence no need to be root / sudo'ed for the deploy account. You then could get a bit fancier and set the login shell for the deploy account to /bin/false or som…

On FreeBSD (and other BSDs?), you can change the privileged port range with a sysctl setting, so you don't need to muck about with the settings, just let any user bind to 80 or higher.