It is a rarity to watch someone secure a freshly installed server right off the bat, yet the world we live in makes this a necessity. So why do so many people put it off until the end, if at all? I’ve done the exact same thing, and it often comes down to wanting to get right into the fun stuff. Hopefully this post will show that it is far easier than you think to secure a server, and can be quite entertaining to look down from your fortress, when the attacks begin to flow.
This post is written for Ubuntu 12.04.2 LTS, however you can do similar things on any other Linux distribution.
Where do I begin?
If this server already has a public IP, you’ll want to lock down root access immediately. In fact, you’ll want to lock down SSH access entirely, and make sure that only you can get in. Add a new user, and add it to an admin group (preconfigured in
/etc/sudoers to have access to sudo).1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 | |
You’ll also want to create a private key on your computer, and disable that pesky password authentication on the server.
1 2 | |
1 2 3 4 | |
Reload SSH to apply the changes, and then try logging in in a new session to ensure everything worked. If you can’t log in, you’ll still have your original session to fix things up.
1 2 3 | |
Update the server
Now that you’re the only one with access to the server, you can stop worrying about a hacker sneaking in, and breathe normally again. Chances are good that there are some updates for your server, so go ahead and run those now.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 | |
Install a Firewall
Running the most recent software now? Good. Go ahead and set up a firewall, and only allow what you need right at this moment. You can always add another exception later, and a few minutes of extra work won’t kill you. IPTables comes preinstalled in Ubuntu, so go ahead and set up some rules for it.
1
| |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 | |
Apply the ruleset with a timeout through
iptables-apply, and if you lose the connection, fix your rules and try again before continuing.1 2 3 4 | |
Create the file
/etc/network/if-pre-up.d/iptables, with the following content. This will automatically load your IPTables rules when you start the server.1 2 | |
Now give it execute permissions, and execute the file to ensure it loads properly.
1 2 | |
Fail2ban those wannabe-hackers
Fail2ban is one of my favourite tools when it comes to security, as it will monitor your logfiles, and temporarily ban users that are misusing your resources, be it brute forcing your SSH connection, or DoSing your webserver.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 | |
Fail2ban installs a default configuration (
/etc/fail2ban/jail.conf), but we’ll want to make our changes in /etc/fail2ban/jail.local, so copy it there.1
| |
Configuration
Change the
ignoreip line to your IP, and decide on an amount of time to ban the scumbags for (default is 10 minutes). You’ll also want to set up a destemail, which I normally enter as my own email address followed by ,fail2ban@blocklist.de. BlockList.de is a system to track and automatically report hacking attempts to the proper abuse contact for their IP.1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 | |
There are a few other settings you’ll want to check out, although the defaults are quite sufficient, so skim through the file quickly until you reach the Actions section.
Actions
Actions allow you to react to malicious activity, however the default is to issue an IPTables ban, while we want it to ban and send an email. Thankfully there is a preconfigured
action_wml, which does just that.1 2 3 4 | |
Jails
In order for Fail2ban to work, it needs to know what to watch. These are configured in the Jails section of the config, and there are quite a few examples pre-loaded and disabled. Since you’ve only enabled SSH access on the server so far, we’ll only enable the SSH and SSH-DDoS jails, however you’ll want to add a new jail for each publicly-accessible service that you install on this server.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 | |
Apply the changes
Now that we’ve configured Fail2ban, you’ll want to reload it, and confirm that it is adding the appropriate rules to IPTables.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 | |
At any time, you can use
sudo iptables -L to list your rules, and subsequently list any currently-banned IPs. At the moment, Fail2ban is handling two malicious individuals:1 2 | |
Staying on top of things
You should now have a server that is locked down and ready to use, however this is not the end of your security journey. Stay on top of updates (and always test them in a non-production environment first), always close ports that you don’t need, check your logs regularly, and know your servers inside-and-out.
HackerNews Followup
There are some great comments over at HackerNews, and I suggest you read through them if you’re interested in different perspectives and higher security. This post is intended as a beginners guide to security, and the end of this post does not mean your server is invulnerable. Use this to quickly lock down a new server, and then build upon it for your unique situation. You may want to look into IPV6 security, changing your SSH port (security through obscurity), secured kernels (SELinux and GRSecurity), tracking system changes, and full audits if your server has ever been unsecured, or has been online for any substantial length of time. There are hundreds of entry points into a server, and every application you install brings yet another possible hole, but with the proper tools, you can go to bed without worries.
No comments:
Post a Comment