I Opened My Connection To SSH Attacks, And These Were The Requests I Saw
Recently I decided to investigate the type of requests that I would receive if I had opened up SSH to the world. The following are the results of that investigation.
First some background.
The SSH service was being run on a Raspberry Pi and was the sole device on the internet connection. The internet connection itself was a standard residential broadband DSL service. At no point was a domain pointing towards the IP. Any SSH requests were speculative.
At this stage, I was only interested in the login attempts rather than what was trying to be done if a connection had been established. I logged the requests for a little over 7 days.
I am not going to go into how I logged the SSH requests in this article, I have covered this in my other article “How I Set Up My SSH Honeypot”.
The SSH honeypot was online for a little over 7 days. During this time I witnessed a total of 129396 logging attempts. Initially, this may sound excessive, however, let me quickly break this down.
The following chart demonstrates the top 20 requesting hosts (the number in brackets is a unique ID for each host).
As the chart demonstrates, the vast majority of requests actually came from three hosts. These three accounted for 116209 of the requests (around 90% of all requests). The requests from these were very much sustained as can be shown in the following chart:
Excuse the period section, they are hourly slots. Each of the larger chunks is a prolonged attack from hosts 28, 41 and 136.
The behavior these three hosts demonstrated differed greatly from the others. Most of the hosts were attempting very targeted credentials (more on that in a moment) these three hosts were carrying out a dictionary attack on the root user. The following is a list of the top 20 users that were attempted.
root - 127111
admin - 188
0 - 79
pi - 73
test - 52
user - 44
support - 33
odroid - 28
ftpuser - 26
postgres - 25
ubnt - 24
guest - 23
ubuntu - 18
Administrator - 16
ftp - 14
oracle - 14
vagrant - 14
webmaster - 14
administrator - 13
dietpi - 13
China, not only had the most requests per host they also topped the total number of hosts coming from the country:
Now onto the passwords that were attempted. This is far more evenly spread, as you may expect, as the Chinese hosts were carrying out a dictionary attack on root, they rarely duplicated passwords. The following is the list of top 20 passwords:
admin - 102
0 - 83
123456 - 67
password - 53
1234 - 41
raspberry - 39
root - 37
ubnt - 35
administrator - 30
welc0me - 29
guest - 26
openelec - 26
test - 25
pi - 23
alpine - 21
default - 21
12345 - 19
postgres - 19
alex - 16
ftpuser - 16
The second most requested password was 0 (zero) however I believe this to be an error on the attackers part. Most came from the same host along with the username 0 (zero). I do not believe this to be a logging issue rather an issue on the attackers part not sending the correct payload. If we couple this list along with the unique username/password combinations it paints an interesting picture:
0 - 0 - 79
admin - admin - 72
root - root - 32
root - welc0me - 29
root - openelec - 26
pi - raspberry - 24
pi - pi - 20
root - None - 20
ubnt - ubnt - 20
admin - password - 19
guest - guest - 19
test - test - 18
root - 1234 - 16
root - 123456 - 16
root - admin - 16
root - password - 16
root - libreelec - 15
What I find particularly interesting are the types of devices that are being probed for, for example, 44 attempts on Raspberry Pi’s (across 2 sets of credentials in the top 20, more outwith). I can only assume these have become popular targets due to the ease of development on them (a side note, the SSH honeypot was hosted on a Raspberry Pi). Another target is home theatre systems (libreelec and openelec). These types of applications should not require remote management, therefore the fact they are showing on such lists suggests that they are regularly on miss-configured equipment allowing ports through the router.
My original intention was to identify the types of devices that the attempted credentials are intended for, however, once the attacks went into full steam this became an impossible task.
The following are some of the more unusual requests:
Why: This is the default username for Kali Linux, a distribution generally used for honeypots and hacking etc.
Why: Clearly aimed at a Raspberry Pi but a very odd password. Google has 365 results when searching for it, predominantly other people who have run honeypots as well as dictionaries intended for attacks such as this. Oh and of course what password does have the obligatory twitter hashtag.
Why: There were a number of passwords that had a similar pattern (starting with %username%). I would suggest this was a miss-configured script carrying out the attack. I suspect %username% was a placeholder in a template.
Why: Again this looks like a template gone wrong, however, I wonder if there was an admin user called peng on 163.com’s servers, or is peng simply a user of the service?
Why: There was a very large number of requests that followed this same format. The password would always start with 1971–1981. Upon investigating it appears they are dates. They all fit the format YYYYMMDD with no exception. Not all dates were covered (but years were) and each combination had been attempted 6 times. There was evidence of years out with this range but not full dates. Are people aged between 38 and 48 more likely to use their date of birth as a password? I suspect not but an interesting observation.
Why: You would expect this to be someone who has made a mistake in their script, passing the file URL instead of iterating the contents. However, you would be wrong. A quick Google search shows similar results in other lists of found passwords. Is it possible that it was a mistake at first but the people who make password lists found it in a scrape of attempted logins?
Leaving services such as SSH open can result in a large number of such requests. Regardless of whether you are Joe bloggs on a home connection or Microsoft running an Office 365 server. Be sure to lock down any ports you do not require. I suspect any other service port would see similar traffic.
I would like to point out that although a very large proportion of the requests came from China (and specifically from a small number of hosts), this does not mean that it was a Chinese miscreant attempting to break into the device. Although it could have been, it is just as likely that the device is a server or device that has been compromised. Clearly, these attackers have a disregard for the traffic being noticed, otherwise, the requests would have been throttled.
If you are interested in taking a look at the requests yourself, I have compiled a CSV file with each individual request over on Github Gist. I have obfuscated the connecting IP’s however, and replaced with a unique ID (identified as host_id). If importing into a database the following table structure will suffice:
CREATE TABLE honeypot (
id int(11) NOT NULL AUTO_INCREMENT,
username varchar(250) DEFAULT NULL,
password varchar(250) DEFAULT NULL,
`when` datetime DEFAULT NULL,
country varchar(250) DEFAULT NULL,
host_id int(11) DEFAULT NULL,
PRIMARY KEY (id)
I have also written an article entitled “How I Set Up My SSH HoneyPot” which describes the steps taken and some of the takeaways.
Interested in how best to secure your SSH server? Take a read of my my new article ‘So How Do I Secure SSH?’.