The slow brute zombies are back post details what appear to be distributed SSH password brute force attempts from clouds of compromised systems. This method avoids logscan countermeasures, where attackers making too frequent attempts from a single IP are blocked. pam_tally type blocks will still help, as these are applied at the account level, not source address level. However, the random connection attempts may cause a denial of service to legitimate users then locked out by pam_tally. On the other hand, root or admin should never be used for remote work,† especially to Internet available servers. If the attacker knows or guesses a real account, they can cause problems. Defense in depth should be employed: block SSH except to port knocking sources, or only allow SSH access to users on a VPN. The VPN, in turn, should require at least two factor authentication: a password, and an RSA token, for example.
Where possible, also block or rate limit outgoing Internet traffic: no need to incur the bandwidth costs of illegitimate traffic escaping from your networks, nor the ire of remote sites who see your systems attacking them. Be sure to weigh the benefits of locking down outbound traffic with the risks of disrupting legitimate communications, and the complexities of maintaining a whitelist of permitted outgoing traffic.
† PCI:DSS and other regulations frown upon shared accounts—especially administrative accounts. Excessive use of administrative accounts also increases the risk of a sloppy input causing a lesser or greater disaster, depending on the typo.
