[sf-lug] reasons for running/not running fail2ban

[Rick Moen]

Quoting Alex Kleider (a_kleider at yahoo.com):

> Saturday evening I had an opportunity to discuss fail2ban and Rick gave
> me his views on why he did NOT like to run it. 
> Rick, I hope I am not miss quoting you but here's my understanding:
> 1. the chance that an attacker might by this method actually guess a
> correct name and password pair is minute

This is situation-dependent.  For context:  The threat model we're
discussing is some remote IP iteratively attempting ssh logins, most
commonly carrying out this attempt against entire ranges of target IPs.
The bad guy (or, more likely, the bad guy's bot) either has a list of
known-good usernames (like "rick" being a valid user on host
linuxmafia.com, which isn't difficult to figure out), or merely runs
through lists of likely usernames, and tries some sort of "dictionary
attack":  running through a long list of plausible passwords.

Under those conditions, whether the attack vector is a plausible threat
mostly depends on whether your users employ dumb passwords.  If they do,
and your system runs sshd, your system is dead meat to such attacks.  
(However, then it's pretty much dead meat _with or without_ things like 
Fail2ban.  Fortunately, modern systems check users' proposed passwords
against cracklibs, and prevent them from using the worst sorts of
bonehead passwords -- absent the root user overriding that protection.)

If _none_ of your users employs dumb passwords, then attempting to
brute-force them through a dictionary attack is not a credible threat:
Statistically, matching one of your password would simply take way, way
too long for the attempt to be even worthwhile.  Also, statistically,
you'd notice the attempt way, way, way before it succeeded, because 
your hard disk would fill up from the unbelievably large sshd logfiles.

> and
> 2. you don't like the idea of a program having input into your
> iptables.

1.  Automatic processes creating iptables entries in response to 
(alleged) attacks makes _me_ nervous.  Doesn't it do the same for you?
Wouldn't you be concerned about someone making your own system DoS
itself in any of various ways, ranging from bloating your iptables
ruleset and destroying system performance to (via forged traffic)
causing your system to null-route an IP you _want_ to talk to.

2.  Running complex code with a high degree of privilege, especially
for no compelling purpose, makes me nervous, too.

3.  And, let's face it, the "attack" in question doesn't, in reasonable
perspective, even qualify as an attack at all:  It's just some shlub's
bot script (metaphorically) twisting your doorknob.

It's common for people new to *ix and to security to lose perspective
and resort to bad countermeasures against vastly overstated threats.
Fail2ban is one such bad countermeasure; Port Sentry is another and has
pretty much the same set of drawbacks.  Here's an essay explaining that:
http://www.linux.ie/articles/portsentryandsnortcompared.php

(In broad terms, throwing software at a threat you don't even understand
in the first place is far more likely to make matters worse than not.)


> I was discussing this with a friend and his comment was that it isn't
> against repeated password attempts that we are trying to protect
> ourselves; it's against denial of service. 

Ironically, such measures are a major DoS threat, themselves.

> My understanding is that it's against someone who is not actually
> expecting to log on, but against someone that just is trying to
> overwhelm your resources.

One of the reasons I said a dictionary attack against an sshd isn't a
credible threat model (assuming no use of chump passwords) is that each
login attempt is inherently quite slow.  In consequence, someone's scripted
attempt to dictionary-attack your sshd isn't an efficient way to DoS
it or your system.  If someone _does_ wish to DoS your system, that's
not how he/she will do it; he/she will use some vastly more efficient 
means of flooding it with traffic, such as just running a script that 
uses netcat to hammer one of your daemons with traffic -- or just try to
blitz your kernel's TCP/IP stack to the extent that it is overwhelmed.


> I'd be interested in comments regarding these issues.

Please note:  Questions like yours often lead to tedious flamewars, when
all the software gadget freaks[1] emerge to argue the merits of their
security gimmicks against the above sysadminly objections.  I've
attempted to qualify what I say (above) carefully to not leave any
obvious opening for that ritualised discussion, but think there's still
a chance that badness will ensue.

[1] Online discussions of security often to devolve to standoffs between
enthusiasts for overcomplicated and overengineered solutions, on the one
hand, and seasoned system administrators and security people on the other.
I tend to refer to the former sort as "gadget freaks" -- and am not in 
their camp.