[sf-lug] reasons for running/not running fail2ban
a_kleider at yahoo.com
Tue Feb 12 17:40:36 PST 2008
--- Rick Moen <rick at linuxmafia.com> wrote:
<a lot of security related stuff>
Thank you very much, Rick.
I appreciate your taking the time to explain your position on these
matters: as always, if one takes the time to go through it it leads to
a much better understanding of the issues.
ALSO thank you for your help with Screen: I've been playing with it
today and successfully resumed a session at home that I had (this time
purposely) left unfinished at work- I would have never known that the
facility exists and yet you use it all the time....
How often do I find myself saying about Linux: "cool!" Often! :-)
ps hope there are no flame wars
> Quoting Alex Kleider (a_kleider at yahoo.com):
> > Saturday evening I had an opportunity to discuss fail2ban and Rick
> > 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
> > 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
> 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
> mostly depends on whether your users employ dumb passwords. If they
> 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
> Fail2ban. Fortunately, modern systems check users' proposed
> against cracklibs, and prevent them from using the worst sorts of
> bonehead passwords -- absent the root user overriding that
> If _none_ of your users employs dumb passwords, then attempting to
> brute-force them through a dictionary attack is not a credible
> Statistically, matching one of your password would simply take 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
> > 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
> 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
> perspective, even qualify as an attack at all: It's just some
> 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
> pretty much the same set of drawbacks. Here's an essay explaining
> (In broad terms, throwing software at a threat you don't even
> in the first place is far more likely to make matters worse than
> > I was discussing this with a friend and his comment was that it
> > 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
> login attempt is inherently quite slow. In consequence, someone's
> 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
> blitz your kernel's TCP/IP stack to the extent that it is
> > I'd be interested in comments regarding these issues.
> Please note: Questions like yours often lead to tedious flamewars,
> all the software gadget freaks 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
> a chance that badness will ensue.
>  Online discussions of security often to devolve to standoffs
> enthusiasts for overcomplicated and overengineered solutions, on the
> hand, and seasoned system administrators and security people on the
> I tend to refer to the former sort as "gadget freaks" -- and am not
> their camp.
> sf-lug mailing list
> sf-lug at linuxmafia.com
a_kleider at yahoo.com
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
More information about the sf-lug