DDoS Happens!
Denial of Service (DoS) attacks are malicious acts that prevent the utilization of an IT system. The attack can be a single “silver bullet” packet sent to a system that disrupts a service and crashes it. Other DoS attacks can involve an attacker gaining access to the target system, taking control of it and shutting it down. DoS attacks can also manifest with transmitting a deluge of packets or opening many connections to a target system, overwhelming it to the point of saturating its capacity and consuming all its available resources, thus rendering it unusable.
The source of a DoS attack can be a geographically diverse set of traffic originators all sending packets to a single target. This is known as a Distributed Denial of Service (DDoS) attack. David Dittrich (@davedittrich) at the University of Washington Tacoma was one of the first to discover DDoS attacks, uncovering the Stacheldraht attack tool in 1999. Ever since those early days of DDoS research, these types of attacks have continued to increase and metamorphose over the years. If you’re interested in the evolution of DDoS, please review the presentation by Merike Kaeo from Farsight Security on “DDoS History, Trends, Call for Action,” which she delivered at NANOG70.
DDoS Traffic Packet Types
DDoS attacks are typically asymmetric, in that the source address of the packets are from spoofed addresses so the return traffic does not return to the transmitter. The source address can also be spoofed to appear to be from a victim system, such that the resulting reflected response traffic overwhelms the spoofed destination address. DDoS attacks can be volumetric floods of massive amounts of layer 3 and 4 or layer 7 attack traffic. DDoS attacks can consume CPU or memory resources or IP address pool resources in the victim’s system, rendering it unusable. DDoS attacks can also take advantage of connection timeouts or session-state timers to bog down application servers. DDoS attacks can also target software vulnerabilities using specifically crafted packets. There are a wide variety of packet types that comprise most DDoS attacks, including, but not limited to:
- ICMP packet floods
- UDP fragments
- TCP SYN/ACK/RST floods
- CharGEN floods
- NTP reflection floods
- DNS reflection floodsS
- SDP reflection floods
- CLDAP reflection floods
The types of packets that attackers generate can vary from year to year or day to day depending on which method may be the most detrimental to the victim. In recent years, NTP and DNS reflection DDoS attacks have been prevalent. There are documented methods for “Finding and Fixing Open DNS Resolvers” that may prove helpful in ensuring that your DNS servers aren’t complicit in these types of attacks.
A great source of information on recent DDoS activities is the Akamai State of the Internet Report. In the Q4 2017 report, Akamai determined that there was a 14% increase in total DDoS attacks, a 14% increase in infrastructure layer 3 and 4 attacks, a 22% increase in application-layer attacks, and a 4% increase in reflection-based attacks. Another great source of DDoS trends and statistics is the Arbor Networks (now the security division of Netscout) Worldwide Infrastructure Security Report (WISR); they recently published their thirteenth report.
Do DDoS Attacks Really Occur Over IPv6?
The wide variety of attack packet types can use either IPv4 or IPv6 for the network-layer protocol. However, if a target only has IPv4 transport and connectivity to and from the Internet, then it’s only possible for the attack to use IPv4. As IPv6 has becomes more widely deployed, IPv6 will be an increasingly viable attack protocol.
Eric Vyncke and I wrote about IPv6 DDoS in 2008 in our book “IPv6 Security” (Chapter 3), but it took a few years for IPv6 DDoS attacks to be seen in the wild. Some of the first sizable IPv6 DDoS attacks were observed by Arbor Networks and documented in February 2012. I was interviewed about these early IPv6 DDoS attacks and at the time I felt that the attacks were the result of one of two possibilities: The first possibility was that attackers might just be clueless about the IP version that the attack used. It could be that the attacker’s botnet army happened to have IPv6 Internet connectivity and the attacker simply pointed to a victim’s FQDN, which resolved to an IPv6 address. Therefore, the attack unknowingly took place over IPv6 transport. The second possibility was that the attackers were purposefully using IPv6 as the transport protocol to assess whether their victims had IPv6 DDoS mitigation measures in place. The attackers could also be betting the victim did not have an IPv6 defensive capability and hoping that an attack over IPv6 would be more disruptive. My hope was for the former possibility of clueless attackers unknowingly using IPv6.
The concerns over IPv6 DDoS attacks continued into 2015 as more observations were being made. DDoS attack traffic volumes continued to rise: at the end of 2016, the Mirai botnet was able to generate an astounding 600 Mbps. An Arbor Networks report stated that the peak traffic volume that their ATLAS system monitored was 641 Gbps (in a DNS reflection attack), but the largest NTP reflection/amplification attack observed was 662 Gbps.
Recently, in early March 2018, there was an unprecedentedly massive DDoS attack that leveraged Memcached servers to perform a packet amplification attack directed at GitHub. The traffic volume reported by Akamai/Prolexic as an astounding 1.3 Tbps sent to Github. Then Arbor Networks observed a 1.7 Tbps reflection attack directed toward an ISP customer. The second attack reportedly was initiated by 1900 compromised IPv6-connected hosts, exploiting open DNS resolvers for packet amplification. The Register reported “It’s begun: ‘First’ IPv6 denial-of-service attack puts IT bods on notice”, and others reported this as the “first native IPv6 DDoS attack.” While this was far from being the first IPv6 DDoS attack, it was a sizable volumetric attack. The DDoS attack volume was way off the charts, setting a new high-water mark for these types of attacks, regardless of IP protocol version. It is now clear that as IPv6 gains adoption, it will become a more lucrative connection protocol for attackers.
How to Be Prepared?
Attackers have demonstrated that they can vary their attack methods quickly and, in some cases, they can stay ahead of the defender’s ability to change their mitigation strategies. When enterprises are preparing their IPv6 DDoS mitigation measures, they should realize that their IPv6 protection measures are going to be very similar to their IPv4 protection measures. It is also important to recognize that an organization needs to have equal protections for IPv4 and IPv6. If the attacker senses weakness in either transport protocol, then the attacks will use the less defended protocol.
The Arbor Networks WISR #13 report stated that of those organizations who have deployed IPv6, only 61% could monitor their IPv6 traffic. Furthermore, DDoS over IPv6 was one of the major concerns of the survey’s respondents. Even though most DDoS attacks occur over IPv4, 8% observed DDoS attacks that used IPv6 packets.
Enterprises must plan to mitigate an IPv6 DDoS attack before it happens, and there is published guidance on how to achieve this goal. Ognian Mitev (the RMv6TF Chair, currently at Charter Communications) and Barry Dykes gave a great presentation at NANOG63 on “Approaches for DDoS — an ISP Perspective” that covers many of the common mitigation methods. However, the most practical advice for enterprises is to simply IPv6-enable their currently used common DDoS mitigation techniques.
Access Control Lists (ACLs) can be used to block the incoming packets based on type, source or destination. Even though ACLs are the lowest lifeform on the DDoS mitigation spectrum, they are quick and easy to deploy in a tactical situation. Ingress and egress filtering is considered a Best Current Practice (BCP) and documented in IETF BCP 38. ACLs can also be used to filter Bogon addresses, thus filtering any packets sourced from anything other than assigned IPv6 global unicast addresses. Bogon route servers, such as those maintained by Team Cymru, can be helpful in keeping these route filter ACLs consistent and regularly-updated.
Unicast Reverse Path Forwarding (Unicast RPF) can also be a useful method in dropping packets where the source address does not match the return route back to that originating address. Routing tables can be used to identify traffic with spoofed source addresses arriving on an abnormal interface. Unicast RPF can work well by utilizing the IPv4 or IPv6 routing table to detect and drop spoofed packets.
Remotely Triggered Black Hole (RTBH) (RFC 5635) is a common DDoS method used in large networks. This technique has been adapted for IPv6 (RFC 6666), too. Cisco has a great paper on configuring “Remotely Triggered Black Hole Filtering in IP Version 6”.
Intrusion Prevention Systems (IPSs) can also be used to block IPv6 attack traffic. Depending on the vendor you choose, the IPv6 capabilities in these products vary greatly. Therefore, you want to look carefully at the ingredients list and scrutinize the vendor’s IPv6 feature claims and prefer vendors who have dual-protocol IPS engines.
NetFlow-based DDoS protection measures, like those popularized by Arbor Networks, are dual-protocol capable. Steinthor Bjarnason, from Arbor Networks, presented on “As on a Darkling Plain: Network Survival in an Age of Pervasive DDoS” at the NANOG71 event.
Other emerging solutions involve utilizing BGP Flowspec (RFC 5575); this method could be used with IPv4 or IPv6 equally well. There is an IETF draft (draft-ietf-idr-flow-spec-v6-09) to disseminate flow spec rules for IPv6 attacks. Cisco provides configuration examples for BGP Flowspec on their ASR 9000 routers.
Another emerging mitigation technique is to leverage DDoS Packet Scrubbers. Examples of this would include the Radware DefenseFlow and the A10 Networks Threat Prevention System (TPS), which won the 2014 RMv6TF Best of Show for IPv6 Product and Service Award.
A popular choice for enterprises is cloud DDoS mitigation. Akamai acquired DDoS mitigation company Prolexic, and now offers their DDoS mitigation service. Verisign offers a DDoS mitigation service; their 4th Quarter 2017 DDoS Trends Report provides valuable information. Other popular cloud-based DDoS services come from Arbor Networks, and Incapsula’s cloud DDoS solution comes from Imperva.
Content Delivery Networks (CDNs) such as Akamai, CloudFlare, and Limelight Networks can also provide DDoS protection, many of which have significant IPv6 capabilities. Krassimir Tzvetanov, from Fastly, gave a great presentation on “Fundamentals of DDoS Mitigation” at the recent NANOG72 event as an update to his DDoS Tutorial from NANOG69.
Cloud-based Web Application Firewalls (WAFs) such as those from Threat X, Cloudflare, and Incapsula can also help protect DDoS attacks from affecting your web applications, regardless of IP protocol version.
Summary
You need to have DDoS mitigation procedures at-the-ready, and not wait to configure them until you need the DDoS mitigation techniques. People often utter the Franz Kafka quote “Better to have, and not need, than to need, and not have.” I would like to put forward a revision of this Kafka quote for consideration: “It’s better to have a DDoS protection mechanism and not need it than to need a DDoS protection mechanism and not have it.” The Boy Scout Motto “Be Prepared” also rings true.
When a DDoS attack strikes you do not want to frantically search for your upstream ISP’s support contact information or try to hurriedly deploy an inline IPS. In the midst of a sudden IPv6 DDoS attack you do not want to be scrambling to apply IPv6 ACLs or to rapidly configure a BGP-based RTBH infrastructure. In times of crisis, you are highly likely to make mistakes, thus increasing your mean-time-to-mitigate. It is far better to prepare for this DDoS war during peacetime and, hopefully, you never need to deploy these measures.
This post originally appeared on Infoblox Community blog: https://community.infoblox.com/t5/IPv6-CoE-Blog/IPv6-DDoS-and-Protection-Measures/ba-p/12830
Scott Hogg is the Chief Technology Officer (CTO) for GTRI.
