For years, I’ve had all sorts of boxes out on the internet, exposed. I did think about security a lot, and sometimes panicked about something that, while the chances of an attacker finding it are low, it only takes one determined and talented attacker to expose it. I didn’t know just how important this was until back in 2006, one of my home servers was broken in to by a Turkish hacker group. I was using VHCS at the time, which is a free CPanel of sorts used to manage a system hosting multiple websites, which included a textbook error in how not to use the PHP switch() function that the developers seemed to ignore pleas to fix it. I did notice from the attack however that the attacker used a website that actually performed the exploit for them. The author of the tool that performed the exploit created it because they were infuriated with the lack of seriousness the developers were taking his reports.
See here for an advisory on that vulnerability: http://www.rs-labs.com/adv/RS-Labs-Advisory-2006-1.txt
It was a really easy fix. The devs simply didn’t ‘break;’ off their case statements to stop the script rolling in to the other cases, resulting in the user getting an error page, but the account being created with full admin privileges anyway! I fixed the vulnerability myself and all was fine, even later attempts, but the incident put me off using CPanel-type softwares to manage multi-host servers for life. This means I now SSH in regularly and modify the files myself, or build shell scripts to automate some tasks. Of course, because of the power I had within a shell, I saw the brute-force attempts rolling in through the logs and made sure my passwords were strong. Then I stopped using passwords and resorted to certificates. Now, I still see the attacks coming in, but knowing pretty well that none of them would get in unless there was an SSH exploit and I hadn’t patched up recently. Frustrated seeing the attempts, I decided to lock SSH down further.
Moving the SSH port is hardly convenient
I moved my SSH port to get around the attempts to something above port 60000. This was ok, but I did forget the port I had moved it to sometimes, and ended up hitting the console anyway. Also, when operating on a remote server and you forget it (I don’t write access details down unless I’m documenting processes and I know the document won’t go outside the department) you have to contact support with the embarrassing request to change the port back. In the end, moving the port is moving the problem, whilst creating others. If you really want to do this as a quick measure, release your chosen port in IPTables and edit the “Port” setting in /etc/ssh/sshd_config, then restart sshd.
Neither is port knocking,
Port knocking is brilliant, but requires a client to ‘knock’ the specified port. Not all workstations have this client unless you install it, and you won’t have privileges to do this all the time. Basically it revolves around setting two or more ports as listen ports and using the knock client to ‘knock’ them in order. Once you’ve knocked them in the correct order, the port it’s protecting opens up for a few seconds, and closes straight back up again, but not locking you out again as your connection is established. To scanning software these ports still show as no-reply provided this is how IPTables is set up, it’s not recommended to have the firewall reveal the machine’s presence by responding saying ports are closed, simply drop them; try this out using Steve Gibson of GRC.com’s ShieldsUP! – And while you’re at it, subscribe to his SecurityNow podcast. It’s through this podcast that I get a lot of my security intel from. If you do have the ability to install stuff and a good memory or are ok with writing port numbers down, you can get the knockd from here: http://www.zeroflux.org/projects/knock
Fail2Ban bans failed attempts at doing nasty things
Fail2Ban basically scans through your log files looking for strings that indicate a failed login or repeated hits to the search function on your site (Not exactly a DDOS, but generates enough load to knock your site offline temporarily, so it kinda is), and then applies an IPTables rule to kill them off the server at the firewall so they no longer reach the service they were trying to penetrate. I went for this as, while it doesn’t get rid of the problem, it shouldn’t result in me forgetting important information, and it slows them down significantly, and logs each block. I have logs going to PaperTrail so if the box does get compromised through SSH, clearing your tracks on the server doesn’t get rid of the logs on PaperTrail. It’s simple to set up too!
Using ArchLinux, it was readily available from the Arch repos.
Once installed, make a copy of /etc/fail2ban/jail.conf and name it jail.local. Edit that file instead, the jail.local will override the jail.conf. Scroll down to [ssh-iptables], change enabled = false to enabled = true, and change the logauth setting to the file where all your SSH auth details go. Fail2Ban will check this file for denied entries. The maxretry setting determined how many times it will see the denied message for a specific host before it applies the block. I also set the IgnoreIP setting toward the top of the file to the IP range BT uses for Infinity. This setting makes Fail2Ban ignore denied messages from the range you specify here. I have a dynamic IP, so I specified a range. Lastly, the bantime setting determines how long a host is forbidden from connecting to your box before it releases it. It’s tempting to make this infinite, but if you lock yourself out, that’s bad.
Hopefully this is useful to someone!
