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.
