Thursday, April 20, 2006

Comments on SSH Security

There were a lot of interesting comments from my SSH post yesterday, both here and on Digg. I'd thought I'd address some of the points raised, and go into a bit more detail on why you should use key-based authentication.

Shallow Defense

One poster advocated leaving password authentication in place, and just using strong passwords. This is a bad idea for a few reasons. First, even if you pick a password strong enough to make brute-force attacks next to impossible, you are still relying on a single authentication factor. Depending on your circumstances, you should take into account non-brute force methods of attack that may compromise passwords, like social engineering or exploiting weaknesses in underlying key-exchange or encryption algorithms. Again, this depends on your circumstances. If you are the only SSH user and are willing to accept the risks of password authentication, it may work fine for you. The idea of not relying on a single authentication method, applying defense in depth whenever possible, underlies the idea of using two-factor (keys + passphrases) authentication. Brute force attacks become impossible without an attacker having your private key.

Automated Blocking

Quite a few posters advocated using password authentication, plus a tool like Denyhosts. I've never been a big fan of methods like this, I think using the security features in SSH itself makes for a simpler and cleaner solution, for a few reasons.

Single Point of Failure

Denyhosts works by periodically scanning your access logs to look for evidence of failed logins. What happens if this process fails (cron dies or software bug), and you haven't taken other steps to secure your SSH installation? It's even worse when you consider that a failure would most likely be silent, so you would think you are protected from brute-force attacks, but would not be.

To the developer's credit, the Denyhosts FAQ lists a few other ways of securing SSH, among them the ones I mentioned in my article yesterday. I would say to just implement key-based authentication, and forget about trying to intelligently block brute-force logins. While the defense in depth principle would say to use both Denyhosts and OpenSSH's security features, once you implement two-factor authentication, brute force attacks become impossible without your private key, so why bother? You could argue that it gives the bad guys a hard time no matter what, and there is something compelling about this, like using greylisting to slow down spammers. However, once you eliminate the possibility of a brute-force attack succeeding, Denyhosts doesn't offer you any more security.

False Positives

Blocking a source IP address is prone to false-positives. An anecdote might illustrate this point - about seven years ago, the Check Point managed security provider I worked with had a policy of adding 'bad guy' hosts to a group that was summarily dropped at perimeter firewalls. A 'bad guy' was anyone who port-scanned back then. The initial process was manual, and it became too time-consuming to add and remove IP addresses from the block lists. Some "port scans" were legitimate traffic, but in some cases were real port scans, just part of security audits. This procedure was eventually dropped as too difficult to maintain. Later, they experimented with Check Point's "Malicious Activity Detection" (MAD), a scheme much like Denyhosts, which was capable of automatically dropping or rejecting traffic sources that matched certain patterns, like port-scans or SYN floods. The problem was that it was too easy to deny valid traffic, and administrators of busy networks would spend too much time un-blocking legitimate users. Like other source-IP blocking methods, it was replaced by methods that filtered application or network-layer content, and summarily dropped traffic that matched certain patterns, regardless of source IP address (these methods still have problems with false-positives, but they don't pick on individual sources, so are easier to manage).

Circumventing the IP Blockers

This is just a thought experiment, but there may be at least one way to circumvent tools like Denyhosts. Consider the attacker that routinely uses something like The Onion Router (TOR), but for arbitrary TCP connections. Every minute or so, their source IP address will change (as seen from the target). The attacker could configure their brute-forcing software to make a few login attempts and wait about a minute before trying again under a new source IP address. They might be able to continually attack a host this way for an indefinite period without notice, depending on the Denyhosts threshold settings. Most admins won't use settings that are too draconian, because of the time spent un-blocking legitimate users who may have just fat-fingered their passwords, so this probably has a good chance of working against non-root accounts for which the failure threshold will be higher, and where strong passwords are not being used. It probably won't work at all against root accounts or where a valid user account is not known. Given the level of underground cooperation among botnet operators, I'd be surprised if this wasn't already being tried, but there is really no way to know (It will also work against purely connection-counting based methods, although in this case, an anonymyzer is not needed, just a way to throttle brute force attempts down to a few per minute).

Anyway, this is not to suggest that Denyhosts is a bad project, or doesn't work. It obviously works well for quite a few people. It's just worth keeping in mind the points I've raised above before leaving password authentication enabled.

Technorati Tags: ,

No comments: