Consulting,  Kerio,  Mac OS X Server,  Microsoft Exchange Server

Blocking Spam Attacks

Various Spam Issues and the Appropriate Steps to Resolve Them:

 

Symptom: Users of the domain are getting a large amount of spam

Problem: Spam sucks…

Resolution: Outsource spam to MXLogic, Postini, Katharion, etc., limit incoming traffic over port 25 to the IP scheme of the outsourced service and use whatever form of message hygiene is built into the server for a layered approach (eg – Intelligent Messaging Filter in Exchange, Spam Assassin in Mac OS X Mail Server, Kerio Spam rules, etc.

 

Symptom: An IP or domain name is getting flagged as being a spammer although the users do not send spam.

Problem: The mail server potentially does not have all the required aspects for a modern mail server.

Resolution: Verify that there is a reverse DNS record (PTR) for the domain, implement an SPF record for the domain and review the outgoing logs to verify that the users are not sending bulk mail from the domain.  Review dnsstuff to see which RBLs might have marked the domain as spam and request removal.  telnet into the server over port 25 and attempt to do an ehlo command, to verify that some random IP cannot communicate directly with the server over port 25.

 

Symptom: The mail server is getting a large amount of traffic in the queue for mail that cannot be delivered to addresses on your domain that do not exist.

Problem: The server is being hit with a directory harvest attack.

Resolution: Limit the hosts that can communicate with the server over port 25 to an outsourced mail provider. Throttle the number of messages that can be sent through the server over a given span of time to email addresses not on the server.  Block emails coming to the server if there is no account on the server.

 

Symptom: The mail server is getting a large amount of traffic in the queue for mail that cannot be delivered, although the headers do not show that the mail is coming from or heading to any accounts on the server.

Problem: Someone is trying to relay mail through the server.  Whether the relay attempts are successful or not they are still taking up resources on the server and should be stopped.

Resolution: Limit the hosts that can communicate with the server over port 25 to an outsourced mail provider.  Verify the server requires SMTP authentication for outgoing mail.  Throttle the number of messages that can be sent through the server over a given span of time.  Throttle the number of messages that can be sent through the server over a given span of time to email addresses not on the server.

 

Symptom: One user of a domain is getting a large amount of Non-Delivery Reports (NDRs).  The user is not sending bulk mail but the number of NDRs are enough to bog the server down with the queue trying to process them all.  The queue does not shows a large amount of outgoing mail.

Problem: A password of the users account on the server has likely been compromised.

Resolution: Change the users password, consider blocking NDRs using the spam filter service (if one is used) for 72 hours, until all receiving queue’s have timed the messages out.

 

Symptom: One user of a domain is getting a large amount of Non-Delivery Reports (NDRs).  The user is not sending bulk mail but the number of NDRs are enough to bog the server down with the queue trying to process them all.  The queue does not show much outgoing mail.

Problem: Someone is masquerading as the user.  

Resolution(s): Change the users password, just in case (highly unlikely that any accounts have become compromised).  If you are using an outsourced service such as MXLogic, Postini, Katharion, etc then request they enable NDR blocking temporarily.  This will reduce the load of traffic coming into the server.  After 72 hours call the outsourced service and see how much traffic in NDRs the organization is getting.  Still expect 1/10 to come into the mail server queue given the way NDRs are indicated in mail headers, but anticipate a much lower volume.  Also make sure they have an SPF record for the server, which will reduce the number of NDRs slightly

All mail servers should have the following:

A reverse DNS record for the IP(s) of the mail server

An SPF record (www.openspf.org).  SPF is not as widely used as it should be, but it can help a lot.

Regular checks of dnsstuff to verify they are not marked as spammers by any of the major RBL services (spamcop, spamhaus, etc)

Local message hygiene (eg – Intelligent Filtering, RBLs, Spam Assassin, SPF, etc)

SMTP (port 25) traffic limited to a mail filtering solution if possible