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
--
## 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/
