fail2ban not catching SMTP password brute force attack

Question

Spammers are running brute force password guessing attacks on my server (postfix on Debian). They have already guessed two user's passwords and started sending spam using my server. Passwords changed and attacks mitigated (for now), but I want to block them completely.

I installed fail2ban, but for some reason it fails to detect the attacks.

/etc/fail2ban/fail.conf contains:

[sasl]

enabled  = true
port     = smtp,ssmtp,submission,imap2,imap3,imaps,pop3,pop3s
filter   = sasl
# You might consider monitoring /var/log/mail.warn instead if you are
# running postfix since it would provide the same log lines at the
# "warn" level but overall at the smaller filesize.
#logpath  = /var/log/mail.log
logpath  = /var/log/mail.warn

/etc/fail2ban/filter.d/sasl.conf contains:

# Fail2Ban configuration file
#
# Author: Yaroslav Halchenko
#
# $Revision$
#

[Definition]

# Option: failregex
# Notes.: regex to match the password failures messages in the logfile. The
#          host must be matched by a group named "host". The tag "<HOST>" can
#          be used for standard IP/hostname matching and is only an alias for
#          (?:::f{4,6}:)?(?P<host>[\w\-.^_]+)
# Values: TEXT
#
failregex = (?i): warning: [-._\w]+\[<HOST>\]: SASL (?:LOGIN|PLAIN|(?:CRAM|DIGEST)-MD5) authentication failed(: [ A-Za-z0-9+/]*={0,2})?\s*$

# Option:  ignoreregex
# Notes.:  regex to ignore. If this regex matches, the line is ignored.
# Values:  TEXT
#
ignoreregex =

When I run the filter on /var/log/mail.warn, it produces results:

# fail2ban-regex /var/log/mail.warn '(?i): warning: [-._\w]+\[<HOST>\]: SASL (?:LOGIN|PLAIN|(?:CRAM|DIGEST)-MD5) authentication failed(: [ A-Za-z0-9+/]*={0,2})?\s*$'

Running tests
=============

Use regex line : (?i): warning: [-._\w]+\[<HOST>\]: SASL (?:LOGIN|P...
Use log file   : /var/log/mail.warn


Results
=======

Failregex
|- Regular expressions:
|  [1] (?i): warning: [-._\w]+\[<HOST>\]: SASL (?:LOGIN|PLAIN|(?:CRAM|DIGEST)-MD5) authentication failed(: [ A-Za-z0-9+/]*={0,2})?\s*$
|
`- Number of matches:
   [1] 15293 match(es)

Ignoreregex
|- Regular expressions:
|
`- Number of matches:

Summary
=======

Addresses found:
[1]
    123.169.7.222 (Sun Feb 25 06:40:18 2018)
    123.169.7.222 (Sun Feb 25 06:40:21 2018)
...
    185.173.176.157 (Fri Mar 02 10:12:46 2018)
    185.173.176.157 (Fri Mar 02 10:13:15 2018)
    185.173.176.157 (Fri Mar 02 10:13:43 2018)
    185.173.176.157 (Fri Mar 02 10:14:11 2018)
    185.173.176.157 (Fri Mar 02 10:14:41 2018)
    185.173.176.157 (Fri Mar 02 10:15:13 2018)
    185.173.176.157 (Fri Mar 02 10:15:42 2018)
    185.173.176.157 (Fri Mar 02 10:16:13 2018)
    185.173.176.157 (Fri Mar 02 10:16:42 2018)
    185.173.176.157 (Fri Mar 02 10:17:10 2018)

Date template hits:
34294 hit(s): MONTH Day Hour:Minute:Second
0 hit(s): WEEKDAY MONTH Day Hour:Minute:Second Year
0 hit(s): WEEKDAY MONTH Day Hour:Minute:Second
0 hit(s): Year/Month/Day Hour:Minute:Second
0 hit(s): Day/Month/Year Hour:Minute:Second
0 hit(s): Day/Month/Year Hour:Minute:Second
0 hit(s): Day/MONTH/Year:Hour:Minute:Second
0 hit(s): Month/Day/Year:Hour:Minute:Second
0 hit(s): Year-Month-Day Hour:Minute:Second
0 hit(s): Year.Month.Day Hour:Minute:Second
0 hit(s): Day-MONTH-Year Hour:Minute:Second[.Millisecond]
0 hit(s): Day-Month-Year Hour:Minute:Second
0 hit(s): TAI64N
0 hit(s): Epoch
0 hit(s): ISO 8601
0 hit(s): Hour:Minute:Second
0 hit(s): <Month/Day/Year@Hour:Minute:Second>

Success, the total number of match is 15293

However, look at the above section 'Running tests' which could contain important
information.

Despite all of that, /var/log/fail2ban.log does not show blocking of the offending IP address.

Update

Following suggestions, I've increased the log level. This shows:

2018-03-02 12:47:55,920 fail2ban.filter : DEBUG  Processing line with time:1519986602.0 and ip:185.173.176.157
2018-03-02 12:47:55,920 fail2ban.filter : DEBUG  Ignore line since time 1519986602.0 < 1519987675.92 - 600
2018-03-02 12:47:55,920 fail2ban.filter : DEBUG  Processing line with time:1519986635.0 and ip:185.173.176.157
2018-03-02 12:47:55,920 fail2ban.filter : DEBUG  Ignore line since time 1519986635.0 < 1519987675.92 - 600

The jail.conf has:

bantime  = 600
maxretry = 3

A shot in the dark: did you get the threshold right? I mean, f2b may properly detect these attacks but its logic is that the IP is only banned if it had `X` unsuccessful attempts in `Y` timespan, that is, with some rate `X/Y`. If this threshold is too low in your case (i.e. the attack is properly spread in time), fail2ban won't consider this to be an attack. IOW, if fail2ban would ban on every match of its criteria, the users which legitimately failed to type their password would be banned right away. — kostix, Mar 02 '18 at 09:37
Consider raising the f2b's loglevel (set `loglevel` to `4`) for debugging. — kostix, Mar 02 '18 at 09:38
From `Ignore line since time 1519986602.0 < 1519987675.92 - 600` and [the docs](https://www.fail2ban.org/wiki/index.php/MANUAL_0_8#Jail_Options), I think that `600` is the value of the `findtime` option. That is, crack attempts from a given IP seem to come in strides larger than `findtime`, and hence get ignored by `fail2ban`. `1519987675.92-1519986602.0` is `1073.92` or circa 18 minutes. — kostix, Mar 02 '18 at 13:24
@kostix Can you write that as an answer so I can accept that? The (bad word censored) adapt their scanning speed to my settings. Fine, I will let them scan 24 passwords a day and see how long it takes them to crack one. — Shachar Shemesh, Mar 02 '18 at 18:45
May I recommend you to put TLS authentication in place? I mean, mandate TLS on the outside and require validation of the certs presented by the clients. You may need to create and support your own CA (the `easy-rsa` package may help) but in return this solution will be pretty much bullet-proof against password guessing. — kostix, Mar 02 '18 at 19:12
I don't see that fitting in to the deployment I do to my target audience (in particular, my parents). It's not a bad idea, it's just one that is not practical. Kinda like all other TLS deployment ever. With letsencrypt, I don't even think it needs to be a private CA. — Shachar Shemesh, Mar 02 '18 at 19:15
One thing I might do, however, is have an SMTP authentication username that is different than the email address for which it belongs. Even that might prove beyond the capabilities of my target audience. — Shachar Shemesh, Mar 02 '18 at 19:16

score 3 · Accepted Answer · answered Mar 02 '18 at 19:16

From the Ignore line since time 1519986602.0 < 1519987675.92 - 600 log record and the docs, I conjure that 600 is the value of the findtime option. That is, crack attempts from a given IP seem to come in strides larger than findtime, and hence get ignored by fail2ban.

1519987675.92-1519986602.0 is 1073.92 or circa 18 minutes.

A bullet-proof solution would be mandating the usage of TLS on the Internet-facing interface and mandating verification that the certificates presented by the clients are issued by a trusted CA.

fail2ban not catching SMTP password brute force attack

1 Answers1