Protecting a Garry's Mod server from DDoS attacks

A Garry's Mod server that disappears for three minutes at eight in the evening and then comes back rarely has a hardware problem. In the vast majority of cases an attack is running, and it runs exactly when the most players are connected. DDoS protection for Garry's Mod therefore starts with one question: which packets are allowed to reach your server at all. This article answers it in that order, first what you can secure yourself in the next ten minutes without spending a cent, then where those measures physically end, and finally what has to happen in the network in front of the server.

Everything here refers to an srcds server on Debian 12, Debian 13, Ubuntu 22.04 LTS or Ubuntu 24.04 LTS. The configuration file lives at garrysmod/cfg/server.cfg, the commands are written for root, and as a normal user you put sudo in front of them. This is about running your own root or dedicated server, not about a slot at a game server provider.

If the attack is running right now: do not change anything in server.cfg and do not restart srcds. Capture the measurements first (step 9), because once the attack is over they are gone. A restart costs you the counters and drops the server straight back into the same flood.

Why a Garry's Mod server needs DDoS protection

A Garry's Mod server publishes its IP address and its port all by itself. That is not an oversight, it is a requirement: a server that is not in the server browser gets no new players. The listing exists because the server registers with the Steam master server and then answers every A2S query that arrives from outside. So the question is never whether an attacker finds your address, only what happens when he aims at it.

Then there is the nature of the communities. Garry's Mod is mostly not played in rounds but in persistent worlds: a DarkRP community keeps player accounts, property, jobs and progress in a database for months. An outage on a Friday evening therefore costs more than a lost match, it costs regulars. That is exactly why competing communities, banned players and rented server booters (services that launch an attack against any address for a few euros a month) are the three most common triggers. The attacker needs neither skill nor any serious amount of money.

Technically, three traits come together. The game traffic runs over UDP, and UDP has no connection setup you could insist on, so source addresses can be spoofed. The server query sits on the same port as the game, which means any crude block always hits both. And on top of all of it sits Lua: every Workshop addon brings its own code into the same process, and one unprotected network event is enough for a single client to stall the server without any bandwidth at all. For the details of what a DDoS attack actually is, read What is a DDoS attack?.

The ports that actually matter for Garry's Mod

A Garry's Mod server starts on port 27015 by default, on UDP for the game including the server query, and on TCP for RCON. The number is changed at startup with -port, and with several instances you count up (27016, 27017 and so on). A typical start command looks like this:

./srcds_run -game garrysmod -console \
  -port 27015 \
  +maxplayers 64 \
  +gamemode darkrp \
  +map rp_downtown_v4c_v2 \
  +sv_setsteamaccount YOUR_GSLT_TOKEN \
  +host_workshop_collection 123456789 \
  -authkey YOUR_STEAM_WEB_API_KEY

From that follows the entire attack surface. The table below is the basis for every firewall rule further down:

Of these eight entries, exactly one belongs on the open internet without restriction: 27015/UDP. Everything else is either limited to your own address, bound to 127.0.0.1 or never started in the first place. The most expensive misconception in this field is the assumption that Garry's Mod has a separate query port you can simply close. It does not.

What you can do yourself before spending money

This section is the longest one, and that is deliberate. A cleanly configured Garry's Mod server survives small and medium attacks under its own power, no matter who hosts it. None of it costs money, and most of it is done in fifteen minutes.

1. Take stock: what is listening at all

Before you write a single rule, check what your server offers to the outside. Do not guess, look:

ss -lntup

The interesting column is the local address. 0.0.0.0:27015 and [::]:27015 mean "reachable from the entire internet", 127.0.0.1:3306 means "local only" and needs no firewall rule. On a DarkRP server that has grown over time you will almost always find more services than expected: MySQL, a web server for FastDL, a panel, a Discord bot, a second test server on 27016 and some forgotten voice service. A port scan from outside gives you the attacker's view:

nmap -Pn -sU -sT -p- --min-rate 1000 YOUR.SERVER.IP.ADDRESS

2. Leave open only the ports srcds really needs

Garry's Mod needs a single rule facing the outside, plus SSH and the restricted RCON access. With UFW it looks like this, and in exactly this order so that you do not lock yourself out:

ufw allow 22/tcp comment 'SSH'
ufw allow 27015/udp comment 'Garrys Mod game and A2S'
ufw allow from 203.0.113.10 to any port 27015 proto tcp comment 'RCON'
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

Replace 203.0.113.10 with your own address. Only open SourceTV on 27020/UDP if you genuinely broadcast. The full guide including the escape route is in Setting up the UFW firewall without locking yourself out. If it happens anyway: KVM root servers and dedicated servers at KernelHost have no IPMI and no iDRAC, you get back in through the VNC console in the customer panel. That console does not hang off the network stack of the guest system, so a firewall rule inside the guest cannot block it.

The database has no business on the open internet under any circumstances. Check in /etc/mysql/mariadb.conf.d/50-server.cnf that it says:

bind-address = 127.0.0.1

3. Limit the A2S query without dropping out of the server list

This is the mistake that costs most Garry's Mod servers. Because game traffic and server query occupy the same port, a blanket block or an overly tight rate limit on 27015/UDP throws out your own players and finishes the attack for the attacker. The correct place to work is the distinction between query packets and game packets.

The engine ships three console variables for this, and they belong in server.cfg. Their defaults are conservative, but they are set:

sv_max_queries_sec 3
sv_max_queries_sec_global 60
sv_max_queries_window 30

sv_max_queries_sec limits the answered queries per source address (default 3 per second), sv_max_queries_sec_global caps the sum across all addresses (default 60 per second), and sv_max_queries_window sets the averaging window (default 30 seconds). These values protect the CPU from producing pointless answers. They do not stop the packets from arriving, and anyone who sets the global value very tight disappears from the server browser during an attack, because the queries of the listing sites go unanswered as well.

One layer down, the query traffic can be separated cleanly. All connectionless packets of the Source engine start with four set bytes (0xffffffff), while the traffic of already connected players does not carry that header. A rate limit per source address can be placed on exactly that with nftables:

table inet gmod {
    chain input {
        type filter hook input priority -10; policy accept;
        udp dport 27015 @th,64,32 0xffffffff \
            meter a2sflood { ip saddr limit rate over 8/second burst 20 packets } drop
    }
}

You load the file with nft -f. The priority -10 makes sure the rule takes effect before the UFW filter chain, and @th,64,32 reads the first four bytes behind the UDP header. With classic iptables a u32 match does the same job:

iptables -A INPUT -p udp --dport 27015 \
  -m u32 --u32 "0>>22&0x3C@8=0xFFFFFFFF" \
  -m hashlimit --hashlimit-name gmod_a2s --hashlimit-mode srcip \
  --hashlimit-above 8/sec --hashlimit-burst 20 -j DROP

One point that almost every guide on the internet leaves out: it is not only the server query that is connectionless, the connection setup is too. A joining player sends several packets with that same header before he is in the game. A limit that is too tight therefore locks out new players even though the server stays reachable. Start generously (8 to 15 packets per second and address) and only tighten the limit once you have measured a week of normal operation.

4. Secure RCON or switch it off entirely

RCON is a favorite target on Source servers, and for three reasons at once. First, it sits on the same port number as the game, only on TCP, so it is found without any searching. Second, the Source RCON protocol transmits the password in plain text, with no TLS and no key exchange: whoever reads the traffic has it. Third, the payoff is maximal, because whoever holds RCON can change the map, ban every player, alter the configuration and stop the server. An attacker who takes over RCON needs no bandwidth at all any more.

Never leave rcon_password empty and never let it be guessable, a value from openssl rand -base64 32 is enough. Against login attempts the engine brings a brake of its own:

rcon_password "A_LONG_RANDOM_PASSWORD_HERE"
sv_rcon_minfailures 3
sv_rcon_maxfailures 5
sv_rcon_minfailuretime 30
sv_rcon_banpenalty 1440

With that, an address is banned for a day after three failed attempts within 30 seconds. Two warnings about it. First, this exact mechanism also locks out your own admin panel when an old password is stored there: what operators report as "RCON suddenly stopped working" is usually their own ban. Second, the firewall restriction from step 2 remains more effective, because it never lets the attempt reach the application in the first place. If you only need RCON occasionally, keep the port closed and work through an SSH port forward:

ssh -N -L 27015:127.0.0.1:27015 root@YOUR.SERVER.IP.ADDRESS

5. Rate-limit Lua network events, the most common self-inflicted outage

A substantial share of the Garry's Mod outages reported as DDoS attacks are nothing of the sort. They are Lua overloads triggered by a single connected client using a few kilobits per second. The reason lies in how the net library is built: as soon as an addon registers a network event with util.AddNetworkString and listens for it with net.Receive, any client can trigger that event in a loop. Without a limit of its own, the server executes every single message. Facepunch has documented this in its own issue tracker more than once and has not built a limit into the engine, so throttling is explicitly the job of the addon author.

Check every addon you wrote and every addon you bought for three things: an upper bound per player and second, a check of the message length, and that the player is determined on the server side from the second parameter instead of from the content of the message. A workable pattern looks like this:

util.AddNetworkString("khrp_buy")

local budget = {}

net.Receive("khrp_buy", function(len, ply)
    if not IsValid(ply) then return end
    if len > 256 then return end

    local now = CurTime()
    local b = budget[ply]

    if not b or now - b.start >= 1 then
        b = { start = now, count = 0 }
        budget[ply] = b
    end

    b.count = b.count + 1
    if b.count > 10 then return end

    KHRP.HandleBuy(ply, net.ReadString())
end)

hook.Add("PlayerDisconnected", "khrp_budget_cleanup", function(ply)
    budget[ply] = nil
end)

Two lines in server.cfg belong with it. sv_allowcslua defaults to 1 in Garry's Mod and lets clients run their own code with lua_run_cl and lua_openscript_cl: on a public server that value belongs at 0. And sv_kickerrornum disconnects clients that produce more than the given number of client-side errors (default 0, which means disabled):

sv_allowcslua 0
sv_kickerrornum 25

6. Separate Workshop content and FastDL from the game server

Workshop addons are not a side note in Garry's Mod, they are the norm: a DarkRP community binds its collection with +host_workshop_collection, and the clients download that content directly from Steam. That does not touch your uplink. The key behind -authkey is a Steam Web API key and should be treated like a password: it belongs in the start script, not in a public repository and not in a Discord channel.

The bandwidth is consumed by the second path. Everything that does not come from the Workshop (your own maps, sounds, materials) goes through the download channel. Without sv_downloadurl that channel runs over the game port itself and competes directly with the game traffic. With FastDL it runs over HTTP. If that web server sits on the same host and the same IP address, both share the same uplink: a wave of joins or an attack on 80/TCP then hits the game as well. These values make sense:

sv_downloadurl "https://fastdl.your-domain.com/garrysmod/"
sv_allowdownload 1
sv_allowupload 0
net_maxfilesize 64

sv_allowupload 0 takes away the clients' ability to push their own files to the server and closes a path that is neither needed nor controlled. net_maxfilesize limits the size of files transferred through the game channel, in megabytes. Where possible, put FastDL on a different host or behind a name of its own, so the load does not land on the same address as the game port.

7. Catch join floods and slot exhaustion

Slot exhaustion is an attack that needs no bandwidth: the attacker occupies every free slot with automated connections so that real players see a full house. With Garry's Mod there is an aggravating factor, because every join costs the server work while the resource list and the gamemode are negotiated, long before the player is actually in the game.

Four things work against it. First, a realistic upper bound: setting +maxplayers higher than your gamemode can carry only enlarges the attack surface. Second, sv_timeout, which defines after how many seconds without a message a client is dropped (120 in the common configurations): if you want to shed half-open connections faster, set the value lower. Third, the rate limit on connectionless packets from step 3, because the connection setup runs over exactly those. Fourth, for closed groups, a server password:

sv_password "members_only_password"
sv_timeout 90
sv_filterban 1
sv_region 3

Garry's Mod ships no real whitelist of its own, it comes through extensions such as ULX or through your own check in the CheckPassword hook. And one thing has to be clear: a whitelist protects your game logic, not your uplink. An attacker who floods your server does not want to join at all. His packets get rejected, but they have arrived all the same, and that is exactly the point.

8. Take load off the kernel: connection tracking and receive buffers

This step explains outages that look like a volumetric attack but are not one. The kernel creates entries in connection tracking (conntrack) for UDP traffic, and with spoofed source addresses every address means a new entry. Once the table is full, the kernel drops packets indiscriminately: the attack and your players go out together, and the system log says "nf_conntrack: table full". The current value and the limit are shown by:

sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max

The most effective step is not to have the game traffic tracked at all, because the engine manages its own sessions:

table inet raw {
    chain prerouting {
        type filter hook prerouting priority raw; policy accept;
        udp dport { 27015, 27020 } notrack
    }
    chain output {
        type filter hook output priority raw; policy accept;
        udp sport { 27015, 27020 } notrack
    }
}

With iptables the equivalent is iptables -t raw -A PREROUTING -p udp --dport 27015 -j NOTRACK and the same line for OUTPUT with --sport. After that the port needs an explicit allow rule, because without tracking no rule that checks for an existing state applies any more. And if packets arrive faster than srcds picks them up, the receive buffer overflows, which looks like packet loss to your players even though the uplink is free:

net.core.rmem_max = 16777216
net.core.rmem_default = 1048576
net.core.netdev_max_backlog = 16384

Those lines belong in a file under /etc/sysctl.d/ and become active with sysctl --system. Whether they are needed is something the kernel tells you itself: if UdpRcvbufErrors in nstat -az is climbing, they help. If the counter stays at zero, the change does nothing. This is headroom, not protection.

9. Capture measurements while everything is still normal

The most important step is the one almost nobody takes beforehand: build a baseline. Without a normal value you cannot say after an incident whether 40,000 packets per second was a lot or simply a Saturday evening. Work out the normal value for your own server once: 64 players at a cl_cmdrate of 66 produce around 4,200 inbound packets per second, and anything well above that needs an explanation. With apt-get install -y vnstat sysstat the measurement runs permanently in the background. During an incident four commands are enough:

sar -n DEV 1 10
ip -s link show eth0
nstat -az | grep -i udp
tcpdump -ni eth0 -c 200 "udp port 27015 and udp[8:4] = 0xffffffff"

The first shows packets and bytes per second, the second the drop counters of the interface, the third the UDP error counters of the kernel. The fourth line shows only the connectionless packets, which is exactly the class a query flood abuses: if that counter fills up in seconds while barely anyone is connected, you have your answer. Always cap tcpdump with -c, because a capture under full load puts extra strain on a server that is already overloaded. How to read the numbers is covered in Detecting a DDoS attack on your server.

What is the A2S reflection flaw and does it still affect me

A2S reflection is an attack in which your server is not the target but the tool. The attacker sends a small query with a spoofed source address to thousands of game servers, and their considerably larger answers all converge on the actual victim. Historically an A2S_INFO request was 25 bytes (4 bytes 0xFFFFFFFF, 1 byte 0x54, plus 20 bytes for the string "Source Engine Query"), while the answer ran to several hundred bytes. US-CERT lists the Steam protocol in its table of amplification attacks with a factor of 5.5, which means one gigabit at the attacker turns into 5.5 gigabits at the victim.

Valve closed this gap from November 2020 onwards, and did so in two ways. Connectionless query packets have to be padded by the sender to 1,200 bytes since then, which makes the request larger than the answer and pushes the amplification factor below 1. During the rollout, operators could enforce the stricter behavior in advance with the environment variable STEAM_GAMESERVER_MIN_CONNECTIONLESS_PACKET_SIZE=1200. In addition, for A2S_PLAYER and A2S_RULES the server does not answer with data right away but with a challenge (S2C_CHALLENGE) that the asking party has to send back in a second request. Anyone spoofing the source address never gets to see that challenge.

Two things follow from this for you. Keep the server binary up to date, because the protection sits in the Steam game server layer and not in your configuration. And do not confuse reflection with a query flood aimed at you: against the second form only the rate limit from step 3 helps, and beyond that, filtering in the network in front of the server.

Where these measures stop: bandwidth and packet rate

Now the part that no configuration file can solve. Everything described so far runs on your server, which means at the far end of the uplink. A firewall rule decides about a packet that has already traveled down the wire. You can drop it, but you cannot un-send it.

Do the math once. A typical game server sits on 1 Gbps, which is 125 megabytes per second, and the uplink is full as soon as somebody sends more. The second figure usually hits earlier: with the smallest possible packets of 64 bytes, around 1.49 million packets per second fit into 1 Gbps, and around 14.88 million into 10 Gbps. Depending on CPU and network card, a normal server kernel handles a few hundred thousand of them before it starts dropping. So an attack that does not even fill a third of your uplink can still take your server down, because the processing time goes into the dropping. Operators experience this as "the utilization was not even high, and yet everybody had lag spikes".

For a sense of the magnitudes that really occur: on KernelHost servers we have filtered, among others, a UDP flood of over 112.2 Gbps at over 8.7 million packets per second against a game server, and a multi-vector attack of over 473.4 Gbps at over 41.5 million packets per second against a voice server. 473.4 Gbps is roughly 470 times a 1 Gbps uplink and still roughly 47 times a 10 Gbps uplink. There is no local setting for that. Volumetric attacks have to end in the network in front of the server.

What KernelHost puts up against it

The always-on protection included with every server package

DDoS protection at KernelHost is built in two layers and permanently active, with nothing for you to switch on, order or configure:

• Layer 1: 17 Tbps of mitigation capacity in the global scrubbing network. Volumetric attacks are scrubbed close to their source, before they even reach the datacenter.
• Layer 2: Arbor real-time filtering with 3.2 Tbps in Frankfurt am Main. Directly in front of the server, protocol-specific patterns are detected and dropped, packet by packet.

Two properties make the difference. The protection runs permanently and does not have to react to an attack first, so there is no switchover window in which your players get thrown out. And no null-routing is used: your IP address stays on the network, only the malicious packets are dropped. Whoever takes the IP address off the network achieves the same result for you as the attacker does. The location is Frankfurt am Main. Which games and protocols are covered is listed in Game server DDoS protection in real time.

Advanced DDoS Protection for communities under constant fire

Some projects are attacked not occasionally but deliberately and for weeks on end, with changing patterns and always right at peak time. For those there is Advanced DDoS Protection from EUR 50.00 per month, PrePaid and with no minimum term. The difference is not more capacity, it is control:

• A dedicated protected IP from the Frankfurt core, which your server is switched over to inside our own network. Nothing has to be rebuilt on your side.
• Self-managed protection rules per port and protocol in the customer panel: you define what is allowed on 27015/UDP and what is allowed on 27015/TCP, without writing a ticket for it.
• Changes take effect in real time, so you can fine-tune while an attack is still running instead of waiting for the next maintenance window.
• A protection profile that matches the game, for Garry's Mod and the other Source titles as well as free TCP and UDP profiles for modified servers and custom applications.

The PrePaid model applies here too: no minimum term, no notice period, no contract and no setup fee. Once the wave of attacks is over, you simply do not renew. If you currently run your Garry's Mod server somewhere else, you get this protection by moving to KernelHost, because the filtering happens inside our own network and not on third-party infrastructure.

The two tiers compared

For most Garry's Mod communities the included always-on protection together with a clean server configuration is enough. Advanced DDoS Protection is the answer to somebody taking it personally.

Common mistakes and how to fix them

"The server is running but has vanished from the server browser": usually 27015/UDP was blocked outright or rate-limited too tightly. Because game traffic and query share the same port, a crude rule hits both. Work with the match on connectionless packets instead. If the server stays invisible even though the port is reachable, check sv_setsteamaccount: without a valid Game Server Login Token a Garry's Mod server is heavily downranked in the list, and every server needs its own token.

"My iptables rule is correct and still has no effect": three causes are common. The rule sits behind the UFW chains and is never reached, it was gone after the last reboot (then apt-get install -y iptables-persistent and netfilter-persistent save help, or an entry in /etc/ufw/before.rules), or the attack is volumetric and the rule works correctly on an uplink that is already full. Use iptables -L INPUT -n -v to check whether the hit counters are rising. If they stay at zero, the rule is never reached.

"My DarkRP server has lag spikes for everyone but the uplink is free": that is almost always Lua and not an attack on the uplink. Look in the server log for which network event arrives suspiciously often and check the corresponding addon for a per-player limit. If sar -n DEV 1 10 and the drop counters stay unremarkable, it was not a DDoS attack.

"RCON suddenly stopped working": not a DDoS attack, usually your own ban. An admin panel with an outdated password trips sv_rcon_minfailures, and sv_rcon_banpenalty bans the address for the configured number of minutes. Fix the password, lift the ban, then restrict the port to your own address.

"I changed the IP address and was offline again two days later": that is the normal case. Your server publishes the new address itself as soon as it has registered with the master server again, and a game server without a public address has no players. Changing the address buys hours or days, it is not a solution.

"My previous provider blocked my IP address": that is null-routing. The provider protects its own network with it, and for you the result is identical to a successful attack, usually for hours afterwards. If in doubt, ask whether traffic is filtered or null-routed. The answer says more about your availability than any hardware spec.

"I do not see anything unusual in tcpdump": if the traffic is already filtered in the network upstream, nothing arrives on the server, exactly as expected. That is the normal case when filtering works. The other way round applies as well: once the uplink is saturated, even the SSH session you wanted to measure with may no longer reach you. Use the VNC console in the customer panel then.

In short

• A Garry's Mod server needs exactly one open port: 27015/UDP. Game traffic and the A2S query run there together, and there is no separate query port.
• RCON sits on 27015/TCP, transmits the password in plain text and belongs open to your own address only, or reached through an SSH port forward.
• Do not limit the port, limit the connectionless packets carrying the 0xffffffff header. A blanket block on 27015/UDP throws out your own players.
• The most common Garry's Mod outage is not a DDoS attack but a network event without a limit: every event registered with util.AddNetworkString needs an upper bound per player and second.
• With packets of 64 bytes a 1 Gbps uplink carries around 1.49 million packets per second. Above that the loss happens at the router in front of it, and every local rule becomes pointless.
• At KernelHost the two-layer always-on protection is included with every server package at no surcharge: 17 Tbps of mitigation capacity in the global scrubbing network and Arbor real-time filtering with 3.2 Tbps in Frankfurt am Main, without null-routing.
• Anyone under constant targeted fire adds Advanced DDoS Protection from EUR 50.00 per month: a dedicated protected IP and self-managed rules per port and protocol, effective in real time.

If your server already runs at KernelHost, the filtering is active without you having to do anything. If you still notice something unusual, open a support ticket so that the filter rules for your IP address can be fine-tuned. Give four details right away: IP address, port, the time window in your own time zone and what you are seeing (players getting thrown out, server missing from the browser, lag spikes). During an ongoing attack you can also reach us through the WhatsApp emergency chat at +43 650 8209883.

If you run other Source titles alongside Garry's Mod, the shared fundamentals are in Protecting CS2 and Source servers from DDoS attacks, and how to set up the underlying installation cleanly is covered in Installing a game server with SteamCMD.