[sf-lug] ssh "attacks" - distributed slow scans - not exactly "news", but for the curious ...
Michael Paoli
Michael.Paoli at cal.berkeley.edu
Sun Nov 30 11:44:04 PST 2008
Over the past few years or more, I've noticed some trends in the basic
ssh "attacks" - ones that essentially try fairly common login names and
weak passwords likely to be used with those login names.
Of course there are the older, common "noisy" attacks, that just try a
fast succession of IDs all from a single IP - these tend to generate
lots of log activity, easily attract attention to themselves, and are
also easy to block in quick order via various automated means.
But what I've seemed to notice in increasing trends, are attacks that
are relatively similar in their name/password approach, but try to be
much more stealthy - to fly under the radar and not trip automated
blocking/alarms. Most notably, trying as little as twice or less from a
single IP, before moving to other IPs, and trying the "attack" much more
slowly.
Anyway, going over some log data, I decided to take a closer look, to
see if my guesses on the attack methodology actually matched reasonably
to the log data - and yes, it does.
This is from my log data - trimmed down to date/time (US/Pacific),
login, and IP, and tossing out any sequence of 3 or more consecutive
attempts from the same IP.
Here we have an older attack, possibly already underway (many typical
"attacks" start earlier than amanda in lexographic sequence, I probably
already tossed out older log data, except for backups):
Nov 19 06:46:26 amanda 208.124.205.234
Nov 19 06:49:25 amanda 148.243.156.138
Nov 19 06:55:44 amanda 69.53.116.164
Nov 19 06:59:03 amanda 201.12.50.2
Nov 19 07:02:02 amanda 81.2.252.20
Nov 19 07:15:14 amanda 189.54.102.228
Nov 19 07:17:40 amanda 72.20.102.20
Nov 19 07:20:52 amanda 82.53.248.40
Nov 19 07:27:16 amanda 71.166.159.177
Nov 19 07:30:18 amavis 71.166.159.177
Nov 19 07:33:35 amavis 62.72.101.154
Nov 19 07:36:37 amavis 75.147.27.85
<256 lines snipped>
Nov 21 07:07:29 vhost 79.188.168.83
Nov 21 07:11:20 web0 200.123.174.145
Nov 21 07:12:01 web 221.4.104.101
Nov 21 07:12:52 webservd 125.77.106.246
Nov 21 07:13:38 work 88.63.75.242
Nov 21 07:15:26 wwwrun 210.196.240.218
Nov 21 07:16:58 zope 200.207.85.162
And wasting little time, likely another "attack" from the same botnet:
Nov 21 07:25:06 adam 212.108.35.16
Nov 21 07:25:40 adam 213.163.19.158
Nov 21 07:26:41 adam 217.128.20.4
Nov 21 07:27:22 adam 64.183.133.194
Nov 21 07:28:14 adam 200.123.174.145
Nov 21 07:29:54 adam 190.60.41.82
Nov 21 07:30:41 adrian 125.77.106.246
Nov 21 07:33:58 adrian 88.199.30.6
Nov 21 07:34:42 adrian 217.76.34.230
Nov 21 07:35:34 alex 61.135.234.7
Nov 21 07:38:07 alex 66.189.40.144
Nov 21 07:38:51 alex 80.240.214.74
Nov 21 07:39:48 alex 200.253.157.34
Nov 21 07:40:37 alex 210.193.36.178
Nov 21 07:41:20 andy 71.63.229.140
<376 lines snipped>
Nov 21 17:11:32 tracy 221.132.77.244
Nov 21 17:12:34 tracy 212.160.157.41
Nov 21 17:14:01 tracy 85.198.121.54
Nov 21 17:14:37 vincent 212.202.242.170
Nov 21 17:15:42 vincent 84.123.175.87
Nov 21 17:18:42 vincent 200.51.40.154
... not quite all the way to "z", ends with the above,
then again, quite shortly thereafter:
Nov 21 17:26:12 ann 211.154.254.120
Nov 21 17:29:21 ann 201.16.168.17
Nov 21 17:31:24 ann 200.21.82.18
Nov 21 17:33:38 ann 82.77.56.131
Nov 21 17:34:40 ann 201.34.125.250
Nov 21 17:36:35 anouk 85.18.102.76
Nov 21 17:37:41 anouk 195.234.169.138
<143 lines snipped>
Nov 21 21:24:48 temporary 193.224.241.4
Nov 21 21:25:49 temporary 24.181.23.242
... then looks like this one perhaps resets, rather than completes,
jumping to:
Nov 21 21:30:05 christelle 82.182.188.187
Nov 21 21:33:20 christelle 200.157.176.13
Nov 21 21:34:24 christelle 59.37.63.151
Nov 21 21:36:25 christelle 71.63.229.140
Nov 21 21:40:35 christiane 208.87.4.7
Nov 21 21:42:43 christiane 194.224.118.61
<238 lines snipped>
Nov 22 08:34:28 marine 65.106.11.222
Nov 22 08:37:08 navy 200.60.156.90
Nov 22 08:39:39 navy 200.29.137.117
Nov 22 08:41:20 navy 211.154.254.120
another reset?
Nov 22 08:43:39 aadi 200.241.63.132
Nov 22 08:44:15 aadi 196.25.224.126
Nov 22 08:44:58 aadi 208.87.4.7
Nov 22 08:45:51 aaliyah 85.18.159.125
Nov 22 08:46:45 aaliyah 85.119.222.69
Nov 22 08:47:38 aaliyah 59.6.185.34
Nov 22 08:50:26 aaralyn 91.135.200.86
<4261 lines snipped>
Nov 30 09:05:08 freya 62.167.4.140
Nov 30 09:06:58 freya 74.95.165.97
Nov 30 09:08:30 freya 210.255.180.14
Nov 30 09:14:11 frieda 201.251.61.108
Nov 30 09:19:32 frigg 213.23.175.198
Nov 30 09:21:29 fritz 58.246.149.46
Nov 30 09:26:53 fritzi 213.163.19.158
Nov 30 09:28:52 fritzi 201.251.61.108
Nov 30 09:30:36 fritzi 85.39.252.226
Nov 30 09:32:26 fruma 200.21.104.66
Last I checked, the above still appears to be underway.
Again, all of the IPs were filtered down to those used no more than twice
in succession. Among them we find 527 distinct IPs, the IP used the
most was used 60 times, runner up, 46 times, ... we find 260 distinct
IPs used 6 or fewer times.
total times each used number of distinct IPs
20 6
19 10
18 4
17 16
16 6
15 10
14 9
13 14
12 18
11 12
10 13
9 14
8 20
7 27
6 14
5 12
4 20
3 53
2 54
1 107
... so, not only are IPs not used more than twice in succession, seems,
unsurprisingly, the attack network has a fairly to rather large battery
of IPs available for use, and to a large extent, doesn't heavily reuse
the same IPs against any single target IP.
Other random commentary :-)
"Of course" good strong passwords always continue to be important - that
typically continues to commonly be one of the first - or last - lines of
defense.
Many of the automated tools to block ssh "attacks" won't manage to block
these stealthier attacks - nevertheless they may still be rather to
quite useful to reduce exposure (and resource consumption and annoyance
factors).
Administrative accounts such as root shouldn't have ssh login enabled,
or if they must, it should be via ssh keys, and with
password/interactive login methods disabled via ssh.
In general, using ssh keys for login, and not passwords - and disabling
password login where feasible, is more secure. Proper key management,
however, remains an important factor.
Where feasible, ssh login access should be restricted by source IP(s).
Where feasible/practical, running ssh on a non-default port can greatly
reduce the attack vector from many automated attacks - but it's a bit of
"security by obscurity" - it will only get one so far, and will be
little defense against more specifically targeted attacks.
Where feasible, other methods, such as "port knocking", etc.[1] may
substantially increase security.
Access to and controls on ssh login is only one layer of defense.
Again, not exactly "news"[2].
select references:
1. http://cipherdyne.org/fwknop/docs/SPA.html
2.
http://www.google.com/search?hl=en&q=ssh+distributed+attack&btnG=Google+Search&aq=f&oq=
More information about the sf-lug
mailing list