Akamai Diversity
Home > Web Security > The Unforeseen Risk of Shared Services DDoS

The Unforeseen Risk of Shared Services DDoS

A DDoS attack targeted at one web site is bad enough. But what happens when that single attack poses the distinct possibility of doing even more damage than originally intended. The kind of collateral damage I'm talking about is very real when you take into account IT architectures reliant on shared services.

Shared services include anything that serves more than one application or set of users, for example:
- Network infrastructure
- Network bandwidth
- Market data and other sources of information.
- Domain name servers

And while shared services can benefit an organization by bringing down IT costs, creating resource efficiencies and shrinking the IT footprint, in the case of a DDoS attack, there can be significant disadvantages. An attack on an organization with a healthy amount of shared services has the capability to cause unforeseen outages across a wide number of applications, users, and geographies.

In this post I'll present three cases in which a DDoS attack impacted a shared service, knocking out applications far beyond the attack target. In each of these cases, the companies were not using Akamai to protect the systems under attack.

 

 Case #1

Case No. 1.jpg

Attack: DDoS attack on Brazilian bank subsidiary
Result: US Bank knocked out due to shared infrastructure in its data center

In this first example, we documented a DDoS attack that was launched at a bank in Brazil. This was a relatively simple attack against the home page of the Brazilian site. 

Because the Brazilian web site shared network infrastructure in one of the bank's global data centers, the US banking web site was also brought down. The attackers had no intention of bringing down the US site. But because of the weak link in shared services - in this case the networking capacity in the data center - this major US bank was brought down by a group of teenagers in Brazil.

What's especially ironic is the bank had invested heavily in DDoS protection for their US web site. They were completely blind-sided.

 

Case #2

 Case No. 2.jpg

Attack: DDoS attack against a Luxembourg customer of a US exchange.
Result: Market data unavailable to USsubscribers during market open hours.

This second case highlights the potential vulnerabilities of market data systems. A major US exchange had a market data service that was used by a customer in Luxembourg to serve its clients. That application came under a DDoS attack which took it out. Unfortunately, that market data service also served one of the exchange's main applications for desktop clients in the US, which ultimately failed.

What's interesting here is that this was not a web site that was brought down, but rather a desktop client application.

 

Case #3

Case No. 3.jpg

Attack: DDoS attack on the name servers of a US subsidiary of a European bank
Result: Bank web sites globally taken offline

In this last example, we illustrate the very high risk associated with DNS, or domain name servers.  A name server translates a web address (mybank.com, for example) to the IP address of the web server.

In this case, Akamai tracked a DDoS attack launched against the domain name servers of a large regional bank in the US.

Unfortunately for the bank, those name servers also provided DNS to many of the bank's web sites across three continents, which all were knocked-out by the attack.

 

How to defend shared services from DDOS:
We believe the best way to defend your shared services from direct or indirect attack is to utilize a cloud security solution. I'll provide some insight into how Akamai would do this related to the situations presented earlier.

In the first situation, Akamai would have protected the attack against the bank with layered defenses, including cached content from Akamai servers, rate limiting of the request (not at the packet level but at Layer 7) and full inspection of the Layer 7 request with our Kona Web Application Firewall. We'd also recommend implementing origin cloaking to protect it from direct attacks among other techniques. More importantly, all of these protections would have been implemented in the Akamai cloud, protecting the web site and the underlying shared services.

For the second scenario, many people don't realize that you can protect market data systems, but you can.  Akamai has customers that are doing it by implementing very short caching rules and rate limiting.  It gets technical, and if you want to hear more we'd be glad to discuss it with you. The important thing is that it has to be done in the cloud, before traffic hits your data center.

In the third situation, it's as easy as deploying Akamai's eDNS. That alone could have prevented a global outage altogether...something Akamai has successfully done on multiple occasions.

These three cases are just a very small sample of many instances of shared services DDoS attacks that Akamai has observed.  If you have any questions about shared services DDoS and its potential impact on your organization - or would like to talk further about web security in general - please let us know.

Rich Bolstridge is chief strategist, Financial Services at Akamai

Leave a comment