gamemann / XDP-Firewall

A firewall that utilizes the Linux kernel's XDP hook. The XDP hook allows for very fast network processing on Linux systems. This is great for dropping malicious traffic from a (D)DoS attack. IPv6 is supported with this firewall! I hope this helps network engineers/programmers interested in utilizing XDP!
https://deaconn.net/
MIT License
492 stars 87 forks source link

UDP spoofed or random ip ddos #51

Closed axl303 closed 6 days ago

axl303 commented 2 weeks ago

Hello,

I need some help, how can we try to block random ip ddos, by random I mean every new request is coming from different ip address. Rate limits won't help here, because ips are changing and if we just drop first packet from every ip, there are some smart attacks that are making just 3 to 5 requests per ip and that won't work either.

The udp game is Counter-Strike (mainly) or srcds. I think mainly attacking A2S methods, but not fully sure.

Do you guys have any suggestions, how to counter the spoofed/randomised ip flood, described above. I think some validation can help here or? Not much experienced. If there are experienced users (I know that there are), please can you give some advices.

gamemann commented 2 weeks ago

Hey, is this for Counter-Strike 2 or an older Counter-Strike game such as Source? There are some SourceMod/MetaMod extensions and general applications that cache the responses of the A2S queries for a certain period of time which should help in your case. However, I'm unsure which ones work/do not work for the Counter-Strike servers you're hosting.

Unfortunately, spoofed attacks are pretty hard to mitigate due to what you already said (random source IPs/ports, etc.) and if the attacks causes the CPU to pin due to too many packets even with the caching in-place or over-saturates the server's NIC capacity, you will need to ask your hosting provider whether they are able to mitigate the attack or find a hosting provider/(D)DoS mitigation service that can (preferably one that caches A2S responses on the edge of their network).

I hope this helps!

axl303 commented 2 weeks ago

Thanks for the comment!

The games are CS2 (Srcds) CS 1,6 (GoldSrc) and the servers are completely steam only. I was just curious and interested if there is any solutions to the random ips ddos. Seems like caching is the most easy/efficient way to deal with this.

I've read some blog post (https://blog.izetmulalic.com/changes-to-steam-server-browser-query-info/) which I don't fully understand and there are some texts about "spoofed attacks with this challenge". This might be only for steam only servers/clients or? Can same thing be implemented in the xdp program for validation for example or is there any way to validate request / challenge the request?

I am a newbie to the networking and xdp, so please forgive me if I wrote something wrong.

gamemann commented 1 week ago

Hey, sorry for the late reply, I've been very busy recently :(

Since you're running CS2 and CS 1.6, using the first project I linked in my last reply (source-query-proxy) would likely work best for your needs. However, there's still a chance it might not be enough due to your hardware limitations (read below).

As for the blog article you linked, a few years ago Valve implemented challenges for A2S queries. This makes it so the server will respond to the first packet of each A2S request with a challenge. The client's second request will require the challenge generated by the server in order to retrieve the full A2S response from the server. While this does help, there's still a high chance it won't be enough because you're limited to your physical server's NIC capacity (1 gbps is standard) and CPU power. While the challenge helps with spoofed (D)DoS attacks since the server won't generate the full A2S response each time due to an invalid challenge (spoofed attacks won't receive the challenge number to use), it still needs to generate and send back a challenge for each spoofed request which takes up CPU (a large attack exceeding millions of packets per second will likely pin your server's CPU unless if you have a very powerful CPU).

Caching the A2S response is the most effective way of combating these attacks since it takes a lot less load off of the CPU since the game server won't generate an A2S response on every validated request. However, if the attack is big enough, it will still exceed your NIC's capacity or CPU power. Therefore, without upstream (D)DoS protection, you would need to upgrade your server's NIC/link capacity or CPU (e.g. going from 1 - 10 gbps in link and NIC size or a more powerful CPU with more cores or higher clock speeds).

Caching the A2S responses in XDP would also be faster assuming the NIC's Linux driver supports DRV mode for best performance. The program I linked above does not utilize XDP though and there aren't many projects that utilize this mechanism which are free and open-source. I did make open-source packet processing software called Kilimanjaro a couple years ago or so for a gaming community I used to be a part of that utilized an Anycast network and performs A2S caching through XDP (with challenge support). However, this project isn't supported and the A2S caching can't be used individually from the project. You'd need to extract the code from the project above and make your own XDP program that passes the first A2S requests (or other type of traffic) to the user-space instead of being tunneled through the IPIP protocol. Unfortunately, I'm also tied with NDAs that states I can't share a more up-to-date A2S caching mechanism I have.

In short, I would say try source-query-proxy to see if this helps with the (D)DoS attacks against your server. If it still impacts your server, you will either need to get upstream (D)DoS mitigation (whether from your hosting provider or a (D)DoS mitigation service) or upgrade your server's NIC/CPU (I wouldn't recommend this route since it's costly and there's not an easy way in knowing how much CPU power you'll need for whatever attack you're getting hit with). If you're familiar with programming, you can try extracting my A2S caching code from Kilimanjaro and use it individually in your own XDP program to improve caching performance, but you'll still be limited by your server's hardware.

I hope the above helps and sorry for the wall of text (trying to provide as much information as I can)!

Edit Source-query-proxy appears to support attaching to the TC hook via (e)BPF. This is definitely faster than the user-space (which is what I thought was only supported at first), but not as fast as XDP. Here's a benchmark I found.

Benchmark Image

axl303 commented 1 week ago

Wow! Thanks for the information and the time spent explaining to a noob like me! Much appreciated!

I am using xdp in driver mode. Saw that query cache and will try to do something from your other project also.

Can I contact you via email or discord just for 2-3 more easy questions about the game attacks, not a2s related.

gamemann commented 1 week ago

Yeah, feel free to reach out! I have been really busy though, so expect delayed responses, etc. I believe you sent me a friend request that I accepted an hour or so ago.