I've never seen SSH attackers probe a space of user IDs in such a way that they would eventually find a user ID like Z@an4ar. In fact, they just stick to standard user IDs like root, and probe only the password spaces. If your super user account is not named root, or not available by that name via SSH, it is safe from attacks which only try that name.
sshd can be configured simply not to allow root logins. To use root, you log into some other account and then su. That other account can have a name that attackers will never try, and a decent password.
Then, if you happen to be using a log based banning system, since you know that no legitimate user would be trying the name root, you can impose an instant ban on such an IP address, with a long duration. It's really just for reducing traffic more than anything.
Regarding aliasing root, you can create an alias for the UID 0 user simply by editing your password and shadow files to create duplicate entry. If the root entry appears first, then that name is still used whenever a UID is resolved to a user name, like in your ls -l and whatnot.
The shadow entry for root can have a star in the password field so that it cannot be used for logging in by any means; only the alternative name can be used via the other entry that has a password set up in its shadow entry.
Addendum: I just ran some scripts to see what attackers are trying. They probe various funny user names but there doesn't appear to be any system behind it. They are all short names. The vast majority of them are nothing but lower case letters. A few have underscores and digits, as well as dashes and periods. Some are digits only. A few are using glyph characters:
!
!!!
?
#$
I suspect that the user IDs being tried are all targeting known passwords that have been obtained before. I.e. they are probing "where else on the planet has the same user ID used that same password".
The valid users they are trying are:
avahi
backup
bin
daemon
Debian-exim
foo
games
gdm
gnats
hplip
irc
libuuid
list
lp
mail
man
messagebus
news
nobody
ntp
postgres
proxy
root
saned
sshd
sshroot
statd
sync
sys
uucp
www-data
None of these allow login; they have a * in the shadow file.
You get that if you believe attackers can't break your passwords, screening SSH with "port knockers" or fail2ban isn't doing anything, right?
The whole thing is kind of moot though. For other reasons, you should just wrap all this stuff up in WireGuard and never think about it again. WireGuard is silent; you can't probe it.
kazinator|1 year ago
sshd can be configured simply not to allow root logins. To use root, you log into some other account and then su. That other account can have a name that attackers will never try, and a decent password.
Then, if you happen to be using a log based banning system, since you know that no legitimate user would be trying the name root, you can impose an instant ban on such an IP address, with a long duration. It's really just for reducing traffic more than anything.
Regarding aliasing root, you can create an alias for the UID 0 user simply by editing your password and shadow files to create duplicate entry. If the root entry appears first, then that name is still used whenever a UID is resolved to a user name, like in your ls -l and whatnot.
The shadow entry for root can have a star in the password field so that it cannot be used for logging in by any means; only the alternative name can be used via the other entry that has a password set up in its shadow entry.
kazinator|1 year ago
The valid users they are trying are: avahi backup bin daemon Debian-exim foo games gdm gnats hplip irc libuuid list lp mail man messagebus news nobody ntp postgres proxy root saned sshd sshroot statd sync sys uucp www-data
None of these allow login; they have a * in the shadow file.
tptacek|1 year ago
The whole thing is kind of moot though. For other reasons, you should just wrap all this stuff up in WireGuard and never think about it again. WireGuard is silent; you can't probe it.
Demiurge|1 year ago