Guest post by One common method attackers use when attempting to compromise a server is brute forcing login credentials. Given enough time, automated tools can guess a person’s username and password, granting the attacker access to an unprotected server. To counter these sorts of attacks, where passwords are guessed by trial and error, several tools have been created. Utilities such as Fail2Ban and DenyHost monitor login attempts and automatically block the computers performing these types of attacks.
Last week the DenyHost project added a feature which allows the utility to block attacks by using the PF firewall. PF is typically used on the OpenBSD and FreeBSD operating systems to block or forward network traffic. The project’s website reports:
DenyHost 2.9 adds one new feature, the ability to work with the PF packet filter, popular on BSD systems such as FreeBSD, OpenBSD, NetBSD, PC-BSD and TrueOS. The DenyHost daemon will now work with existing PF tables in real time, allowing administrators to block incoming secure shell connections at the firewall level. Examples of how to set up the appropriate PF rules and enable DenyHost to work with PF are available in the DenyHost configuration file (denyhosts.conf).
Neat
…just use public key authentication for ssh and you don’t have to worry about brute forcing anymore.
Plus PF already has a rate-limiting feature built-in that does pretty much what fail2ban/denyhost does.
Edited 2014-11-11 05:12 UTC
For many people public-key authentication is not practical. Especially if you travel a lot, it would be a shame if losing your USB stick meant you couldn’t access your server anymore.
Also, rate limiting and the filtering DenyHost/Fail2Ban aren’t really the same thing. There is some overlap, but they perform quite different tasks. Rate limiting via PF slows down connection rates which is really good in a distributed attack, but it does not block the attack. An attacker can continue to guess passwords for weeks or months, the attack just slows down a little. DenyHost quickly blocks attacks from specific remote machines after just three failed login attempts. This makes DenyHost (and Fail2Ban) must bette at thwarting drive by attacks.
As an example, I use both rate limiting and DenyHost on my servers. With rate limiting brute force attacks continue for hours since the attacker isn’t stopped, just slowed down. But once DenyHost is added, each attacker only gets three tries and then the attack is stopped. This reduces traffic to the server, reduces “spam” in the logs and reduces the chance of an attack succeeding.
Connection filtering using PF is good, but it is not a replacement for a tool like DenyHost.
Well, all I have to say is, if you’re not using keys you’re doing it wrong. Ok, I’ll admit that there are corner cases where you want password authentication but those are very rare. Most of the time it’s just that people don’t want to use keys, doesn’t know it exist or haven’t taken the time to set it up (which takes no time at all).
Be that as it may, you still don’t need denyhost though.
You’re wrong, it does exactly that. After X number of connection attempts in Y seconds the offending IP can be added to a table that is used in a block rule. It works very, very well and there’s no need for an external program to do it.
http://home.nuug.no/~peter/pf/en/bruteforce.html
Edited 2014-11-12 06:55 UTC
I see brute force attacks all the time on production servers. I’ve toyed with the idea of redirecting attacks to honeypots for which the attack will have a very high likelihood of succeeding.
This would do two things, it could possibly reveal more information about the attacker. The brute force session is completely automated, but subsequent logins may be backed by real humans. Or at least it would reveal more information about the payload.
But the second thing is, I’m guessing that a successful login into a honeypot would have a greater chance of actually stopping the automated attack at the source rather than merely blocking it at the destination.