Halloween at Nexthosting: 10% off game servers with the code – until November 1
Guide for Rust server operators: three protection layers, ready-to-use iptables and Fail2Ban rules, monitoring steps and a provider checklist.
Effective DDoS protection for a Rust server needs three layers at the same time: upstream mitigation at the network operator, a game firewall with a Rust profile, and local hardening with iptables and Fail2Ban. The reason lies in the protocol: Rust runs over UDP and the RakNet protocol, so a pure Layer 7 filter as used against classic web attacks is not sufficient. If you want a stable gaming experience, you should choose a hosting provider with dedicated game profiles for Rust.
In short:
- Comprehensive DDoS protection for Rust servers consists of upstream mitigation, a game firewall with a Rust profile, and local hardening with iptables and Fail2Ban.
- Network scrubbing at the hosting provider filters large attacks before they reach the server, while a dedicated firewall recognizes the game traffic pattern and repels attacks.
- When configuring iptables and Fail2Ban, you need to know your ports so you can specifically limit connection attempts and effectively block repeat attackers.
- Real Layer 4 protection requires paid offerings; free solutions such as Cloudflare are hardly suitable for UDP-based games like Rust.
- A fast-developing attack can be recognized by rising latency, irregular packet loss or suspicious connection behavior, and acting early makes recovery easier.
A single protection mechanism is never enough against a serious attack. The question is not “which tool,” but which layer takes on which task.
Network or upstream mitigation is the first line of defense, as explained in detail in external security articles, for example in the security archive of JOMOX Media. It absorbs large volumes of traffic before they even reach your server, usually via anycast scrubbing networks that distribute the attack across multiple data centers. In a UDP flood of several hundred gigabits per second, no local rule will help you anymore, no matter how well it is configured.
The game firewall sits one layer above and distinguishes legitimate player traffic from attack patterns. In its own documentation on the Application Firewall, OVHcloud explicitly describes a Rust profile that allows per-IP-address rules and recommends “Drop” as the default policy. This is an important difference from generic Layer 3/4 scrubbing: a game profile knows the typical phases of a Rust session, from the handshake to ongoing gameplay, and can therefore reduce false positives.
The proxy layer, if used, hides the real server IP and pre-filters part of the traffic before it is even forwarded to the game process. And finally, server-side hardening (iptables rules, conntrack limits, Fail2Ban) takes effect against smaller disruption attempts and script-kiddie attacks.
Important to know: Cloudflare's free tier primarily handles Layer 7 and is therefore hardly suitable for UDP-based games like Rust. A Hetzner tutorial explicitly points out that real Layer 4 protection requires paid products such as Spectrum. If you only enable a generic web interface firewall, you will hardly protect your Rust setup effectively.
Before you write any rule: know your ports. By default, Rust uses one UDP port for the game protocol (often 28015) and another one for RCON. The underlying RakNet protocol uses a cookie mechanism when establishing a connection, similar to a SYN cookie in TCP, to reject simple spoofing attempts early.
DROP for everything above that.conntrack) fills up rapidly during a flood attack. Raise the table limit as a precaution and monitor it with conntrack -C, otherwise your server collapses at your own firewall.tcpdump capture during the attack gives your host the raw data to adjust the mitigation rules in a targeted way.Pro tip: Test your iptables rules first with a low threshold on a test server. Limits that are too aggressive otherwise block legitimate players when they reconnect after a brief connection drop, which feels like a server problem even though your own firewall is the culprit.
An interesting additional approach from defense research is the principle of proof of work: the client has to solve a small computational puzzle before the actual connection. This is not a standard mechanism for Rust, but the concept shows up in some experimental mitigation projects on GitHub, for example in this proof of concept for DDoS defense, which demonstrates how filter logic can be implemented technically at the application level.
An attack rarely announces itself with a warning message; it shows up in metrics. Rising latency despite a normal player count, a sudden increase in the connection rate from a few IPs, unusual packet loss or many incomplete handshakes are the classic early indicators.
Automated countermeasures take effect fastest at this point:
Community reports from the uMod forum show a recurring pattern: operators who hand a pcap capture to support early get suitable mitigation rules much faster than those who provide only a vague description of the problem. A short capture with the timestamp of the attack's start is often more valuable to support than any written description.
Communicate openly with your community during an attack, for example via Discord. A short status update prevents false assumptions about “broken servers” and keeps players on board instead of them drifting off to another server. Local Fail2Ban rules reliably help against freeloaders and minor disruption attempts, but according to Hetzner they do not replace real upstream scrubbing in a volumetric attack.
Before you sign a contract, check these four points specifically:
You can ask about these criteria directly in any first conversation with a host, without having to read the technical fine print beforehand.
The network topology often decides how resilient your setup is even before the first attack. Separate the Rust process from other services such as databases or web panels, ideally on separate systems or at least in separate network segments. That way, an attack on the game port does not automatically take down your backup system or your panel as well.
Where possible, use a dedicated uplink with sufficient capacity headroom instead of squeezing out the last available percent of bandwidth. A server that already runs close to its limit during normal operation tips over much faster at a small increase in load.
Also segment access to management interfaces such as RCON or the control panel with dedicated firewall rules, ideally restricted to known IP addresses. An attacker who floods the game port but has no access to RCON at least cannot additionally tamper with your server configuration.
If you run several Rust servers in parallel, you should not have them all run on the same public IP. Distributed IPs make it harder for attackers to hit several servers at once with a single campaign. Also document your network topology in writing; it speeds up communication with support enormously when things really need to move fast.
Even with good protection, an attack can get through, for example via a previously unknown amplification vector. What matters then is how quickly you return to normal operation without losing save data.
Automated daily backups are the minimum; for active communities, a shorter interval is worthwhile, for example every few hours during peak playing times. Do not store backups exclusively on the same physical system as the running server, otherwise the backup is of little use if the underlying hardware is affected.
After an attack, a short post-mortem is worthwhile: when did it begin, which metrics raised the alarm first, how long did recovery take? These notes help you respond faster to the next incident. Also check whether configuration files or plugins were modified during the attack, especially if an exploit attempt was running in parallel. A recovery plan that can only restore the bare server files but does not cover player data or economy databases is incomplete. And communicate the incident transparently to your community: a short recap after the attack has been weathered builds more trust than silence.
Many operators spend time on iptables fine-tuning before they have even evaluated a host with a game firewall. That is the wrong order. Upstream mitigation and game profiles should always come before local rule tuning, because they absorb the large attacks against which iptables has no chance anyway. Managed scrubbing pays off as soon as repeated attacks disrupt gameplay, not only after the tenth incident. And set realistic expectations: this is about operational reliability, not absolute immunity.
— Erik
If you have to click through the firewall documentation of several providers before your own server is even running, you lose time that is better spent on your community. On the Rust product page, Nexthosting offers ready-configured servers with NVMe storage, built-in DDoS protection and a server location in Germany, without you having to set up scrubbing rules or game firewalls from scratch yourself. You can find details on single-core performance and hardware, such as X3D processors, in an article on performance optimization for Rust servers. If you also want to clarify questions about data protection and server location in Germany, there is a checklist on data protection in hosting. Some providers offer support for custom adjustments to mitigation profiles, so that configurations fit the respective server setup better.
The measures described here are based on publicly documented practice, not on guesswork. For Rust servers, Nexthosting relies on NVMe storage, a server location in Germany and DDoS protection that is already built in; you can find concrete details on the Rust server page.
For technical depth, it is worth looking at primary sources:
The most effective approach is a combination of upstream mitigation by the host, a game firewall with a Rust profile, and local hardening with iptables and Fail2Ban. In our experience, a single measure alone is not enough against larger UDP floods.
Yes, numerous community operators host PvE Rust servers on infrastructure located in Germany, available from various hosting providers.
DDoS protection refers to technical measures that shield a server from targeted overload attacks using massive, often spoofed traffic. For Rust servers, this usually combines network scrubbing at the provider with game-specific firewall rules.
The cost depends heavily on the provider and the scope of the mitigation, and no concrete, universally valid prices can be given responsibly. With many hosts, basic DDoS protection is already included in the server price, while extended game firewall profiles sometimes have to be configured separately.