Most operating systems have a time-tested method for fighting brute-force password attacks, but with a downside. Some equation involving the number of attempts over some amount of time results in password lockouts for another amount of time. If the settings are too lax, you risk an attacker having enough chances of guessing a correct password. If your settings are too tight, it can cost your support desk extra load or worse.  Many applications do not have access to these operating system controls though.

How easy is it to guess a correct password? A little background information will help. In 1956, George Miller published a paper in the Psychological Review in which he maintained that human information processing capacity is limited to at most seven, plus or minus two, chunks of information. If we chose truly random passwords, each character would be one chunk. But we do not! In fact, of the 76 easily-typed symbols (for English, this includes upper- and lowercase letters, numbers and symbols), research shows that 80% of the symbols used in passwords are chosen from only 32 of those, and, 10% of passwords are comprised solely from those 32 symbols. For the curious, those 32 symbols, in order of occurrence, are:

ea1oirn0st2lud!m3hcyg94kSbpM758B

Although a truly random nine-character password is very difficult to crack, our passwords are not usually very random and therefore much weaker. Given how much information is protected by passwords, many have argued that we should ban them in favor of passphrases, which are easier to remember and can be stronger than shorter, random passwords.

Also see Bruce Schneier’s article entitled Secure Passwords Keep You Safer for more information about the importance of choosing good passwords.

That’s all fine and good for operating systems, but what about applications that aren’t normally protected by such measures? Well, if you’re running Linux, you should consider Fail2Ban. It scans logfiles looking for evidence of break in attempts, and if found, takes some configured action. Normally this will involve creating a firewall rule to deny access from the offending IP address for some amount of time. Of course, some form of logging and notification is also possible. Configuration support exists for a fairly broad array of services, including sshd, apache, and various MTAs.

Nice, you say — yeah, go right ahead and enable that! As always, think about your use cases and the consequences of the actions taken. An attacker (or poor typist) behind a NAT’ed IP address can easily create havoc for other users behind that same address. If that happens by mistake at a branch office, for example, all other users at the location would be prevented from communicating with the affected service. Fail2Ban does have some sophisticated configuration capabilties, but the defaults appear a bit draconian to me. For example, if someone at an IP address fails to successfully authenticate to SSH several times, the default iptables rule drops all SSH traffic from that IP address. From the Internet at large, this seems just fine, but from a NAT’ed address (again, say a branch office), that can have disasterous effects for other valid users. If you have the need, consider modifying the iptables rules to just filter TCP SYN packets (or new UDP flows, e.g. --state NEW); of course this will not work for services that do not reset TCP connections following some number of failed authentication attempts. A better approach may be to customize the failed authentication regular expression to only log and notify for failed attempts from some sources, while blocking from others.

Some have advocated using a PAM module, such as pam_tally to lock accounts — again, for services that use PAM authentication. I actually like the Fail2Ban approach better — if you lock an account, you have potential for a denial of service attack. If you lock an IP address, you may have much risk at all for impacting crucial services. You can always consider layering both approaches.

The bottom line — think about what the proposed action might mean for you, and consider several use cases and not just the obvious remote script-kiddie/robot!

Advertisements