Is there some sort of mail exploit going around lately?

I'm upgrading everything to CentOS 5 (an interesting exercise) and have experienced slowdowns only to find in the logs brute force dovecot login attempts:

**********************************************

May 7 07:08:37 a104 dovecot-auth: pam_succeed_if(dovecot:auth): error retrieving information about user basic
May 7 07:08:37 a104 dovecot-auth: pam_unix(dovecot:auth): check pass; user unknown
May 7 07:08:37 a104 dovecot-auth: pam_unix(dovecot:auth): authentication failure; logname= uid=0 euid=0 tty=dovecot ruser= rhost=213.177.138.57
May 7 07:08:37 a104 dovecot-auth: pam_succeed_if(dovecot:auth): error retrieving information about user bass
May 7 07:08:38 a104 dovecot-auth: pam_unix(dovecot:auth): check pass; user unknown

************************************************

Why in the world would someone try a brute force get mail?? This isn't even fishing for users as all get rejected.

Scratching my head.....

my logs are filled with this since the first minute the server got online. Sometimes I see a certain IP trying to login for a day, sometimes for an hour.
Probably just kids trying out some toy software to see if they can actually hack a server, lol

i try not to worry much

Why in the world would someone try a brute force get mail?? This isn't even fishing for users as all get rejected.

There are actually several reasons:

If they find a user/password via POP/IMAP, they may have a real system user/pass with which to login to the system with--which provides a means for escalation attacks, or at least a platform for doing more brute forcing scanning for other systems. This is why one should grant shell accounts with caution--virtual server owners obviously need a shell to be productive, but mailbox/FTP users almost certainly don't.

If they find the POP/IMAP user, they've found the SMTPD auth user...and thus can send spam through your server. Your server is legitimate and will be treated as such by Gmail, Hotmail, Yahoo, etc. for at least a little while. So, getting access to your SMTP server would be a nice way for a large scale spammer to spew out messages unimpeded by reputation-based filters for possibly several days (until your servers reputation is thoroughly shot).

And, of course, any way in is better than no way in. If they have a user account that has a shell, they're far more likely to be able to escalate to a root level account (because they then have access to all of the binaries on the system...so if any suexec binary is insecure, they've got root...if the kernel has any escalation bugs, they've got root). And once they have root, you've lost your server. Starting over from a fresh install is usually the cheapest/safest response.

Scared yet? ;-)

But, there's not much to be done about it, since we can't shut down POP/IMAP. We just have to use strong passwords, change them periodically, and make sure users don't have more privileges than they need. nologin or false is the right shell for anybody that doesn't need shell access...and will prevent just about every horrible outcome I've mentioned above. Since virtual server owners generally need a shell, you should make sure they know to use strong passwords (8+ chars long, not just letters, and not dictionary words).

oooooooooooookay! Ouch. Schooled, yep!!!

We haven't had any brute force pop attacks before, but then all the servers are going to SMTP auth now that I figured it out. Just thought it odd to try the pop, but then, like you say, any way in is good and we can't set an sender denial after X bad recipients like we can in the MTA for spam.

We routinely encourage using phat in their passwords like "n3wp@$$w0rd" or something. And we maintain no shells for mail users so I feel a little better. It's that bloody server load |-(

There's been some discussion of this recently on the dovecot list. Start with this thread:

http://www.dovecot.org/list/dovecot/2008-January/027772.html

I agree with the thought that this belongs in the realm of IDS rather than under each exposed service...they all get hit like this constantly. I also agree tarpitting is probably not the right approach.

A couple of posts down someone mentions a package called Fail2Ban that reads log files and denies the source address after n failures. Interesting idea if this sort of thing bothers you...but as someone above said this type of probing is harmless if you've taken prudent precautions.

Checked out the link, interesting notes...

I was banning IPs until I reasoned that these attacks are most often coming from pirated machines or loosely monitored bandwidth providers ( AT&T, AOL/Roadrunner, Charter etc)anyway, and that the IP of the attacker is going to change accordingly. THat's why Leif's rules (hey it's famous here now ;-) were a great addition for helping secure SSH & FTP etc (I suppose I could put a rule in there for port 110 as I think of it). I'd be afraid that a comprehensive(and growing) list of blocked IP addresses would begin to block legitimate traffic in the long run.

Yes, don't want to create a windows environment by adding so many APPs that the server load keeps you from getting any work done.

Prudence is still the answer.

Yeah, you wouldn't want to block the attacking address or network forever, just long enough to let their scan timeout and move on to the next victim. You'd have the entire dial-up world blocked before too long.

I put a port 110 rule in the IP tables and that should take care of it I hope. I don't think he was a dialup prankster though. He'd tied up 11 boxes for 15 minutes simultaneously. A 30 second timeout should be more than the mailer can handle and less time than the normal user would take to figure out he made a mistake ;-0