I have a box still running woody, and can't run iptables recent match on it (see an earlier post in my blog on how to use this kernel filter to effectively block ssh scanners). Every few days another hacker, most of them being IPs from China, hits it with a SSH scan.

When I notice these scans via logcheck mails and it still seems to be in progress I usually manually block that IP. Maybe I should move the ssh server to a different port for now.

Anyway, I just received the following lines via logcheck:

Apr  6 01:04:50 sshd[1371]: Failed password for news from 213.80.123.21 port 42768 ssh2
Apr  6 01:05:29 PAM_unix[23403]: (ssh) session closed for user testtest
Apr  6 01:05:32 PAM_unix[6136]: (ssh) session closed for user testtest
Apr  6 01:06:20 PAM_unix[6793]: (ssh) session closed for user testtest
Apr  6 01:13:38 sudo: erich [...] block_host.sh 213.80.123.21

So first of all, I happened to block that scanner by chance just a few minutes after he had actually hit an account with a weak password.

Fortunately, that user (like all users by default) has shell /bin/false, so these three logins were pretty short. Figures that I immedeately locked that account (which apparently has been sitting around for a year and was never used, locked as in "user not found"), and I'm annoyed that someone created an account with most probably username == password, despite the account creation tool even generating secure passwords for you. I also ran a system check, but it's clear that they couldn't ran their default attacks and didn't have time to come up with some clever mail/whatever combination to get in.

But a couple of things for you to take away:

• Use filters to block scanners.
• Monitor your logfiles. It's worth it.
• If a user doesn't need ssh access, don't give him ssh access. Consider a restricted shell, or a non-exec filesytem for untrusted data.
• Make sure you don't have accounts with extremely weak passwords such as username == password on your systems. That is what they are scanning for.
• Don't ever give access to the account creation tool to anyone who doesn't enforce a strict password policy, unless your tool does ensure that.
• Don't let users with shell access or similar pick unsafe passwords.

Oh, and it is interesting, that once they hit that "locked down" account, they actually gave up scanning. They tried three times logging in to that account, and then didn't scan anymore. Maybe I should modify my ssh server to send unknown users always to /bin/false.