Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Network Security

9/18/2019
09:05 AM
Larry Loeb
Larry Loeb
Larry Loeb
50%
50%

DNSSEC Can Encourage DDoS – Nexusguard

Report found that DNS Amplification contributed to the largest share, compared to other methods, of attack activities in Q2 2019.

Nexusguard is, it says, "a cloud-based distributed denial of service (DDoS) security solution provider."

It put out a "Threat Report Distributed Denial of Service (DDoS) for Q219" that is understandably focused on the part of the security problem that it routinely deals with. The company says it gets the numbers reflected in the report from "attack data, research, publicly available information, Honeypots, ISPs, and logs recording traffic between attackers and their targets." All this effort goes to evaluate DDoS events "in a manner that is not biased by any single set of customers or industries," as the report put it.

Nexusguard found that DNS Amplification contributed to the largest share, compared to other methods, of attack activities in Q2 2019. It showed up in 65.95% of the attacks.

A DNS Amplification attack means that UDP packets with spoofed target IP addresses are maliciously sent to a publicly accessible DNS server. Attempting to respond to the sender, DNS resolvers transmit a large response to the target's spoofed IP address. The target receives an enormous amount of responses from the surrounding network.

Consider for context that during the quarter, Nexusguard's honeypot network captured 144,465,553 malicious DNS queries. That's a lot, which is sort of the point of the amplified attack.

It's no wonder that Nexusguard found that DNS Amplification was the leading DDoS attack vector, showing sharp increases of 31.01% QOQ and 1,040.41% YOY, respectively. HTTP and HTTPs Flood followed, dropping 12.78% and 36.00% (QOQ), while increasing 281.51% and 363.33%, respectively, (YOY).

The HTTP Flood attack is the second most common attack, attempting to exhaust server resources by generating valid, volumetric HTTP requests or sessions. The most common method to launch these attacks is HTTP GET flooding.

The third most common vector is HTTPS Flood. These sessions are typically HTTPS GET. They overwhelm the victim's web servers by flooding them with answer requests (ACK). The process forces servers to allocate maximum resources to handle the volumetric attack traffic. Normal traffic can't get though because of this.

Nexusguard found single-vector attacks dominated with 63.56% of the total, while multi-vectors accounted for the rest. Two- and three-vectored attacks were 13.56% and 8.71%, respectively. The maximum number of vectors they saw was 13.

As far as duration of the attacks, 74.18% of attacks lasted fewer than 90 minutes. 2.42% lasted more than 1,200. The quarterly average was 182.9 minutes, while the longest attack they saw lasted 28 days, 1 hour, and 11 minutes. In the quarter, the average duration dropped by 65.57% (QOQ) and 42.50% (YOY) and the maximum duration fell by 3.76% (QOQ) while rising 467.97% (YOY).

The report has an interesting take on DNSSEC. It notes that, "The growing adoption of DNSSEC suggests that DNS Amplification will continue to pose a significant threat to service provider and enterprise networks alike. Long overdue, the deployment of DNSSEC as the ultimate patch for fixing DNS cache poisoning is finally gaining widespread acceptance. The downside is the exceptionally long responses DNSSEC-enabled servers generate. The long DNS responses include records containing cryptographic keys and/or signatures. When a domain is upgraded to support DNSSEC, it returns traditional records as well as DNS records. As a result, the sizes of DNSSEC-enabled DNS responses significantly exceed those of traditional responses."

An attacker will like this, since it is easier for an attacker to stuff up a system with a long response. But the rest of us may put up with the potential problem of DDoS for the cache fix of DNSSEC.

— Larry Loeb has written for many of the last century's major "dead tree" computer magazines, having been, among other things, a consulting editor for BYTE magazine and senior editor for the launch of WebWeek.

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
COVID-19: Latest Security News & Commentary
Dark Reading Staff 7/1/2020
Ripple20 Threatens Increasingly Connected Medical Devices
Kelly Sheridan, Staff Editor, Dark Reading,  6/30/2020
DDoS Attacks Jump 542% from Q4 2019 to Q1 2020
Dark Reading Staff 6/30/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
The Threat from the Internet--and What Your Organization Can Do About It
This report describes some of the latest attacks and threats emanating from the Internet, as well as advice and tips on how your organization can mitigate those threats before they affect your business. Download it today!
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-15478
PUBLISHED: 2020-07-01
The Journal theme before 3.1.0 for OpenCart allows exposure of sensitive data via SQL errors.
CVE-2020-6261
PUBLISHED: 2020-07-01
SAP Solution Manager (Trace Analysis), version 7.20, allows an attacker to perform a log injection into the trace file, due to Incomplete XML Validation. The readability of the trace file is impaired.
CVE-2020-15471
PUBLISHED: 2020-07-01
In nDPI through 3.2, the packet parsing code is vulnerable to a heap-based buffer over-read in ndpi_parse_packet_line_info in lib/ndpi_main.c.
CVE-2020-15472
PUBLISHED: 2020-07-01
In nDPI through 3.2, the H.323 dissector is vulnerable to a heap-based buffer over-read in ndpi_search_h323 in lib/protocols/h323.c, as demonstrated by a payload packet length that is too short.
CVE-2020-15473
PUBLISHED: 2020-07-01
In nDPI through 3.2, the OpenVPN dissector is vulnerable to a heap-based buffer over-read in ndpi_search_openvpn in lib/protocols/openvpn.c.