|Intro|  |News|  |Threats|  |Alerts|  |Papers|  |Events|  |Reading|  |Links|  |About Me|  |Powered-by...|
D: dos; D: dos run; run dos run
[Back to Main]

Distributed Denial of Service attacks are far from a joking matter.  Indeed, DDoSs continue to be one of the most effective ways to obliterate an opponent from the face of the Internet.  Various statistics show that thousands of DDoS attacks occur each month, many of them are actually turf wars between "script kiddies", but a disturbing amount are directed at e-commerce sites, government installations, corporate web presences, etc.  To add insult to injury, many spam campaigns now (purposely or not) manifest themselves as DDoS attacks at the SMTP protocol level.  Vast floods of spam can choke mail relays, and bring overworked groupware systems to their knees.  Disk space can be exhausted causing SAN/NAS headaches.  In general, it just gets ugly.

I wouldn't be bringing all this up unless I had a solution, right?  Right.  First and foremost, recognize that the SMTP application layer is no less a target for attackers than HTTP (as in many common defacement attacks, SQL injections, customer record grabs, etc).  It's readily recognized that HTTP is a vector for attack and companies are finally starting to invest money in protecting their web servers, but what about SMTP?  Web deployments are usually situated in a DMZ far away from the internal company network, but on the other hand port 25/tcp is usually passed right through the firewall onto the trusted network segment and into a soft, squishy groupware server.

A simple nmap scan of a random range of IPs for port 25/tcp will reveal an absolutely staggering number of Exchange and Notes servers, directly connected to the Internet!  Even the enterprises who wisely place an SMTP gateway between the Internet and their groupware system often have deployed Sendmail.  Sendmail may possibly by the only product to have a worse security track record than Microsoft's software, yet it still makes up a modest percentage of Internet gateways (especially on Linux distributions, where it's often the default MTA--ISPs and other large sites are wising up and selecting secure alternatives).

People, it's time to get serious, these systems cannot be allowed to handle hostile Internet traffic.  The first step to mitigating DDoS attacks against your e-mail infrastructure is deploying an e-mail security gateway.  There are many products billed as just such a solution, but few hold up to the light of intense scrutiny.  First, many are based on older generation Windows products, which just aren't going to cut it as security gateways.  Next, many of these products are actually anti-spam or content filtering point solutions that included the "security" buzzword since it looks sexy

The first thing to look for is a platform that has been strenuously hardened against attacks.  The approach taken by an overwhelming number of security appliance vendors, including Nokia, F5, CipherTrust, Alteon, Sourcefire, Cisco, and Juniper Networks has been to either use a custom hardened BSD kernel, or use BSD as a reference model for their proprietary OS.  Several other vendors have choosen to deploy systems on Linux or Solaris based platforms (although careful examination should be done to determine how much of those stock systems are still left, since both OSs have their share of security problems).  Last, Windows 2003 is being touted as much more secure than it's predecessors.  Although this largely remains to be proven, it is possible to harden a Windows system to make it somewhat sturdier, although I personally would stay awake at night if it was "protecting" my DMZ.

After narrowing the field to a solid set of platforms (including if you're taking the do-it-yourself method for an e-mail gateway), examine the specific precautions in place to protect against DDoS attacks.  On a homemade system, make sure you follow the readily available system hardening guides to implement protection against SYN flooding (syn cookies, syn proxy, etc).  Does the product you're examing have some mechanism at the IP or SMTP session level to protect you against DDoSs?  If the solution relies totally on some after-the-fact examination of messages, it's already too late.  It's absolutely essential to make the DDoS filtering decision before the message is written to memory/disk and starts taking up precious resources.

Next, how deep is the protection offered?  Multi-layered approaches to security are always the best, and even if there is network level defense against an e-mail DDoS, a correlation engine that examines accepted messages for flood characteristics can still provide a lot of value.  Other considerations are how fast will your solution accept and process messages?  This relies to some extent on the hardware selected (UDMA133, SCSI160, 100baseTX, 1000baseSX, etc) but usually it relies a lot more on the speed and efficiency of the software being used.  A scanning solution based on extensive content scanning against huge dictionaries or lists can result in a significant performance degradation.  Does the solution have any load-throttling capabilities to prevent it from overrunning your internal system if it turns out that the gateway can perform significantly faster than your groupware system?  Last, is there any mechanism to generate alerts when a DDoS is detected?

Last, one of the most effective ways to overcome any kind of DDoS attack is to distribute the resources that are being attacked.  First and foremost, you should have multiple SMTP gateways on different networks, preferably at different physical locations.  Most companies have more than one site that houses computers for their operations, so you should consider making use of one for a backup e-mail gateway.  Remember that backup gateways should have no less protection than your primary gateway (see the sections on Rogue MXs, and WiFi).

In addition, multi-homing your network to multiple upstream providers is a great way to mitigate DDoSs (that's up to your networking folks), and finally putting multiple gateways behind some type of load balancing scheme can help maintain uptime (round robin, number of connections, or least latency).  There are a number of fine Hardware Load Balancers (HLBs) that can accomplish this, or you can do "poor man's balancing" by using DNS record overloading.

It's important to remember that even though your firewall will protect you against some network attacks, those targeted specifically at port 25 will normally go through.  You must have something SMTP-specific to defend you against traffic that looks legit to the firewall (yep, it's SMTP all right!) but will definitely not be received well by your internal systems and users.  E-mail is probably more critical to most organizations than their website, after all, how much of your revenue and business continuity relies on being able to send and receive e-mail?  Ask yourself, "which would be more damaging, lose our website for two days, lose our office phones for two days, or lose our e-mail for two days?"  In most cases, the answer is going to be the latter.




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