About a month ago, I migrated my server hosting to a new cloud provider. I’m trying some new things, but as part of that process I’ve once more looked into trying to analyze ssh bot activity. It may not be very useful, but it’s somewhat interesting.
I wrote a simple Python script, made some modifications, and am considering adding some more things to it. However, the quick gist at the moment is I’ve had it tabulate the number of times an ID is used to try to brute-force an ssh connection. Here are the results of the top 25 from a month of data:
| ID | Count |
|---|---|
| admin | 1821 |
| user | 721 |
| ubuntu | 589 |
| root | 504 |
| debian | 446 |
| pi | 165 |
| user1 | 159 |
| 111111 | 139 |
| test | 136 |
| guest | 92 |
| support | 86 |
| 123321 | 85 |
| 1234 | 84 |
| ubnt | 79 |
| oracle | 66 |
| ftpuser | 64 |
| postgres | 63 |
| ftp | 61 |
| (NULL) | 61 |
| default | 49 |
| master | 46 |
| nagios | 43 |
| administrator | 42 |
| manager | 42 |
| adm | 41 |
Notice that the top entries seem to be for Debian-based Linux distros. Maybe these, like the raspberry pi, are setup in a rudimentary way via some guide online (or maybe used an example password without thinking) where they are left open to attacks like these. Just goes to show, if you are using a password login for SSH (why would you?) maybe the only thing worse you can do is to use these IDs. Maybe look at how services are setup a bit more carefully if they are using these IDs. Really look into turning off root ssh logins and using public key ssh authentication. Be sure to also pair that with some form of blocking technology so that it can potentially discourage these attempts as well. Other than that, I’m just leaving this here if anyone finds the data interesting.