Why game servers get DDoS attacks, and why generic protection struggles

It is a Friday evening, forty people are on your server, and at nine o'clock the game freezes for all of them at once. Pings jump into the hundreds, players time out, and the server list shows your server as unreachable. Twenty minutes later everything comes back as if nothing happened. The machine never crashed, and nothing in its logs explains the gap.

Everyone affected at once while the machine itself stays healthy is what a denial-of-service attack usually looks like from the inside. Games draw many of these attacks,⁵ and a game server is harder to protect than a website of the same size, for three reasons that feed each other: a game server has to be public, it has to answer within milliseconds, and it speaks a protocol that generic filters do not understand.

Games are a favourite target, and attacks are cheap

Many attacks on game servers are not the work of skilled attackers at all. They are bought. Booter or stresser services sell denial-of-service attacks by subscription, and the FBI describes them as a way to pay for an existing network of infected devices instead of building one.¹ The same FBI notice names the buyers only in general terms: malicious cyber actors, pranksters and hacktivists.¹

Games come up again and again when police act against these services. When the FBI seized the domains of 15 booter services in December 2018, the Justice Department listed gaming platforms among their victims and pointed out that the action came the week before Christmas, a period it said has historically seen heavy DDoS activity against games.² A seizure of nine more booter sites in May 2025 again named gaming platforms among the victims, and those nine sites alone had been used for hundreds of thousands of actual or attempted attacks.⁴ A 2019 study of the booter market cites earlier work showing that most booter attacks hit end users, assumed to be game players, and gaming websites.⁵

The price explains the volume. The same study found 10 to 20 US dollars typical for a month of attacks big enough to disrupt a home connection or a website without specialist protection.⁵ When the FBI bought subscriptions and aimed them at its own machines, some test attacks cut the connection completely, even when the target sat on a well-provisioned network.³ Defence is the expensive side: the seizure affidavit notes that buying spare capacity or a protection service typically costs a victim far more than the attacker pays for a booter.³ And the market is large. Records from booters seized earlier counted their registered users in the hundreds of thousands and their attacks in the millions.³

Takedowns work, for a while. The December 2018 operation, which combined seizures with arrests, cut recorded attacks by about a third for at least ten weeks.⁵ Services come back, though: of the 13 booter domains seized in May 2023, ten were reincarnations of services taken down in a sweep of 48 the previous December.³ The 2023 and 2025 seizures were part of Operation PowerOFF,³ an international effort whose principal partners include Europol.⁴ Attacks will stay cheap and easy to buy; plan for them.

Typical price of a month of booter attacks, per the 2019 study

10 to 20US$

Fall in recorded attacks, for at least 10 weeks, after the FBI action of December 2018

a third

Booter domains seized in May 2023 that were comebacks of services seized months before

10 of 13

Nobody publishes reliable figures on why a given game server is attacked, but the reasons are easy to guess. A game is a contest with winners, losers and rival communities, an attack costs a few dollars, its effect on everyone playing is instant, and a hired service can, as the FBI notes, obscure who was behind it.¹ That is reasoning, not a measured finding. The motives behind DDoS in general are in what a DDoS attack is.

A server that has to tell everyone where it is

A website can hide. Put a content delivery network in front of it and visitors only ever see the network's addresses, while the server behind it stays unlisted. A game server usually cannot. Each player's game client sends its packets straight to the server's address, so every client that has ever joined knows it, and the server advertises itself so that new players can find it.

Server lists make the exposure explicit. FiveM's documentation lists a setting, sv_forceIndirectListing, whose whole job is to stop the server list advertising a server by its real IP address. Its default is false, so out of the box the real address is what gets published, and the same page notes that the old sv_master1 setting can no longer take a server off the master list.¹⁴ Source servers answer anyone who asks: Valve's documentation opens by saying you can query a running game server for information with UDP packets, sent to the server's own listen port.¹² That is how a server browser shows the name, map and player count of every server on its list, and it means the list gives every reader an address and a port.

So a popular game server's address is public, stable and tied to a known port; the attacker has nothing to find. Hiding helps less than people hope. FiveM documents putting a reverse proxy in front of the server and turning on indirect listing so that the list shows the proxy instead,¹⁵ but the proxy then becomes the address everyone knows, and it needs the same protection.

The damage rarely stops at one address. Booter attacks can cut off other customers of the same provider through a shared connection point,³ which is why a provider may stop routing traffic to an attacked address altogether (blackholing), taking the server offline to spare its other customers.

At the packet level, players look like a flood

Almost every fast-paced game runs over UDP. RFC 768 defines it as a way to send messages with a minimum of protocol mechanism: no connection, no guaranteed delivery, no protection against duplicates.⁷ Games choose it on purpose. Valve's networking documentation points out that in a fast action game even a few milliseconds of delay feels laggy and makes it hard to hit other players,¹³ so a game would rather lose a stale packet than wait for it to be sent again.

Now look at what normal play sends. A Source engine client sends command packets at a fixed rate, usually 30 a second, and by default asks for 20 snapshots a second in return,¹³ more on servers that run faster (the guide to tick rate explains why). A 32-player server therefore receives about 32 × 30 = 960 small packets a second from players alone, steadily, from 32 addresses, all to one UDP port. Server browsers add more, from people who will never join: a Bedrock Edition client sends a ping to the servers on its list almost every second while the player sits on the server list menu.¹⁷

Describe that traffic without mentioning a game and it sounds like an attack: a steady stream of small UDP packets, from many addresses, to one port, with no handshake at the transport layer. UDP has nothing like TCP's opening exchange, which filters use to tell a real connection from a forged one (see SYN floods and SYN cookies). And the source address proves nothing. The IETF's UDP guidelines warn applications not to treat a packet's source address as proof of who sent it, since forging one is easy,⁸ and CISA describes flood requests that carry fabricated return addresses.⁶

Here is the difference in bytes. Valve's documentation specifies that a server info query starts with four bytes of FF, then the type byte T, then the string Source Engine Query and a zero byte.¹² That is 4 + 1 + 19 + 1 = 25 bytes of payload; with a 20-byte IPv4 header and an 8-byte UDP header, a 53-byte IP packet. A flood packet of 25 random bytes sent to the same port is also a 53-byte packet.

Everything a port rule or a rate limit reads is in the grey boxes. The difference lives entirely in the payload, and to see it a filter has to know what this game's packets are supposed to look like.

The same query carries a lesson about amplification. Its reply is larger than the request, so answering directly made Source servers usable for reflection attacks, and in December 2020 Valve let servers answer first with a challenge number the client must send back.¹² Amplification has its own guide, amplification attacks; the challenge returns below, because it is the cleanest way to tell a real client from a forged one.

Why generic defences punish the players

A website under attack has room to manoeuvre. It can hold a visitor on a challenge page for a few seconds, or make a request wait while it decides, and a page that loads a second late is still a page. A game client has no page to show a challenge on, and in a fast action game a delay of a few milliseconds already feels laggy.¹³ A detour through a distant scrubbing centre costs in the same currency: every extra kilometre of path is added to every round trip the player makes (reasoning from distance, not a measured figure). So a game server's defence has to decide in line, packet by packet, without asking the player anything and without adding delay.

Faced with traffic it cannot read, a generic defence can block by port, count packets or absorb the flood with capacity, and each fails players in its own way. On a game server a false positive, a real player dropped as if they were the attack, does the attacker's work.

Blocking UDP, or capping the port

Blocking UDP on the game port stops the flood and the game with it, since the game is the UDP on that port. A cap on the total packets the port accepts is gentler and still blind: it keeps the server alive but cannot choose which packets survive, so real and forged packets are dropped at the same rate. The server stays up, and nobody can play on it (the worked example below puts numbers on this).

Limits per source address

A limit on each source address sounds fairer, and it fails in both directions. Set it below what a real player sends and it cuts every player. At 30 command packets a second, a limit of 20 drops a third of them, and each carries two or more of the player's input commands.¹³ Set it high and a flood spread over many forged addresses stays under it without trying. One address is not one player, either: carrier-grade NAT, run by internet providers, shares one IPv4 address among several subscribers,¹⁰ so a limit sized for one player cuts off everyone behind that address.

What does the player see? In Source the server has the final word on where every player is. When its answer differs from what the client predicted, the client corrects its own position, and Valve notes that the correction can make the view jump erratically.¹³ A long run of dropped command packets, like the 333 ms hole above, is one way to make the answers differ. Loss on the way back is hidden only briefly: the client draws the world 100 milliseconds in the past, so one lost snapshot is invisible, but after more than one in a row it has to guess, and it stops guessing after 0.25 seconds.¹³ Players call all of this lag, whether the attack or the filter caused it.

A last tempting rule, distrusting any address that has never connected before, hides a game server from its own list: the browsers querying it are mostly addresses that have never joined.

Scrubbing that sees volume, not the game

Upstream scrubbing is built for volume. It can absorb a flood far bigger than any single server's link, and against a flood that size nothing on the server can help. But a flood that fits inside the link and looks like players at the header level gives a generic scrubber nothing to key on, so it either passes the flood to your server or clips players along with it. The IETF makes the underlying point about spam filters: any such filter will wrongly block some genuine mail, and for that mail the filter itself is the denial of service.⁹

What understanding the protocol changes

RFC 4732 names the way out. Short of building enormous spare capacity, it says, the one real defence against attacks that exhaust resources is to treat attackers differently from everyone else: look for something a genuine user can do that an attacker cannot.⁹ For a game server that something is speaking the game. A real client runs the game's own code, so every packet it sends has the game's structure and arrives in the order the protocol expects. A flood generator has to imitate all of that, packet by packet, and a forged source cannot finish any exchange at all.

A protocol check, often called a validator, is a filter that knows one game's protocol and asks of every packet on that game's port: is this the game speaking? In general it checks four things.

• The first packet is one the game really sends first. A Minecraft Java client opens with a Handshake packet, ID 0x00, carrying its protocol version, the address and port it is connecting to, and what it wants next: 1 for status, 2 for login, 3 for transfer.¹⁶ A Bedrock client's first message is an Unconnected Ping, and RakNet's offline messages carry a fixed 16-byte marker.¹⁷ A Source query starts with four bytes of FF and a type byte.¹²
• The structure holds together. Lengths match the contents, and every field holds a value the protocol allows. A Minecraft handshake whose "next state" is 7 did not come from a Minecraft client, whatever else it gets right.
• Messages arrive in order. A login packet from an address that never sent a handshake announcing a login is not a client that followed the protocol.
• The client can receive at its address. RFC 4732 calls this reachability testing: making a client prove it can receive traffic at the address it claims.⁹ The challenge Valve added to Source queries in 2020 is exactly this.¹²

The challenge turns UDP's weakness around. Forging a source address costs the attacker nothing only as long as nothing has to come back. Once the server replies with something the client must repeat, the reply goes to whoever really owns that address, and the sender is left guessing. A cheaper variant needs no reply at all: while under attack, drop the first packet from any source not seen before. A real client that hears nothing sends again and gets through; a flood that sends each forged packet once never does. Unlike distrusting new addresses outright, this costs a newcomer one retry, and only while the server is under attack.

A validator has to be written for each protocol and kept current as games change. On the wrong port it drops every real packet, because another game's traffic fails every check. It cannot read an encrypted payload. And well-formed packets from real, infected machines pass the structure checks, so validation sits alongside per-client rate limits and behavioural rules rather than replacing them. RFC 4732 is blunt about it: each technique of this kind has serious limits, and defence against denial of service is mostly about making attacks costly enough, not about stopping every one.⁹

A worked example: 32 players and 200,000 packets a second

Take a Source server with 32 players, each sending the default 30 command packets a second: 32 × 30 = 960 packets a second of real traffic. An attacker rents a flood of 200,000 packets a second aimed at the game port. Each is a 53-byte IP packet, the size of the info query in the drawing above, filled with random bytes and sent from 50,000 forged addresses: 200,000 ÷ 50,000 = 4 packets a second from each.

In bits the flood is small. On Ethernet each 53-byte packet rides in a 71-byte frame, since the Ethernet header and checksum add 18 bytes, and every frame also takes a 64-bit preamble and a 96-bit gap on the wire,¹¹ so each packet occupies 71 × 8 + 64 + 96 = 728 bits. At 200,000 a second that is 200,000 × 728 = 145.6 million bits a second, about a seventh of a 1 Gbit/s port. No link fills up. The problem is 200,000 packets a second that each look like a player at the header level, every one of which, if it reaches the game, has to be read and thrown away by the program that runs the match. Three defences:

The per-source limit is the instructive failure: it lets the whole flood through and still drops a third of every player's command packets. The protocol check wins because this flood is what it was built for. Change the attack and the answer changes: a flood bigger than the link has to be absorbed upstream before any check on the server sees it, and well-formed packets from real infected machines move the fight to per-client limits and behavioural rules. Each layer handles the traffic it can see, which is why protection stacks them.

Mistakes server owners make

• Treating a hidden address as protection. Hiding narrows who can find the server. Every player still learns the address of whatever they connect to, and that address still needs filtering.
• Changing the IP after every attack. It buys hours, not safety: the new address leaks as soon as people play on it, and each move breaks the saved server entries your players rely on.
• Running a validator for the wrong game on a port. It fails every real packet. If you move a game to a new port, move its protocol check with it.
• Paying a booter to "test" your server. You would be funding the services that attack you, and the traffic comes from a botnet of malware-infected computers.¹ US investigators found the network-testing claims of such services to be a pretence,⁴ and the FBI investigates their use without the owner's permission as a crime under the Computer Fraud and Abuse Act.¹

What to do before the next one

Know your normal. Players times packet rate gives a first estimate (960 packets a second for the server above), but measure it at a busy hour: packets a second on the game port, distinct addresses, queries. In an incident you want to compare against a number, not a feeling.

Look at your own traffic once. Capture a few packets to your game port so you know what the game looks like on the wire. Here are a Source server's listening socket and two captured packets, one of each kind from the drawing above:

$ sudo ss -ulpn 'sport = :27015'State  Recv-Q Send-Q Local Address:Port  Peer Address:Port ProcessUNCONN 0      0            0.0.0.0:27015      0.0.0.0:*     users:(("srcds_linux",pid=2143,fd=12))$ sudo tcpdump -ni eth0 -c 2 -X 'udp dst port 27015'tcpdump: verbose output suppressed, use -v[v]... for full protocol decodelistening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes21:04:31.482117 IP 198.51.100.23.53467 > 192.0.2.10.27015: UDP, length 25  0x0000:  4500 0035 1c46 4000 3811 3a1d c633 6417  E..5.F@.8.:..3d.  0x0010:  c000 020a d0db 6987 0021 1a3a ffff ffff  ......i..!.:....  0x0020:  5453 6f75 7263 6520 456e 6769 6e65 2051  TSource.Engine.Q  0x0030:  7565 7279 00                             uery.21:04:31.482161 IP 203.0.113.77.41022 > 192.0.2.10.27015: UDP, length 25  0x0000:  4500 0035 0000 4000 f311 895f cb00 714d  E..5..@...._..qM  0x0010:  c000 020a a03e 6987 0021 edda 8e13 a75c  .....>i..!.....\  0x0020:  02d9 41f0 6b9a 33c8 17e4 5d80 2fb6 710c  ..A.k.3...]./.q.  0x0030:  ee94 285a c3                             ..(Z.2 packets captured2 packets received by filter0 packets dropped by kernel

The first packet is a real info query: after 28 bytes of header its payload starts ffff ffff 54 and spells out Source Engine Query. The second has the same port and length and nothing a header filter could object to, and its payload is noise. If an incident's packets look like the second, a protocol check for your game removes them. If they look like the first, from thousands of addresses, it is a query flood, and the query challenge is the answer.

Expose only what players need. Open the game's ports and nothing else, and keep remote consoles and admin panels off public addresses; game server ports and firewalls goes through it port by port. Keep the server software current, since protocol fixes such as Source's query challenge only help servers that run them, and if you front a FiveM server with a proxy, turn on indirect listing so the list advertises the proxy rather than the server.¹⁵

Ask your provider precise questions. Which games does the filter validate, on which ports, and what happens to a game it does not know? What does it do with a carrier NAT address full of players? An answer only in gigabits per second describes capacity, which matters, but is not the same as telling your players from a flood.