Re: Stopping SSH dictionary attacks?

[Adriaan <adriaan312_(_at_)_hccnet_(_dot_)_nl>]

On Tue, 21 Dec 2004, Chris Weiss wrote:

> So I notice in my authlog that someone's been hitting my SSH daemon with 
> a 'dictionary' username attack from multiple IPs. It's not really 
> causing too much trouble (I've only got one name in the AllowUsers 
> config option), but I sure would like to put a stop to it.
> 
> I was really hoping that the SSHD had some sort of timeout for 
> authorization failures that would cause the daemon to reject any further 
> attempts from a failed IP for x minutes after x failed attempts, but 
> there doesn't seem to be that facility - am I missing something?
> 
> The box with the SSH Daemon is behind an IPCop firewall that 
> port-forwards the SSH port.

I have something similar. An ADSL router redirecting ssh to the OBSD 
firewall box.

> 
> One solution I'm considering is writing a script that parses authlog 
> every hour or so and adds any IPs with more than x failed login attempts 
> to ipcop/etc/hosts_deny, am I on the right track with this (has someone 
> already done it - I'm a big fan of not re-inventing the wheel)?
> 

Those boxes performing those login attempts are probably Linux boxes. The
following rule, as recently suggested on this list member blocks these
attacks at the initial SYN packet.

@1 block drop log quick on xl0 proto tcp from any os "Linux" to any port = 
ssh

A snip from my "/var/log/pflog" file :

tcpdump -tttenr /var/log/pflog | grep '1/0' | sed -e 
's#\(^.*\) S .*$#\1#' | less

Dec 19 10:09:02.724564 rule 1/0(match): block in on xl0: 
63.105.206.197.48307 > 10.0.0.200.22:
Dec 19 10:09:05.725236 rule 1/0(match): block in on xl0: 
63.105.206.197.48307 > 10.0.0.200.22:
Dec 19 10:09:11.725595 rule 1/0(match): block in on xl0: 
63.105.206.197.48307 > 10.0.0.200.22:
Dec 19 20:47:43.946526 rule 1/0(match): block in on xl0: 
140.115.55.180.34240 > 10.0.0.200.22:
Dec 19 20:47:46.942509 rule 1/0(match): block in on xl0: 
140.115.55.180.34240 > 10.0.0.200.22:
Dec 19 20:47:52.942630 rule 1/0(match): block in on xl0: 
140.115.55.180.34240 > 10.0.0.200.22:
Dec 19 21:05:44.262903 rule 1/0(match): block in on xl0: 
61.97.192.99.44092 > 10.0.0.200.22:
Dec 19 21:05:47.260656 rule 1/0(match): block in on xl0: 
61.97.192.99.44092 > 10.0.0.200.22:
Dec 19 21:05:47.683973 rule 1/0(match): block in on xl0: 
67.19.188.98.53248 > 10.0.0.200.22:
Dec 19 21:05:50.663302 rule 1/0(match): block in on xl0: 
67.19.188.98.53248 > 10.0.0.200.22:
Dec 19 21:05:53.260985 rule 1/0(match): block in on xl0: 
61.97.192.99.44092 > 10.0.0.200.22:


The boxes allowing a telnet login, make themselves known as Linux 
boxes.

telnet 63.105.206.197
Trying 63.105.206.197...
Connected to 63.105.206.197.
Escape character is '^]'.
Red Hat Linux release 7.2 (Enigma)
Kernel 2.4.7-10smp on an i686
login:


telnet 140.115.55.180
Trying 140.115.55.180...
Connected to 140.115.55.180.
Escape character is '^]'.

    colloid180 (Linux release 2.4.20-8smp #1 SMP Thu Mar 13 16:43:01 EST 
2003) (0)

login: 


Normally I don't allow ssh in, I just doing it for a 3 weeks, when my 
collegue was on the road. 
The OS check can be circumvented by a determined cracker, but at the 
moment it is working for me.


=Adriaan=