[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: fail2ban vs. syslogd compression

Hi there,

On Tue, 28 Aug 2007, Maxim Kammerer wrote:

> I believe this belongs to the security-mailing list.

Agreed. :)

> ... pop3-cracking attempts ... stupid ...

There's a lot of it about.  They'll try ftp, irc, ssh and http as
well.  In fact they'll try anything that offers them a connection.
There's a moral in there somewhere.

> ... fail2ban didn't respond. ... 'last message repeated 4 times',
> which is not helpful at all to fail2ban.

You might call that a bug in fail2ban, but I think the authors are
aware of the issue and it's not necessarily very easy to deal with.


You need to be careful that the 'last message repeated' really was the
last message you saw from the log stream.  Messages from multiple log
relays could easily confuse the logging process(es), so it's best to
deal with it upstream.

> However, I consider it a realworld scenario that a cracker/script
> kiddy would hit the server in a short time.

It does happen. :(

> I then sought to disable this kind of log compression

I've seen 'Last message repeated 3785 times'.  =:0

> So I ended up with not knowing what to do and turned to the debian
> security list. you people have any idea, or what are you doing?

On our public servers we use syslog-ng, partly because it doesn't do
message aggregation but mostly because it's more easily configured
than the usual syslogd.

We rolled our own log message analysis tools.  Connections (+attempts)
are piped via syslog-ng through Perl scripts.  Including a generous
amounts of commenting and whitespace there are about 1700 lines of
Perl, so it's quite a bit of work but it saves an enormous amount of
time trawling logs and stops much skulduggery.  (M-x ispell-word... :)

This is mostly about stopping spam, and blocking on IP stops over 90%
of spam attempts, but attempts to hack our Webservers is also an issue.
As you say, they're stupid.  Most attacks are attempts to compromise
Microsoft software - we don't run any - and the bulk of the rest are
either attempts to exploit known vulnerabilities in PHP, Cacti and
other stuff that we also don't run, or attempts to use our servers as
free proxies.

The scripts log to a database, maintain hashes of the connections with
some timeouts, implement port knocking for ssh access, and other stuff
like that.  We block an IP (using iptables & ipsets) at the slightest
provocation and we never block less than a /24 range.  Most offenders
are blocked permanently, at the last count we're blocking about 27,750
ranges.  Our scripts could handle the 'repeat' messages if they needed
to, but they don't.  The script kiddies don't get five tries, we block
them after the first. :)



Reply to: