Limiting/queueing UDP traffic to specific port to avoid DoS (UDP spoofing)

[AdrianX]

Hi,

I have a game server running on port 1111, that can be accessed from public IP 85.1.2.3:1111, using port forwarding to internal IP 192.168.1.201:1111. This game server uses only UDP protocol.

I'm receiving a UDP flood attack with 120Mb p/s, where it receives connection requests from more than 100000 different IPs, using UDP spoofing (false source addresses). The addresses uses are in the same range of the IPs from legitimate users, so blocking by range is not possible.

When the server receives the requests it is just overwhelmed and completely freezes, so I'm trying to somehow using traffic shaping (limiters? queues?) burst the traffic into the machine at a defined rate, such as 2Mb p/s, while also giving opportunity to the legitimate players to request connection (this is just 1 packet, and it's the same one used in the attack).

Also the attack completely fills PfSense state table in a matter of seconds and it freezes.

How can I do this, please?

Thanks.

[heper]

@adrianx said in Limiting/queueing UDP traffic to specific port to avoid DoS (UDP spoofing):

his is just 1 packet, and it's the same one used in the attack).

you could possibly try to limit the number of states each host can generate by setting the Max. src. states in your current pass-rule.

If you want to prevent exausting your states & killing your firewall, you could also set Max. states

i doubt any of this will solve your issue. i suggest you talk to your isp. DDOS is best handled upstream

[AdrianX]

If I set max src states, then the attack completely fills the state table and new legitimate requests never get in.

[heper]

@adrianx

max src states is supposed to limit the amount of states for each individual host .... odd that it would lock out legitimate requests

[AdrianX]

@heper The problem is that the attack creates only ~4 states per host, as it spoofs tens of thousands of IPs per second, each one sends those 4 packets (connection requests to a game server, UDP). So that wouldn't help there, I guess.

That's why I was looking more into a way of queueing the traffic, just "getting it all in" but in a queue, and randomly drop packets from it, allowing some of them, just enough to not saturate de game server receiving them but also enough to give chance to legitimate incoming connections to come in.

For that I have been looking in the traffic shaping options, and the algorithms there like Random Early Detection, etc. But I'm not entirely sure on how to setup it for incoming traffic on public ip 81.1.2.3 and port 1111 (example ip and port for where the server resides).

Is that too crazy? I'm happy if you could provide me any pointers.

Thanks.

[heper]

@adrianx and limiting it to 1 state per host doesn't help ?

you say your pipe isn't exausted, so perhaps you could experiment with snort or suricata to detect the malicious UDP packet? Alerts can be configured to be blocked
someone in the IDS section of the forum might be able to point you in the right direction.

snort or suricata can/will abuse lots of cpu cycles & memory ...

[AdrianX]

@heper Legitimate players need to send 4 packets to establish connection, If I limit it to 1 state, will it still work for them? Spoofed attack also sends the same 4 packets.

I will have a look at suricata and snort. Do you know how I could do the queueing I mentioned before using the traffic shaper?

Thanks.

[heper]

@adrianx
you can either just try & possibly break your production environment
or
setup a lab-environment with VM's to experiment

i'm no expert in neither traffic shaping, nor IDS/IPS ...
I think the problem you'll need to solve is how to separate the good packets from the bad ones.
I believe creating some sort queue will not solve your state problem ... the queue will just fill up and the states will overload

[AdrianX]

@heper Thanks for your help, really appreciate it. Hopefully someone else in the forum can give me a few more tips on the queueing and this specific type of attack.

[heper]

@adrianx

in the mean time you could try and find the differences between the DDOS packets & the good packets by doing packet captures (& analyzing them in wireshark)