Re: [exim] Handling unadvertised AUTH

Top Page
Delete this message
Reply to this message
Author: Ted Cooper
Date:  
To: exim-users
Subject: Re: [exim] Handling unadvertised AUTH
On 02/05/16 23:16, Phillip Carroll wrote:
> compelling reason to run another log scanning daemon. Actually, I am not
> sure why an exim user would not favor lfd over fail2ban, given that lfd
> has built-in support for blocking AUTH failures.


If you're already running a log scanning daemon, it makes sense to
continue to use it.

I prefer fail2ban over LFD as I don't run CSF. Don't think I'll be
headed down that path.

> The only complicated part is obviously the regular expression itself,
> which is no different with fail2ban.
>
> The most complicated part of the expression appears to be locating the
> IP in the myriad formats of the "H=" part of the log line that exim
> generates. (I have about 75,000 recent examples, obviously with much
> redundancy, but I have counted at least a dozen variations.)


Can always pull all of the regex from the configs of fail2ban.
exim-common.conf includes the H= and pid regex, while the rest is more
specific to task. There's a bit of a macro-ish substitution happening.

We're massively off track for the Exim mailing list at this point ;)

HOST = (?:::f{4,6}:)?(?P<host>\S+)
host_info = H=([\w.-]+ )?(\(\S+\) )?\[<HOST>\](:\d+)? (I=\[\S+\]:\d+
)?(U=\S+ )?(P=e?smtp )?
pid = ( \[\d+\])?

failregex = ^ (plain|login) authenticator failed for (\S+ )?\(\S+\)
\[<HOST>\].*
            ^ SMTP protocol error in .* \[<HOST>\] .* AUTH command used
when not advertised


There are more in the default config files. I'm sure they won't transfer
directly maybe due to quoting and marco-ish, but it does match all lines
in my logfile. Configuration options in Exim can of course alter them.

> The crap I am seeing in that H segment of the log message brings up
> another point. It looks like most of these AUTH attacks have obvious
> stuff in the HELO/EHLO that could/should be rejected to start with.
> Including some HELOs that not only present an IP instead of a server id,
> the IP they present is my own server's IP!


Blocking on known bad HELO is fairly standard fare, and has a good
hit-rate plus low false positive rate. A normal day sees 65%-85%
rejected this way, but can peak higher - I'm a little rough on that as I
don't actually even track raw ip and quoted ip rejects as they are so
numerous.
- raw ip address (especially server's own addresses!)
- quoted ip address (there's zero use case for this from live internet)
- ptr == helo == "generic looking"
- ! ptr && helo == "generic looking"
- ! ptr && ! fwd dns helo
- blocklist

Keep in mind that authenticating users will quite often use a quoted ip
address (and some poor saps use raw ip) for their HELO, prior to auth,
so rejecting early is not a good idea.

Some spam bots also go insane if they are not rejected at RCPT time,
hammering away like a woodpecker at HELO or DATA rejects.