|Intro|  |News|  |Threats|  |Alerts|  |Papers|  |Events|  |Reading|  |Links|  |About Me|  |Powered-by...|
When Rogue Squadron aren't StarWars™ heroes
[Back to Main]

One of the most basic and damaging threats present to e-mail is that of un-maintained, un-authorized, or un-known Mail eXchangers.  Think like a spammer for a moment.  If you were trying to circumvent anti-spam protection at a site, which mail server is least likely to have such protection?  Well, you're least preferred MX record, of course!  It's common knowledge that most entities now deploy some type of anti-spam protection on their servers; however such protection is expensive to purchase and tedious to maintain (or develope, if you're doing it in-house and/or with Open Source tools).  With this reasoning, it's easy to induce that most sites will only deploy protection to the least amount of servers they think is necessary.  This usually means that only the primary, and some times secondary MX records point to protected SMTP servers.  Very often there are secondary, tertiary, etc MX records with little or no anti-spam protection at all.

Most spammers may not be terribly clever (although a small percentage are extremely crafty), but they aren't blind.  All you have to do is configure your spam software to attempt delivery to MX records in reverse order (i.e. least preferred/highest numbered MX records are tried first).  Many times this results in spam getting through completely unscathed, to the bewilderment of the e-mail administrator (especially if he just paid $100,000 for some hot commercial product that is supposed to block spam).

So how do you counter-act this threat?  This is probably the easiest threat to counter (and potentially has the most benefit): turn off all unprotected SMTP servers and remove them from your MX records!  OK, so it's not quite that simple, but it's not much more involved.  First, you need a list of all servers that are configured to receive mail for your domain.  Your first move should be a "whois" on your domain name(s) to see what the listed authoritative DNS servers are.  Next, armed with that list, do a dig/host/nslookup (pick your tool) off of your authoritative servers (make sure you test each one, they may not be in agreement!) to look for MX records for each of your published domains and sub-domains.

At this point you have a fairly good list, but you're not quite done.  From each DNS server listed in your whois records, do a dig/host/nslookup for NS records for each of your domains.  You may be surprised to learn that what is listed in your zone files as authoritative DNS servers is likely different from what is listed in whois (there are reasons for this, but it's outside the scope of this topic).  If you find any additional authoritative DNS servers (and I assure you it's fairly likely) then you need to repeat your first step of looking for MX records via each of these newly discovered DNS servers.  The reason you need to go to all this work of finding DNS servers for your domains and zones is because any of these methods could be used by spammers to look up your MX records, and you want to make sure you have a complete list of your MX records so you can have some assurance there won't be further surprises.

Now that you have your list of MX records, examine them closely.  Which of them are actually maintained by your messaging team?  Probably only a few of possibly dozens.  The best course of action from here is to contact any teams you know are responsible for the other servers, or any teams that may be responsible, and ask them why they're running their own SMTP server that is advertised to the world.  There may be some valid reasons, but remind them that you are in charge of messaging for your entity and they need to funnel all mail traffic through your servers.  Politely ask them to come up with a transition plan to move their services onto your servers, or transition passwords and control of those servers over to your team.

Note that other groups may not be happy to relinquish control to you, and this will mean addition work for your team.  You may need to record this as a business justification for more resources and forward it to the appropriate decision-makers.  If the other teams refuse to cooperate, then escalate to your management and security.  At this point it's quite possible that it will be necessary to have the security team shut off firewall access to those rogue servers from the outside and/or have the DNS team remove the offending entries from DNS.  It's very important to the integrity of your messaging environment that all messaging servers are controlled by a single team.  It will greatly strengthen your case if you can show (via viewing RFC 822 message headers, or log entries) that SPAM or other offensive or dangerous messages came through a server controlled by a different team.  If you can show this evidence to a manager, you'll likely get the blanket go-ahead to cut-off access to any servers not belonging to your group.

So at this point you go back to focusing on your core servers and protecting them, right?  Almost.  There is another step.  To be completely thorough you need to actually scan all your IP blocks for open port 25/TCP (or even more thorough, scan for SMTP banners on all TCP ports).  Usually this step is performed by your security team or a penetration tester.  In fact, if you have someone regularly assessing your Internet face for vulnerabilities, they may have already compiled just such a list and all you need to do is cross-reference it with what should be available.  Remember that a server doesn't have to be listed in an MX record in order to receive mail for you.  Spammers are becoming increasingly like crackers in their attempts to infiltrate your network and they've been known to use exactly this tactic to locate servers to spam through that aren't even listed in DNS.

By far the most easy way to deal with this possibility is to make sure that your firewall team only allows access to port 25 for the IPs of the servers you give them as valid.  There should be a default-deny policy on all external (and Extranet/Vendornet) firewalls for port 25.

Are we there yet?  Unfortunately, no.  With the wide deployment of wireless networks (commonly called WiFi and usually implemented over 802.11a/b/g) there is another potential hole in your e-mail infrastructure.  I've decided to dedicate a section to dealing with WiFi and it's effect on e-mail, so check out that section as well for a continued discussion.




This site © copyright 2003-2011 Brian Keefer.  Unauthorized republication is forbidden.