The Community Forums

Interact with an entire community of cPanel & WHM users!
  1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

strange and too many authentication failures from legitimate clients

Discussion in 'Security' started by sehh, Mar 4, 2014.

  1. sehh

    sehh Well-Known Member

    Joined:
    Feb 11, 2006
    Messages:
    579
    Likes Received:
    5
    Trophy Points:
    18
    Location:
    Europe
    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:

    Code:
    Mar  4 09:35:29 server dovecot: pop3-login: Disconnected (auth failed, 2 attempts): user=<info@mydomain.com>, method=LOGIN, rip=<remoteip>, lip=<localip>, TLS
    Mar  4 09:36:12 server dovecot: pop3-login: Disconnected (auth failed, 3 attempts): user=<info@mydomain.com>, method=PLAIN, rip=<remoteip>, lip=<localip>, TLS
    Mar  4 09:38:06 server dovecot: pop3-login: Disconnected (auth failed, 3 attempts): user=<info@mydomain.com>, method=PLAIN, rip=<remoteip>, lip=<localip>, TLS
    
    and this is what I see in /var/log/exim_rejectlog:

    Code:
    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.
     
  2. cPanelMichael

    cPanelMichael Forums Analyst
    Staff Member

    Joined:
    Apr 11, 2011
    Messages:
    30,814
    Likes Received:
    672
    Trophy Points:
    113
    cPanel Access Level:
    Root Administrator
    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.
     
  3. mtindor

    mtindor Well-Known Member

    Joined:
    Sep 14, 2004
    Messages:
    1,281
    Likes Received:
    37
    Trophy Points:
    48
    Location:
    inside a catfish
    cPanel Access Level:
    Root Administrator
    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:

    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
     
  4. sehh

    sehh Well-Known Member

    Joined:
    Feb 11, 2006
    Messages:
    579
    Likes Received:
    5
    Trophy Points:
    18
    Location:
    Europe
    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 :)
     
Loading...

Share This Page