On 07/28/2015 03:06 PM, Chris Adams wrote:
Once upon a time, Warren Young <w...@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.
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
