Brute-Force SSH Server Attacks Surge (InformationWeek) [LWN.net]

Brute-Force SSH Server Attacks Surge (InformationWeek)

Posted May 14, 2008 17:23 UTC (Wed) by endecotp (guest, #36428)
In reply to: Brute-Force SSH Server Attacks Surge (InformationWeek) by kssingvo
Parent article: Brute-Force SSH Server Attacks Surge (InformationWeek)

No, don't use fail2ban or denyhosts or any of the similar tools.  They are in the "line of
fire" and any bugs that they contain are security bugs.  This isn't a theoretical problem: see
http://lwn.net/Articles/216217/; denyhosts could be exploited by an attacker to add arbitrary
addresses to its blocklist, including for example the IP addresses of its legitimate users.
That's a serious bug and there could be more.  We want less code in the line-of-fire, not more,
and we want that code to be of the highest quality (as openssh is, except when it has been
hacked around by an incompetent maintainer).  Simple rule: use strong passwords, or disable
password authentication, and don't worry about all of those failure messages in your auth log.

to post comments

Brute-Force SSH Server Attacks Surge (InformationWeek)

Posted May 14, 2008 17:39 UTC (Wed) by rfunk (subscriber, #4054) [Link]

While I agree with your general point, I have two points of 
partial-contention.

Most importantly, if you allow password authentication at all, you need to 
pay attention to failed logins, and take steps to prevent someone from 
eventually getting around to guessing your good password.  (I watch my 
logs and manually block IP addresses that are trying to brute-force their 
way in, but I'm lucky enough not to be getting hit nearly as hard as 
others are.)

Also, I've long disliked fail2ban and similar tools because it's too easy 
for legitimate users to get blocked.  But some variant might be 
appropriate, such as one that notifies the sysadmin and asks for approval 
before blocking.  (Though of course this adds more of the evil complexity 
that you rightly argue against.)

I've toyed with the idea of a system that not just penalizes failed 
logins, but also gives positive points for successful logins, so that it's 
harder for legitimate users to get blocked.  And of course, if blocking 
does happen, it should eventually expire.

fail2bban with knockd & whitelist

Posted May 15, 2008 0:04 UTC (Thu) by AnswerGuy (guest, #1256) [Link]

I use fail2ban with a whitelist on port 22 and port knocking on two additional ports (with a
five port knock for each).

Thus I can be assured that I can still get in even if someone has spoofed failures from some
adress I'm using that's not on my whitelist.

I could just turn off port 22 on that server since I only ever use one of the alternatives.

The advantage of fail2ban or its ilk in this case is to prevent the bandwidth and CPU hit for
repeated brute force ssh attempts.  hiding the alternatives behind a knock sequence is even
more effective since the casual port scanners can't even find the running service.  If I see
brutish failures on one of the alternative ports then I can be certain that someone sniffed my
knock sequnce ... and change it.