sshd brute force attempts?

Erik Norgaard norgaard at locolomo.org
Wed Sep 20 08:25:03 PDT 2006


Elijah Savage wrote:
> Joao Barros wrote:
>> I'm using BruteForceBlocker quite successfully.
>> I take the opportunity to thank danger for it :-)
>>
>> http://www.freshports.org/security/bruteforceblocker/
>>
> I use /usr/ports/security/denyhost
> 
> It was very easy to install and setup the config file is commented so 
> well and has so many different parameters. I get reports like this 
> anytime my thresholds are crossed.

Both seem to do the same thing, react to failed attempts by maintaining 
statistics of offending hosts. But this is a loosing game, it assumes a 
default permit policy - you might wish to read Ranum's "The Six Dumbest 
Ideas in Computer Security":

   http://www.ranum.com/security/computer_security/index.html

So, great you block an ip from some offending host - after it stopped. 
And if the same host comes back then it will likely have a different ip. 
Nothing gained.

Taking the consequences, employ a default deny policy. Then allow what 
you can trust.

1) As I wrote elsewhere, almost everyone can block out the large part of 
the Internet. Allow only the countries that you know your users are 
likely to visit, a filter is here

   http://www.daemonsecurity.com/pub/src/tools/cc-cidr.pl

Ofcourse, this won't be perfect, there are also compromised machines in 
good countries. When you see the remaining attacks, don't just block the 
ip but the whole network as registered with whois. whois.cyberabuse.org 
produces output that can easily be scripted.

You can be more restrictive and enforce stronger authentication, and it 
is very simple to implement:

2) Do you trust any system? Packet filter includes passive OS 
fingerprinting that allows you to block untrusted systems. Why allow 
your users to login from depreciated Windows 95/98/ME hosts?

3) Disable shell access, or at least ssh access, for common system users.

4) Enforce strong passwords or switch to ssh-keys.

Finally: Relax!

Yes, there are some entries in your log, but evidently no one got in, so 
why care? There are tons of cracking attempts in your apache log files, 
there are tons of relaying attempts in your maillog.

All these attempts consume bandwidth and diskspace as the connection is 
attempted and logged. But if this does not interrupt your service there 
is really no need to worry about it.

Blocking failed login attempts does not make your system safer - the 
attempt failed! The log will just be in your firewall log.

In the vast majority of cases, these are scripted attacks and are 
defeated by simple means such as those described above.

You will be wasting your time trying to block individual hosts as events 
occur. Meanwhile other problems do not get your attention, spam is much 
more difficult to handle and a much greater problem than failed ssh 
attempts.

Cheers, Erik

-- 
Ph: +34.666334818                      web: http://www.locolomo.org
X.509 Certificate: http://www.locolomo.org/crt/8D03551FFCE04F0C.crt
Key ID: 69:79:B8:2C:E3:8F:E7:BE:5D:C3:C3:B1:74:62:B8:3F:9F:1F:69:B9


More information about the freebsd-questions mailing list