False positives on "imaps TLS negotiation failed: [46.33.111.111]"

[Alex Bligh]

I am seeing several lines in my mail log from cyrus imapd with the text (IP address changed)

May 22 21:40:24 shed cyrus/imaps[1076589]: imaps TLS negotiation failed: [46.33.111.111]

These are treated as an attack. I am pretty sure what is happening here is that the user concerned (who appears to have somewhat poor internet connectivity) is occasionally timing out on TLS negotiation, generating that error message. They seem to be on a static-ish IP (changing once every couple of months), so once a month the same user gets their IP address blocked. Looking at surrounding log lines, it is always the same user, who successfully authenticates shortly before and shortly after from the same IP.

This seems like a bug, because failed TLS negotiations due to timeout are not really an attack - there are just what we expect in imperfect connectivity conditions. Especially as ssh guard does not discard the resultant “badness” if there is a successful login subsequently from that IP.

If it’s not a bug, is there a way for me (locally) to stop that match occurring while leaving the rest in place?

System details:

Linux shed 5.4.0-104-generic #118-Ubuntu SMP Wed Mar 2 19:02:41 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
ii sshguard 2.3.1-1ubuntu1.1
ii cyrus-imapd 3.0.13-5
ipset backend
/usr/lib/x86_64-linux-gnu/sshg-blocker -a 30 -b 100:/var/run/sshguard.blacklist -p 600 -s 7200 -w /etc/sshguard/whitelist

‌

[Kevin Zheng]

Can you still reproduce this with the latest version?

Or, would you mind running echo "your attack here" | sshg-parser -d and paste the output here?

[Alex Bligh]

I’ve attached what you have asked for below with the same light obfuscation of the IP address concerned.

Further investigation indicates however it looks like the change might have been committed here:

https://bitbucket.org/sshguard/sshguard/commits/d3eca20441572dd261ff6db5153a7f28329bd07b

then reverted here:

https://bitbucket.org/sshguard/sshguard/commits/f3258b752c01b799c78b2e02de6dcba856f94028

and the reason for the reversion seems to be “Client attempts to negotiate tls 1.0 or tls 1.1 will generate this exact pattern.”

I’m using Ubuntu 20.04 LTS which is reasonably modern (I’m not even sure an upgrade to 22.04 is possible yet), and appears to carry the commit but not the revert.

# lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 20.04.4 LTS
Release: 20.04
Codename: focal

Clearly there are also some connections that are bogus that also give “imaps TLS negotiation failed” (as far as I can tell from the user concerned all the devices are actually working, but it is conceivable one of them is old and doing something stupid). But as sshguard does not give positive credit to successful connections, it’s difficult to know what to do here and the revert is probably right. Perhaps that change should go to the distribution?

Is there any way to disable that specific rule locally?

Data below

root@shed:/home/amb# zgrep "imaps TLS negotiation failed" /var/log/mail.log.4.gz | fgrep 46.33 | wc -l
12

That’s about a week of logs, and seems typical

# zgrep "imaps TLS negotiation failed" /var/log/mail.log.4.gz | fgrep 46.33 | tail -1 | perl -p -e 's/46.33.\d+.\d+/46.33.111.111/g'
May 27 17:24:01 shed cyrus/imaps[1469392]: imaps TLS negotiation failed: [46.33.111.111]

and as requested

root@shed:/home/amb# zgrep "imaps TLS negotiation failed" /var/log/mail.log.4.gz | fgrep 46.33 | tail -1 | perl -p -e 's/46.33.\d+.\d+/46.33.111.111/g' | /usr/lib/x86_64-linux-gnu/sshg-parser -d
Starting parse
Entering state 0
Reading a token: --accepting rule at line 127 ("May 27 17:24:01 shed cyrus/imaps[1469392]: ")
Next token is token SYSLOG_BANNER_PID ()
Shifting token SYSLOG_BANNER_PID ()
Entering state 4
Reading a token: --accepting rule at line 238 ("imaps TLS negotiation failed: ")
Next token is token CYRUSIMAP_TLS_ERR_PREF ()
Shifting token CYRUSIMAP_TLS_ERR_PREF ()
Entering state 27
Reading a token: --accepting rule at line 330 ("[")
Next token is token '[' ()
Shifting token '[' ()
Entering state 103
Reading a token: --accepting rule at line 302 ("46.33.111.111")
Next token is token IPv4 ()
Shifting token IPv4 ()
Entering state 1
Reducing stack by rule 39 (line 196):
$1 = token IPv4 ()
-> $$ = nterm addr ()
Stack now 0 4 27 103
Entering state 143
Reading a token: --accepting rule at line 330 ("]")
Next token is token ']' ()
Shifting token ']' ()
Entering state 164
Reducing stack by rule 66 (line 279):
$1 = token CYRUSIMAP_TLS_ERR_PREF ()
$2 = token '[' ()
$3 = nterm addr ()
$4 = token ']' ()
-> $$ = nterm cyrusimapmsg ()
Stack now 0 4
Entering state 62
Reducing stack by rule 23 (line 176):
$1 = nterm cyrusimapmsg ()
-> $$ = nterm msg_single ()
Stack now 0 4
Entering state 51
Reading a token: --(end of buffer or a NUL)
--accepting rule at line 327 ("
")
--(end of buffer or a NUL)
--EOF (start condition 0)
Now at end of input.
Reducing stack by rule 17 (line 167):
-> $$ = nterm repetition_suffix ()
Stack now 0 4 51
Entering state 122
Reducing stack by rule 16 (line 164):
$1 = nterm msg_single ()
$2 = nterm repetition_suffix ()
-> $$ = nterm logmsg ()
Stack now 0 4
Entering state 79
Reducing stack by rule 7 (line 134):
$1 = token SYSLOG_BANNER_PID ()
$2 = nterm logmsg ()
-> $$ = nterm syslogent ()
Stack now 0
Entering state 45
Reducing stack by rule 1 (line 116):
$1 = nterm syslogent ()
-> $$ = nterm text ()
Stack now 0
Entering state 44
Now at end of input.
Shifting token $end ()
Entering state 120
Stack now 0 44 120
Cleanup: popping token $end ()
Cleanup: popping nterm text ()
220 46.33.111.111 4 10

‌

[Kevin Zheng]

I can confirm that the false positive you're seeing was fixed in v2.4.2. To fix this problem, you can:

1. Upgrade to v2.4.2.
2. Recompile the v2.3.1 parser with a source patch to remove the signature, then set PARSER in sshguard.conf
3. Compile the v2.4.2 parser, then set PARSER in sshguard.conf.

Unfortunately, it is not currently possible to change the rules in sshg-parser without recompiling it.