Spencer Krum

Today we will analyze ssh logs on a server on the open internet. These connections generally fall into two categories, successful logins from legitimate users, and failed logins from attempted ssh brute force attacks. We will provide no information on the successful logins and will provide high level analysis of the unsuccesful logins.

Basic stats:

• First log event: Jan 11 03:53:39<
• Last log event: Jan 12 05:41:32
• Total log lines: 44853
• OS Version: Centos 6.5
• sshd: Version : 5.3p1 (from yum)
• sshd: Release : 104.el6_6.1 (from yum)

Light analysis:

• Failed password authentication for root: 22199
• Failed password for other users: 209
• Other users:

admin
appcadmin
arun
binbin
dasusr1
db2fenc1
db2fenc2
edx
elbarassin
evanss
galbatorix
ghost
gusrli
hadoop
ham
icang
info
kang
kenny
kjclub
klindley
mrlong
solr
tansya
tester
ubnt
vagrant

Some of these users are quite interesting. ‘admin’ is of course a classic, as are ‘info’ and ‘tester’. But ‘hadoop’, ‘vagrant’, and ‘solr’ are relatively new technologies and it is both scary and encouraging that the brute force bots are attempting to compromise those users. ‘galbatorix’ has to be my favorite name in this list, just because it is hillarious. ‘binbin’ is a close second. I’m also suprised to find attempts at mispelled user names such as ‘icang’ (probably a mispelling of icinga) and ‘ubnt’ (probably a mispelling of ubuntu). I’m not sure if this is because the bots have mispellings from incompetent operators, or if this is an attempt to gain access through an accidentaly created user. I can totally see how an admin setting up a service would mistype ‘adduser icang’ and then run ‘adduser icinga’ without cleaning up after themself.

Next, lets look at the attackers:

Thi s tells us more or less what we expect. We have two kinds of attacks going on. One kind of attack will brute force passwords against a single server until its database is exhausted, another kind will try a single password against its list of servers, before circling around and trying a second password. This second kind is more sophisticated because it hides from tools like fail2ban.

Conclusion: I should really turn off password auth on this server. Keys only is the way to go, still, it is impressive that 43K attempts were made in about 24 hours. It is interesting that despite this server having ipv6, no brute force attacks have been made over ipv6. This is likely due to the big-sky problem, which may be a topic for an upcomming post. It is also interesting that root accounts for almost all of the brute force attacks and regular users are very few. It is worth noting that the analysis could be performed over a longer period, data from a week or a month or more may provide more results.