Coping With 1 Million SSH Authentication Failures? 497
An anonymous reader writes "I own a small Web development studio that specializes in open source software, primarily Drupal, WordPress, and Joomla for small businesses. Our production servers, which host about 50 sites and generate ~20K hits/week, are managed by a 3rd party that I'm sure many on Slashdot would recognize. Earlier today I was researching some problems on one of our sites and found that there have been over 1 million SSH authentication failures from ~1200 IP addresses on one of our servers over the last year. I contacted the ISP, who had promised me that server security would be actively managed, and their recommendation was, 'change the SSH port!' Of course this makes sense and may help to an extent, but it still doesn't solve the problem I'm facing: how do you manage server security on a tight budget with literally no system admin (except for me and I know I'm a n00b)? User passwords are randomly generated, we use a non-standard SSH port, and do not use any unencrypted services such as FTP. Is there a server monitoring program you would recommend? Is there an ISP or Web-based service that specializes in this?"
So? (Score:5, Interesting)
If you really have secure passwords, the random guessers aren't going to get them. Log it and move on.
I get thousands of Chinese hackers attempting to break into the battery monitor in my tool shed, big deal. I don't know why my battery voltage and solar current is so important to them, but they can knock themselves out all day.
If the logs bother you then install fail2ban and configure it to lock people out after a few bad guesses. (Then be ready to unlock yourself from an alternate IP when you inevitably lock yourself out.)
Re:Tar Pitting (Score:5, Interesting)
I use a variation on tarpitting that has worked very well for me.
It cut the attempts down from 60,000/day to 20 or 30 per day.
I just add a small delay between the initial connection attempt
and when I send the username/password prompt. The delay (in
seconds) is the number of attempts in the last 30 minutes,
squared. This makes all but the most determined attacker
give up and go away very quickly.
I have been using this with both FTP and SSH for the last
year, and it works great.
pam_abl (Score:3, Interesting)
http://lmgtfy.com/?q=pam_abl [lmgtfy.com]
Share and enjoy!
I don't understand the problem (Score:3, Interesting)
So there have been a million failed attempts to log in over SSH in a year. That's about one failed attempt every 30 seconds.
What's wrong with that? It's not like they're getting in, right?
Re:Tar Pitting (Score:4, Interesting)
Re:Exactly (Score:2, Interesting)
But a million cars haven't driven past. Only ~1200 --- in the past year. This is no big deal. Hell, I start thinking something is wrong when I DON'T see many failed SSH attempts in the daily log reports.
Re:Passwords? (Score:4, Interesting)
Re:Move to a higher order port and use denyhosts (Score:3, Interesting)
Changing the port might be troublesome if you're trying to SSH from public locations like airports and such. They usually leave port 22, 443 and 8080 open for their own services and block all others, so you will have to either set up VPN to get into your servers or wait until you're elsewhere. Additionally, an evenly-slightly determined hacker can still find where your sshd process is listening on by running a basic nmap scan.
Key exchange and disabling root login is probably the best way to go. Fail2ban worked really well when my server had a Linux distro on it.
Re:So? (Score:3, Interesting)
Re:fail2ban (Score:4, Interesting)
Nobody's going to guess a 2048-bit RSA key.
No but they can steal if from your users' computers. It's one thing to have staff use keys when they are on your secure network but having users who are out on the web using keys when you can't control the security on their machines is only as secure as your dumbest client. Of course if they can hack and steal keys, they can probably steal passwords as well. For remote access one of the securest ways is using a security token. Every time user logs in they have to enter a different number.
Re:Change ports (Score:3, Interesting)
I actually go one step further: after IPv6-enabling my site, I only allow v6 ssh inbound. Since Teredo makes it possible to get v6 from nearly anywhere, it doesn't cause any inconvenience, and ssh attacks have basically vanished. 'course, it won't last forever, but it works great right now.
Re:fail2ban (Score:3, Interesting)
Nobody's going to guess a 2048-bit RSA key.
http://ftp.de.debian.org/debian/pool/main/o/openssh-blacklist/openssh-blacklist_0.4.1.tar.gz [debian.org]
If the 2048 RSA key is one of these they probably will, get it, especially if they have a million chances.
Re:fail2ban (Score:3, Interesting)
Re:Tar Pitting (Score:4, Interesting)
But what happens if you call scp from a number of scripts in parallel? You will get banned?
The problem is that you want to act only on the failed login attempts.
Re:fail2ban (Score:3, Interesting)
"Because stealing RSA/DSA SSH keys is so much more common than dictionary/brute attacks..."
You seem to forget that if you are seeing those attack levels is because of user computers already rooted, so anything on the client's side it's already at the attacker disposal. What do you prefer? Seeing thousands of failed login attempts in your logs or not seeing anything because the attack succeded by taking control of the ssh keys on the client's machine?
Re:fail2ban (Score:3, Interesting)
The best authentication relies on two factors, what you have and what you know.
A rooted client gives the attacker access to at least one part of that.
A separate physical RSA token is probably the only thing to prevent that, since they work without being attached to the authenticating system and even full scale keylogging monitored by a squad of hackers in rotating shifts will not really suffice.