strange and too many authentication failures from legitimate clients

[sehh]

I'm having the following problem. The /var/log/maillog and /var/log/exim_reject are reporting a large number of failed authentication logins from my own client PCs.

For example, one PC uses Thunderbird as an email client. When Thunderbird loads, it produces an authentication failure, but right after that it starts to download emails without a problem. This causes my automated scripts to think that this is an attack and eventually the IP address of that Thunderbird machine is blocked. Most of these systems use Kaspersky as an anti-virus.

Here is what I see in /var/log/maillog:

Mar  4 09:35:29 server dovecot: pop3-login: Disconnected (auth failed, 2 attempts): user=<[email protected]>, method=LOGIN, rip=<remoteip>, lip=<localip>, TLS
Mar  4 09:36:12 server dovecot: pop3-login: Disconnected (auth failed, 3 attempts): user=<[email protected]>, method=PLAIN, rip=<remoteip>, lip=<localip>, TLS
Mar  4 09:38:06 server dovecot: pop3-login: Disconnected (auth failed, 3 attempts): user=<[email protected]>, method=PLAIN, rip=<remoteip>, lip=<localip>, TLS

and this is what I see in /var/log/exim_rejectlog:

2014-03-04 14:12:50 dovecot_plain authenticator failed for <removehost> ([127.0.0.1]) [<removeip>]:12918: 535 Incorrect authentication data (set_id=<emailaddress>)
2014-03-04 14:12:53 dovecot_login authenticator failed for <removehost> ([127.0.0.1]) [<removeip>]:12918: 535 Incorrect authentication data (set_id=<emailaddress>)
2014-03-04 14:22:38 dovecot_plain authenticator failed for <removehost> ([127.0.0.1]) [<removeip>]:13327: 535 Incorrect authentication data (set_id=<emailaddress>)

Why does the Thunderbird client try LOGIN method first, then twice with PLAIN method? And since it has the correct password, why does it still fail to authenticate?

I see the same problem with Oulook, except it fails with two PLAIN methods only, it doesn't try a LOGIN method. It fails to authenticate a few times then starts to work fine.

Any help would be appreciated.

Thank you.

 

[cPanelMichael]

Could you open a support ticket using the link in my signature so we can attempt to reproduce this issue using a test email account on your system? You can post the ticket number here so we can update this thread with the outcome.

Thank you.

 

[mtindor]

I'm having the following problem. The /var/log/maillog and /var/log/exim_reject are reporting a large number of failed authentication logins from my own client PCs.

For example, one PC uses Thunderbird as an email client. When Thunderbird loads, it produces an authentication failure, but right after that it starts to download emails without a problem. This causes my automated scripts to think that this is an attack and eventually the IP address of that Thunderbird machine is blocked. Most of these systems use Kaspersky as an anti-virus.

Here is what I see in /var/log/maillog:

Mar  4 09:35:29 server dovecot: pop3-login: Disconnected (auth failed, 2 attempts): user=<[email protected]>, method=LOGIN, rip=<remoteip>, lip=<localip>, TLS
Mar  4 09:36:12 server dovecot: pop3-login: Disconnected (auth failed, 3 attempts): user=<[email protected]>, method=PLAIN, rip=<remoteip>, lip=<localip>, TLS
Mar  4 09:38:06 server dovecot: pop3-login: Disconnected (auth failed, 3 attempts): user=<[email protected]>, method=PLAIN, rip=<remoteip>, lip=<localip>, TLS

and this is what I see in /var/log/exim_rejectlog:

2014-03-04 14:12:50 dovecot_plain authenticator failed for <removehost> ([127.0.0.1]) [<removeip>]:12918: 535 Incorrect authentication data (set_id=<emailaddress>)
2014-03-04 14:12:53 dovecot_login authenticator failed for <removehost> ([127.0.0.1]) [<removeip>]:12918: 535 Incorrect authentication data (set_id=<emailaddress>)
2014-03-04 14:22:38 dovecot_plain authenticator failed for <removehost> ([127.0.0.1]) [<removeip>]:13327: 535 Incorrect authentication data (set_id=<emailaddress>)

Why does the Thunderbird client try LOGIN method first, then twice with PLAIN method? And since it has the correct password, why does it still fail to authenticate?

I see the same problem with Oulook, except it fails with two PLAIN methods only, it doesn't try a LOGIN method. It fails to authenticate a few times then starts to work fine.

Any help would be appreciated.

Thank you.

I have to wonder if you weren't getting hit with too many SMTP Auth requests [lots of it going around] with not enough authentication daemons running. When that happens, your server fails to authenticate users. And during that time, you end up having users who get a password prompt in their Outlook/Thunderbird and so they type in something new to try. Then, when the server is back to normal serving authentication requests, those clients who re-typed in their [wrong] password now fail to authenticate.

I've had this happen with a few clients over the past few days. Server stops authenticating; they get password prompts; they type in some other password than the one that is valid for their account; server authentication returns to normal and then can't authenticate those bad passwords my clients put in.

grep 'Unable' /var/log/exim_mainlog

Ex output for me:

2014-03-03 13:17:18 courier_login authenticator failed for 24-119-173-70.cpe.cableone.net (USER) [24.119.173.70]:2855: 435 Unable to authenticate at present (set_id=abc): socket read timed out inside "and{...}" condition

That's some hijacked PC [or miscreant] brute forcing SMTP Auth and using up all the auth daemons, causing socket read timeouts. At the time that is happening, any valid authenticators into mail will fail authentication and get password boxes popping up. If they type the wrong password in trying to get the box to go away, when things are normal again they can't authenticate.

Mike

 

[sehh]

Here is how I solved the problem:

1) Disabled plain-text logins (which broke pretty much all emails, we manually ask all our clients to enable SSL/TLS).

2) Disabled POP3/IMAP virus scanning, on those systems that have it (Kasperksy and NOD32).

3) Raised the limit of the authentication daemons to the same amount as the max number of POP3/IMAP daemons.

So far so good