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.
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
Well, now what?
Work with Me
I'm available for hire and always taking new clients, big and small. Got a project or an idea you'd like to discuss? Startup plan but no developer to make it happen? Just get in touch, I'd love to see if I can help you out!
Leave some Feedback
Got a question or some updated information releavant to this post? Please, leave a comment! The comments are a great way to get help, I read them all and reply to nearly every comment. Let's talk. 😀
Longren.io is proudly hosted by DigitalOcean
Nice post. I hadn’t heard about breakinguard.
Fail2ban is another great option:
http://fail2ban.sourceforge.net/wiki/index.php/Main_Page
Thanks for the info Canuck! Fail2Ban looks great!! I am probably going to switch my breakinguard box over to Fail2Ban simply because Fail2Ban looks like it still gets regular updates, where breakinguard does not.
Many thanks for the link!
Looks good. I’m using a program called authfail that does the same thing, and it’s also written in PERL.
A complementary approach is configure sshd to require crytographic keys instead of passwords. No amount of brute force would suffice to guess a key. Properly set up, this approach is actually more convenient (IMO) than passwords. The setup is nicely explained at Setting up ssh
From October 2005 until May 2006 I was at Georgetown University and had a
machine which was online 24/7 with the same IP. I also noticed SSH attacks,
and wrote a small script to get an overview of the IPs used by the attacker(s)
and the login names being tryed. Here is a link to my overview:
http://ilan.schnell-web.net/test/ssh.html
Notice that sometimes the same login names are tryed on different day from diffenrt IPs,
so the attacker uses the same script.
Ilan Schnell, I really like that option as it gives an instant look at what IP’s have been attempting to login. Any chance I could get the script you use to generate that page?
I was fed up with ssh brute force attacks, but I didn’t want to install software to automate blocking via iptables (I really think this should be an option in sshd itself). Instead, I’ve configured sshd on *all* of the systems I’m responsible for to listen on a single port that is not port 22. You’d think this would be a hassle, as there are some machines that I don’t have control over that still listen on port 22. Instead of specifying the -p flag when connecting when using ssh clients, I simply added entries to my .ssh/config file so that the hosts listening on other the other port had the Port parameter set properly. This means I can connect to port 22 or the ‘other port’ completely transparently. In one year, I have had ZERO brute force attacks.
I’ve hacked together a similar script myself, that scans the logs and adds ips to iptables on the fly. Although it was a fun project, I have come to the obvious conclusion that it is always better to adopt a deny all by default policy on your firewall and just open it up for ips that
you will be connecting from. The other method, which is brilliant, is called port knocking that involves running a sniffer that listens for a ‘magic’ packet and then opens up port 22(or whatever) as and when.
guys, it’s quite easy to avoid this entirely
yes, you can go about installing scripts to do the job (deny.hosts, bruteforce blocker, sshdfilter, sshdguard) or you can just get rid of password-authentication altogether (My solution.) Use two-form factor authentication (private/public key) exchange instead. use PuttyGen to generate the keys, or ssh-keygen on Unix, and put them in /etc/ssh/sshd_host_dsa_key or $HOME/.ssh/authorized_keys2 (or whatever is specified in /etc/ssh/sshd_config) … this way, brute-force wordlists attempts are thwarted… also, consider changing the default sshd port, from 22 to something high. i chose 12586. third, why not get rid of sshd entirely if you’re the only one administering the server?? you can install webmin instead. Now you can administer your server through a browser GUI.
Yeo
fail2ban do what must to do 🙂