SMTP being hijacked - trying to block sender

b. If the connections coming from outside check the authentication logs and check careful the smtp headers to find which account (used) is being used to relay. Many user use weak password like 123456 or the e-mail name and is easy to hack. Reset their password

The interesting thing is that my live authentication log looks perfectly normal. It does not show any one user authenticating more than usual. All the users are legitimate employees in Open Directory sending normal work mail.

Wow, just found something in the mailaccess log on the OSX server. Hundreds of these entries on August 27, authentication attempts using different usernames:

Aug 27 03:33:41 s2 dovecot [53]: auth(default): od[getpwnam_ext](celadonia,92.48.116.93):No record for user
Aug 27 03:33:41 s2 dovecot [53]: auth(default): od(celadonia,92.48.116.93): lookup failed for user: celadonia

The 27th was after I deleted the 'test' account on Open Directory. This looks like brute force attack to me, a script systematically checking all possible usernames and common server names to get in again. I don't see anything in the logs after Aug 27, but obviously we were under attack that day.

That's a UK IP address that's part of a /28 public subnet, so the ISP should be able to alert their customer to the apparent fact that they have an infection: abuse@as29550.net.  Include a large enough portion of your log to demonstrate that this was an attack.

Is there a reason you need to allow authentication traffic originating from outside your network?  Would requiring remote mail clients to use a VPN from company-certified laptops suffice?  Or, could you require remote mail users to access via an internal web-based application similar to Outlook Web Access?

Cheers - Bob

It's more for convenience than anything. Due to the nature of our business, with at least half of the employees out in the field at any given time and many traveling internationally, requiring them to use VPNs would usually be a cumbersome solution. We do have webmail access on our mail server which they can connect to via HTTPS, but most prefer using their dedicated email clients due to integration with contacts, calendars and other things that do not translate over to webmail. 

I definitely realize what you suggest would be a lot more secure and I have thought about alternatives many times, especially during this incident. I just think that in the end, our business is a lot different than a typical corporation and the employees need more flexibility. 

Our SMTP relaying setup has worked great for the last few years, this is the first time it has ever been compromised. In a perfect world, I'd like to get this infection or intrusion out of the system, shore up whatever security vulnerabilities I had and continue using this setup. I really like how the Astaro has that LDAP backend mechanism and of course all the spam & anti-virus protection that our OSX Server cannot match.

And thanks for tracing that IP... there is also a second one in the logs, 187.130.128.145, and it seemed to take over later in the day for another massive chunk of authentication requests. 

Again, none of that kind of activity since Aug 27th, but the infection/intrusion/attack/whatever continues on the SMTP Proxy live log.

Yeah, that's what I thought. I don't think you have any evidence of any infection in your configuration - only what now seems to be an obvious exposure. 

Cheers -  Bob

Sorry for any short responses!  Posted from my iPhone.

Edit: With the help of an IT colleague, I was able to finally figure this out. What was happening was we were being bombarded by external spammers, not an internal infection, as you rightly guessed Bob. It looked like our SMTP was being used to send mail but it was really just spooling incoming mail that spammers were trying to send to us. None of the Mail Security features for AntiSpam or Relaying worked to block these people (Sender Blacklist, Expression Filter, Known Bad Hosts etc) so I added the IP addresses of the top spammers to a Packet Filter rule I have that automatically blocks bad IPs, and that did the trick. CPU usage dropped back to where it should be and SMTP is back in business. 

As for the brute force attacked that guessed that 'test' LDAP account, I think that was part of this same general spam attack, and they were able to temporarily use our SMTP to send out mass spam mail to outside users, resulting in us being blackilsted with a couple RBLs. But that shouldn't be too hard to remedy with a couple emails.

As a precaution I scanned & deleted thousands of old malware-infected emails from the mail server (migrated over from the old Cyrus-based server to the new Dovecot one), and also tightened up password security requirements in Open Directory. I'll be keeping a much more watchful eye on SMTP from now on - those Astaro Daily Executive Reports are a lifesaver. 

Thanks everyone for your suggestions and input, it's greatly appreciated. Very nice community here and having people to troubleshoot with helped a lot.

I don't know if you're using Lion or not, but apparently there's a really nasty bug where Lion will accept any password when using LDAP authentication.  Bug allows Mac OS X Lion clients to use any LDAP password | ZDNet

I don't know if you're using Lion or not, but apparently there's a really nasty bug where Lion will accept any password when using LDAP authentication.

Tremendous find, Scott!  I bet that's exactly what their script was looking to exploit, and they found Steve's Astaro that was allowing LDAP-authenticated relay from remote users. I guess the "test" account had no password, or had the default password they were looking for - then, when that stopped working, their script shifted to other names, but it was unable to authenticate because Steve's LDAP server didn't have the bug you reported to us.

Does that fit, Steve?

Cheers - Bob