When I have set up this WordPress site, the very first thing I was concerned with, is with the security and amount of the information I collect. I wanted to minimize stored private information, so an attack on the site have little to no collateral damage. Because I certainly don’t care enough about what email address, personal interests, other contact info, favorite food and color does John Doe have for me to also store it on my server, and even less I want to be responsible for it.
So after I’ve enabled the Akismet Anti-spam: Spam Protection plugin, I have installed the Loginizer by Softaculous plugin too, that protects the login interface of a WordPress site. After a while, what I find in the report, was… well, shocking isn’t the right word: I was well aware of the practice of brute-force attacks. I wasn’t expecting from the attacks to be so numerous on a fairly new site. The attack attempts were made on the vulnerable XML-RPC feature, and I have found a solution for this online. Out of the numerous option it offered, I choose to modify the .htaccess file, as I have direct access to it, and don’t mind hands-on solutions. If you want to read for a solution for your WordPress site, read the following article:
After a quick check, whether the change works, and a quick fix of a typo, voilà, the URL is no longer accessible, and Loginizer is not reporting any attacks since. Apparently, it does legitimately show brute-force attacks, and it is not just using scare tactics to make you purchase the Pro version of it—though I may look in to purchasing one for myself. #not-sponsored
But then my focus shifted slowly to the SSH server I also use. Surely, it is also being attacked. Right? But rather than assumptions, I wanted to see it for myself first. The XML-RPC attacks were so clear, why wouldn’t this be? You can list any SSH based traffic with journalctl -u ssh or by viewing the /var/log/auth.log file, but in either case, the entries were written in natural language. Normally, that wouldn’t be an issue, but if I want to quickly filter it through to find out statistics out of how the SSH server is being used, I would need to know what possible sentences there are to track user interactions with the server: Have they typed in an invalid username, an invalid password, have they even tried to use password, or have they tried some other means to authenticate, were there any successful authentication, etc. This is where better stack’s post helped me:
The post is about how you can configure monitoring of security risks in your systems by visualizing the authentication data. This is similar to what Loginizer offered to me on WordPress, but this is applicable for SSH logins. This sounds just like what I want to do, and I want to come back to this article later, but for now, after skimming quickly through it, I’m only interested in the log message formats. What I’ve gathered from the above article would be the following regular expressions, that can be used with grep -E:
sshd.*\<Invalid user– when someone typed in an invalid username for authentication, followed by the name of the attempted user.sshd.*\<Failed (\w+) for– for when an authentication method failed. Most common authentication method is “password,” so the message most commonly would read “Failed password for user…”sshd.*\<Accepted (\w+) for– when the user successfully authenticated themselves, with the specified authentication method: “Accepted password for user…” This also means, that the user is granted a session to the server.sshd.*\<Disconnected from user– when the user closed the connection to the server, followed by the user name that closed the session.
Earlier, I’ve seen that they have attempted various usernames for login. How many are there? The following command will list these log entries:
journalctl -u ssh | grep -E 'sshd.*Invalid user' | wc -l
Nah, it’s just over 50 thousands and growing since I’ve set up the server between February 8 and March 12, no big deal. “This is fine.” /s OK, while I do use SSH to maintain my server—so disabling SSH is not an option for me—I still can one-up my security, if I change what port number I use for SSH. The main point, is to improve the security by obscuring the port number for SSH—so I can’t share here my choice, but I’ll not to leave it at 22. For that, we need to change the port number in the /etc/ssh/sshd_config file to something different, by specifying (or changing) the following line to a different number from 22:
Port 22
What I do want to share here, is a code snippet, that you can quickly list only the connections attempts and state here, that includes invalid username, failed authentications, accepted authentications (and thus opened sessions), and disconnected sessions. I may use this to configure a weekly report, so I know what’s up with the server.
journalctl -u ssh | grep -E 'sshd.*\<(Invalid user|Failed (\w+) for|Accepted (\w+) for|Disconnected from user)'
I was also curious what usernames are the attackers trying out to log in as, and they are trying out quite a lot. Among them are “admin”, “user”, “root”, “guest” but none surprises me as much as the 0 character length username. I find it very fascinating what usernames the attackers are trying, so I have shared a list with you at the end of this post. They’re also trying the username “adam” to my great disappointment. Never would have chosen that name for this exact reason, but now I have hard evidence on why I shouldn’t. If you also would like to list what usernames the attackers are using on your server, you could too execute the following command:
journalctl -u ssh | grep -oE 'sshd.*\<Invalid user (\w*)' | awk '{ printf $4 "\n" }'
And there was silence… for 8 days. 😞 At least the number of attacks have been mitigated.
