Securing Webservers (Ubuntu 12.04 LTS)

March 2, 2013

So I set up a lot of boxes and quite a few of them get hammered on pretty hard by attackers looking to break them open. I’ve been doing more than usual in the way of this lately so figured I’d do a quick round up of some of my favourite tools to make life easier. These aren’t just applicable to webservers but most of the boxes I use these on are.

Recently things have changed, with IPv6 becoming not just a nice-to-have but a need-to-have these days you’ll tend to run into quite a few tools that work great for IPv4 but aren’t applicable or don’t work on IPv6 yet.

Read on after the break!

So the first line of protection goes in at the IP level; Shorewall is an excellent iptables management tool. iptables remains the way to go when it comes to firewalls, in my opinion, as it’s the best supported. Manually managing rules for it, however, is a nightmare. Shorewall takes the pain out of rule and policy management; it also supports IPv6. Ubuntu users can install it trivially with apt, but configuration is a bit of a headache to get started with.

The basic premise is you remove everything in /etc/shorewall, copy in an example config from the /usr/share/doc/shorewall tree, and configure it. The ‘universal’ example works well on single machines; you’ll want something more complex for multiple network interfaces, but there’s examples for those too.

One gotcha I ran into – make sure the interface name in your zones file is ‘any’ (with a single NIC) or specifies the right NIC. Some examples default to eth0 and I’ve locked myself out at least twice when forgetting to set that to eth2 or eth1!

Once you have Shorewall set up and running you can allow things like SSH access and deny everything else. You’ve immediately just reduced your attack profile by an order of magnitude. Keep your open ports list as small as possible and scope them to source IPs or zones wherever possible – for instance if two boxes need to talk to each other open each port to the other machine’s IP only.

Next up is securing your ssh daemon. Install some SSH keys and disable password authentication. It’s the easiest way to stop attackers from compromising your machine and stops weak passwords being an issue (though you should always keep your root password set to something nice and arcane – I use a Yubikey-stored password for most of my boxes combined with a pre-typed string). You might also want to move SSH from port 22 to another port, but I find this can make for too much complexity in other services.

Fail2ban is a small Python daemon which checks logfiles and (with a minor config tweak to use shorewall) will integrate with your firewall to block people who fail to log in repeatedly. Still no IPv6 support here, though, but it’s worth having around regardless in my opinion.

OSSEC is another tool I’ve been playing with lately – it’s a host-based intrusion detection system. Basically you can install it on one system or across many with agents and a central server to manage analysis of reports and the like. It’s pretty simple to set up and configure in this manner and will then email you on suspicious activity. That’s stuff like dodgy web server requests, package installations, changes to watched files and folders – you get the idea. It comes with a comprehensive rule set you can use out of the box, and is maintained by Trend Micro.

There are a few other tweaks I do on my boxes – namely things like locking down sudo (allow permissions for specific commands if you need to elevate permissions or use setuid wrappers), setting up email alerts for my various monitoring tools to alert me of shenanigans, and locking down web servers and caches to only permit well-formed requests at paths I’m expecting (for instance, on my Ruby on Rails webapp, I’m not expecting URLs to end in .php or .aspx so I can drop those requests to a 404 or similar as early in my stack as possible to eliminate potential malicious/scanner clients). If you use an odd error code or log these, you can combine this sort of logic with OSSEC to put in firewall blocks on clients raising a lot of these codes.

As ever, proper key management and password security is absolutely vital, but the tools mentioned above will go a long way towards keeping boxes secure and letting you know about attacks. If you’re using Apache or nginx with applications like WordPress then tools like mod_security might also help you. And in most situations it’s safe to enable unattended upgrades for security updates (or at least have your system email you when updates are pending).