Groundhog Day for DNS DDoS Attack Announcements
– by Patrick Lynch
Amplification Dangers Abound
On February 11, 2014, Prolexic announced that there is increased likelihood of Domain: A specified location where a set of activity or knowledge exists. For instance, an Internet domain is synonymous with a website address or URL where information can be made available. LookingGlass Cyber (n) - A fancy name for a URL or website. Name Services (DNS) Distributed Denial of Service (DDoS) attacks because a new DDoS toolkit, known as DNS Flooder 1.1, had been released. On February 13, 2014, CloudFlare blogged about a new Network Time Protocol (NTP) DDoS attack.
DDoS attacks are crippling, clogging network pipes and setting up the targets for blackmail or worse.
There are several typical solutions to DDoS attacks:
- Rate limits, a typical Linux systems approach, can shrink the size of the attack, but do not prevent them.
- Seeking unique patterns in the attack traffic and blocking traffic containing the pattern. This requires analysis and some delay before implementation.
With the limitations of the above approaches, is there anything better? Perhaps there is another way to solve what could now be considered typical DNS and NTP DDoS problems, but first, some background: Both NTP and DNS use UDP as their transport protocol. UDP is connectionless: unlike TCP, UPD has no connection establishment, no session tracking, and no session tear down. It is actually the connectionless nature of UDP that allows an attacker to spoof source addresses so that a UDP based service (e.g. DNS or NTP) can be used to flood a target with up to forty times traffic amplification.
Replacing UDP with TCP can eliminate this UDP-based vulnerability, but even TCP has other denial of service risks as well as having a three times traffic increase relative to UDP for equivalent operations, small packets, in particular.
Because UDP protocol handlers themselves are connectionless, upon receipt of a spoofed response, the receiving application stack is unaware that it didn’t send a request. This leads to excess corner case processing and other performance-degrading symptoms.
A visit to the hypothetical
Consider now, a hypothetical firewall with the following characteristics:
- It can track outbound UDP requests
- It permits valid returning UDP responses through the firewall
- Responses that were not requested are dropped. Non-requested responses are hallmarks of DDoS traffic.
This hypothetical firewall automatically stops all of the reflective-type UDP-based DDoS attacks while allowing valid response traffic. The challenges facing this hypothetical firewall include hundreds of thousands to millions of UDP flows. I believe that most firewall-architecture applications running on industry-standard x86-based hardware can’t handle that type of volume without a severe performance penalty.
Hypothetical made real
The firewall described above exists today. CloudShield Technologies, using specialized but open hardware and software, provide solutions that can track UDP requests and responses without perceived user latency. There is no need for TCP mandates and UDP-based DDoS attacks can be prevented, rather than mitigated. A dream come true?
Let’s Look Ahead
CloudFlare warned about DDoS attacks via SNMP, which is UDP-based. Fortunately, I think that one is enterprise-internal, and hopefully enterprise firewalls are blocking that. But the hacker might find one of the many other UDP-based services and attack it. Is your infrastructure up to repelling it?