SUMMARY: sshd password-guessing attacks

Tom Yates <[email protected]> Fri, 8 Apr 2005 11:05:42 +0100 (BST)
Newsgroups gmane.linux.admin.managers
Message-ID <[email protected]>
On Tue, 5 Apr 2005, Tom Yates wrote:

> Bjorn Tore Sund has an elegant solution using the "recent" modules in
> iptables.  This module does appear to be in my kernel (2.4.29), so I'm in
> the process of recompiling and, if this works, I will post code fragments
> after testing.

it proved necessary to update my kernel (2.4.29 has 'recent', but i wasn't 
compiling it, so i went the whole hog and upgraded to 2.4.30 as well as 
turning on the module), and iptables (1.2.8 doesn't have the hooks for 
'recent'; there is evidence that later versions of 1.2 do, but i just 
went to 1.3.1 on a general principle of "oooh, shiny!").

i now have the following rules in place:

IPT=/usr/local/iptables/sbin/iptables
# [many lines later]
$IPT -A INPUT -p tcp --syn --dport 22 -m recent --name sshattack --set
$IPT -A INPUT -p tcp --dport 22 --syn -m recent --name sshattack \
  --rcheck --seconds 60 --hitcount 3 -j LOG --log-prefix 'SSH REJECT: '
$IPT -A INPUT -p tcp --dport 22 --syn -m recent --name sshattack \
  --rcheck --seconds 60 --hitcount 3 -j REJECT --reject-with tcp-reset

which means that, if in a rolling 60-second window, two SYNs have been 
received on port 22 from a particular IP address, the third and subsequent 
SYNs are rejected with a tcp reset.  after an amusing incident during 
testing where i shut down all my ssh sessions to the box (fortunately, i 
was testing on a local machine), i decided only to reject further SYNs, so 
existing sessions are not dropped, even from a host which triggers the 
trap.  note that these rules will need to come *before* any blanket permit 
to port 22.

it's been very effective so far.  logwatch no longer reports lengthy 
fishing expeditions, but none of my users has reported any problems. 
examination of the kernel logfiles suggests that some fishing tools 
sputter to a halt, continuing to produce streams of SYN requests for five 
or ten seconds after being slapped down, whereas others get a single 
refusal and bugger off.

i post this as it may be of particular use to people running distros later 
than mine, for which no recompilation may be necessary.  thanks again to 
all, especially bjorn.


-- 

   Tom Yates
   http://www.teaparty.net
_______________________________________________
LinuxManagers mailing list - http://www.linuxmanagers.org
submissions: LinuxManagers-35TzE1X9F6582KRnZfj+bdi2O/[email protected]
subscribe/unsubscribe: http://www.linuxmanagers.org/mailman/listinfo/linuxmanagers