Not too long ago there was a reasonable amount of press ( in the IT world anyhoo, meatspace pretty much ignored it ) regarding attacks against the SSh protocol. The “SShPsychos” group has been responsible for a large number of coordinated brute force attempts against well known usernames with a variety of common passwords. This isn’t long term targeted attempts against a particular target – rather a scatter-gun approach at anything that’s running an SSh daemon on Port 22 using a short-ish list of dumb passwords.
To be honest, I’d known about this sort of background level for a long time – and it came as no great surprise to me. It’s been going on as long as I’ve had an SSh server running on a public IP, and to be fair the volume _has_ increased. It has been a great example to students though when I’ve been teaching Linux security – pointing out the reasons for carrying out the basics of securing SSh:
- No remote root login
- Complex passwords
- Specific IP firewall rules if/where possible
And also some of the more complicated ones:
- Chroot Jails
- Multi-Factor Authentication
Even now, logging into my webserver ( “www.thinking-security.co.uk” ) via SSh on Port 22 there are approximately 2000 illegitimate login attempts over the last 20 hours. Quite often when I re-connect after a weekend or more than a few days, this number is in the 10s to even 100s of thousands. I’ll be honest, it doesn’t particularly bother me – it is much rattling of windows and testing of locks – there are much easier fish to fry on the interwebs than that particular machine.
It did cause me to ask two particular questions though:
1) Where are all the attacks coming from ?
2) What usernames and passwords are they trying ?
Turns out that question 1 is easy, and question 2 is half easy …
On any Linux server, the connections made against SSh are logged. These go into /var/log/secure and here is a prime example:
May 15 14:35:55 ts-one sshd: Invalid user bankid from 126.96.36.199 May 15 14:35:55 ts-one sshd: input_userauth_request: invalid user bankid [preauth] May 15 14:35:55 ts-one sshd: pam_unix(sshd:auth): check pass; user unknown May 15 14:35:55 ts-one sshd: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=188.8.131.52 May 15 14:35:57 ts-one sshd: Failed password for invalid user bankid from 184.108.40.206 port 59470 ssh2 May 15 14:35:57 ts-one sshd: Received disconnect from 220.127.116.11: 11: Bye Bye [preauth]
This is one connection attempt – the source ( from ) is 18.104.22.168, and it has presented the invalid user “bankid” – this has actually failed at this point – but SSh won’t let the attacker know that, it will still allow them to enter three password attempts before terminating the connection. This inability to tell if it is the username or the password that has failed is actually quite important – realise that if you can tell if an account is valid, then you can easily stop wasting time and effort on ones which are not. This non-specific failure method “Either the username or the password is wrong” leaves the whole possible space open requiring a far greater number of attempts to find a valid username _and_ password combination.
22.214.171.124 – great IP address – I’m sure that there are some savants out there who can look at that and tell me where it is from – but I assure you, I am _not_ one of them. I have to look it up – and even then the sources occasionally disagree ( not that it actually really matters as I’m not sending a drone over to wreak revenge ). For the purposes of the remainder of this process I’ll be using the MaxMind database, and, for the sake of legal compliance:
This product includes GeoLite2 data created by MaxMind, available from http://www.maxmind.com.
This data is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.
There is a direct interface to the data that is available on the front page of the MaxMind website which allows for the query of a single IP address, and, for us in the case above, this tells us:
IP Address = 126.96.36.199 Country Code = FR Location = France, Europe Coordinates = 48.86, 2.35 ISP = OVH SAS Organization = OVH SAS
So it is a French IP address hosted with the OVH Company.
As a hosting company, they aren’t directly responsible for the attack, rather it is just being launched from a machine that has been allocated an IP address within their scope. However, having said that, a quick glance at a Google search about them suggests that this is far from the first time that they have been used as a stepping stone onto other things …
The IP address lookup also gave us the Lat / Long ( estimated – by a long shot ! ) of the address. We can plug these into Google Maps to have a look-see at the rough area of operation _of the IP address_. This isn’t, most likely, where our perpetrator is sitting – more likely the recorded head office of the company …
That’s great one IP address down – 2000 to go …
In the next articles in this series, I’m going to extract all of the IP addresses & usernames from the logs ( across multiple servers ! ), and then plot these against a map to show both historic and real-time data … And then we’re going to move on to finding out what passwords are being attempted using a “honeypot” !