How to mitigate UDP Flood?

Question

Servers with majority of its traffic in UDP (new connections are expected), what can be used to effectively mitigate UDP flood? For example forged source IPs with variable sized UDP payload (typically 0-40 bytes) sent to UDP service port and the application will have problems if it sees UDP flood.

1. Are there any side effects to drop all incoming UDP with payload smaller less than a certain size? I know it does not solve the problem but it somehow increases the cost of the attack.
2. Anything I can effectively do with a SRX240 or PA-2000?
3. Or any other suggestions?

Answer 1

UDP attacks generally fit two profiles:

1. Small packets aimed at hammering the application of the server.
2. Large packets aimed at exhausting available bandwidth.

There is of course also the possibility of using large packets if the attacker knows that a well-crafted packet can cause additional processing time on the server in excess of the additional bandwidth cost.

Simply dropping UDP packets below a certain size is far too blunt of an instrument to really be commendable, not least because this may well just result in your attacker changing strategy.

For example, if the focus was to hammer your servers, the attacker could switch to an DNS amplification attack that aims to exhaust your available bandwidth.

---

So what can you do to mitigate these issues or respond? It generally comes down to observing an attack and then profiling it. There are a few basic things you can do such as implementing uRPF at your edge to filter spoofed IPs that do not actually exist on the public internet and using rate-limiting heuristics that will block an IP if it repeatedly sends what you consider "bad" traffic (e.g. rapidly transmitting small UDP datagrams).

When it comes to an active attack, analysis is the key:

Do you observe a common source port, IP (address/range) or payload data within the attack traffic, if so, you have criteria to define a block rule with.

On the other hand, if you're falling victim to a DNS amplification attack or anything that relies on exhausting your available inbound bandwidth - the only real counter-measure if it is killing your throughput is to blackhole the target addresses at your upstream provided. Basically, you sacrifice the reachability of the target for the good of the rest of your network. If it doesn't saturate your links, any decent stateful firewall should block unsolicited DNS response packets.

Answer 2

First of all, you should understand, what resource is affected by an attack.

If it is bandwidth (you can find it out by analyzing your bandwidth graphs), you should consider using rtbh as previous speaker supposed.

If it is your application/network stack affected by an attack (analyze your server cpu and interrupts usage) then you have to filter malicious traffic somehow. The point of UDP is a minimal datagram service, with implementation of security, reliability and other functions passed to you. So if your protocol doesn't support security functions (which I think it doesn't), there's not much you can do. Any signature-based packet filtering techniques, I think, are merely palliatives. You filter out one signature, attackers will come up with another.

One of the possible solutions to your problem is to introduce some kind of primitive authentication. Make your users log in into a tournament web-page before the game, for example, and add their IP address to a whitelist, blocking the others. Another way is to user port-knocking. You can produce a specific wrapper or launcher for a game binary that does send some 'magic' packets pinning a hole in your firewall. This approach sometimes is used protecting games like Lineage.