I was the victim of an SSH scan once. I set up an old box as a dev server in my apartment for a project course in college. I was in a group of about 12 students. One of them whose username was robert set his password to robert (a brilliant move).<p>We only realized the machine was compromised because the interloper decided to pick two user accounts at random and delete them (another brilliant move).<p>Upon investigation I found that a keylogger had been installed in order to discover the root password. I inspected the output of the keylogger to trace the attacker's steps. Similar to the SSH scan in the article, the attacker had logged into his own FTP server to download various scripts and crackers. Well, the keylogger had logged his FTP password as well (whoops). Naturally I logged in and deleted absolutely everything in sight. :-P
Lots of needless clutter in the discussion, so I thought I'd drop a quick comment with clarifications:<p>1. As far as I can tell, this specific attack is meant to target MIPS-based OpenWRT/DD-WRT devices, like the Linksys WRT series.<p>2. lsof and all that crap isn't available by default. So, use 'ps' and 'netstat -a', and 'ls -la /var/tmp' to poke around your router.<p>3. Go into the web admin interface and disable sshd on the WAN interface, if it isn't already (it's off by default). In DD-WRT, go to Administration->Management-> and ensure "SSH management" is disabled.
Interesting idea. Reading through the threads it becomes apparent that the attackers are targeting home wired/wifi routers. The attacker sits on your gateway and passively monitors your traffic with you being none the wiser!
The correct way to address this is not to rely on fail2ban or start moving ports around (although these will remove noise from your logs, they shouldn't be solely relied upon) but to use public key authentication. It's not hard to set up and once you disable password authentication support on OpenSSH then the scans can try all they like, but they're not getting anywhere.<p><a href="http://wiki.centos.org/HowTos/Network/SecuringSSH" rel="nofollow">http://wiki.centos.org/HowTos/Network/SecuringSSH</a>
A friend had me look at a server that had been compromised by SSH bruteforce a few months ago. The intruder was using it as an IRC bouncer, and he was a romanian named Alexino.<p>I actually found him on the IRC network, and he tried to get me to pay him to tell me how he got in :)
This gentleman is illegally hosting my tools, which are copyrighted and not licensed for redistribution. Just because I try to pwn your box doesn't mean you have the right to violate my copyrights. Expect to hear from my lawyers.
I've seen similar things come up before on HN and on mailing lists I'm on. Rather than keep repeating myself whenever this crops up, I've posted here: <a href="http://www.minklinks.com/weblog/2010/11/19/practical-guide-securing-openssh/" rel="nofollow">http://www.minklinks.com/weblog/2010/11/19/practical-guide-s...</a>
Looks like it tracks to a server/VPS place in The Netherlands<p>Wonder if he followed-up with the hosting service by reporting the address as being used in an attack. It would be interesting to turn the tables and listen in on some of his traffic going to that address.
book recommendation: <a href="http://www.amazon.com/Cuckoos-Egg-Clifford-Stoll/dp/0671726889" rel="nofollow">http://www.amazon.com/Cuckoos-Egg-Clifford-Stoll/dp/06717268...</a>
There will always be the usual crowd of "conservatives-just-for-the-sake-of-being-conservative" crying out whenever this advice is given, but here goes: if possible in your environment, and for your users, just run your SSHd on a non-standard port, and the problem of automated scans will be a non-problem.
<i>cd /var/tmp;</i><p>When I see things like this it makes me think that if standard paths weren't used, then it would it at least make things a little more interesting for the hacker. (They'd have to find a location first.)