[SOLVED] Large number of failed ssh login attempts

Hello,

I own a Raspberry Pi running a ssh server. As I have noticed many login attempts from different locations on earth (mainly from China), I have configured my server to accept connections from only 2 or 3 known IP addresses. I also wanted to see what passwords were used by the attackers so I wrote a small PAM module to log this information. Surprisingly, all passwords are nearly the same. They often start with the 4 ASCII characters #8, #10, #13 and #127 in this order. I havn't found information on the web about possible vulnerability of ssh to special characters. What do you think about that?

My guess is automated random port scans.

It looks like an automated script to search for systems vulnerable to brute force password attacks on ssh.

If they're coming from the same networks, you can always report them to the netblock owner. That takes a small effort even with a template but often reduces the attack.

Also, there is sshguard which can automatically add most if not all of those attackers to your firewall's block list, even for IPv6 sources.

Originally Posted by Izwal What do you think about that?

Something doesn't add up, is what I think.

I wrote a small PAM module to log this information. Surprisingly, all passwords are nearly the same. They often start with the 4 ASCII characters #8, #10, #13 and #127 in this order.

Welcome to LQ! Maybe "doesn't add up" means: Are you *absolutely sure* your capture works? Did you test it, with a login attempt from you, with a test pwd, to check for? I would have expected to find web-search results, but didn't, for:

password "8 10 13 127"

Or is that http://ascii.cl "bs lf cr del"? (no results for that either). What was the other "nearly the same" part?

Also, share=post some specifics (those similar pwds, 'logs', -d ,...) that we can have a look at & advise on (of course, obfuscate your publicIP!). 'Picture worth 1K words'. Tips: 4a)CODE, |nc termbin.com 9999

As long as it is possible for "anyone on the planet" to reach a login: prompt on your box, you will have no end of misery, and "no dictionary will ever protect you." But you do have an alternative: an easy-to-implement alternative will shut all of this completely down, cold, and keep it that way forever after.

Have a look at my LQ blog where I discuss How To Build a 'Dwarvish Door' With OpenVPN.

The strategy which I describe there will bring an immediate end to all such access attempts. To the outside world, your system has no "open ports," and, so far as they can detect, it's not running OpenVPN, either! (Unless they demonstrate in the initial handshake that they probably possess the proper tls-auth certificate, the OpenVPN sever won't even answer the phone.)

The only way to enter is to possess two one-of-a-kind digital certificates, the second one of which also has not been "revoked" by you.

Only then can one reach ssh or anything else. (ssh, which of course you have set up to require a third digital certificate and not to ever prompt for a password, becomes the second also-impenetrable layer in your outer defenses, guarding all access to a shell prompt ... a layer which will never be assaulted because it will never be found.)

Authorized users can clear these obstacles in seconds, and can carry on their communication with your system, securely, as though it were simply attached (through a (software) router) to their local network. They don't have to think further about security: it is secure, and they are certain that they are talking to the intended machine. (In like manner, your machine knows that it is communicating specifically with them. It knows them by name.)

(Digital certificates can be encrypted with a password, e.g. for use with "road warrior" machines that might get stolen in an airport bathroom, so that they can't be used until you get a chance to revoke them, which act instantly and selectively(!) renders them useless – encrypted or not.)

The number of unauthorized access attempts will immediately drop to zero and stay there ... forever.

I've deployed many public servers – I won't tell you the IP-addresses and you can't find them – that have never had an unauthorized access attempt. Ever. Nor will they. Ever.

Hello everybody and thank you for the contributions.

I finally managed to log passwords by modifying my "sshd_config" file:

PermitRootLogin yes
AllowUsers *@*

Since this modification, the login attempts are successfully logged:

2017-08-20 18:18:24  from xxx.xx.xxx.xx user="root" pass="!@"
2017-08-20 18:18:27  from xxx.xx.xxx.xx user="root" pass="!@"
2017-08-20 18:18:28  from xxx.xx.xxx.xx user="root" pass="123456"
2017-08-20 18:19:47  from xxx.xx.xxx.xx user="root" pass="password"
2017-08-20 18:19:48  from xxx.xx.xxx.xx user="root" pass="root"
2017-08-20 18:27:38  from x.xxx.xxx.xx user="root" pass="welc0me"
2017-08-20 18:27:40  from x.xxx.xxx.xx user="root" pass="rpitc"
2017-08-20 18:27:41  from x.xxx.xxx.xx user="root" pass="nosoup4u"
2017-08-20 18:27:44  from x.xxx.xxx.xx user="root" pass="default"
2017-08-20 18:27:46  from x.xxx.xxx.xx user="root" pass="rpitc"
2017-08-20 18:30:13  from xxx.xx.xxx.xx user="root" pass="1q2w3e4r"
2017-08-20 18:30:16  from xxx.xx.xxx.xx user="root" pass="default"
2017-08-20 18:30:18  from xxx.xx.xxx.xx user="root" pass="abcd1234"
2017-08-20 18:31:09  from xxx.xx.xxx.xx user="root" pass="raspberry"
2017-08-20 18:31:11  from xxx.xx.xxx.xx user="root" pass="centos"
2017-08-20 18:31:14  from xxx.xx.xxx.xx user="root" pass="changeme"
2017-08-20 18:41:42  from xxx.xx.xxx.xx user="root" pass="1111"
2017-08-20 18:41:45  from xxx.xx.xxx.xx user="root" pass="superuser"
2017-08-20 18:41:47  from xxx.xx.xxx.xx user="root" pass="1qazxsw2"
2017-08-20 18:42:36  from xxx.xx.xxx.xx user="root" pass="vagrant"
2017-08-20 18:42:39  from xxx.xx.xxx.xx user="root" pass="power"
2017-08-20 18:42:41  from xxx.xx.xxx.xxx user="root" pass="Admin@123"
2017-08-20 18:53:02  from xxx.xx.xxx.xxx user="root" pass="qweASD123"
2017-08-20 18:53:05  from xxx.xx.xxx.xxx user="root" pass="rootme"
2017-08-20 18:53:07  from xxx.xx.xxx.xx user="root" pass="zabbix"
2017-08-20 18:53:55  from xxx.xx.xxx.xx user="root" pass="rootroot"
2017-08-20 18:53:58  from xxx.xx.xxx.xx user="root" pass="123qweasdzxc"
2017-08-20 18:54:00  from xxx.xx.xxx.xx user="root" pass="666666"
2017-08-20 19:04:31  from xxx.xxx.xxx.xx user="root" pass="qazwsx"
2017-08-20 19:04:34  from xxx.xxx.xxx.xx user="root" pass="1q2w3e4r5t6y"
2017-08-20 19:04:36  from xxx.xxx.xxx.xx user="root" pass="oracle123"
2017-08-20 19:05:26  from xxx.xxx.xxx.xx user="root" pass="pa55w0rd"
2017-08-20 19:05:29  from xxx.xxx.xxx.xx user="root" pass="abc"
2017-08-20 19:05:31  from xxx.xxx.xxx.xx user="root" pass="P4ssw0rd"

So my conclusion is that the "pam_unix.so" module does not store password when login attempt is not allowed for user from IP.
Hence the data retrieved by the "pam_get_item" function is incorrect.

Of course I don't want to allow login from anywhere so I will revert my "sshd_config" file.