Protecting a RedM server from DDoS attacks

A RedM server that disappears in the middle of a session and comes back ten minutes later rarely has a hardware problem. Usually an attack on port 30120 is running, and it runs exactly when the most players are online. This article shows how to protect a RedM server from DDoS attacks: first what you can secure yourself at no extra cost, then the physical limit of those measures, and finally what has to happen in the network in front of the server once the attack is bigger than your uplink.

Everything here refers to an FXServer with gamename rdr3 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 of them. RedM is the Red Dead Redemption 2 modification by Cfx.re and the sister project of FiveM. Both run on the same server application, which is why part of the network technique really is identical. Where that is the case, it is stated here in one sentence and covered in detail in Protecting a FiveM server from DDoS attacks. Everything else in this text is RedM-specific.

If the attack is running right now: do not change anything in server.cfg and do not restart the server. Capture the measurements first (see the section "Collect measurements"), because once the attack is over they are gone.

Why RedM servers are such frequent DDoS targets

A RedM server is a more rewarding target than its player count suggests, and the reason is the size of the scene rather than its smallness. In September 2026, public server list trackers counted around 2,000 active RedM servers with roughly 12,400 concurrent players, against around 39,000 FiveM servers with roughly 325,000 players. Whoever takes down one of 2,000 RedM servers removes a far larger share of the entire scene than somebody hitting one of 39,000 FiveM servers. For an attacker who wants to hurt a competing project, the leverage is therefore much greater.

The structure of the communities adds to that. RedM roleplay lives on fixed sessions at fixed hours, often with applications and character approval. An outage at 8 pm does not hit random players, it hits exactly the people who signed up for that evening. Many projects also run as a hobby on a small budget, depend on a single cheap server and have no second instance to switch to. Publicly documented cases from the RedM scene describe attack series lasting months at an almost daily rate, hitting the game server and the separate voice server at the same time.

On top of that comes a technical detail: the game traffic runs over UDP. UDP is a connectionless transport protocol: there is no connection setup the server could insist on, and source addresses can be spoofed. So an attacker does not have to join your RedM server, or even address it correctly, in order to create load. For what a DDoS attack actually is and how it is assembled, read What is a DDoS attack?.

The ports that actually matter

By default a RedM server binds to a single port, and it does so on both protocols. In server.cfg:

endpoint_add_tcp "0.0.0.0:30120"
endpoint_add_udp "0.0.0.0:30120"
set gamename rdr3
sv_enforceGameBuild 1491
sv_licenseKey "cfxk_..."

The line set gamename rdr3 is the only one that distinguishes a RedM server from a FiveM server. Without it, the very same FXServer registers itself as a GTA V server and a RedM client will not connect. RedM has no separate query port and no separate RCON port: server queries, connection setup, game traffic and RCON all run through those two entries on 30120. This is the hard data:

Of the four ports listed, exactly two belong on the open internet: 30120 TCP and 30120 UDP. Port 40120 and port 3306 do not belong there, and SSH on port 22 should be restricted to your own addresses. This is the most common avoidable mistake on RedM servers, because many projects start from a ready-made txAdmin recipe and never check afterwards what the server offers to the outside.

What you can do yourself before spending money

This section is the longest one, and that is deliberate. A cleanly configured RedM server survives small and medium attacks under its own power, no matter who hosts it. The order is chosen on purpose: you measure first, close next and only then limit.

1. Take stock: what is listening at all?

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

ss -lntup

The interesting column is the local address. 0.0.0.0:30120 and [::]:30120 mean "reachable from the entire internet", 127.0.0.1:3306 means "local only" and needs no firewall rule. Next to the FXServer, a RedM machine regularly shows txAdmin on 40120, MariaDB on 3306, a web server for the project site and occasionally a voice service. A port scan from outside gives you the attacker's view:

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

2. Leave open only 30120 TCP and UDP

Two rules facing the outside are enough for RedM, everything else gets restricted or is never published in the first place. 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 30120/tcp comment 'RedM'
ufw allow 30120/udp comment 'RedM'
ufw allow from 203.0.113.10 to any port 40120 proto tcp comment 'txAdmin'
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

Replace 203.0.113.10 with your own address. On a connection with a changing address this is impractical, and the better route is described in the next section on txAdmin. The full guide including the escape route is in Setting up the UFW firewall without locking yourself out.

The database has no business on the open internet under any circumstances. VORP, RSGCore and RedEM:RP all need a MariaDB or MySQL, usually through oxmysql with a connection string in server.cfg. That connection runs locally, so the port does not have to be reachable from outside. Check in /etc/mysql/mariadb.conf.d/50-server.cnf that it says:

bind-address = 127.0.0.1

3. Secure the HTTP endpoints of the FXServer

On the TCP side of 30120, the FXServer answers HTTP requests without anyone having to start Red Dead Redemption 2. Have a look at what your RedM server serves there:

curl -s http://127.0.0.1:30120/info.json | head -c 600
curl -s http://127.0.0.1:30120/players.json | head -c 600
curl -s http://127.0.0.1:30120/dynamic.json

/players.json lists the connected players together with their identifiers, /info.json lists the server configuration and the loaded resources, /dynamic.json the current occupancy. Those three endpoints are exactly the documented layer 7 attack path against FiveM and RedM servers: they are reachable without authentication, they can be queried as often as anyone likes, every query costs your server work, and the content tells an attacker when an attack is worth the effort. Two countermeasures cost nothing. First, the endpoints of your players do not belong in the response, and one line in server.cfg is enough for that:

sv_endpointPrivacy true

This setting hides the IP addresses of your players in the public reports the server puts out. Second: if your Discord bot or your project website shows the player count, do not query the endpoint from the visitor's browser, but cache the result at fixed intervals instead. That way a busy status page produces one query per interval instead of one per visitor. In a small scene like RedM this counts twice over, because a single server status bot can be embedded in several Discord servers at once.

4. Take txAdmin on port 40120 off the open internet

txAdmin is the management interface included in the FXServer build for both FiveM and RedM, and it listens on 40120 TCP by default. Behind it sits full access to your server: restarts, ban list, player database, resource management. If you have no static IP address for an allow rule, keep the port closed to the outside and reach it through a local port forward over SSH, then open http://127.0.0.1:40120 in your browser:

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

Leaving txAdmin publicly exposed gives you two problems at once: a login form that login floods can be aimed at, and a service that does work on every request even though it has nothing to do with the game. When in doubt, bind txAdmin locally right away by letting the service listen on 127.0.0.1 only.

5. Limit connection and packet rates per source address

Against small attacks and sloppy bots, an upper limit per source address helps. Both rules apply to 30120, so to both protocols of the game:

iptables -I INPUT -p tcp --dport 30120 --syn -m connlimit --connlimit-above 8 --connlimit-mask 32 -j DROP
iptables -I INPUT -p udp --dport 30120 -m hashlimit --hashlimit-name redm_udp --hashlimit-mode srcip --hashlimit-above 500/sec --hashlimit-burst 750 -j DROP

The first rule drops new TCP connections as soon as one address holds more than eight of them open at the same time, the second one drops UDP packets once the same source sustains more than 500 packets per second. The starting values are a little lower than on a FiveM server, because a RedM server with 32 slots simply produces fewer legitimate connections per address. Starting values are not truths, though: a busy roleplay evening produces far more packets than an empty server, and setting the limits too tight throws out your own players. Measure a week of normal operation first.

Two notes on this. Plain iptables rules are gone after a reboot, and on Debian and Ubuntu you save them like this:

apt-get install -y iptables-persistent
netfilter-persistent save

Under UFW, such rules belong in /etc/ufw/before.rules, because otherwise they disappear with the next ufw reload. Another bottleneck that is often overlooked is the connection tracking of the kernel: once it fills up, the server drops legitimate packets as well, and the 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

6. Protect the 32 slots against join floods

A RedM server has exactly 32 slots without OneSync. With OneSync it has 48, and beyond that an Element Club subscription is required for up to 1,024 places. That number is security relevant, because it is the ceiling an attacker has to fill: whoever holds 32 join attempts open at the same time occupies a default server completely, without a single player ever arriving in the game. On a FiveM project with 128 places, the same threshold is four times as high.

One RedM-specific advantage offsets that in part: RedM requires a legitimate copy of Red Dead Redemption 2, whether bought through Steam, Epic Games or Rockstar, plus the Rockstar launcher. A join flood built from thousands of throwaway accounts, the way it works on free games, costs real money here. Attacks therefore shift to the network layer and to the HTTP endpoints, where no copy of the game is needed.

Against everything that uses the regular join path, a whitelist still works. You implement it on the server side in the playerConnecting event, where you hold the connection with the deferral functions, check the identifier and only then let the player through. Add a strict account check and a realistic player limit:

sv_authMaxVariance 1
sv_authMinTrust 5
sv_maxclients 32

sv_authMaxVariance is a value from 1 to 5 and states how much a player's identifier may change for a provider; 1 is the strictest setting. sv_authMinTrust also runs from 1 to 5 and describes how unlikely a spoofed identity has to be; here 5 is the strictest value. Set an RCON password only if you actually need RCON, because that access sits on the same open port 30120. 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.

7. Judge the entry in the RedM server list correctly

Honesty beats wishful thinking here: your IP address cannot be kept secret. RedM uses the same Cfx.re master server infrastructure as FiveM, and the list entry carries the connection endpoint in plain text in the connectEndPoints field. Through the public interface at servers-frontend.fivem.net, the matching address can be looked up for any cfx.re code, for RedM exactly as for FiveM. If you do not need the public entry at all, because the project runs purely through Discord and direct connections, you can mark the server as private with sv_master1 "": it then cannot be joined through the server browser. That costs you all visibility for new players, though, and in a scene with 2,000 servers visibility is the actual engine of growth.

Two habits are more effective. Never publish the raw IP address yourself, so neither in the Discord channel nor on the project website. And connect your players through a hostname, so that you can change the address if it comes to that without breaking every reference. The classic pitfall here is old DNS records: a forgotten A record pointing at the previous address makes any change pointless.

8. Validate VORP, RSGCore and RedEM events on the server side

Many outages that get reported as a DDoS attack come down to a single script. RedM resources communicate through network events, and an event that the server executes without checking it is an open door: anyone who fires a TriggerServerEvent from the client with arbitrary values can create dollars, spawn horses or trigger database queries in a loop until the server grinds to a halt. That applies to all three common frameworks alike: VORP Core, which has held the largest script base since 2020, RSGCore, and the older RedEM:RP.

The inventory and character resources are particularly exposed, because they write to the database on every call. An event loop that saves an inventory state ten times per second puts more strain on a RedM server than many a packet flood, and it comes from the inside, where no firewall applies.

Three rules catch most of that. Register only those events with RegisterNetEvent that really are meant to come from the client. Never rely on values the client sends along, but determine the player on the server side from source. And limit how often a player may trigger the same event, especially for anything that hits the database. If the server stutters while the uplink is quiet, resmon 1 in the client console shows the processing time per resource, and the culprit is usually right at the top.

9. Collect measurements before you need them

The most important step is the one almost nobody takes beforehand: build a baseline while everything is still normal. Without a normal value you cannot say after an incident whether 40,000 packets per second was a lot or simply a well attended Tuesday evening. With apt-get install -y vnstat sysstat the measurement runs permanently in the background. During an incident four commands are enough: packet rates per second, the drop counters of the interface, kernel messages and a short sample of the traffic.

sar -n DEV 1 10
ip -s link show eth0
dmesg -T | tail -50
tcpdump -ni eth0 port 30120 -c 200 -q

One rule for tcpdump: always cap it with -c, because a capture under full load puts extra strain on a server that is already overloaded. Also watch whether the load sits on the UDP side or on the TCP side of 30120. UDP load points to a packet flood against the game traffic, TCP load to a flood against the HTTP endpoints, and the two need different countermeasures. How to read the numbers is covered in Detecting a DDoS attack.

Where these measures stop

Now the part that no server.cfg can solve. Everything 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 travelled 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. Attacks against roleplay projects usually range between 5 and 50 Gbps, so five to fifty times your uplink. Whether your iptables rule behind it is any good no longer matters, because the packets of your players stop getting through before that.

The second figure is the packet rate, and it often hits earlier than the bandwidth does. With small packets of 64 bytes, around 1.49 million packets per second fit into an uplink of 1 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 RedM server down, because the processing time goes into the dropping. Operators experience this as "the utilization was not even high, and yet everything was gone". Those lag spikes without visible server load are the typical appearance of a packet rate attack.

For a sense of the magnitudes that really occur: on KernelHost servers we have filtered, among others, an attack of over 473.4 Gbps at over 41.5 million packets per second against a voice server, and a UDP flood of over 112.2 Gbps against a game server. There is no local setting for that. Volumetric attacks have to end in the network in front of the server.

What is different about RedM compared to FiveM

The short answer: the network technique is identical, the environment is not. Both run on the same FXServer, both use 30120 TCP and UDP, both are managed through txAdmin on 40120. Everything above about ports, rates and endpoints applies to both. What differs are the surrounding conditions, and those decide how quickly an attack takes effect:

Three points from this table matter for the defense. First, the smaller scene makes every single RedM server more valuable as a target, because one outage affects a larger share of the players. Second, the default ceiling of 32 slots lowers the threshold at which a join flood shuts the server down. Third, fewer ready-made hardening recipes exist for RedM than for FiveM, which is why many projects run an unchanged default configuration. The defense is the same, the starting point is worse.

What KernelHost puts up against it

The always-on protection included with every server

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 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 are no opening minutes in which the RedM server is gone. 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 filtering is located in Frankfurt am Main. Which games and protocols are covered is listed in Game server DDoS protection with real-time filtering.

Advanced DDoS Protection for projects under constant fire

Some projects are attacked not occasionally, but deliberately and for weeks on end. 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 separately what is allowed on 30120 UDP and what is allowed on 30120 TCP, without writing a ticket for it. On RedM that separation is particularly useful, because game traffic and HTTP endpoints share the same port number and have completely different patterns.
• Changes take effect in real time, so you can fine-tune while an attack is still running.
• A protection profile matched to the application. There is a suitable profile for Cfx.re servers on 30120, and there are profiles for modified and custom applications on any TCP or UDP port.

Both apply to servers hosted at KernelHost. If your RedM project currently runs elsewhere and keeps getting knocked off the network, the recommendation is to move it, not to add another product.

The two tiers compared

For most RedM projects 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

"My server does not show up in the RedM server list, I suspect an attack": check the configuration first. Without set gamename rdr3 the FXServer registers as a GTA V server and never appears in the RedM list. If the license key from portal.cfx.re is missing or wrong, the entry does not happen either. An attack looks different: the entry stays in place and the connection fails.

"Hundreds of players get an error while joining, it looks like a flood": usually it is a game build problem. If sv_enforceGameBuild does not match what your resources expect, the client reports "server specified an invalid game enforcement". Set the value your framework requires, commonly 1436 or 1491, and restart the server completely.

"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 or an old DNS record. Changing the address buys time, it is not a solution.

"My iptables rules have no effect": three causes are common. The rules sit behind the UFW chains and are never reached, they were gone after the last reboot (then netfilter-persistent save or an entry in /etc/ufw/before.rules helps), 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.

"The server is running, but every player is rubber-banding": that is more often a script than an attack. First use resmon 1 to see whether one resource is eating the processing time, and check the inventory and character resources of your framework. If sar -n DEV 1 10 stays unremarkable, it was not a DDoS attack.

"txAdmin shows hundreds of failed connection attempts": that is a join flood, and it hits the game logic, not the uplink. The whitelist, the account check through sv_authMinTrust and the connection limit per source address work against it.

"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 the 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, which works independently of the network of the guest system.

In short

• A RedM server needs exactly two open ports: 30120 TCP and 30120 UDP, set through endpoint_add_tcp and endpoint_add_udp. There is no separate query port and no separate RCON port.
• txAdmin on 40120 TCP and the database on 3306 TCP do not belong on the open internet, but on your own address and on 127.0.0.1 respectively.
• sv_endpointPrivacy true takes the player IP addresses out of the public reports, and a cached server status takes load off /players.json, the documented layer 7 attack path against Cfx.re servers.
• A RedM server has 32 slots without OneSync, 48 with OneSync and up to 1,024 with Element Club. The fewer the slots, the cheaper a join flood becomes, and the more a whitelist and an account check matter.
• RedM and FiveM run on the same FXServer, distinguished solely by set gamename rdr3. The network defense is therefore identical, the environment is not: around 2,000 RedM servers against around 39,000 FiveM servers make every single RedM project the more valuable target.
• Local firewall rules end where the uplink is full: 1 Gbps is 125 megabytes per second, and with packets of 64 bytes around 1.49 million packets per second fit into it. Everything beyond that has to end in the network in front of the server.
• At KernelHost the two-layer always-on protection is included with every server package, active from provisioning onwards and without null-routing. If you want to steer the filtering yourself, Advanced DDoS Protection from EUR 50.00 per month gives you a dedicated protected IP and your own rules per port and protocol.

If your RedM project 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 we can fine-tune the filter rules for your IP address. During an ongoing attack you can also reach us through the WhatsApp emergency chat at +43 650 8209883.