How to mitigate UDP flood attacks?

Question

My friend linked me some website where you pay $5.00 / m and get access to a plethora of 'dos stresser' tools that offer udp flooding, and other malicious flooders. It's a web-based system and you just enter in their IP and you're done. It's literally that easy it's sad.

My issue is even if you're behind iptables on a linux vps and are dropping all UDP packets, those packets are still going to hit the server. I'm curious is there a way to block incoming UDP packets at the physical layer, or physical firewall so they cannot reach the software layer (or clients servers)? If that makes sense :P. I'm very bad at trying to explain this.

Thanks!

Answer 1

Your explanation is fine! I think I understand your question.

DDoS Mitigation works generally by placing a mitigation device/system upstream from your internet connection. You can contract a DDoS mitigation service like Prolexic for these services, or you can go with a cloud provider that already includes DDoS mitigation from whatever vendor.

It is impossible to mitigate DDoS at the physical level from your server because the packets are likely flooding the next hop up on the network, e.g. your ISPs local switch. So, you can be dropping the packets all you want, they are still coming from the ISPs switch to your network and utilizing your bandwidth. Thus, to mitigate the attack, the packets need to be dropped upstream.

For smaller web sites, you can use a proxy service like CloudFlare -- in fact, this is the preferred solution for many until they reach very large size. CloudFlare works by controlling your DNS for the domain. It then proxies all web traffic through its network and servers, which are heavily fortified to withstand DDoS attacks and also to intercept other common hack attempts such as XSS and SQL Injection. Legitimate traffic is then forwarded to your web server while suspicious traffic is dropped upstream, leaving you unaffected by the affects of a potential DDoS.

Answer 2

In general there are three things you can do to mitigate a flood of packets.

1. Ensure that your server does not need excessive resources to handle incoming packets. A decent server can easily respond to 1 Gbit/s of echo requests. But if an incoming UDP packet from an unconfirmed source address will start a computation which need significant amount of memory and CPU power and eventually uses multiple UDP packets to transfer a response back to the client, then your server will be an easy target. Your application is not the only thing you need to pay attention to. If you have firewall rules also pay attention to how much processing is involved in each packet there.
2. Have enough bandwidth. Since packets you receive will have consumed your incoming bandwidth regardless of what you do with them, having enough incoming bandwidth is crucial.
3. Push filters backwards against the traffic. This requires co-operation from your provider. If there are easily recognizable patterns which can be used to distinguish legitimate traffic from the flood, then filters could be applied earlier such that your link doesn't become overloaded.

The mitigations mentioned above apply both when you are being attacked directly and when you are a victim of a reflection attack. Due to their nature reflection attacks can be more powerful, but there are also more measures you can make against reflection attacks.

Understanding reflection attacks

First of all it is important to understand how a reflection attack works such that you have a chance of recognizing one when you are hit by it.

1. Attacker send a packet with a spoofed source IP address to some service.
2. Service process the request and send a reply which is larger than the request to the spoofed source IP.
3. Final target receives a larger flood of packets than the attacker was able to produce directly.
4. Target sends error messages back to the service because the replies are not recognized.
5. Service ignores error messages because they do not relate to any ongoing operation (from the service point of view this request was processed and forgotten at step 2).

The server mentioned at step 2 is also known as the reflector. Usually the attacks target a reflector running a UDP based service. Often DNS is targeted, attacks abusing EDNS and DNSSEC can be particular effective. NTP has also proven to be a very effective reflector on at least one occasion.

If administrators don't understand what is happening it is very easy for the administrators of the reflector and the target to blame each other. Having two victims blame each other and each assume the other victim is the attacker is not very productive. Ideally those two administrators co-operate on mitigating the attack.

If you are the final target of a reflection attack you will usually be dealing with a large number of reflectors. Working with the administrator of each reflector separately may not be very productive. Also bear in mind that though the administrators of the reflectors are not malicious, they may be lazy.

Additional measures against reflection attacks

Protection against reflection attacks start already at protocol design. When the client address has not yet been confirmed it is critical to not send more packets or more bytes back to that IP address than you received from it. Reflection attacks are efficient with protocols where the reply is larger than the request.

Protocols running over TCP do not need to consider this problem. The TCP handshake is more robust against reflection attacks than most protocols. Only protocols working at a lower layer than TCP or on top of something ligher like UDP need to protect against reflection.

When implementing an already specified protocol you first need to understand the protocol well enough to know exactly where it has protections against reflection and where it does not. Any protections against reflection specified in the protocol must be implemented securely (which almost certainly means that you need to make use of a good random number generator).

Additionally you need to understand where protection against reflection is lacking in the protocol you are implementing. In such cases you need to be careful with implementing mitigations in your code.

In the above explanation of what happens during a reflection attack the last step was a service ignoring an error message. Instead of ignoring it, the service could use such error messages as indication of a potential ongoing reflection attack and take necessary countermeasures. Sadly such countermeasures are not widespread (I don't know if anybody have applied them).

As an administrator deploying a service which could potentially be used as reflector, you need to understand what you are doing. Only deploy such a service if you need it. Pay attention to any ongoing reflection attacks, and whenever possible use an implementation with measures against reflection.

In general as administrator ensure that your systems send proper ICMP error messages in response to packets which are unexpected or directed to an invalid IP, protocol number, or port number. Also ensure that ICMP error messages are rate limited.

Sending ICMP error messages for every incoming packet targeted at a closed port could become problematic. This is because the ICMP error message contains a copy of the triggering packet and thus will be larger than the original packet (unless the result became so large that it would be truncated). By sending more bytes than you receive, you not only risk turning an incoming flood into an outgoing flood, you also have a host which could be used as reflector.

Sending ICMP error messages for only half the packets for which you could have done so is sufficient to ensure that the number of outgoing bytes and packets is smaller than the incoming. Thus it prevents ICMP error messages being used as a reflection vector. And it is still enough error replies that they could be meaningfully be used as part of a mitigation.

Don't disable ICMP error messages completely. It will make it more difficult for yourself and your users to debug connectivity issues. In some cases disabled ICMP error messages will even be the reason for connectivity issues. It will also prevent the mitigation against reflection attacks mentioned above. If even a tiny fraction of the reflectors implement such mitigations it is more than enough to make ICMP error messages worthwhile.