Valid CSS Valid HTML 4.0 Transitional

Defending Against Password Guessing

James F. Carter, 2008-06-20

The key issue for authentication is, we want our own users to be able to do normal activities on Mathnet machines, and we want unauthorized hackers to be able to do only standard public activities. The activities include:

Requires Authorization

Public Services

The Threat

Mathnet and other institutions are experiencing frequent password guessing attacks against the SSH service, and FTP is also attacked less frequently. The passwords used are pretty lame and if we enforce password strength rules we should be able to resist such attacks, but sooner or later either our user will get a weak password past the strength rules, or the attacker will get lucky guessing a strong password.

Password guessing attacks, even if not successful, use quite a bit of system resources, interfering with normal operation, and we want to put a stop to this.

While password guessing against SSH is the current nemesis, it's only a matter of time before other authenticated services are attacked. FTP is already being worked on, and IMAP or POP is the hackers' logical next target.

In addition, recently we had one user whose password, we believe, was obtained by a keystroke logger on another network. We would like to resist attacks even when the attacker has the authentic credential.

Requirements for a Defense Scheme

Types of Defense Schemes

Resistance Mechanisms

Getting On the Blacklist

Basically, something looks for frequent login failures from the same host. There are two easy sources of failure information:

Getting On the Whitelist

For the whitelist method attacks are suppressed by default and the problem is to allow legitimate users to get in. The client needs to send something to the server that induces the server to trust the client and add it to the whitelist. This authorization would expire after a certain time, either time after authentication or after a period of non-use.

Global Variant

I've assumed that each server will demand authentication from each client or will recognize and blacklist attackers independently. However, we could set up a global server which would manage a whitelist or blacklist that protects the entire Mathnet at once. There are several styles for this:

Recommendations for Action

At this point we're not ready for production deployment; the idea is to set up some software and estimate how well our users will like it.

I think the whitelist approach gives the most draconian protection for the least effort. There are several blacklist-type protection programs, but the one we're most seriously considering is only effective for SSH attacks, and although that is our currently obvious problem, if we're going to go to the trouble of improving our defenses, we ought to protect against future attacks as well.

The whitelist method also gives us protection for the videoconference equipment, which is notoriously hard to lock down; H.323 is bad in any case. A globally effective whitelist also protects Windows boxes while allowing unusual or advanced techniques like RDP, with no need to adjust Windows firewall rules on the target machine.

Let's set up the per-machine whitelist, and in parallel, investigate a chokepoint router running Linux, which is the preferred router if we want a globally enforced whitelist (or blacklist).

Let's create a CGI to accept the web form (using SASL/PAM for the actual authentication engine, following the model of the Certificate Authority). We'll protect all the MCG Linux boxes, and the MCG people can evaluate the procedure. Then we'll sell it to early adopters such as Anderson and Bertozzi, who may particularly value security. Finally, assuming it's satisfactory, we'll roll it out for the whole department.


stunnel with thttpd. thttpd does not support SSL natively, but you can get inetd to spawn stunnel which will accept the SSL connection, then pipe it to your favorite web server on whatever port you choose. The server then speaks normal HTTP. There is a SuSE package for stunnel.