Follow-up Q's for Gaming Servers (UDP Floods / Game Signatures)

Help
1

hey all,

So I’m currently fighting off a targeted DDOS attack that have been on and off for the last month! We run a gaming server. Unfortunately, the gaming software we utilize limits us to only use the server IP address for inbound traffic and therefore, we can’t use any EDGE solutions to distribute inbound traffic.

Initially, the DDOS attacks all came from a specific number of PORTS likely compromised IOT devices. However, we successfully blocked those and stopped the attacks for a few days. Now they are back using what we believe to be UDP reflection attacks with 46+ million unique IP addresses targeting all ports.

We have a powerful firewall (on AWS), which can handle the traffic. However, about 80% of the bad traffic still passes through to our backend server, as we can’t catch it. Although we had good success with 1 rule from this forum mentioned below, that reduced it to about 20% getting through)

What’s making this difficult is the LOW volume of packets/bytes. I have some questions, and I’ll also provide some specifics of the issue if anyone can assist!

-Type of DDOS - 46+ Million of IPs
-Packets Per IP: 1-200
-Total Bytes Per IP: 93-1000
-Attacker Port: All ports used 0-65000?

We had some good (40-70% Drop Rate) but not enough success when adding the below rule from this site:

drop udp any any → $HOME_NET any (msg:“UDP retransmission verification”; flow:not_established,to_server; flowbits:isnotset,udp_verify; flowbits:set,udp_verify; sid:1;)

My questions are as follows:

  1. Based on the above-mentioned information, what would you recommend?

  2. Could we create a rule that holds traffic and only permits traffic to flow if we receive more than X UDP Packets from 1 source IP in X seconds? And Vise versa. This would probably need to be one time not to interrupt legitimate players.

  3. Since all our UDP traffic is specific to one computer game, is it worth trying to create a signature of a game packet (good packet) and permitting only these packets for UDP? Is there a tool for this? If we feed it 100k example packets to come back with a signature for those packets?

  4. Is it possible to allow traffic that follows a certain process (which a normal user would follow)

-Step 1 TCP Handshake
-Step 2 UDP Traffic

If step 1 is not completed, it won’t allow UDP traffic for this user?

  1. Is it possible to rate limit IPs to Ports, for example, only 1 IP per Source Port?

I know I’ve asked a lot! And also I’m happy if someone is interested to work on this project with me, so you can reach out also.

Really appreciate your support!

2

Here is an Image showing the breakdown, it’s for 10K IPs but it’s likely the same for the 46 million.

sssss

3

Two ideas that might help,

  • assuming your udp traffic are using specific destination ports, you could set an Xbit (aka hostbit) on ips contacting abnormalports and drop subsequent connections from those ips altogether.

  • set an xbit on hosts doing tcp initiation so that you allow only those who did the tcp part to contact udp ports.

These two ideas require at least two rules, one to set the xbit an the other to check and act.

4

Have you looked for any pattern in that DDOS traffic attack?

5

Hey Alex,

Yes, I captured the latest packets last night, as there were several hours of no-doss activity. This is their latest attack type as we’ve blocked the others!

We identified

  • All their packets use the QUIC protocol
  • 99% of the packets are 107 bytes in size.

I also checked out our normal traffic, and we don’t get any 107-byte UDP or QUIC packets (not that we use QUIC).

So an easier solution to DROP these might just be to Drop any UDP packets with a size of 107 bytes. How would we go about writing that?

6

Hi IDSTower,

Regarding this, Xbit approach. Would it work with an AWS Firewall using Suricata 6.X? As there are restrictions on any kind of accessing lookup files (such as geo filters).

I’m not sure if what you mentioned would be practical, as 95% of the time IPs are unique and therefore only hit us once (but when there’s 46 million it makes an impact. BTW: we analyzed the packets and determined them to be QUIC packets that use the UDP protocol (apparently quite famous for IP spoofing).

We will also be looking to understand better the user journey in terms of TCP>UDP>TCP as we haven’t fully captured that yet.

Here is a packet for reference!

7

image
image1913×1297 105 KB

8

Give it a try with Quic and dsize rules.

https://suricata.readthedocs.io/en/latest/rules/quic-keywords.html#quic-keywords

9

  1. In Wireshark, QUIC Short Header packets alone are not identified as “QUIC”. I think the packets are probably coming in from QUIC Initial and Handshake. Are there any services in your inbound traffic that should be treated as QUIC?

  2. If the service does not exist, it seems appropriate to block all inbound QUIC. As mentioned above, identifying the QUIC Short Header is difficult, so it seems appropriate to consider how to identify packets for Initial and Handshake.

In my case, to identify QUIC, I connect other additional signatures with flowbits based on the signatures below or signatures using the Suricata QUIC option.
alert udp any any → any any (msg:“IETF-QUIC (RFC9000) Initial”; flow:not_established; dsize:>1159; content:“|00 00 00 01 08|”; offset:1; depth:5; byte_test:1,<=,0xcf,0; byte_test:1,>=,0xc0,0; )

  1. QUIC can also be done as a reflex attack. Looking at the Wireshark image alone, I would suspect that a bi-directional stream would exist. Does the entire UDP stream with that packet exist as pcap?
10

Xbits are not restricted per aws docs, however in my experience while developing integration with the aws network firewall, not everything in documented.

If the ips hits you only once, this would be a bit difficult without other criteria.

Fyi: UDP is the only way possibly to spoof IPs with since they do not require 3-way handshakes as in tcp.