On 4/30/2016 4:05 PM, Ted Cooper wrote:
> On 01/05/16 03:00, Phillip Carroll wrote:
>> All I need to do now is figure out which acl to use and the syntax to
>> test for the AUTH fail, call the csf command, and log the action.
>
> There's a good reason everyone suggested fail2ban at the drop of a hat -
> it's by far the simpler solution.
>
> Extracting "authentication" meaning during ACLs time is going to be
> difficult, if not impossible in some circumstances. Inference might be
> the best it could be inside Exim, using it to create a mirror auth state
> machine. Not sure that is possible or how it would be done as there
> really aren't enough trigger points to follow it.
>
> It's not a portion of the conversation that has good ACL coverage as
> authentication is a multifaceted system and not simply boiled down to a
> single yes/no or location. The ACLs are centred around SMTP commands
> (plus a few extras - acl_not_smtp*, _notquit, _mime, _dkim, etc).
>
> There are a couple of AUTH related ACL - acl_smtp_auth and
> acl_smtp_mailauth - corresponding to the two instances when AUTH can be
> used. The outcome of the ACLs is to accept or deny the AUTH command
> itself, and nothing much related to actual state of user authentication.
> Available state is $smtp_command_argument which will tell the requested
> method. Can infer that client wishes to auth.
>
> Neither of the ACL is run at all if AUTH hasn't been advertised, as Exim
> already knows the outcome. The only indicator here would be that the bad
> command variable has been increased, but again, it can't be directly
> associated with authentication.
>
> The next place to (indirectly) check regarding AUTH would then be
> QUIT/not-QUIT, and MAIL FROM. At both of those points you would be able
> to tell if an advertised host had managed to authenticate or not with
> the assistance of an $acl_c variable set in auth acl. Need more state to
> know if this is really a client to be upset with.
>
> Therein lies the issue with tracking authentication within Exim - there
> isn't enough state or events present to track the full situation. A lot
> of efforts and hacks might get a partial state machine of the situation.
>
> Data for non-SMTP commands (AUTH is one)
> http://www.exim.org/exim-html-current/doc/html/spec_html/ch-access_control_lists.html#SECTdatfornon
>
> The other thought I had for this was the new Events system, but it
> doesn't currently have any triggers around authentication.
> http://www.exim.org/exim-html-current/doc/html/spec_html/ch-events.html
>
> Another point I missed from your OP regarding a custom log file - *nix
> system have no problems with a log file being written to and read from
> at the same time. The tail program will track the end of a file and
> write everything appended to stdout. There's more to it than that, but
> that should help with any log file version of tracking.
>
> fail2ban would work with csf, or any command really. But yes, it does
> use regex and iptables by default - although it does come with a set for
> default configured Exim.
>
>
Ted, thanks for making very clear to me why handling this within exim
configuration is (at least currently) a non-starter. I now see clearly
why all the fail2ban suggestions.
I am not as clear on why I should prefer fail2ban over the custom log
scanning feature in the lfd daemon I already run as part of csf. After
taking a more detailed look at both tools over the weekend, I don't see
any obvious reason to prefer one or the other. The setup for doing the
scan with lfd appears very straightforward. Thus, I don't have a
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.
In lfd, the log filter requires writing a short Perl IF block. I am by
no means expert in Perl, but I think I can handle an isolated IF block.
:-)
An example custom lfd filter looks like:
if (($globlogs{CUSTOM1_LOG}{$lgfile})
and ($line = REGEX)
{
return ("Failed myftpmatch login from",
$1,"myftpmatch","5","20,21","1");
}
where REGEX is the matching regular expression containing a capture
group for the IP. The return values include an identifier message, IP,
ports, how long to block. etc..
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.)
I will post back here the lfd block I come up with. In the interim, I
would appreciate seeing some regex that the folks plugging fail2ban use
for the AUTH not advertised case, if there are actually any out there.
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!
I am going to review the recent thread here that presented some HELO acl
filters.
Phil Carroll
