How to attack DDoS threats with a solid defense plan
A comprehensive collection of articles, videos and more, hand-picked by our editors
There's a saying amongst some MSSPs that there are two kinds of customers: those that use DDoS mitigation services...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
and those that never had a DDoS attack happen to them. The reason why isn't hard to understand: from the point of view of those who've been through it, even a single DDoS event can be so traumatic to business operations that just one experience can be enough to transform DDoS mitigation services from a nice to have to a must have.
In 2015, the University of Leuven in Belgium and Stony Brook University in New York published a paper, Maneuvering Around Clouds: Bypassing Cloud-based Security Providers, which describes an issue associated with a number of popular cloud-based DDoS mitigation techniques. That paper, along with the companion CloudPiercer tool -- described by the paper as an "automated origin-exposing tool" -- demonstrates a vector by which an attacker could potentially gather the information required to circumvent certain types of DDoS mitigation services. Specifically, many cloud-based DDoS mitigation services rely on changes to DNS (i.e., DNS rerouting) as a mechanism to pre-filter DDoS traffic.
Services that operate in this way adjust the DNS record of a customer to point to their site -- sometimes referred to as a "scrubbing center." They filter out the bad traffic and pass along only legitimate traffic to the customer site they're protecting. What the research describes -- and the CloudPiercer tool demonstrates -- is accidental exposure of the original IP of the protected site (i.e., the external IP of the protected site.) Such an exposure can lead to circumvention of the mitigation; meaning, if the bad guy can find out what the unprotected IP is, he can still conduct the DDoS attack as if the mitigation measures were not in place.
There was an initial wave of interest in this research which has since quieted down somewhat, but the issue still very much matters. DDoS attacks still exist and are still highly problematic when they happen; likewise, origin discovery is still a critical issue in tools and services that leverage DNS as the methodology to vector traffic. Consequently, many practitioners may be left wondering how specifically to implement DDoS mitigation in the cloud using DNS rerouting -- or even whether a cloud mitigation service makes sense in light of this research. It's not an easy question to answer, but it is one that can be approached systematically; keeping a few things in mind during an implementation can mean a world of difference if the worst happens and your organization falls victim to a DDoS attack.
First, it is important that practitioners understand origin address discovery while evaluating and implementing cloud-based DDoS mitigation services. Specifically, practitioners need to understand what it is and why it matters. Larger customers may have the option in certain situations (i.e., when they have the flexibility to deploy hardware and they have at least a /24 prefix -- a Class C block) to select between BGP and DNS as a methodology for redirecting traffic to a scrubbing center. Despite the additional complexity associated with using BGP over DNS, they may give higher weight to it in light of the origin discovery issue. Part of obtaining this understanding could entail some pointed Q&A with the service providers they're evaluating about origin discovery -- what services the provider offers to help, what the expectations and assumptions are made about how the customer will keep information protected and so on.
Secondly, it is important to establish a process to check for origin disclosure on a periodic basis. There are any number of ways that the origin IP might be disclosed, and the CloudPiercer tool checks for some of those ways, but keep in mind that any disclosure at all -- from a web developer accidentally including it in a comment on the site to unchanged MX records to pingbacks to information on X.509 certificates -- can all potentially leak this information. Therefore, any available methodology that you can leverage to find this information is beneficial. This can include vulnerability scanning tools, application testing tools, DLP tools, or anything that can tune or write rules to help find and flag origin disclosure is beneficial here. Running these tools -- or doing a self-examination -- periodically is particularly valuable as each assessment is a "point in time" exercise, and configurations can change and content updates can be released rapidly.
Next, testing the DDoS service itself is beneficial. The trap is to view DDoS mitigation services like insurance: there when you need it but invisible when you don't. A better approach is to test the DDoS mitigation just like testing DR or other contingency measures. A reputable vendor won't balk at this request; it's what it does and gives it an opportunity to showcase its capability -- it may even help you facilitate such a test. This isn't to suggest that someone bait Anonymous into a DDoS attack here, but even a small-scale test that doesn't break the bank on bandwidth consumption can make sure the service is operating as intended and that the organization gets what it pays for.
Lastly, evaluate implementing filters or detection rules on traffic that does not originate from the scrubbing center. Some service providers may suggest filtering all traffic that does not originate from them; this can be a good approach when it's practicable, but note that there could be situations that prevent this. For example, a large install base of a legacy application with a hardcoded or difficult-to-change IP could make strict filtering difficult to effect. Even in situations where this it isn't possible or practicable to filter all traffic excepting that from the scrubbing center, there are still options. For example, it's possible to utilize an IDS or other detective control to alert the security team to unexpected connections that do not originate from the service provider; while this won't prevent a DDoS, it will at least alert the organization to something suspicious, like an investigatory probe from an attacker that could lead to something more sinister down the line.
While the decision of how to approach DNS-based DDoS mitigation is a challenging one, from an implementation standpoint, there are some very real steps that enterprises can take to ensure they're getting the protection they want and expect. By understanding what origin discovery is, by testing -- both for origin discovery and the DDoS mitigation service itself, and by evaluating filtering and/or detection mechanisms, organizations can stay ahead of the game.
Check out this guide to DDoS defense planning
Learn how to create a cloud DDoS protection plan
Find out how to protect cloud networks from DDoS attacks