Surviving a Botnet Attack: Secure Your Linux Box
I have a simple Samba server that I use to store some music, work files, backups and some other random junk. I also use it to run an IRC bot and a streaming music bot. Nothing fancy, but it works well. I haven’t worried much about security beyond the default setup since it’s behind my router and firewall and doesn’t really have anything sensitive on it. While looking through the log files this afternoon, I saw that it’s been getting flooded with SSH connection attempts – all of which failed – from literally all over the globe. Typical signs of a botnet attack. Up until now, I’ve been using the default SSH setup. It’s OK, fairly secure, but nowhere near as secure as it could be with a few tweaks.
The First Line of Defense
My server was attacked with several floods per day for 15 days... but it was never compromised. Why? The first and most important rule in network security: strong passwords. Mine are fairly long, but very strong as a result – random strings of numbers, letters and special characters that make it nearly impossible for a dictionary/brute force attack to guess. A “dictionary” or “brute force” attack is where the attacker uses a large file of normal words as it’s source, repeatedly trying every word or combination of words as a login and password. Given enough time attacking a simple password, this sort of attack will eventually guess the right combination. It sounds like a no-brainer, but really think about it. How often have you set a simple password (something like “snot” or “ernie”) and thought “bah, no one would bother trying to hack this computer/account so it doesn’t matter.” This box of mine is a simple
Samba server behind my router and firewall, and yet it was found by a botnet and attacked. Strong passwords kept it secure. Even though the attack never compromised my server, I decided it was time to lock things down a bit further.
Hardening Security
First, I didn’t want these connection floods to keep coming. OpenSSH doesn’t prevent or lock out multiple failed connection attempts. It will allow an attacker to keep trying forever... which is what gives a brute force attack it’s power. To stop this in it’s tracks I installed DenyHosts. It’s a Debian package (it’s available for other distros as well) that will automatically prevent repeated failed connection attempts from an IP address or host. After X failed attempts, DenyHosts will add the offending IP to your hosts.deny list, which will tell your box to ignore any and all future connections from that IP. It’s highly configurable, easy to setup, and you can have it mail you each time a new offender is added to hosts.deny. To make things even better, DenyHosts will auto-update it’s list of malicious hosts from a master server, updated by other DenyHosts users. If an attacker tries to gain access to another server running DenyHosts, you’ll know about it and can lock him out before he can even try knocking on your door. Here’s a quick, simple setup guide.
Next, I changed the default SSH port from 22 to something only I know. This prevents any attacker from even talking to the SSH service on my box unless they know the specific, non- default port I’ve assigned. This isn’t major, since it’s easy enough to portscan any server to see where SSH is running, but it can go a long way to prevent these automated botnet attacks since they usually attack the default port. Don’t rely on this method alone though. The attack I saw tried random ports for 2 full days before falling back to attacking just port 22. As I mentioned, it’s very easy to portscan a server. Then, I added extra rules to my Samba server’s hosts.allow file to only allow connections from my local LAN, denying requests from any other network. I also added rules to only allow one user, me, and to disallow any connection as root (note that you should never, ever allow remote logins as root). If you haven’t done this before or have no idea what your hosts.allow and hosts.deny files are, here’s a great reference.
Finally, I made certain that my router/firewall wasn’t forwarding SSH requests and double checked it’s log files.
Airtight
Now, flood attacks will be effectively banned from talking to my server. I’ll be notified via email each time a new offender is banned and my SSH service is no longer running on the default port so it’s a little harder to find.
No matter how obscure or “of little value” you think your server or desktop is, someone, somewhere will try to gain access to it in order to use it as a solider in their botnet or something worse. Use strong passwords, keep an eye on your connection logs (even your shitty Wal*Mart router keeps them, check them on a regular basis) and keep your machines locked down or you’re literally begging for someone to hack your shit.
