• Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Search
  • Register
  • Login
Netgate Discussion Forum
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Search
  • Register
  • Login

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

Scheduled Pinned Locked Moved Traffic Shaping
udptraffic shaperddos
10 Posts 2 Posters 1.6k Views
Loading More Posts
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • A
    AdrianX
    last edited by Jan 12, 2021, 9:37 PM

    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.

    H 1 Reply Last reply Jan 12, 2021, 9:57 PM Reply Quote 0
    • H
      heper @AdrianX
      last edited by Jan 12, 2021, 9:57 PM

      @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

      A 1 Reply Last reply Jan 13, 2021, 12:55 AM Reply Quote 0
      • A
        AdrianX @heper
        last edited by Jan 13, 2021, 12:55 AM

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

        H 1 Reply Last reply Jan 13, 2021, 7:27 AM Reply Quote 0
        • H
          heper @AdrianX
          last edited by Jan 13, 2021, 7:27 AM

          @adrianx

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

          A 1 Reply Last reply Jan 13, 2021, 7:37 AM Reply Quote 0
          • A
            AdrianX @heper
            last edited by AdrianX Jan 13, 2021, 7:39 AM Jan 13, 2021, 7:37 AM

            @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.

            H 1 Reply Last reply Jan 13, 2021, 8:03 AM Reply Quote 0
            • H
              heper @AdrianX
              last edited by Jan 13, 2021, 8:03 AM

              @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 ...

              A 1 Reply Last reply Jan 13, 2021, 8:10 AM Reply Quote 1
              • A
                AdrianX @heper
                last edited by Jan 13, 2021, 8:10 AM

                @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.

                H 1 Reply Last reply Jan 13, 2021, 8:21 AM Reply Quote 0
                • H
                  heper @AdrianX
                  last edited by Jan 13, 2021, 8:21 AM

                  @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

                  A 1 Reply Last reply Jan 13, 2021, 8:23 AM Reply Quote 1
                  • A
                    AdrianX @heper
                    last edited by Jan 13, 2021, 8:23 AM

                    @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.

                    H 1 Reply Last reply Jan 13, 2021, 8:30 AM Reply Quote 0
                    • H
                      heper @AdrianX
                      last edited by Jan 13, 2021, 8:30 AM

                      @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)

                      1 Reply Last reply Reply Quote 0
                      1 out of 10
                      • First post
                        1/10
                        Last post
                      Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.
                        This community forum collects and processes your personal information.
                        consent.not_received