Spammers trying to guess email passwords

[cDGo]

I have being seeing multiple attempts in the mail log file (mainlog) showing lines like the following which appear to be from spammers trying to guess passwords.

mainlog-20130526:2013-05-20 04:49:18 login authenticator failed for (localhost) [178.172.199.75]: 535 Incorrect authentication data ([email protected])

Sometimes the set_id shown is a real email address on my server some times a single word like manager, office or backup.

The ip address are frequently changing. It looks as though they are spaced apart so as not to trigger brute force. None of the ips I saw invovled were blocked by brute force. For example:

mainlog:2013-06-16 07:00:23 login authenticator failed for (localhost) [24.182.203.8]: 535 Incorrect authentication data (set_id=office)
mainlog:2013-06-16 07:12:32 login authenticator failed for (localhost) [24.182.203.8]: 535 Incorrect authentication data (set_id=manager)
mainlog:2013-06-16 07:33:56 login authenticator failed for (localhost) [24.182.203.8]: 535 Incorrect authentication data (set_id=manager)
mainlog:2013-06-16 08:24:35 login authenticator failed for (localhost) [24.182.203.8]: 535 Incorrect authentication data (set_id=office)
mainlog:2013-06-16 09:47:51 login authenticator failed for (localhost) [24.182.203.8]: 535 Incorrect authentication data (set_id=office)
mainlog:2013-06-16 10:02:04 login authenticator failed for (localhost) [24.182.203.8]: 535 Incorrect authentication data
mainlog:2013-06-16 10:10:57 login authenticator failed for (localhost) [24.182.203.8]: 535 Incorrect authentication data (set_id=manager)
mainlog:2013-06-16 11:36:51 login authenticator failed for (localhost) [24.182.203.8]: 535 Incorrect authentication data (set_id=office)
mainlog:2013-06-16 11:55:19 login authenticator failed for (localhost) [94.102.53.232]: 535 Incorrect authentication data (set_id=backup)
mainlog:2013-06-16 11:55:19 login authenticator failed for (localhost) [94.102.53.232]: 535 Incorrect authentication data (set_id=backup)
mainlog:2013-06-16 11:55:19 login authenticator failed for (localhost) [94.102.53.232]: 535 Incorrect authentication data (set_id=backup)
mainlog:2013-06-16 11:55:19 login authenticator failed for (localhost) [94.102.53.232]: 535 Incorrect authentication data (set_id=backup)
mainlog:2013-06-16 12:42:18 login authenticator failed for (localhost) [24.182.203.8]: 535 Incorrect authentication data (set_id=manager)
mainlog:2013-06-16 13:09:16 login authenticator failed for (localhost) [24.182.203.8]: 535 Incorrect authentication data (set_id=office)
mainlog:2013-06-16 13:24:19 login authenticator failed for (localhost) [24.182.203.8]: 535 Incorrect authentication data (set_id=office)
mainlog:2013-06-16 16:06:35 login authenticator failed for (localhost) [24.182.203.8]: 535 Incorrect authentication data
mainlog:2013-06-16 16:46:54 login authenticator failed for (localhost) [24.182.203.8]: 535 Incorrect authentication data (set_id=office)
mainlog:2013-06-16 17:02:53 login authenticator failed for (localhost) [24.182.203.8]: 535 Incorrect authentication data (set_id=office)
m

Does anyone know an effective way of dealing with these?

Regards,
Domé

 

[LawsHosting]

Fail2ban + csf/iptables/etc. Look in the How-To forum

 

[flamewalker]

I use CSF to block after 5 or 10 attempts, forget which exactly. I get notices all the time, and have a lengthy ip blacklist.

The downside is if you disable a customer, and their computers frequently check for mail (our custom backend just changes the password), they can get blocked, so I have to go in and unblock their ip. It's a minor nuisance but it keeps the brute force attacks at bay, and is worth it. I only have to unblock, maybe once a month.

 

[nobaloney]

We have problems continually with clients needing us to unblock their IP#s because their users make either manual or automated password errors when checking for emails. I've decided to just unblock all the blocks rather than spend time searching for the right one. If the IP#s are still being hit, they'll end up on the blocklists soon enough.

Jeff