Re: SSH Brute force attacks

["Taylor, Grant" <gtaylor@riverviewtech.net>]

First I'd like to apologize for taking so long to bet back to you.

> Hi Grant, and list
> 
> I have done as advised hope this helps.
> 
> A big thanks to all for enduring me on this list for this thread, I can 
> only imagine how im making a nuisance of my self to all.
> My apologies for this.

You are welcome.  There is no need to apologize for asking for help.  This is what this list is for.  :)

> # Generated by iptables-save v1.2.9 on Thu May 26 11:35:50 2005

<snip>

> *filter
> :INPUT DROP [0:0]
> :FORWARD DROP [0:0]
> :OUTPUT DROP [0:0]
> :SSH_Brute_Force - [0:0]
> -A INPUT -i lo -j ACCEPT
> -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
> -A INPUT -m state --state INVALID -j LOG --log-prefix "INVALID input: " 
> --log-tcp-options --log-ip-options
> -A INPUT -m state --state INVALID -j DROP
> -A INPUT -p tcp -m tcp --dport 113 -j REJECT --reject-with 
> icmp-host-unreachable
> -A INPUT -d 217.199.186.255 -j DROP
> -A INPUT -p tcp -m tcp --dport 80 -m state --state NEW -j ACCEPT
> -A INPUT -p tcp -m tcp --dport 20 -m state --state NEW -j ACCEPT
> -A INPUT -p tcp -m tcp --dport 21 -m state --state NEW -j ACCEPT
> -A INPUT -p tcp -m tcp --dport 25 -m state --state NEW -j ACCEPT
> -A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -m recent --set 
> --name SSH --rsource -j SSH_Brute_Force
> -A INPUT -p tcp -m tcp --dport 10000 -m state --state NEW -j ACCEPT
> -A INPUT -p tcp -m tcp --dport 135 -j DROP
> -A INPUT -p tcp -m tcp --dport 113 -j REJECT --reject-with 
> icmp-host-unreachable
> -A INPUT -p icmp -m icmp --icmp-type 4 -j ACCEPT
> -A INPUT -p icmp -m icmp --icmp-type 12 -j ACCEPT
> -A INPUT -p icmp -m icmp --icmp-type 3 -j ACCEPT
> -A INPUT -p icmp -m icmp --icmp-type 11 -j ACCEPT
> -A INPUT -p icmp -m icmp ! --icmp-type 8 -j LOG
> -A INPUT -j LOG --log-prefix "[INPUT  DROP]: " --log-tcp-options 
> --log-ip-options
> -A INPUT -j DROP
> -A OUTPUT -o lo -j ACCEPT
> -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
> -A OUTPUT -m state --state INVALID -j LOG --log-prefix "INVALID output: 
> " --log-tcp-options --log-ip-options
> -A OUTPUT -m state --state INVALID -j DROP
> -A OUTPUT -m state --state NEW -j ACCEPT
> -A OUTPUT -j LOG --log-prefix "[OUTPUT DROP]: " --log-tcp-options 
> --log-ip-options
> -A OUTPUT -j DROP
> -A SSH_Brute_Force -s 196.36.10.114 -j RETURN
> -A SSH_Brute_Force -m recent ! --rcheck --seconds 60 --hitcount 3 --name 
> SSH --rsource -j RETURN
> -A SSH_Brute_Force -j LOG --log-prefix "SSH Brute Force Attempt:  "
> -A SSH_Brute_Force -p tcp -j DROP
> COMMIT
> # Completed on Thu May 26 11:35:50 2005

I thin I have found your problem.  In short the problem is that you are using the suggested "RETURN" target which is not quite right for your environment.  From the logs that you (previously) posted:

> May 25 06:21:51 ns kernel: [INPUT  DROP]: IN=eth0 OUT= MAC=00:0c:76:5e:d3:61:00:d0:02:eb:84:0a:08:00 SRC=165.146.144.131 DST=217.199.186.118 LEN=48 TOS=0x00 PREC=0x00 TTL=115 ID=40576 DF PROTO=TCP SPT=30066 DPT=22 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (0204055001010402)
> May 25 06:21:54 ns kernel: [INPUT  DROP]: IN=eth0 OUT= MAC=00:0c:76:5e:d3:61:00:d0:02:eb:84:0a:08:00 SRC=165.146.144.131 DST=217.199.186.118 LEN=48 TOS=0x00 PREC=0x00 TTL=115 ID=40578 DF PROTO=TCP SPT=30066 DPT=22 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (0204055001010402)
> May 25 06:22:00 ns kernel: SSH Brute Force Attempt:  IN=eth0 OUT= MAC=00:0c:76:5e:d3:61:00:d0:02:eb:84:0a:08:00 SRC=165.146.144.131 DST=217.199.186.118 LEN=48 TOS=0x00 PREC=0x00 TTL=115 ID=40585 DF PROTO=TCP SPT=30066 DPT=22 WINDOW=65535 RES=0x00 SYN URGP=0 

The first two LOG & DROPs are from the default LOG and DROP of your INPUT chain.  For the packet to make it to this point in your input chain the packet had to traverse the SSH_Brute_Force chain where the source address was set in the SSH recent list.  Seeing as how the source address has not been seen 3 times via the recent match extension and thus qualify for a RETURN to the input chain it is thus LOGed and DROPed by the default LOG and DROP targets of your input chain.  Upon the third packet coming in to your firewall the packet will traverse the SSH_Brute_Force chain and no match the (inverse) "--hitcount 3" recent check and thus not get RETURNED to the input chain and subsequently get LOGed and DROPed by the SSH_Brute_Force chain.  This explains the three log entries with the staggered times and the different log prefix based on where they are getting dropped.  As such I think the s
 olution to your particular situation is to use a target of ACCEPT, not RETURN on your 2nd 
SSH_Brute_Force rule that matches the "--hitcount 3".

Give that a try and let me know if that works for you please.



Grant. . . .