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. -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
