On 07/28/2015 03:06 PM, Chris Adams wrote: > Once upon a time, Warren Young <wyml at etr-usa.com> said: >> Much of the evil on the Internet today — DDoS armies, spam spewers, phishing botnets — is done on pnwed hardware, much of which was compromised by previous botnets banging on weak SSH passwords. > Since most of that crap comes from Windows hosts, the security of Linux > SSH passwords seems hardly relevant. > I happen to know from firsthand experience that SSH slow bruteforcers on Linux are a significant portion of the 'botnet' traffic out there. How do I know this? From a hacked Linux server which was brute-forced and conscripted into being a slow bruteforcer node back in 2009 or so. The particular payload that was dropped on that box was dropped into a normal user account with a moderately strong (but obviously not strong enough) password, and the code never even attempted to escalate privileges. It didn't need to; the slow bruteforcer started and ran as the normal user account and actively attacked other hosts. It did not attempt to install a rootkit and it ran as a normal user with a program name of something that was not out of the ordinary. It did not trigger our rootkit detector or file modification monitors, since normal user directories aren't normally monitored. Again, the attack vector was a relatively weak password (mixed case, letters and numbers, but less than ten characters long). And it ran slow enough that neither snort nor fail2ban were triggered. While I am not at liberty to share the specifics of the code or the huge password files it contained, nor can I share the log files, given the amount of traffic generated and its patterns it is pretty easy to figure out that it was part of a very large operation. Due to this we now block outgoing (and incoming) SSH on port 22 by default now, opening holes only upon request (and we're small enough to make that practical). A quick analysis of the code showed some polymorphism in use. The particular slow bruteforcer I found has been adequately documented elsewhere, so I won't go into more details here. But suffice to say that the password file included some very long and random-looking passwords, along with a million words and regexes (a mixed letters and numbers password with '1337' (leet) spelling should be considered as easy to break as that same password spelled with letters only). And looking through my logs I could see attempts on several user ID's from entirely unique IP addresses; no IP address was used more than once. Better enforcement of password policy on that server would have prevented the attack from succeeding and the machine becoming an attacker itself.