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

[Alex Kleider]

--- 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! :-)

alex
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
> 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.
> 
> 
> _______________________________________________
> sf-lug mailing list
> sf-lug at linuxmafia.com
> http://linuxmafia.com/mailman/listinfo/sf-lug
> 


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