The Low-Intensity, Brute-Force Zombies Are Back 203
Peter N. M. Hansteen writes "In real life, zombies feed off both weak minds and the weak passwords they choose. When the distributed brute-force attempts stopped abruptly after a couple of months of futile pounding on ssh servers, most of us thought they had seen sense and given up. Now, it seems that they have not; they are back. 'This can only mean that there were enough successful attempts at guessing people's weak passwords in the last round that our unknown perpetrators found it worthwhile to start another round. For all I know they may have been at it all along, probing other parts of the Internet ...' The article has some analysis and links to fresh log data."
Re:why are passwords even allowed? (Score:3, Interesting)
If you only allow public key authentication then there's really no need to bother blocking them: you'll never block the entire botnet.
Just let them try - they'll never guess the right private key.
Don't just run it on a higher port. (Score:2, Interesting)
Be proactive on port 22 as well. At the advice of another comment I saw on /. a year or so ago I'm running a honeypot, with three static ports (one of them 22) and 4 roving ports. Establishing a TCP connection to any of them causes your IP to be instantly added to an iptables blacklist. It's worked pretty well; I've got about 2-3 unique addresses trying per day, and about 294 have been blocked since mid-December 2008. It takes care of both port scanners and bots deliberately connecting in order to try and get root on my server.
Of course, the only way to get root on the server anyway is through a Yubikey [yubico.com] OTP or the 64-character randomly generated password I have on an encrypted partition somewhere in case my Yubikey is ever fried/stolen/lost.
I always wondered about that (Score:1, Interesting)
Always these stories about zombies dossing this or bruteforcing that, but never a hint as to where these zombies came from, who they are, etc. You'd think that if you can see them in your logs that easily, it should be possible for their isps to see them as well, or else someone could inform them. Why aren't isps sending zombie customers a letter a la "please clean your machine, or we'll shut down your connection". Is it just that they can't reap profits from the customer anymore? In that case, why don't we just blacklist all isps who refuse to terminate zombies?
quickest fix (Score:2, Interesting)
Re:why are passwords even allowed? (Score:3, Interesting)
I'm still a bit nervous about allowing malicious third parties to effectively write firewall rules for me. The ideal is of course to only allow a certain address range in, but some of us don't really know where the next legitimate connection is going to come from.
Re:why are passwords even allowed? (Score:2, Interesting)
I disagree. I both cases, password auth or key auth, barring any security problem with the protocol, the weakest link is the user. A passphraseless ssh key is tempting to the user for many reasons and unless you audit the passphrases selected by your users, key auth is no more secure than password auth. In fact password auth may actually be more secure if you enforce complexity on the system(s). You have no control over the passphrase on a user's SSH key. You can try to control it, but the user can strip the password at any time and on any remote system.
Not allowing passwords may actually lull you into feeling secure. Multi-user and personal user systems are compromised all the time, and in my and my collegues experiences, break-ins via SSH are as likely to happen via either method. Lame botnets try weak passwords, crafty exploiters try everything and thanks to Phalanx2, their craft became much easier.
Re:iptables goodness (Score:3, Interesting)
then locks down port 22 entirely except for defined, fixed-IP administrative exceptions
This is my default configuration, with a port knock pattern for emergency access.