FR: sendmail8.16-auth support

[asy972]

Environment:

• Fail2Ban version (including any possible distribution suffixes): 0.11.1-alt1

The issue:

Sendmail 8.16 can be build with _FFR_AUTH_FAIL_LOG_USER.
This event is interesting to track via fail2ban.

UPD: Sendmail 8.16.1 released with AUTH_FAIL_LOG_USER by default.

[asy972]

append for jail.conf:

[sendmail8.16-auth]

port    = submission,465,smtp
logpath = %(syslog_mail)s
backend = %(syslog_backend)s

sendmail8.16-auth.conf:

# Fail2Ban filter for sendmail authentication failures
#
# Sendmail 8.16.1 or never is needed
#

[INCLUDES]

before = common.conf

[Definition]

_daemon = (?:sendmail|sm-(?:mta|acceptingconnections))

sendmail_prefix_line = %(known/__prefix_line)s(?:\w{14,20}: )

failregex = ^%(sendmail_prefix_line)s.*: authentication failure: checkpass failed, user=\S+, relay=(?:\S+ )?\[(?:IPv6:<IP6>|<IP4>)\](?: \(may be forged\))?$

ignoreregex =

journalmatch = _SYSTEMD_UNIT=sendmail.service

# Author: Sergey Afonin

[sebres]

Provide a log example, please...

[asy972]

a log example:

Jun 18 04:02:27 relay1 sendmail[16664]: 06I02CNi016764: AUTH failure (LOGIN): authentication failure (-13) SASL(-13): authentication failure: checkpass failed, user=user@example.com, relay=host.example.com [10.1.1.1] (may be forged)

[asy972]

I saw #2751 and updated sendmail8.16-auth.conf according this

[sebres]

Thx!

Fixed in 3f04cba (default sendmail-auth jail is extended with new failregex).
Issue #2751 is solved in other way.

[asy972]

Probably shouldn't have combined these tests into one. The message "possible SMTP attack" is a prepared result of internal Sendmail's diagnostic. The "maxretry" in this case can have the value 1. The "authentication failure" message is generated for each failed attempt and the "maxretry" value should be more 1.

[sebres]

The maxretry serves a bit other needs, it should prevent against possible false positive, for example if a legitimate user doing 3 authentications attempts, mistakenly given wrong user name or password.
The idea is indeed to consider every attempt, so message "authentication failure" must cause single attempt only (counted once).
The message "possible SMTP attack" would just exacerbate this (since I guess it is occurring for recidive users doing multiple tries).

There was some RFE for weighting of several regex (cannot find its number), so if it gets implemented one could set highest weight by "possible SMTP attack" regex to cause immediate ban.

[asy972]

Sorry, I was inaccurate: another string in log possible:

Oct 13 23:14:04 mail sendmail[5976]: 09DJDgOM005976: AUTH failure (LOGIN): user not found (-20) SASL(-13): user not found: checkpass failed, user=user@example.com, relay=host.example.com [10.1.1.1] (may be forged)

So "authentication failure" may be replaced by "user not found" sometimes.

[asy972]

The maxretry serves a bit other needs, it should prevent against possible false positive, for example if a legitimate user doing 3 authentications attempts, mistakenly given wrong user name or password.
The idea is indeed to consider every attempt, so message "authentication failure" must cause single attempt only (counted once).
The message "possible SMTP attack" would just exacerbate this (since I guess it is occurring for recidive users doing multiple tries).

I mean, Sendmail already keeps a record of attempts for the case "possible SMTP attack":

8.12.1/8.12.1   2001/10/01
...
        The maximum number of commands before the MTA slows down when too
                many "light weight" commands have been received are now
                configurable during compile time.  The current values and
                their defaults are:
                    MAXBADCOMMANDS      25      unknown commands
                    MAXNOOPCOMMANDS     20      NOOP, VERB, ONEX, XUSR
                    MAXHELOCOMMANDS     3       HELO, EHLO
                    MAXVRFYCOMMANDS     6       VRFY, EXPN
                    MAXETRNCOMMANDS     8       ETRN
                Setting a value to 0 disables the check.

In this way host can be blocked immediately (i.e. maxretry=1). For the "checkpass failed" case maxretry must be more than 1 of course. Therefore it seems to me that these two options should not be merged now.

[sebres]

In this way host can be blocked immediately (i.e. maxretry=1).

There is still no such possibility to emphasize single regex to cause an immediate ban (but I have some experimental branch doing that, must take a closer look whether it could be backported).
Although an additional jail to do that (with maxretry=1) is possible, but in my opinion a bit too heavy (dual monitoring of same journal for almost the same message format, e. g. prefregex, etc).

[asy972]

in my opinion a bit too heavy (dual monitoring of same journal for almost the same message format, e. g. prefregex, etc).

Yes, I understand this argument. But it seems to me that the file system's cache reduces the problem.

There is still no such possibility to emphasize single regex to cause an immediate ban (but I have some experimental branch doing that, must take a closer look whether it could be backported).

As an temporary alternative I suggest to make three rules: one common and two separate.

[asy972]

Sorry, I was inaccurate: another string in log possible:

And next update... I saw the third variant and now looked to the sendmail's code

#  define LOG_AUTH_FAIL_USER ", user=", (int)MAX_AUTH_LOG_LEN, auth_user

sm_syslog(LOG_WARNING, e->e_id, \
  "AUTH failure (%s): %s (%d) %s%s%.*s, relay=%.100s", \
  (auth_type != NULL) ? auth_type : "unknown", \
  sasl_errstring(result, NULL, NULL), \
  result, \
  SASLERR, \
  LOG_AUTH_FAIL_USER, \
  CurSmtpClient);

I seems the regular expression should look like this

^%(__prefix_line)sAUTH failure \(.*, user=<F-USER>(?:\S+|.*?)</F-USER>, relay=(?:\S+ )?\[%(addr)s\](?: \(may be forged\))?$

[asy972]

Now I saw 4 log's variants:

AUTH failure (login): authentication failure (-13) SASL(-13): authentication failure: checkpass failed, user=
AUTH failure (LOGIN): authentication failure (-13) SASL(-13): authentication failure: checkpass failed, user=
AUTH failure (PLAIN): authentication failure (-13) SASL(-13): authentication failure: Password verification failed, user=
AUTH failure (LOGIN): user not found (-20) SASL(-13): user not found: checkpass failed, user=

[sebres]

Ultimately fixed in 8afea37. Thx!

I seems the regular expression should look like this
^%(__prefix_line)sAUTH failure \(.*, ...

This looks a bit too weak (vulnerable) to me, at least due to the catch-all... We shall stay with more precise regex for now.
The new version seems to match all 4 failures from your previous example (the messages are truncated in your excerpt, but I hope it is correctly covered now).

[SpareSimian]

I'm seeing a lot of log lines that lack the user= part, so the fail2ban regex fails to catch them. Here's an example:

Jul 17 01:22:34 saruman sendmail[25411]: 26H8MRrS025411: AUTH failure (LOGIN): authentication failure (-13) SASL(-13): authentication failure: checkpass failed, relay=[52.229.224.184]

This is on CentOS 7.9 running sendmail 8.14.7 and fail2ban 0.11.2.

I'm able to fix it by adding an optional grouping around the user= part of the regex in my sendmail-auth.local.