SSH scanning changes to a more distributed (coordinated?) model.

Published: 2007-10-22
Last Updated: 2007-10-22 19:17:15 UTC
by donald smith (Version: 2)
0 comment(s)

We have seen reports in the past where a single victim was attacked by multiple source IP addresses in an ssh bruteforce attempt but usually it has been a single or at most a few source IP addresses.
Today we had 4 separate reports of an increase in ssh bruteforce attacks. Two of those reports stated that they were seeing lots of source hosts against a single victim. The isc.sans.org port 22 graph supports this as there has been a large increase in the source hosts seen in ssh scans during this month. If you can verify that this is a distributed, coordinated attack as some of us suspect that would be helpful. The type of coordination I would expect in this case is different systems using different account/password pairs.

“Almost every hour logcheck is emailing me about failed SSH logins. In the past the failed logins usually came from just one host at a time. fail2ban on my server would take care of this and I wouldn't worry. But now I'm seeing multiple servers all trying within minutes of each other and they'll only try a few times so fail2ban isn't working very effectively. It only appears to be for user "root" and "mysql".” (David)

“We're seeing unusually high inbound SSH scanning across our networks. The activity showed up on our radar 10/21 around 18:30 CDT (23:30 GMT). Some of the reverse lookups on scanning hosts suggest that these systems are compromised themselves (e.g. nagios.blah.tld or mail.blah.tld); many reverse lookups do not suggest this... At first blush, it appears that the majority of these remote scanners are in Europe or Eastern Europe.” (Bert)

“I see 2 or three ssh attempts in a day, and
suddenly I'm seeing one about every 3 minutes start almost an hour ago.
(reported around 6am MDT).
Anyone else seeing this stuff? Thanks.
“ (James)


UPDATE Coordination appears to be verified:

"What was more interesting than the distributed of the scans was that each host appeared to scan a different part of the dictionary. Normally we give them 11 tries and then iptables locks them out. When I looked at last week's log summary I was surprised to find several groups of 11 login name attempts which clearly began in different parts of the alphabet.  This looks like an attempt to bypass the limited number of probes from any one host which most good firewall programs impose." (Ben)


From the ascii version of dshields port listing
We can see reported sources of ssh attacks have been climbing fairly steady with the highest number of sources reported occurring yesterday. Of course today’s data is not complete.

date               records    targets      sources tcpratio
2007-10-01    606506      151949    875    100
2007-10-02    1317888    88940        882    100
2007-10-03    828467      112525    881    100
2007-10-04    1344606    53047        843    100
2007-10-05    541713     107031    873    100
2007-10-06    346431    92291        797    100
2007-10-07    282205    47498        848    100
2007-10-08    756005    130631    887    100
2007-10-09    915582    53250        868    100
2007-10-10    321079    85194        860    100
2007-10-11    608362    125370    837    100
2007-10-12    225450    87848        772    100
2007-10-13    147506    60599        829    100
2007-10-14    380275    148700    909    100
2007-10-15    749183    319528    930    100
2007-10-16    1558853    1027756    896    100
2007-10-17    1879869    1564587    901    100
2007-10-18    195446    56762        929    100
2007-10-19    139687    50711        932    100
2007-10-20    249887    96917        933    100
2007-10-21    542479    104323    1012    100
2007-10-22    561213    101314    810    100

I searched for a blocklist that was specific to ssh bruteforce attempts and found this one: http://danger.rulez.sk/projects/bruteforceblocker/blist.php

I am not recommending this black list as I just learned about it and for most of us it would probably be easier to just allow ssh access from the CIDR blocks we expect.

 

Keywords:
0 comment(s)

Comments


Diary Archives