SMTP being hijacked - trying to block sender

Again, it's all the LDAP-authenticated users. I have our Open Directory servers set up for remote authentication to the Astaro, and I require SMTP authentication on the email server, so all employees who want to email need to first have an OD account with email enabled, and then perform some action that queries the firewall which will then automatically create a user object for them. Once those conditions are met they are allowed to email. 

The only downside to this system is the Astaro does not automatically disable or remove user accounts that have been inactive for extended periods of time, as far as I'm aware. I can still block email relaying by disabling user accounts in Open Directory, but if I forget to do that for one of our many temporary employees (we're a production company), then the possibility exists that that person can use our system for personal purposes. I of course try to be as secure as possible with this but the possibility remains due to our size and the temporary schedules of employees.

Astaro does not automatically disable or remove user accounts that have been inactive for extended periods of time

  That would make a nice feature request.  Astaro Gateway Feature Requests.

I am assuming that your IT and/or HR department(s) has a termination checklist of steps that should be followed once a person has left the employment of the company.  Deleting the user account from Astaro should be added.  Keeps someone from forgetting if they always follow a checklist.  I had this implemented at my previous company at the HR level.  When a person quit or got "let go", the checklist would be sent out from HR .  When a step is completed, you check it off and for the purposes of accountability, you initial next to it.  When you've completed "your" steps, you forward it onto the next department in the list.  When the last department has done its' stuff, it gets sent back to HR and filed.

Hey Scott,
Unfortunately, we DON'T have a checklist like that, believe it or not! The problem with that is we are a TV production company mostly made up of temporary employees who come and go throughout the year. Our core, permanent staff is maybe 25% of the workforce here. Most of these temporary workers get rehired by different shows when they finish their current show, but might be out of the office for a few weeks in between. Managing all these users is extremely difficult from an IT perspective because there is no process by which we are informed of a person's coming and going (we typically find out when they come to see us personally, when something doesn't work, like email or WPA2 access). That's why I was thinking that some sort of automatic "spring cleaning" of the Astaro's user list would be helpful for admins like me who don't have the time or resources to micro manage every temporary employee in the company.

At any rate, you've hit a very delicate subject for me, and I absolutely we wish we had that termination checklist... it would make my life so much easier!

I absolutely we wish we had that termination checklist... it would make my life so much easier!

That company I worked for was very similar, high turnover.  The catalyst for the list was a situation where I didn't find out about a termination for cause until two weeks after the employee had left the company.

Make the suggestions to the "powers that be".  Explain the possible liabilities that would be negated (former employee with access), and put forth the checklist as the solution.  Might just get you an attaboy.  Even if they don't want to do such a think at the company/hr level, you can put one together for your own use, so nothing accidentally slips through the cracks.

I took your advice and sent the proposition to the COO... we don't have an HR department but hopefully we can manage to do this on our own.

Well back to the original topic, still dealing with this phishing scam, no progress has been made in locating the infected computer. We've been targeting the Windows users first but none of the scans have come back with anything. I hate the prospect of this dragging out, but because so many of our employees have laptops that they take home (and many of those employees go out in the field for days at a time), it may take a very long time to get to every computer. 

Any other ideas for how to deal with this kind of attack? At least emails are not going out any more, but the firewall is still under immense pressure from all the SMTP requests.

Are all of these emails coming from the same source IP or at least netblock?

What mitigation techniques do you have enabled in the SMTP proxy currently?

I noticed that the IP address in the example spam mail header listed above is in the xbl.spamhaus.org and cbl.abuseat.org DNSBL lists.  You may want to consider adding these as extra RBL zones (I personally prefer to use the zen database for spamhaus, as it is inclusive of all of their databases.).

Hi Steagle,
I used to have this kind of problem.
1- Check the relay hosts for malwares (boot net’s)
2- Open smtp live log to see where the messages come from
a. If the messages come from internal address it may be a infected computer
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 outgoing scan sometimes works well but others not.
Resume:
Most of this kind of behavior are relay host infected or e-mail account compromised
I hope this help.

The header you showed us indicated no internal machine. If there's no header with one, then I bet you can stop trying to find an internal infection that's a source of these emails. 

I think you've already identified the problem is an external entity that's discovering how to auth to your LDAP. You also indicated that the bad guys are creating new accounts!?!?!  It seems like that's the real problem, or ???

Cheers - Bob

Sorry for any short responses!  Posted from my iPhone.

You also indicated that the bad guys are creating new accounts!?!?!  It seems like that's the real problem, or ???

Cheers - Bob

Sorry for any short responses!  Posted from my iPhone.

If the bad guys really are creating new (LDAP) accounts on your open directory, your OSX Server itself may be compromitted by malware, or it's somehow accessible from external, and the bad guys brute force'd your admin password.

Check in ASG Logs or also Reporting all OUTGOING connections and services from your OSX Server.

Reject all unnecessary services from OSX to Internet on ASG's Firewall (only open definately required services)

Install A Malwarescanner on your OSX Server

Check all Accounts with administrative rights on your MAC OSX Server, and maybe changing their passwords may help (at least temporary)

@ Scott - added the two RBL zones you mentioned, thanks. I am not using a SMTP proxy. Just relaying from the OSX Server to the Astaro. I'm seeing all sorts of email addresses in my Top Ten Senders list from random domains, but in the SMTP Proxy live log, it's the cartasi@servizi.it email (corresponding to the IP address posted earlier) that is hammering the firewall with the 1000s of requests. This is why I feel it's malware, constantly running on someone's computer - you would think if it was a live person somewhere, they would have given up by now.

@anwar - I've already installed anti-malware/virus on the OSX Server, and the first scan of the boot drive brought up an infected file in /var/mailman (which we use for some internal mailing lists). That has since been quarantined and no other infected files have come up on subsequent scans. Unfortunately this program (ClamXav) will not scan my RAID volumes, only the boot drive. The mail server is on one of these volumes. I will probably have to run the program from the command line as root for this to work but so far haven't found the instructions to do so. Do you have any other suggestions for decent anti-malware software for Mac that will not have this problem?

@ BAlfson - no, LDAP accounts are not being created. Originally, someone  was using an LDAP account to authenticate to the firewall, but I deleted that as soon as I discovered it and now there are no suspicious authentications going on.