ClearFoundation Tracker - ClearOS
View Issue Details
0022541ClearOSapp-imap - IMAP and POP Serverpublic2018-12-10 14:352019-05-03 02:01
NickH 
NickH 
normalminoralways
closedfixed 
7.5.0 Updates 
7.5.0 Updates7.5.0 Updates 
0022541: filter for cyrus-imap jail does not work
The default filter for the cyrus-imap jail in /etc/fail2ban/filter.d/cyrus-imap.conf does not work on our logs. The filter is:
failregex = ^%(__prefix_line)sbadlogin: \S+ ?\[<HOST>\] \S+ .*?\[?SASL\(-13\): (authentication failure|user not found): .*\]?$

Typical failure lines are POP failed logins are:
Dec 7 15:39:29 mail pop3[21087]: badlogin: [129.145.7.35] plaintext champagne SASL(-13): authentication failure: checkpass failed
Dec 7 15:39:29 mail pop3[21089]: badlogin: [129.145.7.35] plaintext harold SASL(-13): authentication failure: checkpass failed
Dec 7 15:39:29 mail pop3[21090]: badlogin: [129.145.7.35] plaintext crystal SASL(-13): authentication failure: checkpass failed
Dec 7 15:39:29 mail pop3[21088]: badlogin: [129.145.7.35] plaintext bob SASL(-13): authentication failure: checkpass failed

These do not get detected.

If the filter is changed to:
failregex = ^%(__prefix_line)sbadlogin: .*\[<HOST>\] \S+ .*?\[?SASL\(-13\): (authentication failure|user not found): .*\]?$

the lines are then detects. The problem is the first \S (non-whitespace character) where our logs only have a space between "badlogin:" and the IP address. If you change the \S for a ".*", everything that would have been picked up by the first filter still gets picked up, and our log failures get detected.

There seem to be three approaches to fix this:
1 - get upstream to fix (good luck)
2 - add an /etc/fail2ban/filter.d/cyrus-imap.local with a modified filter. This is what I do (and have done for a couple of years)
3 - add a filter to /etc/fail2ban/jail.d/clearos-cyrus-imap.conf. I don't know if this will work, but I think it will. I think it takes precedence over /etc/fail2ban/filter.d/cyrus-imap.conf but defers to /etc/fail2ban/filter.d/cyrus-imap.local which should be under the user's control. This needs testing, but would be the ideal route as ClearOS can override upstream and the user can still override ClearOS.
No tags attached.
Issue History
2018-12-10 14:35NickHNew Issue
2018-12-11 02:38NickHCategoryapp-attack-detector - Attack Detector => app-imap - IMAP and POP Server
2018-12-11 04:37NickHNote Added: 0008691
2018-12-14 12:36dloperTarget Version => 7.5.0 Updates
2018-12-14 12:37NickHNote Added: 0008721
2019-02-01 12:31NickHNote Added: 0008791
2019-02-01 12:31NickHStatusnew => resolved
2019-02-01 12:31NickHFixed in Version => 7.5.0 Updates
2019-02-01 12:31NickHResolutionopen => fixed
2019-02-01 12:31NickHAssigned To => NickH
2019-05-03 02:01NickHStatusresolved => closed

Notes
(0008691)
NickH   
2018-12-11 04:37   
I have subsequently determined that the issue could also be fixed by pushing fail2ban-server-0.9.7-1.el7.noarch through from epel-unverified.

In that case my patch to app-imap can be backed out.
(0008721)
NickH   
2018-12-14 12:37   
Now fixed as app-imap-2.5.8 in updates testing.
Also needs fail2ban-server-0.9.7 from epel unverified
(0008791)
NickH   
2019-02-01 12:31   
Resolved by releasing fail2ban-server-0.9.7 from ELEP