41 ms·
Securing an Ubuntu Server
- zdw 16y agoI tend to find that minimalist OS's, such as plain Debian installed with no frills or OpenBSD tend to be better candidates for security sensitive machines. Some of the utilities mentioned like Tiger haven't been updated in years. No mention of chroot/jails/zones/etc, which can go a long way to nullifying intrusions when they happen, or integrity tools built into the system (using package managers to check for changed binaries, or checksum tools like like tripwire/AIDE/radmind) While it does have some good points, it also strikes me as "cargo cult system administration", specifically "Following a security recipe": http://blog.lastinfirstout.net/2009/11/cargo-cult-system-administration.html http://blog.lastinfirstout.net/2009/11/cargo-cult-system-adm...
- viraptor 16y agoGetting a minimal distro also gives you the possibility to install only the things which are needed, instead of uninstalling a lot of stuff which came in by default. Additionally - if you are serious about monitoring, you should ship the logs to some external host in realtime, so they can't be deleted / changed. Running services in jails is definitely a good idea. Additionally configuring Apparmor and Selinux could be a good idea too. Or even switching to a grsec kernel. For the consistency checking, I prefer Samhain.
- krakensden 16y agoI thought Ubuntu had AppArmor on and configured by default for many/most of the popular services (Apache etc). I often see 'updating AppArmor profile' log messages in system updates, in any case.
- viraptor 16y agoOnly as long as you use the default paths and enforce the profiles... which should be the default for most people. But I think it's worth mentioning in case you have a specific application which you reverse-proxy, or install nginx, or ....
- orthecreedence 16y agoAgreed. If running a server, I'd choose Debian or Slackware over Ubuntu any day.
- rtaycher 16y agoIsn't Ubuntu server a fairly minimal install(not OpenBSD minimal but still).
- Klinky 16y agoThe Ubuntu Minimal CD is one of the leanest distro install options available. https://help.ubuntu.com/community/Installation/MinimalCD https://help.ubuntu.com/community/Installation/MinimalCD
- rwmj 16y agoThat's just a small Ubuntu CD which downloads packages on demand (instead of keeping them on the CD). If you really want a minimal distro, install FreeBSD or build a Debian root using debootstrap and just the daemons you need. I have a Debian machine (acting as a firewall) which is ridiculously parsimonious -- 'ps ax' fits on a single page and most of that is just kernel threads.
- iuguy 16y agoIn defence of the article, it has some good ideas. On the other hand it completely overlooks what people should be doing to secure their systems, regardless of OS. People should look at the role of the system and the information assets contained therein, then determine (if possible) what types of attack and attacker might be able to get in, and how - that tells you what you need to do. If you're not able to do the latter, but can do the former then you're still able to secure your system. A classic example would be a firewall. Your firewall contains no information assets beyond your ruleset. Your firewall however can be used to open up internal access to your network. We can then say, "We believe our attackers will mainly come from the outside". How will they get in? We don't know. What can we do to stop them from accessing the firewall? Put a rule in to drop all traffic with a destination of the firewall's external IP address or network interface. Providing your routing's set up correctly, you've now put in an appropriate countermeasure. Rinse, repeat for all of your Internet-facing assets, hosts, services and applications. It sounds a lot, but it gets quicker the more you do it. Most unlaunched startups with relatively uncomplex setups could do this in a day. Here's another example. Our Apache server is accessible from the Internet. Who can access it? Everyone. Does everyone need to access it? Yes - we're using it to host our application. Who is going to attack this? We don't know, could be someone skilled, could be someone not skilled. How will they get in? An Apache exploit, an Apache misconfiguration, something further up the stack (like our app or PHP). What do we do about it? We maintain Apache versions (to address the Apache exploit issue as best as we can). We make sure all unnecessary Apache modules are disabled and that our Apache setup is as minimal as possible, then look at the directives on the Apache docs and change the settings to be as effective as possible (without breaking our app of course) - this addresses the misconfiguration issue. If we have to switch something on we now know the effect of that and if concerned can ask HN, monitor it or both. As for something further up the stack, let's repeat the process on the way up until we're comfortable with what we have. If you're writing down your reasoning and your results along the way this will help you get up to speed - it also means you can write your own hardening guide, or even integrate it into fabric scripts to save time in the future. You'll also massively increase your understanding of the software you're using in the process, so it's definitely worth doing.
- bryanh 16y agoI go by the trifecta: * Disable root login. * Change SSH port. * Install fail2ban or denyhosts.
- fierarul 16y agoWow, I didn't know of fail2ban and denyhosts. I actually have a home-made script similar to fail2ban.
- bmelton 16y agoYeah, I've written a number of very long, very gruelling scripts that ultimately were all replaced by denyhosts. On the flip side, denyhosts only works on sshd (to my knowledge) -- so the scripts I wrote to monitor tornado log files and block all the random attack vectors is still worth having around.
- mkelly 16y agodenyhosts is configurable enough that I see no reason why it couldn't also work for other services. You'd probably have to hand-configure it (with a regex for each log type), though. That said, I've only ever used it for ssh.
- X-Istence 16y agoI wrote a similar script way before fail2ban was ever created in around 2003 or so. When PF was first introduced. Since then I've just kept using it since it works particularly well for what I want it to do.
- getsat 16y agoYou're missing a really important ssh setting: disable password-based authentication! However, this still won't protect you from vulnerabilities in your ssh daemon itself. Optimally, you would use Single Packet Authorization.
- chanri 16y agoWhat if you can't disable root login (i.e. it's a cloud server)?
- lamnk 16y agoFor a firewall (frontend for iptables) I recommend csf: http://www.configserver.com/cp/csf.html http://www.configserver.com/cp/csf.html Features: stateful inspection, protection from different types of attack, ability to ban port scanning attempts, ban brute force logins for various services (ssh, ftp, ...), numerous configuration options but very easy to configure with excellent inline documentation. For more info see the link above.
- SwellJoe 16y agoiptables already has all those features. I find "frontend" scripts like CSF confusing and distracting, because they throw in everything under the sun, including stuff that might make no sense in my particularly use case.
- lamnk 16y agoYeah, if you know the TCP/IP networking stack and iptables well enough. For most people, they do not. That's why sysadmins exist ;-) Otherwise, can iptables ban those who failed more than 10 SSH logins?
- SwellJoe 16y ago"Otherwise, can iptables ban those who failed more than 10 SSH logins?" Yes, sort of, though it's not "more than 10", it's "drop packets that look suspiciously like an automated attack", which I think is actually cooler because it never outright bans anyone but it makes it impossible to run an effective brute force attack. You'd use the "--state NEW" option to determine whether the connection is a new one or an established one. If someone connects over and over again to ssh (or any login-able service, really) within a short time you can drop them. Rules would look something like this: iptables -A INPUT -p tcp -i eth0 -m state --state NEW --dport 22 -m recent --update --seconds 15 -j DROP iptables -A INPUT -p tcp -i eth0 -m state --state NEW --dport 22 -m recent --set -j ACCEPT Assuming, of course, that you're already accepting ESTABLISHED connections above those rules. iptables is astonishingly powerful and flexible, and it's usually pretty easy to google up the right recipes, if you aren't quite sure of the incantations. It can be a little intimidating, but it more than repays you for the effort. When I did network consulting I was always surprised when I came upon a network where they had a Linux router, web server, mail server, etc., and then a Cisco PIX firewall sitting in front of it. Once again, it's just needless complexity, when the Linux box could do everything the PIX does (and possibly more, in the case of the low end PIX that I usually see). Since you have professed iptables ignorance...are you sure CSF is doing anything sensible in your deployment? By that, I mean, do you have any idea what your firewall rules are actually doing and if they are effective for what you think they are effective for? I'm always a bit wary when I come upon a network where the people maintaining it have no idea what their systems are doing or how they work. While CSF may be a net positive, if the trend is toward avoiding knowledge, it's a dangerous direction to go in. I'm all for simplifying, and sometimes tools make things simpler. But, as I said, in my experience the "pile of shell" firewall scripts complexify things rather than simplify them.
- zokier 16y agonmapping localhost doesn't sound very effective.
- sucuri2 16y agoI don't get why people recommend chkrootkit + failban/denyhost. I would recommend OSSEC to anyone looking for a serious host-based IDS (it does all those tools do + a lot more and very light weight). *link: http://www.ossec.net http://www.ossec.net
- dedward 16y agoI found that, while it looked great, for some reason on every install I tried (granted this was a couple of years ago, but I tried on various distributions and hardware) - the mailing engine tended to silently fail - which was fairly critical. Denyhost, while not as sophisticated by a longshot, is dead easy to install and take care of the SSH brute force issue.
- muppetman 16y agoYou should also look at the grsecurity kernel patch: http://grsecurity.net http://grsecurity.net It can really help to harden a system by making it much, much harder to exploit buffer overflows, making it impossible for users to see any processes other than their own etc. It's a great kernel patch and I highly recommend it.
- dedward 16y agoSecuring a server is relatively easy - what people need to look past is securing the system as a whole. Some day something in the servers or network you are responsible for will probably be breached in some fashion. You won't expect it. You'll find out. You'll panic. Think past securing the perimeter and think about what happens when that fails... because it may. Are you using SSH keys internally to walk around systems? Are they secure? What happens if someone accidentally leaves a test account open somewhere and somehow, through dumb luck, ends up with root access to your kickstart server or whatever config management stuff you have? Now - what will you do when you have to start from scratch? Everyone likes to say once a system is compromised you have to format - but that becomes a daunting task if you're talking about hundreds of systems including the systems used to manage those systems. Do you nuke everything from orbit? Can your business afford the downtime? You need recovery procedures as much as you need security... and you need auditing procedures to ensure that your security and recovery procedures remain valid.... and you need auditing procedures to ensure those auditing procedures are followed. Complexity also breeds problems... keeping systems simple also makes them easier to manage.
- moe 16y agoArticles like this are amusing but also somewhat disturbing. Ubuntu is based on debian unstable. It was created to escape the slow debian upgrade cycles and get more recent packages on the desktop. So far, so good. But why are we now baking a server distro out of a desktop distro that is based on the unstable branch of a server distro? And who would put that on a server and try to "secure" it?
- Tichy 16y agoMaybe debians philosophy and approach is not the only valid one for security. Or people want to choose other trade-offs than the debian maintainers.
- DarkShikari 16y agostable means "doesn't change very often". It does not mean "less buggy". In my experience, Debian "stable" packages tend to be literally covered in bugs and security holes due to being years old. Only a few of the most popular packages get fixes backported.
- moe 16y agoDebian "stable" packages tend to be literally covered in bugs and security holes Would you mind backing this up? Only a few of the most popular packages get fixes backported. Debian must have many popular packages then, considering lenny has accumulated security backports for 1529 packages in amd64 alone. They take security pretty[1] seriously[2] and considering it's all done by volunteers it doesn't seem nice to spread FUD about their work without any data to verify your claims. [1] http://www.debian.org/security/ [2] http://security-tracker.debian.org/tracker
- moe 16y agoIt's interesting to see this particular comment voted down without any replies...
- asdfor 16y agoThe first step on securing an Ubuntu server is switching to Debian (this sounds a bit trollish but oh well)