The Unforeseen Risk of Shared Services DDoS

Reported by: |Updated: September 19, 2013

Rich-Bolstridge-AkamiRich Bolstridge

Chief Strategist,

Financial Services,

Akamai Technologies

A Distributed Denial-of-Service (DDoS) attack targeted at one website is bad enough. But what happens when that single attack possesses the distinct possibility of doing even more damage than originally intended. The kind of collateral damage 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

Though 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.

To shed further light on the magnitude of such an attack, there are 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

Attack: DDoS attack on Brazilian bank subsidiary.

Result: US Bank knocked out due to shared infrastructure in its data center.

Background: 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. As 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

Attack: DDoS attack against a Luxembourg customer of a US exchange.

Result: Market data unavailable to US subscribers during market open hours.

Background: 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

Attack: DDoS attack on the name servers of a US subsidiary of a European bank.

Result: Bank web sites globally taken offline.

Background: 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 too 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.  Akamai itself, has several solutions that would have had a positive impact for each of the firms cited in each of the mentioned case studies.

To illustrate this point, further, 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, deploying Akamai’s eDNS would have been able to prevent a global outage altogether.



Nov 2017 cover


Nov 2017 cover