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?
  • 3
    To answer what you can drop we'd need to know exactly what service you run, so we can determine minimum legal payload length that service can have
    – ytti
    Jun 16 '13 at 7:12
  • I'm not sure if you can do this on SRX240 or not (can anyone confirm?), I would look into setting up uRPF verification though as starting point. Everyone should be running this (see bcp38.info/index.php/Main_Page), packets coming from spoofed or fake source IPs should be an attack of the past.
    – jwbensley
    Jun 16 '13 at 19:46
  • One application is Source Dedicated Server (srcds) service on UDP/27015-27030. Legitimate source port is in usually 27000-27010 range with frequent small UDP updates (probably keepalive, usually 30-50 bytes). UDP flood severely impacts application performance. I do have ACL preventing forged IPs from exiting my network but that does not really help with this particular situation. Jun 18 '13 at 0:07
  • Did any answer help you? if so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you could post and accept your own answer.
    – Ron Maupin
    Jan 5 at 21:06

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.

  • Thanks. Are there any open source/low cost solutions for profiling? All I need for now is to distinguish legitimate payload from random characters. Jun 18 '13 at 0:09
  • Yes, mine is my brain, you'll have to google around if you need something to do it for you.
    – Olipro
    Jun 18 '13 at 0:11

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.