Ok, so I find out while I'm at work that my personal server which resides in my garage is the target of a Reverse NDR (non-delivery report) attack. It all started with me noticing a large amount of objects with random domain names in the Exchange 2003 queues. (yes, it was slow at the office so I decided to tinker and experiment with the heart and guts of Exchange 2003 to increase my exposure/experience on my non-production computer at home. why? -- cause i'm just that kind of nerd =). )
First thing that any IT guy does when confronted with unfamiliar things is google it. After sifting through some nonsense links that pointed to http://www.experts-exchange.com/ (I call it nonsense because you have to pay for access to their forms, and they somehow index their site so that it appears near the top of every IT related search) I eventually found some Microsoft kb articles relating to the issue. Anyone familiar with Microsoft's kb knows that it always follows the structure of SYMPTOMS, CAUSE, RESOLUTION, MORE INFORMATION. Well, after reading some of the symptoms I felt like a total noob since my symptom was grouped with others like:
Your Internet service provider (ISP) notifies you that your Exchange server is delivering unsolicited commercial e-mail (UCE). UCE is also known as spam.
The drive that contains the BadMail folder runs out of space. By default, the BadMail folder is located in the "C:\Program Files\Exchsrvr\Mailroot\vsi 1" folder.
Ok, so maybe I am a noob since I never heard of the folder called "BadMail". Maybe if I forward this post over to
Keegan Jones he'll send me a size small "I'm a noob" shirt. C'mon, I deserve it but can't afford it cause I'm in college, you fraud =P
Continuing on, I learn that there's a simple fix: create a recipient filter to prevent Exchange Server 2003 from accepting messages that are sent to recipients who do not exist.
This is what Microsoft says takes place:
In the default Exchange configuration, e-mail that is sent to name of your e-mail domain.com is accepted as local regardless of the e-mail alias that the message is addressed to. The e-mail alias is the part of the e-mail address that is on the left side of the at (@) symbol. If an e-mail message is sent to an alias that is not valid, the Simple Mail Transfer Protocol (SMTP) service receives the whole message, and then queries the Active Directory directory service for a user or a distribution group that has a matching e-mail alias. For example, if an e-mail message is sent to invalid user name@name of your e-mail domain.com, SMTP queries Active Directory for a user or a distribution group that has the invalid user name@name of your e-mail domain.com alias. However, if the e-mail alias does not exist, Exchange tries to send an NDR to the original e-mail message sender. This can cause many messages, queues, or both, to appear in Exchange System Manager.
After you enable recipient filtering, Exchange validates the e-mail address before Exchange accepts the e-mail message. In this scenario, if no match for this e-mail alias appears in Active Directory, an NDR is still generated. However, in this scenario, it is the responsibility of the sending SMTP server instead of your Exchange server to generate and to deliver the NDR.
After applying the necessary filter, there was still a slew of content in the queues. To fix this, I created a temporary SMTP connector that forwarded all mail (keep in mind this a temporary) through a connector to an invalid IP of [99.99.99.99] and set the Connection Time to 'Run daily at 11:00 pm'. I then refreshed the Default SMTP Virtual Server by stopping it then starting it. Upon starting, the default SMTP Virtual Server re-enumerates the spam messages and puts them in a single queue. I then right clicked the tmp queue, clicked find messages, selected all, then deleted them using the 'Delete (no NDR)' option.
Cool, everything's cleaned up. I removed the temp connector, restarted the Default SMTP Virtual Server, and all was good. For good measure, I researched other common 'best practices' for Exchange which included me removing the potential for my server to be used as a mail relay.
Explanation from MS:
IIS in Windows Server 2003 includes a full-featured SMTP virtual server that you can use to receive and relay e-mail messages to other SMTP servers on your network or to servers on the Internet. The relay function is useful for internal network clients that may have to forward mail to other SMTP servers and for IIS programs that need access to an SMTP server to forward mail.
When the SMTP virtual server relays e-mail messages, it may forward mail that is addressed to any e-mail domain. With this feature, the SMTP virtual server can forward mail to any internal or external network SMTP server for which is can resolve an MX record. However, if the SMTP virtual server is accessible to Internet users, mail relay is not good because unscrupulous users can forward mail to your SMTP virtual server and as a result, distribute unsolicited commercial e-mail to large numbers of computers. This can have a very adverse impact on available bandwidth for your internal connection, and cause your mail server to be placed on "black hole" lists of open mail relays.
The solution? -- disable anonymous access (duh). If the user or computer does not successfully authenticate, the user or computer cannot send mail to the server. woot!
Posts
