At Thu, 29 Sep 2011 11:33:53 +0100, Richard Ibbotson
<richard.ibbotson%googlemail.com@localhost> wrote:
Subject: Re: fail2ban-like tool ?
>
> On Thursday 29 September 2011 11:26:01 Manuel Bouyer wrote:
> > I have a centralized log server, and I'd like to have a real-time
> > analysis tool to block the bad guys at the router level.
> > I looked at fail2ban and it looks like it could do the job, but
> > maybe there's some other tools I'm not awayre of.
> > What are you guys using for this kind of job ?
>
> SSH Guard ?
>
> http://www.sshguard.net/docs/setup/
I'll second that suggestion, though with the caveat that I have not yet
used it on a busy server or loghost, nor will it do "out of the box"
exactly what you mentioned in a later e-mail. I.e. it does not as-is
support any web applications, and depending on the exact format of log
entries from the web application it may also require pre-filtering of
logs. Further it may also require modification to the back-end
interface and some helper scripts to feed firewall changes from the
loghost to the firewall gateway host. I've already modified the IP
Filter back-end to do dynamic-only updates via ipf(8) instead of editing
them into my /etc/ipf.conf file.
It's not exactly trivial to add new log entry patterns to sshguard since
you have to modify its built-in flex+yacc parser, but it's not too
difficult to do either. I think there are some advantages to using
flex+yacc as the log parser, but obviously it also means understanding
at least the basics of flex+yacc, as well as recompiling, to add new
attack signatures.
Another issue with it is that it does not seem capable of matching
across multiple related log entries to get sufficient information to
both identify an event as a part of an attack, and to generate a
blocking rule if necessary.
I.e. as far as I can tell sshguard needs to see both information about
the type of the attack event as well as the source IP address (or
hostname) the attack is originating from all on the same text line. I
have at least one network daemon in production which gives the client IP
and it's child PID on an initial log entry, then any authentication or
authorization failures on a subsequent log entry with only the child PID
to link it to the earlier log entry containing the related source
address. I'll have to have a filter of some sort in front of sshguard
to collate and collapse these related log entries into a single entry
before I can then add a new attack signature for that daemon to
sshguard.
All that said I think I still like sshguard better than any alternative
I've seen to date, and especially better than any implemented in a
scripting language which is not part of the base NetBSD system. It has
some important features described fairly well on its own web site. It
would be even better of course if it were to be improved to allow better
runtime configuration.
--
Greg A. Woods
Planix, Inc.
<woods%planix.com@localhost> +1 250 762-7675 http://www.planix.com/
Attachment:
pgpZqQ75qwgah.pgp
Description: PGP signature