Dense Distributed SSH bruteforce attempts

Published: 2008-02-29. Last Updated: 2008-02-29 22:58:44 UTC
by donald smith (Version: 2)
4 comment(s)

A contributor (Ben) wrote in with an unusually dense distributed ssh scan.

“We noticed an interesting ssh probe attempt today.
In order to prevent iptables blocking based on the number of probes per
minute, each address in an entire Class C block generated only one or
two probes SSH each. These probes all came from 58.147.10.0/24”

Based on the information Ben shared with us it appeared to come from
most of the ips in a /24 cidr block. The last octet is fairly random.
There is some clustering such as a "run" of 200's but that could still
be psuedo random. So who owns that cidr block?

Whois data copyright terms http://www.apnic.net/db/dbcopyright.html
inetnum: 58.147.0.0 -58.147.127.255
netname: TTTNET
descr: Maxnet, Internet Service Provider, Bangkok
descr: under management by TT&T co,.ltd Thailand
country: TH
<SNIP>
e-mail: noc@tttmaxnet.com
address: 252/30 Muang Thai Phatra Complex Tower 1, 22nd Fl., Ratchadaphisek
Rd.,Huaykwang, Bangkok 10320 Thailand
phone: +66-2-693-2100
fax-no: +66-2-693-2100
country: TH
changed: wichaip@ttt.co.th 20060410
mnt-by: MAINT-NEW
source: APNIC

 Traceroute shows them near singapore so Thailand is reasonable.

Tracing route to mx-ll-58.147.10-115.tttmaxnet.com [58.147.10.115]
over a maximum of 30 hops:
1 2 ms 1 ms 1 ms 192.168.0.1
<SNIP>
13 332 ms 334 ms 336 ms ix-2-1-1.core1.S9R-Singapore.Teleglobe.net [209.58.82.26]
14 353 ms 356 ms 512 ms mx-ll-58.147.0-45.tttmaxnet.com [58.147.0.45]
15 393 ms 368 ms 334 ms mx-ll-58.147.0-61.tttmaxnet.com [58.147.0.61]
16 337 ms 339 ms 339 ms mx-ll-58.147.0-85.tttmaxnet.com [58.147.0.85]
17 341 ms 340 ms 338 ms mx-ll-58.147.0-21.tttmaxnet.com [58.147.0.21]
18 mx-ll-58.147.4-118.tttmaxnet.com [58.147.4.118] reports: Destination host
unreachable. 
I seem to be the handler who gets the distributed ssh scan reports.
I wrote a diary about a some seen last year that appeared to be
distributed and coordinated (share a dictionary across multiple hosts)
http://isc.incidents.org/diary.html?storyid=3529

Jim Owens and  Jeanna Matthews of Clarkson Univ. reported on a similar,
though somewhat cruder attack in a paper they recently submitted to Usenix LEET '08.

http://people.clarkson.edu/~owensjp/pubs/leet08.pdf

Keywords:
4 comment(s)

Comments

The trend within my logs is that a scan from a particular IP stops after two tries. I attributed this to the fact that I only allow SSH traffic from trusted IPs anyways (anything else is blocked), and I've changed the daemon port to something non-standard. Reading forums and blogs, the norm is use fail2ban or something similar to block scans. The distributed SSH scan may be a way to circumvent aggressive automated blocking of typical SSH scans. IMO, its not going to matter if the scan is distributed or not...it'll still be blocked if you only allow trusted IPs to use the SSH conduit. This is good info, though, as its apparent that new methods are being developed to combat scripts such as fail2ban.

Ron

Feb 29th 2008
1 decade ago

There are some situations in which you have to allow SSH to everyone. Restricting to trusted IPs is not practical.

Algol

Mar 1st 2008
1 decade ago

Yes, in some cases you have to permit it to everyone, but only in SOME cases. There is never an excuse for a piece of network hardware to reachable via SSH or telnet to the global Internet at large (unless it's a honeypot).

I've started monitoring the syslog output from my network equipment more than I'm watching my server logs. These are the logs that I'm now using to feed my RTBH. I'll null route a source IP with one hit on any of my network gear without exception. There is no mistaking a SSH attempt on a router.

I'm also watching SSH scans coming into our SP network. I wish there was a tool that could recognize the significance of hundreds and thousands of SSH or telnet queries to as many IPs and alert me or take action for me. I haven't come across such a tool yet though.

Justin

Mar 5th 2008
1 decade ago

I've never seen a case where one HAD to allow SSH globally, at all times. That's the easy way out, IMO. Restricting to trusted IPs is practical in the sense that it is the more secure way of doing things. It may be practical in the sense of giving Joe User the loosest access to the network, though. Being a SOC analyst, that's not my focus and I usually attempt to convince (I've never been unsuccessful in this) a customer otherwise.

Ron

Mar 7th 2008
1 decade ago

Login here to join the discussion.


Top of page
Diary Archives