I logged into one of my servers on Monday, and for whatever reason, I ran ss,
when what did my eyes behold but an unfamiliar IP with an established connection
to my SSH daemon. Unaccustomed to this, I immediately freaked out and restarted
the server, thinking someone had broken in. They’d be back, but rebooting would
give me a couple seconds to collect my thoughts.
This was wholly unnecessary. Before I rebooted, I checked who and noted that
I was the only one with a login shell, but that doesn’t guarantee the attacker
isn’t being more stealthy. Still, I should check if they had a shell. If so,
they may have run sudo. But, journalctl -g "sudo:session" -b 0 says it’s just
been me asking for sudo elevation. Okay, maybe it wasn’t a normal shell. If they
compromised the SSH server, there should be some SELinux denials. But,
aureport -a shows <no events of interest were found>. I overreacted, then.
Even so, what was that IP doing with my SSH server? Time to quit messing around
and ask sshd itself. I run journalctl -u sshd and am greeted with the longest
set of SSH login failures I’ve ever seen. Most of these are in this form:
Unable to negotiate with <IP Adress> port <Port Number>: no matching key exchange method found. Their offer: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 [preauth]
It’s a sweeping attack, then. A sigh of relief was in order. Nothing to worry myself about, but there’s some neat info I can extract. For example, since February 19th (the logs don’t go back further than that), my SSH server has given that response 33,014 times to 2236 unique IPs. I also found that attackers have tried 1131 unique invalid usernames. The most common username was pi, with 181 attempts. Finally, there were 30,782 attempted root logins, which my server automatically blocks.
Or in other words, grepping logs is fun.
Still, time for these sweeping attacks to quit flooding my SSHd log. I’ll just
make exceptions for my networks in /etc/hosts.allow and sshd: ALL in
/etc/hosts.deny, and. . .Nothing changed. A bit of Googling led me to run
ldd /sbin/sshd | grep libwrap to find out if my SSHd was even using TCP
wrappers that would be affected by those files. No. Not it is not.
And so the time came for me to learn how to use firewalld a bit better. By moving the ssh service from the public zone to the internal zone and adding my exceptions to the sources list for the internal zone, I’ve finally achieved sweet silence in my ssh log.
Well, at least after I dealt with Deprecated option UsePrivilegeSeparation.