Thwarting Distributed SSH Brute Force Attempts
02 March, 2008
The SANS Internet Storm Center has an interesting
diary entry that discusses a set
of distributed brute force attempts against SSHD originating from a specific Class C subnet
58.147.10.0/24. According to the diary entry, a random selection of IP addresses
within this subnet (which is owned by an organization in Thailand) are probing for
listening SSH daemons on the open Internet, but each IP address is limiting the number of
probes to two. Presumably this is to fly beneath the radar of any threshold-based
detection mechanisms that might automatically block the attempts to communicate with SSHD.After rummaging around in my iptables logfiles, I noticed the following two log entries that show exactly two SYN packets from the IP 58.147.10.209 and destined for one of my systems:
Jun 3 14:55:06 minastirith kernel: DROP IN=eth0 OUT= MAC=00:13:d3:38:b6:e4:00:90:1a:a0:1c:ec:08:00
SRC=58.147.10.209 DST=71.N.N.N LEN=60 TOS=0x00 PREC=0x00 TTL=44 ID=11651 DF PROTO=TCP
SPT=57473 DPT=22 WINDOW=5840 RES=0x00 SYN URGP=0 OPT (020405780402080A7CCF5BC50000000001030302)
Jun 3 14:55:09 minastirith kernel: DROP IN=eth0 OUT=
MAC=00:13:d3:38:b6:e4:00:90:1a:a0:1c:ec:08:00 SRC=58.147.10.209 DST=71.N.N.N LEN=60 TOS=0x00
PREC=0x00 TTL=44 ID=11653 DF PROTO=TCP SPT=57473 DPT=22 WINDOW=5840 RES=0x00 SYN URGP=0
OPT (020405780402080A7CCF677D0000000001030302)
These two packets date back to June of last year, so the 58.147.10.0/24 network has
apparently been active for quite some time. So, beyond the whois information
mentioned in the ISC diary entry, can we tell anything more about our friend at
58.147.10.209? Because I always use the --log-tcp-options command line argument
when building my iptables LOG rules, we have nice hex dumps included in the log messages
above that represent the options portion of the TCP header. Having this information is
necessary in order to passively fingerprint the remote TCP stack with
p0f. The psad
project re-implements the p0f algorithm over iptables log messages - p0f requires raw
packet data acquired via libpcap - so what does psad have to say about the remote TCP
stack?
[minastirith]# psad -A -m /var/log/messages --restrict-ip 58.147.10.209
[+] p0f(): 58.147.10.209 len: 60, frag_bit: 1, ttl: 44, win: 5840
[+] MSS: 1400, SACK, Timestamp: 2093964229, NOP, Win Scale: 2,
Could not match 58.147.10.209 against any p0f signature.
Oh well, that is unfortunate. So, p0f does not seem to have a fingerprint that can
characterize the remote TCP stack. I also looked through the passive OS fingerprinting
database included with the ettercap project,
but no luck there either. This was a manual process though because psad does not yet
support the format of the fingerprints in ettercap, but this will be supported in the
next release.In the meantime, the discussion in the diary entry advocates limiting the set of IP addresses that are allowed to talk to the SSH daemon, but ends with a comment stating that this is not always possible. I agree with this comment, and this is highlighted whenever you administer a system and you need access to SSHD from unpredictable source addresses (such as when travel is involved). A robust solution is to deploy Single Packet Authorization with a default-drop packet filter. Why let arbitrary source IP addresses communicate with your SSH daemon?
