Live data from Hacker News

How I spend my first 5 minutes on a server

plusbryan.com

321–330 of 355 posts

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

#321
post #318

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…

Writing a canonical server security document is difficult because it depends so much on what the server is doing (what kind of application is it running? how is it accessed?) and where you're starting from. (barebones install? something pre-rolled by your VPS service?)

I would start with Ubuntu 12.04 LTS on Linode and see what develops from there.

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

#322

Earlier quoted context omitted.

.. and it saddens me each time I read a comment like this. It's best practice to disable remote root login. A whole industry supports this.

And, yet, the best practice seems to require an user account with full sudo priviledges. If you know the difference between that and root, please explain it, because I can't see any.

I don't do much admin outside my hobby boxes. One guess would be, excluding the ability to enter a root shell, each sudo command is logged so you know who ran it. If the user is root, then it's harder to know what they did while they were root.

Disabling root also means you now have to guess the username and the password instead of just the password.

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

#323

passwd Change the root password to something long and complex. And bam! Not even a full paragraph in and security fail. root login should be disabled completely, and all use of privileges should be through sudo. Debian sets this up for you automatically upon install if you supply an empty root password. Of course, disabling root is just the beginning (and the first user created needs to be locked down, as they are no…

I was installing Arch on RaspberryPi and tried disabling root (since I had seen it done on other distros). Not long after I was fiddling with LVM. When I rebooted it halted on my fstab which couldn't find my VolumeGroups and required my root password to continue booting.

I ended up popping out the drive and mounting it on another box, changed my fstab to noauto, got things to boot and reenabled root.

I figure distros that disable root are setup for these corner-cases where root is required.

The other obvious case is if you're using LDAP and the network is down. Maybe I haven't looked in the right places, but I haven't heard these things discussed.

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

#324
post #266

Earlier quoted context omitted.

I wasted several days trying to get a good puppet setup. In the end it still needs more work, and the deploy system is complicated. I only have 4 boxes to manage. Ansible looks great. Much lighter weight but it can still scale up. Puppet and chef would both benefit by supporting single run light weight modes of usage.

Puppet does have a single run mode of usage: http://docs.puppetlabs.com/man/apply.html I use it to manage just 5 servers, with a Fabric script that rsyncs the manifests up to the servers then runs `puppet apply` to apply the changes.

true, and that's exactly what I was doing. rsync and then run puppet apply. that's just a lot of grinding if you only made one little typo.

and I see here I have capfiles and a system to bootstrap a new server. way too much stuff for this scale. (4 servers)

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

#325
post #149

Earlier quoted context omitted.

Wouldn't the script-kiddie through those hosts into a queue to run a more advanced port scan on? I mean, I see your point, but it seems highly useless compared to, say, simply disabling the password based authentication.

Why would they bother? Script-kiddie is just playing the numbers, any machine with a slightly non-default configuration is not worth the effort. Disabling password authentication is better for "real" security, but doesn't stop those dictionary attacks spamming your logfile. (I still feel there should be better solutions to that problem than changing the port though)

> I still feel there should be better solutions to that problem than changing the port

Well, there is port knocking. http://www.thoughtcrime.org/software/knockknock/

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

#326

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 article on automatic updates if its a personal computer. For others, one can have root mails sent if you are a fast and and read mail daily. This is how many people read about vulnerabilities before they reach the news.

#3: When installing large package like web services, I keep in mind of the long term prospect of each project. I ask the questions: Is there a deb package? Is it being maintained by a large group of independent developers? Is it mentioned in discussion at Serverfault? Are there any recent updates? What does the Wikipedia page have to say?

#4: read the man page, and check any section labeled security. Some man pages will say things like "we have this port open. Its completely insecure, and we expect either the local network to be safe or that you use a firewall". Through this just happened once for me, its still a good practice to check the man page with new services.

#5, avoid php themes/mods that require you to manually patch things. They won't be updated by Ubuntu, so things will either end with you uninstalling it or forgetting that it exist and thus get hacked. Sometimes ubuntu will just install over the mod, dealing with the issue for you.

Other than that, harderning depend on use case. A wiki/forum will need some form of anti-spam protection. A media center need access control or firewall to only allow local network. Unsecured protocols like nfs and nis need something like ipsec. A mail server needs authenticated smtp.

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

#327

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. :)

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

#328
post #318

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…

Writing a canonical server security document is difficult because it depends so much on what the server is doing (what kind of application is it running? how is it accessed?) and where you're starting from. (barebones install? something pre-rolled by your VPS service?)

Sounds as though we need a decision tree app to write the scripts for us. It asks questions such as, "Do you have your own IP block?" and explains the question thoroughly for those who don't understand it, explains the answers offered (for questions such as, "Which of the following types of logins would you like to allow (check all that apply)? Password, public key, ...").

It would offer you explanations, deeper explanations, defaults, recommendations for when you would override the defaults, etc. for each item. It would be smart enough to prevent incompatible or contradictory settings.

Once this process was complete, it would generate the needed puppet / ansible / whatever script, which the admin would run and store for future reference and use. When installing another machine, the original script could be read in by the decision tree and the new script could be generated by modifying the original rather than starting from scratch.

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

#329
post #258

> No secure server is complete without a firewall. Comments like those are why I normally point people to actual security expects (like, say, Schneier), and why I recommend that new admins should ignore as much as possible the practices chanted by the industry. A secure server does not need a firewall. A firewall can be used to secure a server against a specific threat, but that's it. The days of ping of death are be…

Schneier recommends use of a firewall: http://www.schneier.com/blog/archives/2004/12/safe_personal_... You are correct that a firewall will not magically solve all your problems, but it does help to protect against programs that open ports you didn't know about. Recommending against them doesn't make sense, and implying that they are only useful to prevent TCP/IP zero day vulnerabilities is silly (especially since th…

Schneier talks about NAT and 2004 windows laptops (ie, with winxp). I actually asked Peter Gutmann during an IETF meeting around 2005, and he confirmed that nat had improved the situation around and win98/win2k/winxp windows machines and bot nets. If I recall right, the gist of it was that windows machines needed something, and while nat is wrong and bad, it "worked" in this aspect.

This is about as far from a server installed with ubuntu in 2012 that one can get. You are not going to find any such article by Schneier promoting default firewall installations. I suggest here to check out Secrets and Lies by Schneier, as it is rather clear that a firewall need to be configured against the specific threats one can identify. If you fail at identifying threats, the firewall is likely not be useful at all, or will simply work identical to NAT. At worst, it will give a sense of false security.

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

#330
post #258

> No secure server is complete without a firewall. Comments like those are why I normally point people to actual security expects (like, say, Schneier), and why I recommend that new admins should ignore as much as possible the practices chanted by the industry. A secure server does not need a firewall. A firewall can be used to secure a server against a specific threat, but that's it. The days of ping of death are be…

> The only thing I can think of is either a Zero day TCP/IP stack vulnerability (not a realistic threat), or that the admin doesn't trust the other admins when they install new services. Yes, if an admin installs a new email server and enables relaying to the whole world against the explicit recommendation in bold font by the install wizard and the configuration file, a firewall can block that admins' actions. Then a…

In those use cases I agree. If for any reason one do not trust the software installed to behave as expected, a firewall can be a nice net to cover any strange behavior. If the job require Proprietary software services with an unknown/untrusted behavior, or the re-use of old images with strange stuff in them, I would too consider running a firewall. In the case of users however, I tend to apply some good-faith practice and just monitor. If something happen, I can always apply a firewall to deal with the situation. However, I do understand if that is not possible in every work place.

Here nmap do shine, and periodically running nmap is a technique that should be taught in universities. Great way for students to both learn about computer systems, and about learning how to debug problems.

Post reply on HN