Any organization that has ever been through it knows how tremendously detrimental a DDoS attack can be. Aside from...
the obvious, such as decreased performance or complete inaccessibility of an organization's Web presence, there can also be less obvious impacts. For example, consider the financial impact to an organization employing "consumption-based pricing" at an IaaS or even a colocation provider. The impact to the cost associated with a DDoS can be significant when those organizations are charged incrementally for bandwidth or CPU time.
Distributed denial-of-service (DDoS) attacks, despite not always being "front of mind" from an enterprise point of view, can have serious consequences, so it should not be surprising that technologies have emerged that specialize in preventing or mitigating this type of attack. These technologies rely on different mechanisms; for example, one model uses the cloud to mitigate the impact of DDoS attacks by filtering out problematic traffic at the cloud provider with DNS rerouting. The most common method is to adjust the DNS record to refer requests for the customer's Web server to the cloud provider. The cloud provider, in turn, acts as a reverse proxy for inbound requests, filtering out the "bad guy" traffic and proxy legitimate traffic to the customer.
This solution has some advantages: it doesn't require modifications to the customer's website, it doesn't require new hardware and it can be enabled or disabled quickly. However, reliance on DNS rerouting can complicate matters. Since traffic gets to the cloud provider in the first place through DNS resolution, an attack that can bypass domain name resolution -- for example one targeting the underlying customer's IP directly -- would also bypass the protection mechanism entirely.
The impact of this from a practitioner point of view is that keeping hidden the source IP of the services a customer wishes to protect is fairly important. In fact, the value provided by the mitigation service correlates to the degree of difficulty involved in obtaining the origination information -- the better they can keep it hidden, the more difficult it is for the attacker.
This is the point made by researchers from the University of Leuven in Belgium and Stony Brook University in New York, in their paper, "Maneuvering Around Clouds: Bypassing Cloud-based Security Providers" which outlines -- and tests the efficacy of -- a number of methodologies to discover the originating IP of servers that are protected by cloud-based DDoS prevention techniques. They looked at IP history databases, subdomains that resolve to the originating IP, for example, those used for SSH connections, DNS information (e.g., MX records that do not point to the cloud provider), files that might contain IP information, pingbacks and certificate information. The companion website to their research provides a scanning tool that implements these methods for administrators who want to understand whether their own environment is at risk.
What makes this particularly important is not only the prevalence of sites that are vulnerable -- 71.5% of the sites they tested, according to their paper -- but also the fact that that these methods could be built upon by a savvy attacker. For example, the implementation on the CloudPiercer website looks for PHP info files; however, these are certainly not the only files that might contain the IP of the server: Backup files or scripts could contain this information as well.
What can be done?
Exposure of the origination point for a cloud-protected Web server can be undesirable for cloud-based DDoS prevention; it therefore behooves savvy security pros ask a few questions. Most obviously, what can they do to help ensure they stay protected if using cloud-based DDoS prevention services? How can it impact organizations that are currently evaluating DDoS mitigation tools and strategies?
For an organization already using a cloud service as part of their DDoS prevention strategy, it is imperative they understand whether or not they are exposing this information and that they take steps to safeguard against this information being exposed in the future. To determine if they are exposing this information now, a useful first step might be to leverage the free scanner the CloudPiercer research team provides. However, recognizing that there could be other avenues not covered by that tool -- for example, IP history databases other than those employed by the tool, information in files other than those looked for by the tool -- some organizations may wish to undertake a more extensive analysis. They might, for example, evaluate whether a penetration test -- one that specifically includes information disclosure as an objective -- could offer value in ensuring the information is really as hidden as they think it is.
Once they have an understanding of whether or not they are currently impacted, it can be beneficial to establish processes that ensure the information is not disclosed in the future. The specific steps of how they choose to do this will obviously vary from firm to firm, but they might consider periodic scanning, "grepping" content changes for the host IP and evaluating changes where the IP address is referenced, developer education about the issue or other techniques that suit the environment.
For organizations that are evaluating cloud-based DDoS prevention tools and services, it is likewise important to recognize that this issue exists and plan around it. Some options include establishing processes like those described above designed to minimize/prevent information disclosure. These give more weight to appliance-based on-premises solutions in a case where challenges can be foreseen in keeping the origination hidden or considering services that operate in the cloud but that leverage BGP -- many vendors offer both options.
Thinking about this issue and factoring it into security planning is a useful consideration because, while DDoS mitigation is important in its own right, getting the most value for purchased services requires understanding and planning around this issue.
Learn more about how to deny attackers launching denial-of-service attacks.