SYN Flood Knocks Down Heroku

Heroku has been added to the list of cloud sites with availability issues. Their write-up makes me nostalgic for my Motorola pager and the IBM AIX systems that always used to wake me up at night.

The primary on-call engineer was paged and quickly escalated the problem to the on-call incident commander who began investigating. The situation very quickly worsened and some nodes became unresponsive, causing applications with DNS records pointing to those IP addresses to become unreachable.

Oh, but wait, this isn’t some old traditional IT environment. This is the cloud. Applications are unreachable? A traditional IT environment attack, a flood of SYN packets, is to blame.

These attacks affected any customers who had their DNS configured to direct a root domain name (i.e.: mydomain.com, but not www.mydomain.com) at the IP addresses we publish in our documentation. [2] Customers with applications directed via CNAME records at proxy.heroku.com were generally unaffected. Because Heroku.com was also directed at these IP addresses, deploys via git push heroku were similarly affected.

This outage comes just as cloud DDoS mitigation marketing is taking off and encouraging companies to trust their service providers.

VeriSign, which now sells a $35K/year DDoS mitigation service, has just published a scare-report that the chance of attack is higher than ever.

Examination of a global sample of websites revealed that when availability problems occur, sites hosting their own DNS (representative of most enterprises today) are much more impacted than those using third-party managed DNS providers

The CloudFlare blog explains how they would perform traffic analysis for you and then apply limits to reduce the impact duration of DoS attacks.

One of our user’s site was under a denial of service (ddos) attack earlier this week. You can see the surge in traffic (the green line). Then, soon after, you can see the CloudFlare system start to learn from the change in data and start identifying that the new traffic is indeed an attack (red line), rather than a surge in legitimate traffic. As CloudFlare starts to identify the new traffic as an attack, the system starts to block it at our edge nodes around the world.

I wonder if we should call this the Boa Constrictor defence to DDoS — it looks like a well-fed snake.

There are numerous theoretical advantages to having a service provider respond on your behalf to an incident. The reality, however, may be a very different story. One big question to ask a provider is whether they will “own” or personally accept the incident as their own if you transfer responsibility. And that begs the question of whether an incident is in any way a consequence of their architecture/environment.

ISO/IEC JTC1/SC 38 Study Group on Cloud Computing Draft Report

The Study Group on Cloud Computing of the ISO/IEC JTC1/SC 38 has posted a V2 draft report. It has some interesting comments on security, especially confidentiality. It also has updates on cloud computing initiatives, starting on page 23.

  • Cloud Computing Initiatives
  • Open Grid Forum (OGF)
  • The Cloud Computing Interoperability Forum (CCIF)
  • Distributed Management Task Force (DMTF)
  • Cloud Security Alliance (CSA)
  • ETSI Technical Committee (TC) CLOUD
  • Organization for the Advancement of Structured Information Standards (OASIS)
  • Object Management Group (OMG)
  • Storage Networking Industry Association
  • ITU-T Focus Group on Cloud Computing
  • Open Cloud Manifesto
  • W3C
  • CCF (Cloud Computing Forum in Korea)
  • KCSA (Korea Cloud Service Association)
  • The Open Group
  • Study Group on Smart Cloud (Japan) – TBD
  • European Network and Information Security Agency (ENSIA)
  • ISO/IEC JTC 1/SC 27
  • Institute of Electrical and Electronic Engineers (IEEE)
  • CESI (China Electronics Standardization Institute)
  • Cloud Industry Forum (CIF)

…and I see that X9 just initiated their own.

Malware Mutation and Descendancy

A case study by Zynamics illustrates the trouble with assuming each new discovery of malware is new, unique or sophisticated. They used a 50% litmus of similarity and discovered descendants came from only a few bots:

Files, which exhibit a mutual similarity of more than 50 % have been assigned to the same family. The next step was to have the files named by an anti-virus-program (ClamAV). We replaced the MD5 sums with the names in the tree. The result was this graph.

The graph enables us to draw interesting conclusions:

  1. We could clearly assign several bots to a family even though ClamAV did not identify them.
  2. Many “distinct” bots show a strong similarity to other bots and should actually be assigned to one single family (e.g. Trojan.GoBot and Trojan.Downloader.Delf as well as Worm.Korgo.Y and Worm.Padobot.I). This seems to be due to problems in the naming-process.
  3. Basically, all bots are representatives of two big (GoBot, PadoBot) and 3 small families (Sasser, PoeBot, Crypt-8) as well as some “repairs”.

malware tree