4,300 Publicly Reachable Servers Are Posing a New DDoS Hazard To the Internet (arstechnica.com) 13
An anonymous reader quotes a report from Ars Technica: DDoS mitigation provider Netscout said on Wednesday that it has observed DDoS-for-hire services adopting a new amplification vector. The vector is the Datagram Transport Layer Security, or D/TLS, which (as its name suggests) is essentially the Transport Layer Security for UDP data packets. Just as TLS prevents eavesdropping, tampering, or forgery of TLS packets, D/TLS does the same for UDP data. DDoSes that abuse D/TLS allow attackers to amplify their attacks by a factor of 37. Previously, Netscout saw only advanced attackers using dedicated DDoS infrastructure abusing the vector. Now, so-called booter and stressor services -- which use commodity equipment to provide for-hire attacks -- have adopted the technique. The company has identified almost 4,300 publicly reachable D/LTS servers that are susceptible to the abuse.
The biggest D/TLS-based attacks Netscout has observed delivered about 45Gbps of traffic. The people responsible for the attack combined it with other amplification vectors to achieve a combined size of about 207Gbps. [...] The 4,300 abusable D/TLS servers are the result of misconfigurations or outdated software that causes an anti-spoofing mechanism to be disabled. While the mechanism is built in to the D/TLS specification, hardware including the Citrix Netscaller Application Delivery Controller didn't always turn it on by default. Citrix has more recently encouraged customers to upgrade to a software version that uses anti-spoofing by default.
Besides posing a threat to devices on the Internet at large, abusable D/TLS servers also put organizations using them at risk. Attacks that bounce traffic off one of these machines can create full or partial interruption of mission-critical remote-access services inside the organization's network. Attacks can also cause other service disruptions. Netscout's Hummel and Dobbins said that the attacks can be challenging to mitigate because the size of the payload in a D/TLS request is too big to fit in a single UDP packet and is, therefore, split into an initial and non-initial packet stream.
The biggest D/TLS-based attacks Netscout has observed delivered about 45Gbps of traffic. The people responsible for the attack combined it with other amplification vectors to achieve a combined size of about 207Gbps. [...] The 4,300 abusable D/TLS servers are the result of misconfigurations or outdated software that causes an anti-spoofing mechanism to be disabled. While the mechanism is built in to the D/TLS specification, hardware including the Citrix Netscaller Application Delivery Controller didn't always turn it on by default. Citrix has more recently encouraged customers to upgrade to a software version that uses anti-spoofing by default.
Besides posing a threat to devices on the Internet at large, abusable D/TLS servers also put organizations using them at risk. Attacks that bounce traffic off one of these machines can create full or partial interruption of mission-critical remote-access services inside the organization's network. Attacks can also cause other service disruptions. Netscout's Hummel and Dobbins said that the attacks can be challenging to mitigate because the size of the payload in a D/TLS request is too big to fit in a single UDP packet and is, therefore, split into an initial and non-initial packet stream.
great (Score:2)
Re: (Score:1)
If I remember correctly, they held both the SWAT'er, and the person who was supposed to have been SWAT'ed responsible, the SWAT'er for the obvious reasons, and the other for giving out a real "false" address for the SWAT'er to go after. But I could be remembering wrong. I also thing the SWAT'er was like a SWAT for hire or something.
Re: (Score:2)
Seriously WTF? An OPTION for spoofing mitigation?? (Score:2, Insightful)
You know your protocol is completely FUCKED when you have a STUPID STUPID option that should:
A) NOT EXIST AT ALL BECAUSE THE PROTOCOL IS WELL WRITTEN
B) BE ENABLED BY DEFAULT EVERYWHERE BECAUSE WHO THE FUCK IN YOUR INTERNAL NETWORK SHOULD BE SPOOFING ANYWAY?
Another UDP protocol, written by idiots it seems.
All swearing intentional, because this really really is a fucking idiot thing to do.
Re: (Score:2)
The solution is obvious. (Score:5, Funny)
All you have to do is have them all DDoS each other until the admins fix their shit. The best way to have someone fix a problem is to make it their problem.
Re: (Score:3)
All you have to do is have them all DDoS each other until the admins fix their shit. The best way to have someone fix a problem is to make it their problem.
No. Just have the ISPs drop them off the 'net. See how fast it gets fixed then and no messy criminal charges because you stooped to their (DDoS's) level.
Re: (Score:2)
Of course, to do that you have to make it the ISPs problem...
Re: (Score:2)
Of course, to do that you have to make it the ISPs problem...
And you don't think that being a part of the DDoS attack would concern the ISP? They are an integral part of the problem.
Re: (Score:2)
Some seem to care, others show no sign of caring.
TLS packets? (Score:2)
Just as TLS prevents eavesdropping, tampering, or forgery of TCP packets, D/TLS does the same for UDP data.
I have a feeling this is probably what someone meant to say.
Doesn't this cost those companies money? (Score:1)
Once a network goes over its monthly bandwidth contract limit, the ISP starts charging companies per GB of transfer. What are the finance departments at these companies doing? Shouldn't they notice a major increase in that IT budget expenditure line item every month the company's infrastructure was used in a global DDoS attack and ask the question, "Hey, what's up with this line item?"
Every ISP should be tracking unusual traffic through their networks. When a sudden spike occurs in a given month outside