More SSH Brute Force Protection

Stopping SSH Brute Force Attacks resulted in some really great comments and suggestions from readers.

So, this is a follow up to the last SSH brute force post. I didn’t realize there was such a wide selection of applications for dealing with this, but there is! The two best looking options in my opinion are Fail2ban and DenyHosts.

I’ve actually started using DenyHosts on two machines now, and it’s working very well. I chose to go with DenyHosts for a very simple reason. Community stats. I love stats.

Anyway, if you’re looking for something to protect against ssh brute force attacks, go with Fail2ban or DenyHosts, they’re still being actively developed. I can’t say the same for Breakinguard, as it appears to have been abandoned about 1 year ago. And like I said, DenyHosts does it’s job extremely well, I couldn’t ask for anything more.

If you’re looking for another solution, try using cryptographic keys instead of passwords. A tutorial on configuring SSH to look for keys instead of passwords can be found here. This was suggested by commenter pwyll.

Oh, and this is the 700th post. yay!

Stopping SSH Brute Force Attacks

A few weeks ago at work, I noticed a bunch of failed login attempts to one of our Linux servers. After doing some investigation, I found that no intrusion had actually been made, which is excellent. Lines similar to this were filling my /var/log/messages log file:

Aug 20 23:31:26 elixer sshd[22526]: Failed password for invalid user alias from 66.166.22.186 port 26217 ssh2

Notice they’re trying to login with the username “alias”, which doesn’t exist on that system. In fact, all the usernames attempted don’t exist, which makes me feel a little safer. Still, I don’t like seeing my boxes actively attacked. So, to stay on top of these breakin attempts, I installed Breakinguard.

Breakinguard basically watches your log file for any failed login attempts. You can set a pre-defined number of attempts that can be executed before breakinguard will block the IP.

The Package itself does a ‘tail -f’ of your syslog, and when it identifies a matching line within your logs, it logs this ‘attempt’. If more than the pre-defined number of attempts from the same IP address are received it triggers the iptables (or any other block method defined) block and also emails you notification.

I’ve never been able to get the configure script to work for me, simply because the perl module installation always fails. So, to get around that I simply installed these perl modules manually and commented out these lines in the configure script:

$PERL -MCPAN -e "install File::Tail"
$PERL -MCPAN -e "install IO::Socket"

Those two lines execute perl and try to install the File::Tail module and the IO::Socket module. After manually installing the perl modules below and commenting out the lines above in the configure script, the configure script should run and do it’s thing without error.

File::Tail
IO::Socket


After the configuration script has run, you should have a couple new files, /etc/breakinguard.conf and /etc/rc.d/breakinguard. Now, the /etc/breakinguard.conf file stores the breakinguard configuration. This is where you tell breakinguard which log file to monitor and how many incorrect login attempts are defined as a breakin.

I’m not going to bother going through all the options in breakinguard.conf, simply because they’re all explained pretty well within the conf file.

The other “new file”, /etc/rc.d/breakinguard is the script used to launch breakinguard. Run “/etc/rc.d/breakinguard start” to start breakinguard.

Once breakinguard is running, it will monitor whichever log file you specified in /etc/breakinguard.conf (/var/log/messages in my case). When it sees a failed login attempt, it will be noted. Now, when an IP fails a certain number of logins, iptables will be called to block all traffic from the IP.

Below is an example email that’s generated by Breakinguard when it blocks an IP:

BreakinGuard has blocked an IP based on suspicious activity
Please review this server.

Detail:
Hostname: elixer.hostname
IP Blocked: 202.82.16.180
Last log entry that caused the block:
Aug 22 06:17:05 elixer sshd[25591]: Failed password for invalid user alias from 202.82.16.180 port 45340 ssh2

Restoring a Hacked Linux Server

This is a great post at MDLog. Marius goes into great detail on how you should respond when you know a linux server has been compromised.

It’s an interesting read if you’ve ever had the opportunity to be the administrator of a linux server. Probably interesting if you haven’t had that opportunity. None of my systems have ever been hacked, and I admin about 5 linux servers both at home and work. I’ve always sort of had a plan of attack though in the event it did happen. And, I’m happy to say, it would look very similar to Marius’s post.