Protecting an MTA:SA server from DDoS attacks

A server for Multi Theft Auto: San Andreas behaves differently under a DDoS attack than any other GTA multiplayer project, because it offers three separate network services at the same time: the game traffic on 22003 UDP, a full HTTP server on 22005 TCP and the ASE query on 22126 UDP. Each of those three can be attacked on its own, and each one fails in its own way. This guide shows first what you can secure yourself at no extra cost, then where those measures run into the physics of the uplink, and finally what effective DDoS protection for MTA:SA has to do in the network in front of the server.

If the attack is running right now, the most important question is which of the three services is being hit. If players stay connected but no longer receive resources when they join, the HTTP server on 22005 is the target. If the server disappears from the browser while connected players keep playing normally, the ASE query on 22126 is the target. If every connection drops at once, either 22003 is the target or the uplink is saturated. Everything here applies to an MTA server on Debian 12, Debian 13, Ubuntu 22.04 LTS or Ubuntu 24.04 LTS. The commands are written for root, as a normal user put sudo in front.

Why MTA:SA servers are such frequent DDoS targets

MTA:SA projects are convenient targets because they have to publish their own address. A server only shows up in the in-game browser if it registers with the master server list and then answers queries from the outside. That list carries the IP address and the port in plain text, so an attacker needs no reconnaissance at all.

The scene adds to it. German-speaking and Brazilian roleplay servers, drift servers and DayZ conversions compete for the same player base, and an outage during prime time is as visible as it gets. A banned player, a team that fell apart or a competing project needs neither skill nor serious money to ruin an evening. Bookable attack services, known in the scene as booters or stressers, sell exactly two outcomes for a few euros a month: taking an MTA server offline for minutes, or making it unplayable with lag spikes. What a DDoS attack is technically and which attack types exist is covered in What is a DDoS attack?.

Technically, MTA:SA makes it easier for attackers in two places than other multiplayer modifications do. First, the query sits on a UDP port of its own that answers a single byte with a reply several kilobytes in size. Second, every MTA server comes with an HTTP server that delivers the client-side files of all resources, without any authentication, to anyone who asks.

The ports that actually matter

An MTA:SA server needs exactly three ports: 22003 UDP for the game, 22005 TCP for the internal HTTP server and 22126 UDP for the ASE query. The third one is not a free choice, it is derived from the game port plus 123. Set serverport to 22010 and the query lands on 22133.

Two details are written into the shipped mtaserver.conf and get overlooked regularly. httpport may carry the same number as serverport, because one port is TCP and the other is UDP. And serverip is set to auto and should stay there: a hard-coded value binds the ASE socket to exactly that address and breaks the list entry as soon as the address changes.

The ASE query protocol and why it is an amplifier

ASE (All-Seeing Eye) is a pure UDP query protocol: the first byte of the packet decides the reply, and there is no connection setup. The MTA server knows five queries and answers them on 22126:

• s is the full ASE query. The reply starts with EYE1 and carries the server name, game type, map name, version, password status, player count, the complete list of every rule set through setRuleValue, and then every connected player with name, score and ping. That reply has no size limit.
• b and r are the lighter queries for the in-game browser. The reply starts with EYE2 and is cut off at 1,340 bytes in the source code to avoid fragmentation.
• x returns a shortened status message, v returns only the ASE version identifier.

That is where the problem comes from. A request consists of a single payload byte, so 29 bytes on the wire (20 bytes IP header, 8 bytes UDP header, 1 byte payload). A reply of 1,400 payload bytes is 1,428 bytes on the wire. The ratio is roughly 49 to one, and because UDP has no connection setup, the source address can be forged. An attacker can therefore use your server as an amplifier against a third party without ever entering your game. With the full query, the factor grows with your player count and with every rule your gamemode publishes.

MTA ships two built-in brakes against this, and they are worth knowing because they explain why some floods work and others do not. The server answers at most five queries per source address within six seconds and then ignores that address for seven seconds. It also keeps the replies cached for ten seconds instead of rebuilding them per request. The per-address counting is skipped entirely, however, as soon as more than 100 different source addresses are in the list at the same time. With a distributed flood from a botnet or with forged senders, that is exactly the normal case, which is why the built-in brake does not help against a serious attack.

What you can do yourself before spending money

This section is the longest one, and deliberately so. A cleanly configured MTA server survives small and medium attacks on its own, no matter who hosts it.

1. Taking stock: what is listening at all?

First look at what your server offers to the outside. Do not guess, check:

ss -lntup

You should see three lines from the MTA process: 0.0.0.0:22003 on UDP, 0.0.0.0:22005 on TCP and 0.0.0.0:22126 on UDP. If a database on 0.0.0.0:3306, a web server or a forgotten voice service also shows up, that needs to be dealt with. A port scan from the outside gives you the attacker's view:

nmap -Pn -sU -p 22003,22126 YOUR.SERVER.IP.ADDRESS
nmap -Pn -p 22005 YOUR.SERVER.IP.ADDRESS

The server brings its own command for this as well. In the server console, openports checks whether all three ports are reachable from the outside.

2. Keep open only the three ports MTA really needs

With UFW, a workable starting configuration looks like this, and in exactly this order so that you do not lock yourself out:

ufw allow 22/tcp comment 'SSH'
ufw allow 22003/udp comment 'MTA game'
ufw allow 22005/tcp comment 'MTA HTTP'
ufw allow 22126/udp comment 'MTA ASE'
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

The full walkthrough including the way back is in Setting up the UFW firewall. On KVM root servers and dedicated servers from KernelHost you can reach the system through the VNC console in the customer panel if things go wrong, even when the uplink is saturated.

The database does not belong on the internet. If ss -lntp | grep 3306 shows 0.0.0.0:3306, set bind-address = 127.0.0.1 in /etc/mysql/mariadb.conf.d/50-server.cnf and restart the service.

3. Rate-limiting the ASE port without locking out your players

Unlike SA-MP, MTA:SA puts the query on a port of its own, so you can rate-limit it independently of the game itself. That is the biggest practical advantage of this architecture: a rule on 22126 throws out not a single player.

With nftables in a table of its own, so the ruleset does not collide with UFW:

nft add table inet mtaguard
nft add chain inet mtaguard input '{ type filter hook input priority -150 ; policy accept ; }'
nft add rule inet mtaguard input udp dport 22126 meter aseperip '{ ip saddr limit rate over 3/second burst 6 packets }' drop
nft add rule inet mtaguard input udp dport 22126 limit rate over 2000/second burst 500 packets drop
nft list table inet mtaguard

The first rule limits every individual source address, the second one limits the port as a whole. Both matter together: a distributed flood slips through the gap between many individual sources if you only limit per address. The values are tight, and that is acceptable here because a real server browser queries you only every few seconds. With iptables, the hashlimit module does the same thing:

iptables -A INPUT -p udp --dport 22126 -m hashlimit --hashlimit-name mta_ase \
  --hashlimit-mode srcip --hashlimit-above 3/sec --hashlimit-burst 6 \
  --hashlimit-htable-expire 30000 -j DROP

Closing the port entirely is a trade-off, not an insider tip: without ASE your server disappears from the in-game browser and with it from organic growth. If you want it anyway, <ase>0</ase> is not enough. In the source code, opening the port depends on the OR combination of internet mode and LAN mode, so with <ase>0</ase> the socket stays open as long as <donotbroadcastlan>0</donotbroadcastlan> is set. To really close the port you set both:

<ase>0</ase>
<donotbroadcastlan>1</donotbroadcastlan>

The more honest route for a growing project is this: leave the port open, limit the rate, and keep the amplification small by making sure your gamemode does not publish unnecessary rules through setRuleValue. Every rule ends up in the full query and makes the reply bigger.

4. Taking load off the internal HTTP server

The HTTP server on 22005 is a separate attack surface on MTA:SA, because every joining player downloads all client-side files of every running resource from it. On a roleplay project with custom models that quickly amounts to several hundred megabytes spread over hundreds of individual files. The built-in server is deliberately simple: no compression, a fixed budget of worker threads. A few dozen simultaneous requests are enough to leave real players stuck on the loading screen for minutes.

The most effective measure is to take the downloads out of the game server entirely. MTA prepares the files for exactly that, in mods/deathmatch/resource-cache/http-client-files. You serve that folder through nginx or lighttpd and put the address into mtaserver.conf:

<httpdownloadurl>http://cdn.your-domain.tld/mta</httpdownloadurl>

That buys you two things at once. The downloads run through a web server built for the job, and they no longer run through the address of your game server. If the web server sits on a different machine or behind a content delivery network, a flood against the downloads no longer hits the game. One caveat: if the external address is wrong or unreachable, MTA silently falls back to the internal server.

If the internal server stays in use, use its own limits. In mtaserver.conf:

<httpmaxconnectionsperclient>5</httpmaxconnectionsperclient>
<httpdosthreshold>20</httpdosthreshold>
<http_dos_exclude></http_dos_exclude>
<httpthreadcount>8</httpthreadcount>

httpmaxconnectionsperclient limits the simultaneous connections per client to 5, within the permitted range of 1 to 8. httpdosthreshold limits how many connections a single IP address may open in a short period, default 20. http_dos_exclude exempts individual addresses, your own status page for example. httpthreadcount sets the number of worker threads, default 8 in the range 1 to 20. A higher value helps with many small files but costs processing time that the game then does not get.

Also keep in mind what else is served on that port. The resources webadmin and resourcebrowser are started in the shipped configuration and reachable in a browser over 22005. An administration interface does not belong on the internet unprotected: set clean permissions in acl.xml, create a dedicated account with a long random password, and stop the resource if you do not need it.

5. Using the built-in limits in mtaserver.conf

MTA ships more protective limits than most projects use. Some are fixed in the source code, others live in mtaserver.conf. This table collects the ones that matter during an attack:

Three settings deserve a conscious decision. maxplayers is set to 32 and should match reality: every extra slot enlarges the full query and raises the number of connections an attacker can occupy. bandwidth_reduction is set to medium, and the value maximum noticeably lowers outbound load at the cost of synchronization accuracy. And <password></password> turns your server into a closed circle with no effort at all while the list entry stays in place: the fastest emergency brake during an ongoing join flood.

6. Telling join floods and event floods apart

Two attack patterns aim at the game logic rather than the uplink, and they get mixed up regularly.

A join flood opens real connections in rapid succession until every slot is taken or the server can no longer keep up with the setup. MTA limits this by itself to four connections per source address within 30 seconds and then ignores that address for 30 seconds. The console command debugjoinflood shows what the brake is currently doing. The limit works per address, so a botnet with a thousand addresses walks right past it. What helps there is a server password, a whitelist in the gamemode and a rate limit on 22003.

An event flood, by contrast, comes from players who are already connected: a modified client fires triggerServerEvent in a loop until the server runs out of processing time. Out of the box MTA allows 100 events per player and second and rejects anything beyond that with a message about event flooding. If your gamemode uses many small events, check the value before lowering it: set too tight, it throws out your own players.

Independently of that, the same server-side rule applies as everywhere: never trust values the client sends, derive the player from the sender of the event, and limit anything that triggers a database query. A single unchecked event that starts a query is enough to bring a server to a halt without any network attack at all.

7. The server list, your IP address and what else gives it away

Your IP address cannot be kept secret. Every player who has ever connected knows it, and the master server list entry publishes it anyway. Putting a domain in front does not help: the client resolves the name once and then talks to the address directly.

Check instead what else gives your address away. Typical leaks on MTA projects are old A and AAAA records in DNS, the project website on the same machine, a Discord bot with a status display that reads the ASE query publicly, TLS certificates carrying old hostnames, and forum posts from the early days. From that follows a rule many projects learn too late: when you move to a protected address, change the old address at the same time. If it stays alive, it sits in every scanner database and the attack simply walks around the protection.

Two entries in mtaserver.conf affect visibility directly. <serverip>auto</serverip> stays on auto unless you know exactly why it should not. And <owner_email_address> should be filled in: a missing or incorrect entry can affect visibility in the master server list.

8. Logging, so that you have data when it counts

The most important step is the one almost nobody takes in advance: building a baseline while everything is still normal. Without a normal value you cannot say after an incident whether 40,000 packets per second were a lot or just a Friday evening. With apt-get install -y vnstat sysstat the measurement runs continuously.

During an incident, separate the three ports from each other first. These four commands are enough:

sar -n DEV 1 10
nstat -az | grep -E 'Udp(InDatagrams|InErrors|NoPorts|RcvbufErrors)'
tcpdump -ni eth0 -c 200 -q 'udp port 22126'
ss -tn state established '( dport = :22005 or sport = :22005 )' | wc -l

Reading the results is simpler than it looks. If the buffer errors rise while CPU load is low, more traffic is arriving than the process can work through. If one core is pinned while the traffic looks normal, the problem is in the gamemode and not in the network. If the capture on 22126 shows many packets with a single payload byte, it is an ASE flood. If the number of open connections on 22005 sits in the thousands for a sustained period, the HTTP server is the target. With tcpdump the rule is always to cap it with -c, because a capture under full load puts extra strain on an already overloaded server. How to analyze the values in detail is covered in Detecting a DDoS attack on your server.

The server log itself is at logs/server.log and the script log at logs/scripts.log. Both paths are set in mtaserver.conf and can be moved.

Where these measures stop working

Now the part no configuration file can solve. Every measure so far runs on your server, which means at the end of the wire. A firewall rule decides about a packet that has already traveled down the cable. 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, with packets of 64 bytes, around 1.49 million packets per second. Attacks against game server projects of this size usually range between 5 and 50 Gbps, so five to fifty times your uplink. Whether your nftables rule behind it is good stops mattering at that point, because the packets from your players no longer get through in the first place.

The packet rate often bites earlier than the bandwidth. Depending on the CPU and the network card, a normal server kernel processes a few hundred thousand packets per second before it starts dropping. An attack that does not even fill a third of your uplink can therefore take your server down, because the processing time goes into dropping packets. Operators experience this as "utilization was not even high, and still everything was gone".

On MTA:SA a third limit comes on top, and it bites earliest of all. The server reads its network ports in a single processing pass. A query flood on 22126 occupies that pass so thoroughly that the synchronization packets of real players expire in the receive buffer long before the uplink is full. The process does not crash, it just gets slow, and players see rubberbanding. The same applies to the HTTP server: it shares processing time with the game.

For a sense of the magnitudes that actually occur: attacks filtered on KernelHost servers include one at over 473.4 Gbps with over 41.5 million packets per second against a voice server, and a UDP flood at over 112.2 Gbps with over 8.7 million packets per second against a game server. The first case is roughly 473 times the bandwidth and about 28 times the packet rate that a 1 Gbps uplink can take in at all. There is no local setting for that. Volumetric attacks have to end in the network in front of the server.

What KernelHost does about it

Included on every server: the two-layer always-on protection

Every server at KernelHost sits behind permanently active, two-layer filtering:

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

Three properties are decisive. The protection is permanently active, so there is no detection phase during which your server goes offline. No null-routing is used: the attacked address stays in the network and only the malicious packets are dropped, while the connections of real players keep running. And it costs nothing extra, because it is included in every server package from provisioning onwards, from the KVM root server through the game server to the dedicated server. Filtering happens on layers 3, 4 and 7 on every TCP or UDP port, so on 22003 UDP, 22005 TCP and 22126 UDP at the same time. All of this runs in the maincubes datacenter in Frankfurt am Main, Germany. The article Game server DDoS protection in real time shows which games and protocols have profiles of their own.

Advanced DDoS Protection for projects under constant fire

Some projects are not hit occasionally but targeted for weeks on end. For that case there is Advanced DDoS Protection from 50.00 EUR 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. Your server is switched over to it inside the KernelHost network, so you rebuild nothing on your side.
• Self-managed protection rules per port and protocol in the customer panel. On MTA:SA that is exactly the point: you set separate rules for 22003 UDP, 22005 TCP and 22126 UDP instead of treating three very different services the same way.
• Changes take effect in real time, with no ticket and no waiting, so you can fine-tune in the middle of an ongoing attack.
• A protection profile that matches the game. Multi Theft Auto is available as a profile of its own, and so are web servers, voice servers and your own TCP or UDP applications, which all fit behind the same protected address.

The two layers compared

For most MTA:SA projects the included always-on protection plus a clean server configuration is enough. Advanced DDoS Protection is the answer to somebody taking it personally.

Common mistakes and how to fix them

"I blocked 22126, the server is in no list any more, but queries still arrive": then the socket is still open. <ase>0</ase> alone does not close the port as long as <donotbroadcastlan>0</donotbroadcastlan> is set. Check with ss -lnup | grep 22126 whether anything is really still listening.

"Players hang on the loading screen while the game itself runs normally": that is not an attack on 22003, it is the HTTP server on 22005 at its limit. Offload the downloads through httpdownloadurl and review httpmaxconnectionsperclient and httpthreadcount.

"The server vanished from the browser and the players on it notice nothing": then only 22126 is being hit. For connected players that has no consequence, for the inflow of new players it does. A rate limit on that one port is the right answer, not one on the game port.

"I changed the IP address and was offline again two hours later": the attacker got the new address from the same source as the old one, usually the list entry, a Discord bot with a status query or an old DNS record. Changing addresses buys time, it does not solve anything.

"We set a rate limit of 20 packets per second per address on 22003": that is too tight. A single player is already above it during active synchronization, and several players behind the same NAT address share one budget. You are throwing out your own players. On 22126, tight values are unproblematic.

"We locked ourselves out with the firewall": a reboot does not help, because UFW restores its rules at boot. At KernelHost you open the VNC console in the customer panel and run ufw disable there. The VNC console works independently of the guest system's network.

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

"We will simply sit the attack out": attacks that work get repeated. Document the time with the time zone, the duration, the peak values and the affected port. Those are exactly the details a support ticket needs so the filtering can be tightened where it matters.

In short

• An MTA:SA server needs exactly three ports: 22003 UDP for the game, 22005 TCP for the internal HTTP server and 22126 UDP for the ASE query. The third is derived from the game port plus 123.
• The ASE query sits on a port of its own and can therefore be rate-limited without locking out a single player. That is the most important difference from SA-MP, where the game and the query share one port.
• A single request byte on 22126 produces a reply of up to several kilobytes, and the source address can be forged. An unthrottled ASE port is therefore both a target and an amplifier.
• The built-in brakes in MTA work per source address: five queries in six seconds, four joins in 30 seconds. Above 100 simultaneous source addresses the query counting is skipped, so a distributed flood passes straight through.
• The internal HTTP server on 22005 is a separate attack surface. Offloading the downloads to an external web server through httpdownloadurl takes them out of the game entirely.
• Everything that runs on the server only decides small attacks. At 1 Gbps it ends at roughly 1.49 million packets per second, no matter how good your rules are.
• The two-layer always-on protection at KernelHost is included in every server package with no surcharge and works without null-routing. If you want to control the rules per port yourself, add Advanced DDoS Protection from 50.00 EUR per month.

If your project already runs at KernelHost, the filtering is permanently active and there is nothing for you to switch on. If you still notice something unusual, open a support ticket with the time window, the port and the behavior you observed, so the rules for your address can be fine-tuned. During an ongoing attack you can also reach us on the WhatsApp emergency chat at +43 650 8209883. If you host elsewhere and get hit regularly, moving to Frankfurt am Main is the shorter route: further steps for the acute case are in Severe DDoS attack: what to do.