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.


2 Answers 2


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.

  • Oh, thanks for the reply! When you say 'Thus, to mitigate the attack, the packets need to be dropped upstream.' Are you basically saying by the ISP provider (in my case, xfinity) would have to? How exactly do they drop them, null route my IP I'm assuming? There's really no way to stop the packets from coming is there? Does it just boil down to basic math on whoever has the most bandwidth stays alive in the end? Jun 13, 2015 at 1:05
  • Oh, I would use cloudflare, but my game utilizes websockets and.. yeah, there is just no way; sorry didn't mention that in my first comment. But I agree, CF would be a nice option ^^. Jun 13, 2015 at 1:10
  • 1
    Yes, either the ISP provider themselves or their backbone (e.g. Level3) provider needs to do something to drop those packets. They can do something extreme like null route the IP, or they can start identifying offending IPs and blocking them. Xfinity has a vested interest in eventually blocking these attacks to conserve bandwidth. However, you're never going to get real DDoS mitigation on a DOCSIS connection from them, you'd need a much more expensive and technical internet connection for that. There is no real way for you to stop the packets from coming at the endpoint level. Jun 13, 2015 at 1:14
  • So, when the ISP blocks those IP's, that's something that is not possible at the software layer firewall (iptabes), correct? If so, that's why we need to buy ddos/dos protection IP from vps hosts right? Sorry for all the questions, but I want to check. I just think it's silly we cannot mitigate the UDP using iptables (sure, we can drop the packets), but they will still be there unless the upstream provider does something. I want to be the upstream.. I want control..... Jun 13, 2015 at 1:22
  • 1
    Yes, there's nothing you can put on your end between the cable modem and your stuff that will stop those packets from hitting the cable modem. Thus the need for protection from cloud providers, or if you're running your own cage at a datacenter, upstream ISPs. Jun 13, 2015 at 1:25

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.

  • Wow, didn't see your reply until now, good information. Aug 14, 2015 at 0:53

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .