On Wed, Aug 15, 2012 at 12:25:33AM +0200, Michelle Konzack wrote:
> Hello Gregor Hermens,
>
> Am 2012-08-14 17:15:41, hacktest Du folgendes herunter:
> > Am Dienstag, 14. August 2012 schrieb Jean-Christian BEDIER:
> > > Fail2ban is a bad choice if you have customers who use this imap server.
> > why that? You just have to change the configuration to fit your needs, as with
> > every other software...
>
> How dou you do this, if fail2ban does this by IP and you are on a
> dynamic IP like DSL or GSM?
fail2ban works by monitoring the log files for the application and
matching them against two sets of regexes, one to act on and one to
ignore. If it detects more than x forbidden actions in y seconds it
bans the originating IP for z seconds. You have a separate config file
for each combination of application and type of abuse. You can also
set up different actions to execute as a "ban" - it doesn't have to be
an iptables action, it can be anything executable.
Configuring it is basically a matter of configuring the logging
settings on the application you're monitoring to make sure that its
log entries contain enough information to distinguish between abusive
and non-abusive actions by means of matching against two sets of
regexes, creating a fail2ban config file containing appropriate
regexes, and choosing suitable values for x, y and z. It can be made
to consider many different kinds of activity as "abuse", not just
failed logins - I use it to block idiots in China who perform multiple
repeated downloads of the same large video file deliberately in order
to waste the decadent West's bandwidth. The main drawback with it is
that apart from the single count of forbidden actions for each IP, it
is stateless, so you can't write rules like "consider action A abusive
only if it is not preceded by action B". (At least not
straightforwardly; it is possible with some hacks eg. defining a
separate trigger corresponding to each element of the rule, whose
associated "ban action" stores/retrieves state.)
You could write three versions of the config file for a particular
kind of abuse - one which uses IP regex matching to blacklist
troublesome IP blocks and ban them aggressively, one which whitelists
IP blocks of customers and is lenient, and one of intermediate
severity to handle everything else. Or, if the application you're
monitoring has suitable white/blacklisting and logging facilities,
have the application tag its log entries to indicate a white- or
blacklisted IP/IP block, which is probably less computationally
expensive for non-trivial lists :)
From what you say of the abuse pattern you're seeing, though, it may
well be possible to get away with a less complicated setup and simply
discriminate on the number of abuse records in a given time. As long
as the application you're monitoring creates sufficiently informative
log entries to distinguish between successful and unsuccessful login
attempts - which I suspect we can take as a given :) - it ought to be
easy to pick a figure which would be rapidly exceeded by a brute force
attack, but would still allow for enough mistyped/misremembered
password attempts for even a thoroughly inept genuine user.
--
Pigeon
Be kind to pigeons
Pigeon's Nest - http://pigeonsnest.co.uk/
Lucy Pinder Television - http://www.lucy-pinder.tv/
GPG key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x21C61F7F
Attachment:
signature.asc
Description: Digital signature