SSH breakin attempts fixed by fail2ban
Feb 24 20:15:38 fukamachi sshd[6191]: Failed password for illegal user marianne from ::ffff:62.75.250.138 port 53821 ssh2
Feb 24 20:15:39 fukamachi sshd[6193]: Illegal user marit from ::ffff:62.75.250.138
Feb 24 20:15:39 fukamachi sshd[6193]: error: Could not get shadow information for NOUSER
Feb 24 20:15:40 fukamachi sshd[6193]: Failed password for illegal user marit from ::ffff:62.75.250.138 port 53893 ssh2
Feb 24 20:15:41 fukamachi sshd[6195]: Illegal user marlene from ::ffff:62.75.250.138
Feb 24 20:15:41 fukamachi sshd[6195]: error: Could not get shadow information for NOUSER
Feb 24 20:15:41 fukamachi sshd[6195]: Failed password for illegal user marlene from ::ffff:62.75.250.138 port 53966 ssh2
Feb 24 20:15:43 fukamachi sshd[6197]: Illegal user marliese from ::ffff:62.75.250.138
Feb 24 20:15:43 fukamachi sshd[6197]: error: Could not get shadow information for NOUSER
I get literally thousands upon thousands of these every single day. My passwords are pretty good but hell, I don’t like seeing it. Must add up in bandwidth too, after a while.
Solution:
# wget ftp://ftp.debian.org/debian/pool/main/f/fail2ban/fail2ban_0.6.0-5_all.deb
# dpkg -i fail2ban_0.6.0-2_all.deb
Set the number of failed attempts to 5 (up from 2, like in the package’s name), just to give myself some breathing space. After that, the IP is blocked at the firewall level for 60 minutes. Sounds fair.
Instant drop by 99.99% in SSH attempts. Great package! Recommended.
PS. I reverse-dnsed a lot of the IPs attempting breakins, just to see where they were from. I expected lawless countries like China or Russia, but surprisingly the vast majority were from inside the USA. Number one offender was in Chicago, with over 10,000 attempts in a single day! Since it is without a doubt illegal to run automated cracking scripts like that in America, that was an interesting discovery.
February 28th, 2006 at 1:56 pm
The attacks might be coming from dumb script kiddies in the USA, but it’s probably more likely that they’re coming from compromised zombie machines. I too see a lot of these failed attempts (sometimes almost none, but often several hundred; my record to date is 1,500 in a single day) and have been thinking about doing something. Here’s another alternative:
http://www.howtoforge.com/preventing_ssh_dictionary_attacks_with_denyhosts
Still not sure which solution I like best. Would like to find something as light-weight as possible.
February 28th, 2006 at 2:01 pm
Yeah, I was evaluating those two. Fail2ban won because it’s basically zero-conf. The only reason I didn’t go with apt-get is because it’s still testing/unstable for debian and i didn’t want to screw with my sources, so i did a semi-manual install.
Fail2ban is a much simpler install than denyhosts, but they’re both python-based apps which check your auth logs. I guess only time will tell which one actually is superior; i’ll certainly be keeping a close eye on f2b and will let you know how it goes.
Next: email! sigh! it just never ends does it ..
PS spot on about the dumb script kiddies. I actually did some research for one of them, followed the IP back and found an unconfigured VPS just sitting there. Evidently a customer had ordered it, and hadn’t fucking set it up, it was sitting there with a default password (very bad practise for the provider, i know). Our script kiddy evidently discovered this, made himself an account or 10 and set them going.
I emailed the provider and let them know but jesus, how stupid can people be. Why not just leave your new car overnight in the deal lot with the doors unlocked and the key in the ignition while you’re at it. And the worst thing is that this hijacked server has probably done hundreds of millions of these login attempts by now, probably thousands of servers, and not only are there not going to be serious consequences for the owner’s negligence, he’s probably too fucking stupid to know what the consequences of his actions are anyway! Argh!
February 28th, 2006 at 2:52 pm
I don’t think I’ll be trying either of these as I see fail2ban “requires” Python 2.4 or above, and DenyHosts “requires” 2.3… My server only has 2.2 on it and when it comes to that kind of thing I adopt an “if it ain’t broke don’t fix it” policy. Basically, I trust RedHat to only supply security related patches and don’t expect to see a Python update pushed down any time soon.
I think the likelihood of a break-in is fairly low, in any case. Most of the attacks fall into two categories: (1) non-existent accounts which will by definition never work; (2) accounts which exist (eg. “mail” and “news” etc) but which have their shell set to “/bin/nologin” (again, by definition will never work).
This leaves two possible categories: (1) attacking the root account (will never work if you have PermitRootLogin set to “no” in your sshd_config, and of course I do); and (2) attacking existing accounts.
This latter category is a very slim target indeed. The attacker first has to guess the account name, and if he succeeds (unlikely) he must then guess the password (even less likely; I use strong, machine-generated passwords). Finally if he does guess the password then he’ll find himself in a chroot jail limited to the home directory of the user in question (thanks to rssh). The worst he can do is delete some files in the home directory using a SFTP client; he doesn’t even get shell access.
This leaves only two accounts on my system which actually have shell access. I’ve never seen even a single attack on those accounts. The chance of the attacker guessing the password is no better than 1 in 218,340,105,584,896, so basically, I think things are fairly safe.
March 16th, 2006 at 1:03 am
I’ve done a bit more searching on this and this is currently the solution that appears most attractive:
http://www.csc.liv.ac.uk/~greg/sshdfilter/
Rather than periodically scanning log files (yuck) it continuously monitors sshd’s standard output. It can therefore block attacks more quickly and using less resources.