[Dshield] Mail bombing by MyDoom, bouncing of infected emails, and a few other random thoughts
Jon R. Kibler
Jon.Kibler at aset.com
Thu Jan 29 16:53:26 GMT 2004
Wow! MyDoom has created a real mess... not so much the virus itself, but the volume of email it is generating. In a normal day, we handle 5K to 25K mail server connections per day (about 0.3 connections/sec) per MTA. Most of this week, it has been 20K to 50K connections per day per MTA.
The higher average connection rate is really not a problem in and of itself -- the problem is that connections have been arriving in large bursts -- as high as 100 new connections per second. At that point, sendmail starts to have problems keeping up.
Anyway, two real reasons for writing about MyDoom mail bombing:
1) Question: Has anyone else seen similar behavior -- meaning large connection bursts?
2) Pass on some advice on how you can protect yourself from such high connection rates.
For any MTA, the basic strategy to protect against 'mail bombing' is the same:
1) When connection rates start to rise, limit the rate at which you respond to new connections.
2) When load averages start to rise:
a) limit the rate at which you respond to data on the connections,
b) limit the processing performed in response to each connection (such as simply queue received mail instead of actually processing and delivering it),
c) when the LA becomes excessive, reject new connection requests.
3) Limit the total number of process (or threads) that the MTA can spawn.
For sendmail, you can accomplish these actions as follows:
1) Use the ConnectionRateThrottle option to limit the maximum number of new connections per second to which the MTA will respond. Connections are not rejected, there is simply a delay in responding to the connection request.
2) Load averages can be managed by using:
a) The DelayLA option to insert delays between to receipt of an SMTP command the the daemon's response to it.
b) The QueueLA option to simply queue all incoming mail and defer delivery until the LA drops.
c) The RefuseLA option to reject new connections when the LA becomes extreme.
3) Use the MaxDaemonChildren option to put an absolute limit on the number of connections sendmail will concurrently process.
There are other performance tuning options available, but the above 5 are probably the best place to start. In proper combination, they provide pretty good protection against 'mail bombing' situations.
One other oddity we have seen with MyDoom... the forged recipients and the mail servers bouncing the viruses seem to be very local -- meaning that most (>50%) of the MyDoom traffic originates for the local metropolitan area. Usually, mail originating from our metropolitan area probably constitutes less than 1% of all email traffic. Even with other email viruses, we have never seen such a large local burst. Has anyone else seen such an occurrence or are we just "lucky"?
Finally, a plead: PLEASE DON'T BOUNCE VIRUS INFECTED EMAILS!!! (add about 50K more !s)
First, I will acknowledge that the RFCs require you to bounce such messages to their envelope sender. But, let's face it -- the RFCs have been outdated by changes in the real world. Its time we change the standards.
Several reasons not to bounce virus infected emails:
1) Most likely, the sending email address is forged, so the user that appears to be sending the notice is not the infected system.
2) If the email is bounced to a real user's email address, you are only serving to spread the virus.
3) If you bounce the message to a valid domain, but to a non-existent user, then your bounce will be bounced (a "double bounce"), and a lot of MTAs do not handle double bounces well -- especially if the double bounce is to a non-existent user.
4) You are wasting a lot of your local systems' resources, a lot of network resources, and a lot of other systems' resources.
So what should you do? A couple of options:
1) Simply log the fact you received a virus infected message, then discard it.
2) Log the fact you received a virus infected message, quarantine THE ENTIRE MESSAGE, and notify the postmaster.
3) If you want to notify somebody, it should be the abuse contact for the IP address of the connecting MTA (and not the abuse address for the domain of the envelope recipient!).
One other thing not to do (unless you like filling your users' inboxes full of junk): Don't strip the infected attachment from the email and send the rest of the message on to the recipient.
Anyway, this concludes my thoughts, observations, and $0.02 worth. (Step down from the soap box.)
Hope somebody finds this info useful...
Jon R. Kibler
Chief Technical Officer
Charleston, SC USA
Filtered by: TRUSTEM.COM's Email Filtering Service
No Spam. No Viruses. Just Good Clean Email.
More information about the list