Arma-3-Server vor DDoS-Angriffen schützen

Wer einen Arma-3-Server vor DDoS-Angriffen schützen will, hat es mit genau fünf UDP-Ports zu tun: 2302 bis 2306. Ein dedizierter Server, der abends mitten im Einsatz für alle Spieler gleichzeitig wegbricht, hat selten ein Hardwareproblem. Meistens läuft ein Angriff auf genau diesen Portblock, und zwar dann, wenn die Serverliste die höchste Spielerzahl anzeigt. Dieser Beitrag zeigt zuerst, was Sie ohne Zusatzkosten selbst absichern können, danach, wo diese Maßnahmen technisch aufhören, und zum Schluss, was im Netz vor dem Server passieren muss.

Alle Angaben beziehen sich auf einen dedizierten Arma-3-Server (SteamCMD-Anwendung 233780) unter Debian 12, Debian 13, Ubuntu 22.04 LTS oder Ubuntu 24.04 LTS. Die Befehle sind für root geschrieben, als normaler Benutzer stellen Sie sudo voran. Wenn der Angriff gerade läuft: Ändern Sie jetzt nichts an der Konfiguration und starten Sie den Server nicht neu, sondern sichern Sie zuerst die Messwerte aus dem Abschnitt "Protokollieren". Nach dem Angriff sind sie weg.

Warum Arma-3-Server angegriffen werden und wann DDoS-Schutz nötig wird

Arma 3 vereint mehrere Eigenschaften, die einen Server zu einem bequemen Ziel machen. Erstens veröffentlicht der Server seine Adresse selbst: Er meldet sich über Port 2304 UDP am Steam-Masterserver an und beantwortet auf Port 2303 UDP Abfragen mit Name, Karte, Spielerzahl und Mod-Liste. Ohne diese beiden Ports findet Sie niemand, mit ihnen steht Ihre IP-Adresse in jedem Serverbrowser und in jeder Statusseite, die den Serverbrowser abfragt.

Zweitens ist die Spielerschaft an feste Zeiten gebunden. Life-Rollenspiel-Projekte auf Altis und Tanoa, Exile, Antistasi und King of the Hill füllen sich abends und am Wochenende, ein Ausfall um 20 Uhr ist also maximal sichtbar. Drittens gibt es Konkurrenz zwischen Projekten, gebannte Spieler und interne Konflikte, und ein Angriff kostet den Auslöser weder Können noch nennenswertes Geld.

Technisch kommt der entscheidende Punkt hinzu: Arma 3 läuft vollständig über UDP, TCP braucht das Spiel für den Spielbetrieb nicht. UDP kennt keinen Verbindungsaufbau, den man verlangen könnte, und Absenderadressen lassen sich fälschen. Ein Angreifer muss Ihren Server also weder betreten noch korrekt ansprechen, um Last zu erzeugen. Dazu kommt, dass die Simulationsschleife eines Arma-3-Servers im Kern auf einem Rechenkern läuft: Wer genug Pakete schickt, kostet diesen einen Kern Rechenzeit, und zwar unabhängig davon, wie viele Kerne die Maschine sonst hat. Was ein DDoS-Angriff im Detail ist, erklärt der Beitrag Was ist ein DDoS-Angriff?.

Die Ports, um die es tatsächlich geht

Ein Arma-3-Server belegt ab Werk den Block 2302 bis 2306 UDP. Der Startparameter -port=2302 legt nur den ersten Port fest, die übrigen vier ergeben sich fest daraus, nämlich als Spielport plus 1 bis plus 4. Wer mehrere Instanzen auf derselben Maschine betreibt, lässt deshalb mindestens 100 Ports Abstand (2302, 2402, 2502), sonst greifen sich die Instanzen gegenseitig die Folgeports weg.

Von diesen acht Zeilen gehören genau drei ins offene Internet: 2302, 2303 und 2304 UDP. Alles andere ist Verwaltung, und offene Verwaltungsports sind der häufigste vermeidbare Fehler auf Arma-3-Servern.

Was Sie selbst tun können, bevor Sie Geld ausgeben

Dieser Abschnitt ist der längste, und das mit Absicht. Ein sauber konfigurierter Arma-3-Server hält kleine und mittlere Angriffe aus eigener Kraft aus, unabhängig davon, bei wem er steht.

1. Bestandsaufnahme: was lauscht auf dem Server?

Bevor Sie eine einzige Regel schreiben, sehen Sie nach, was Ihr Server nach außen anbietet. Nicht raten, nachsehen:

ss -lntup

Interessant ist die Spalte mit der lokalen Adresse. 0.0.0.0:2302 bedeutet "aus dem ganzen Internet erreichbar", 127.0.0.1:3306 bedeutet "nur lokal" und braucht keine Firewall-Regel. Neben dem Spiel tauchen dort auf einem Life-Server regelmäßig MariaDB, ein Webserver für die Fraktionsseite, ein TeamSpeak- oder Voice-Dienst und ein vergessenes Panel auf. Die Sicht des Angreifers liefert ein Portscan von außen:

nmap -Pn -sU -p 2300-2320 IHRE.SERVER.IP.ADRESSE
nmap -Pn -p- --min-rate 1000 IHRE.SERVER.IP.ADRESSE

Der erste Befehl zeigt den UDP-Block des Spiels, der zweite alles, was auf TCP offen steht. Ein Arma-3-Server braucht für den Spielbetrieb keinen einzigen offenen TCP-Port.

2. Nur die Ports offen lassen, die Arma 3 wirklich braucht

Drei UDP-Ports nach außen reichen, alles andere wird eingeschränkt. Mit UFW sieht das so aus, und zwar genau in dieser Reihenfolge, damit Sie sich nicht selbst aussperren:

ufw allow from 203.0.113.10 to any port 22 proto tcp comment 'SSH'
ufw allow 2302:2304/udp comment 'Arma 3 Spiel, Steam-Query, Steam-Master'
ufw allow from 203.0.113.10 to any port 2306 proto udp comment 'BattlEye RCon'
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

Ersetzen Sie 203.0.113.10 durch Ihre eigene Adresse. Port 2305 bleibt zu, weil Bohemia ihn als reserviert und derzeit ungenutzt führt. Wichtig ist die Zeile ufw default allow outgoing: BattlEye baut vom Server aus eine Verbindung zu arma31.battleye.com auf und braucht dafür ausgehend 2344 auf TCP und UDP sowie 2345 auf TCP. Wer ausgehend pauschal sperrt, sperrt seinen eigenen Anti-Cheat aus. Prüfen Sie nach der Umstellung mit einem echten Beitritt, dass BattlEye Ihre Spieler weiterhin durchlässt. Die vollständige Anleitung samt Rettungsweg steht in UFW-Firewall einrichten, ohne sich selbst auszusperren.

Die Datenbank gehört in keinem Fall ins offene Netz. Altis Life und die anderen Life-Frameworks sprechen über die Erweiterung extDB3 mit einer MySQL-Datenbank, und die Zugangsdaten stehen im Klartext in @extDB3/extdb3-conf.ini. Prüfen Sie in /etc/mysql/mariadb.conf.d/50-server.cnf, dass dort steht:

bind-address = 127.0.0.1

3. Den Steam-Query-Port entschärfen, ohne aus dem Serverbrowser zu fliegen

Port 2303 UDP ist der empfindlichste Punkt eines öffentlichen Arma-3-Servers. Er beantwortet A2S-Abfragen, also die Standardabfrage des Steam-Serverbrowsers: A2S_INFO liefert Name, Karte und Spielerzahl, A2S_PLAYERS die Spielerliste, A2S_RULES die Mod- und Signaturliste. Eine Abfrage ist ein kleines UDP-Paket, die Antwort ist ein Vielfaches davon. US-CERT führt das Steam-Protokoll in Alert TA14-017A mit einem Bandbreitenamplifikationsfaktor von 5,5, und bei Arma 3 fällt die Antwort besonders groß aus, weil die komplette Mod-Liste mitgeliefert wird.

Daraus folgen zwei Dinge. Erstens kann Ihr Server als Verstärker gegen Dritte missbraucht werden, wenn ein Angreifer Abfragen mit gefälschter Absenderadresse schickt. Zweitens, und für Sie wichtiger, kostet jede Abfrage Rechenzeit auf dem einen Kern, der die Simulation trägt. Bohemia führt seit 2015 ein Ticket dazu (T83469): Gefälschte UDP-Pakete an den Spielport oder den Steam-Query-Port trieben die CPU auf 100 Prozent und froren den Server ein, und für einen erfolgreichen Angriff über den Query-Port genügten bereits 4 Mbit/s. Das ist der Grund, warum bei Arma 3 die Paketrate gefährlicher ist als die Bandbreite.

Der erste Hebel ist die Antwortgröße. Die Direktive steamProtocolMaxDataSize in der server.cfg legt fest, wie viele Bytes der Server in seine Query-Antwort packen darf. Betreiber großer Mod-Listen erhöhen sie auf 2048 oder mehr, weil sonst die Warnung "Query data overflow, Mods/Signatures will not be correctly received by clients" im Protokoll steht. Jede Erhöhung vergrößert aber genau die Antwort, die ein Angreifer verstärkt. Setzen Sie den Wert deshalb so niedrig, wie es Ihre Mod-Liste gerade noch erlaubt, und räumen Sie ungenutzte Mods aus dem Startbefehl:

steamProtocolMaxDataSize = 2048;

Der zweite Hebel ist eine Ratenbegrenzung je Quelladresse, die nur den Query-Port trifft. Sperren Sie 2303 UDP nicht pauschal: Ohne Query-Antwort verschwindet Ihr Server aus dem Serverbrowser und aus jeder Statusseite, und neue Spieler finden ihn nicht mehr. Ein legitimer Serverbrowser fragt einige Male pro Minute ab, nicht hunderte Male pro Sekunde.

4. BattlEye-RCon aus dem offenen Netz nehmen

BattlEye ist der Anti-Cheat von Arma 3 und wird in der server.cfg mit BattlEye = 1; eingeschaltet. Die dazugehörige Fernsteuerung, BattlEye RCon, ist ein eigenes UDP-Protokoll und wird in BattlEye/beserver_x64.cfg konfiguriert (die Datei mit dem Zusatz _x64 gilt für arma3server_x64, den heute üblichen Server):

RConPassword IhrAlphanumerischesPasswort
RConPort 2306
RConIP 127.0.0.1
MaxPing 350
RestrictRCon 0

Drei Punkte sind entscheidend. Das RCon-Passwort muss rein alphanumerisch sein, Sonderzeichen bringen den Protokollparser von BattlEye still aus dem Tritt, und ein RCon-Zugang mit stillem Fehler ist einer, den Sie im Ernstfall nicht haben. RConIP legt fest, auf welcher Adresse RCon lauscht: Steht dort 127.0.0.1, ist die Schnittstelle nur lokal erreichbar, und Ihr RCon-Werkzeug erreicht sie über eine SSH-Weiterleitung. Und RConPort muss oberhalb des Spielblocks liegen, üblich ist der Spielport plus 4, also 2306. Wer RCon nach außen öffnen muss, gibt den Port nur für die feste Adresse seines Admin-Teams frei.

Eines sollte dabei klar sein: BattlEye ist ein Anti-Cheat, kein DDoS-Schutz. Es prüft Spieler, die verbunden sind. Ein Angreifer, der Ihren Server flutet, will gar nicht beitreten.

5. Den Headless Client fest binden

Ein Headless Client ist eine zweite Arma-3-Instanz ohne Grafik, die sich wie ein Spieler mit dem Server verbindet und ihm die Berechnung der KI abnimmt. Das ist bei großen Missionen der wichtigste Leistungsgewinn überhaupt, weil die KI sonst auf demselben Kern liegt wie die Simulation. Freigeschaltet wird er in der server.cfg:

headlessClients[] = {"127.0.0.1"};
localClient[] = {"127.0.0.1"};

Der Server lässt ohne diese Einträge keine Headless-Client-Verbindung zu, das ist die gute Nachricht. Die schlechte: localClient[] räumt der eingetragenen Adresse unbegrenzte Bandbreite und praktisch keine Latenzprüfung ein. Tragen Sie dort ausschließlich 127.0.0.1 oder die feste Adresse Ihres eigenen Headless-Client-Servers ein, niemals einen ganzen Adressbereich. Gestartet wird der Client mit -client -connect=127.0.0.1 -port=2302 -password=..., und er belegt einen Slot aus maxPlayers. Planen Sie den also ein, sonst stehen Ihre Spieler vor einem vollen Server.

6. Beitritt, Signaturen und Abstimmungen härten

Diese Einstellungen schützen nicht Ihre Leitung, aber sie schließen alles, was über den regulären Beitrittsweg kommt: manipulierte Clients, Skript-Ausführung im Spiel und Abstimmungs-Missbrauch. Die folgenden Zeilen gehören in jede server.cfg eines öffentlichen Servers:

verifySignatures = 2;
BattlEye = 1;
kickDuplicate = 1;
allowedFilePatching = 0;
maxPlayers = 64;
disconnectTimeout = 30;
maxPing = 200;
maxDesync = 150;
maxPacketLoss = 50;
kickClientsOnSlowNetwork[] = {1, 1, 1, 1};
voteThreshold = 1.5;
voteMissionPlayers = 100;
onUnsignedData = "kick (_this select 0)";
onHackedData = "kick (_this select 0)";

verifySignatures = 2 erzwingt die Signaturprüfung Version 2 für alle Addons und ist die Mindestanforderung für jeden öffentlichen Server mit Mods. allowedFilePatching = 0 verweigert Clients, die mit -filePatching gestartet wurden, den Beitritt (Wert 1 erlaubt es nur Headless Clients, Wert 2 allen). kickDuplicate = 1 wirft die zweite Verbindung derselben Kennung heraus. kickClientsOnSlowNetwork[] entscheidet je Eintrag, ob die vier Schwellen aus maxPing, maxPacketLoss, maxDesync und disconnectTimeout nur protokolliert (0) oder durchgesetzt werden (1). disconnectTimeout akzeptiert Werte von 5 bis 90 Sekunden. Ein voteThreshold über 1 macht Abstimmungen unerreichbar und beendet damit den beliebtesten Weg, einen Server ohne ein einziges Angriffspaket zu stören: den Missionswechsel per Abstimmung.

7. Paket- und Verbindungsraten je Quelladresse begrenzen

Gegen kleine Angriffe und unsaubere Bots hilft eine Obergrenze je Quelladresse. Weil Arma 3 reines UDP fährt, arbeitet man mit hashlimit, und der Query-Port bekommt eine deutlich engere Grenze als der Spielport:

iptables -I INPUT -p udp --dport 2303 -m hashlimit --hashlimit-name a3_query --hashlimit-mode srcip --hashlimit-above 10/sec --hashlimit-burst 20 -j DROP
iptables -I INPUT -p udp --dport 2302 -m hashlimit --hashlimit-name a3_game --hashlimit-mode srcip --hashlimit-above 900/sec --hashlimit-burst 1200 -j DROP
iptables -I INPUT -p udp --dport 2302:2306 -m length --length 0:27 -j DROP

Die erste Regel verwirft Query-Abfragen aus derselben Quelle ab dauerhaft mehr als zehn pro Sekunde, die zweite Spielpakete ab dauerhaft mehr als 900 pro Sekunde, die dritte UDP-Pakete ohne verwertbare Nutzlast. Alle drei Zahlen sind Startwerte, keine Wahrheiten: Ein voller Life-Server mit 80 Spielern erzeugt deutlich mehr Pakete als eine Antistasi-Runde zu sechst, und wer zu eng einstellt, wirft eigene Spieler heraus. Messen Sie erst eine Woche im Normalbetrieb.

Zwei Hinweise dazu. Reine iptables-Regeln sind nach einem Neustart weg, unter Debian und Ubuntu sichert man sie so:

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

Unter UFW gehören solche Regeln in /etc/ufw/before.rules, weil sie sonst beim nächsten ufw reload verschwinden. Ein oft übersehener Engpass ist außerdem die Verbindungsverfolgung des Kernels: Auch UDP legt dort Einträge an, und ein Query-Flood aus vielen gefälschten Adressen füllt die Tabelle in Sekunden. Läuft sie voll, verwirft der Server auch legitime Pakete, und im Protokoll steht "nf_conntrack: table full". Stand und Obergrenze zeigt:

sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max

8. basic.cfg: Bandbreite, Paketgrößen und Zusatzdateien

Die zweite Konfigurationsdatei eines Arma-3-Servers heißt basic.cfg und wird mit -cfg= geladen, während -config= die server.cfg lädt. Sie steuert das Netzverhalten und enthält genau einen Wert, der unmittelbar sicherheitsrelevant ist:

MaxMsgSend = 1024;
MaxSizeGuaranteed = 512;
MaxSizeNonguaranteed = 256;
MinBandwidth = 15000000;
MaxBandwidth = 100000000;
MinErrorToSend = 0.001;
MinErrorToSendNear = 0.01;
MaxCustomFileSize = 0;
class sockets { maxPacketSize = 1400; };

MaxCustomFileSize ist die maximale Größe in Bytes für Gesichts- und Sounddateien, die Spieler mitbringen und die der Server an alle anderen verteilt. Der Wert 0 schaltet diese Verteilung ab. Damit fällt ein Weg weg, auf dem ein einzelner Client die Bandbreite Ihres Servers ohne jede Angriffsinfrastruktur belegt. MinBandwidth ist die Bandbreite, die der Server als gesichert annimmt, Richtwert ist die Spielerzahl mal 256 kbit/s, also rund 16 Mbit/s für 64 Slots. Zu optimistische Werte erhöhen Last und Desynchronisation, weil der Server Nachrichten erzeugt, die er dann verwirft. MaxMsgSend begrenzt die Pakete je Simulationsschritt und ist der erste Hebel gegen Desynchronisation, der Standardwert 128 ist für moderne Server zu niedrig angesetzt.

9. Protokollieren, damit Sie im Angriff nicht raten müssen

Der wichtigste Schritt ist der, den fast niemand vorher macht: eine Vergleichsbasis anlegen, solange alles normal läuft. Ohne Normalwert können Sie nach einem Vorfall nicht sagen, ob 40.000 Pakete pro Sekunde viel waren oder einfach Samstagabend. Mit apt-get install -y vnstat sysstat läuft die Messung dauerhaft mit, und logFile = "arma3server.log"; in der server.cfg gibt Ihnen die Serversicht dazu. Während eines Vorfalls genügen vier Befehle:

sar -n DEV 1 10
ip -s link show eth0
dmesg -T | tail -50
tcpdump -ni eth0 udp portrange 2302-2306 -c 200 -q

Aufschlussreich ist der Vergleich der Ports. Liegt die Last fast vollständig auf 2303, ist es ein Query-Flood, und der trifft die Rechenzeit. Verteilt sie sich gleichmäßig über 2302 bis 2306 mit immer neuen Absenderadressen, ist es ein gefälschter UDP-Flood, und der trifft die Leitung. Bei tcpdump gilt: immer mit -c begrenzen, ein Mitschnitt unter Volllast belastet einen ohnehin überlasteten Server zusätzlich. Wie Sie die Werte auswerten, steht in DDoS-Angriff erkennen. Wie der Server überhaupt sauber installiert und aktualisiert wird, steht in Gameserver mit SteamCMD installieren.

Wo diese Maßnahmen aufhören

Jetzt der Teil, den keine Konfigurationsdatei lösen kann. Alle bisherigen Maßnahmen laufen auf Ihrem Server, also am Ende der Leitung. Eine Firewall-Regel entscheidet über ein Paket, das bereits über das Kabel gelaufen ist. Sie können es verwerfen, aber nicht ungesendet machen.

Rechnen Sie einmal mit. Ein typischer Gameserver hängt an 1 Gbit/s, das sind 125 Megabyte pro Sekunde, und die Leitung ist voll, sobald jemand mehr schickt. Die zweite Größe ist die Paketrate, und bei Arma 3 schlägt sie fast immer zuerst zu. Bei kleinen Paketen von 64 Byte passen in eine Leitung mit 1 Gbit/s rund 1,49 Millionen Pakete pro Sekunde. Ein normaler Serverkernel verarbeitet je nach CPU und Netzwerkkarte einige hunderttausend davon, bevor er anfängt zu verwerfen, und die Arma-3-Simulation hängt zusätzlich an einem einzigen Kern.

Die Zeile mit den 4 Mbit/s ist die unangenehmste. Ein Angriff muss bei Arma 3 nicht groß sein, um zu wirken: Er muss nur genug Pakete an den richtigen Port schicken. Betreiber erleben das als "die Auslastung war doch gar nicht hoch, trotzdem war alles weg". Umgekehrt gilt für volumetrische Angriffe die einfache Physik: Bei 473,4 Gbit/s ist jede lokale Einstellung bedeutungslos, weil die Pakete Ihrer Spieler schon vorher nicht mehr durchkommen. Volumetrische Angriffe müssen im Netz vor dem Server enden.

Was KernelHost dagegen stellt

Der Dauerschutz, der auf jedem Server inklusive ist

Der DDoS-Schutz von KernelHost ist zweistufig aufgebaut und dauerhaft aktiv, ohne dass Sie etwas einschalten, bestellen oder konfigurieren müssen:

• Stufe 1: 17 Tbps Mitigationskapazität im globalen Scrubbing-Netzwerk. Volumetrische Angriffe werden nah an ihrer Quelle bereinigt, bevor sie das Rechenzentrum erreichen.
• Stufe 2: Arbor-Echtzeitfilterung mit 3,2 Tbps in Frankfurt am Main. Direkt vor dem Server werden protokollspezifische Muster erkannt und verworfen, Paket für Paket.

Zwei Eigenschaften sind entscheidend. Der Schutz läuft permanent und muss nicht erst auf einen Angriff reagieren, es gibt also keine Minuten am Anfang, in denen der Server weg ist. Und es wird kein Nullrouting eingesetzt: Ihre IP-Adresse bleibt im Netz, verworfen werden nur die schädlichen Pakete. Wer die IP-Adresse aus dem Netz nimmt, erreicht für Sie dasselbe Ergebnis wie der Angreifer. Welche Spiele und Protokolle abgedeckt sind, listet Gameserver-DDoS-Schutz in Echtzeit.

Advanced DDoS Protection für dauerhaft beschossene Projekte

Manche Projekte werden nicht gelegentlich, sondern gezielt und über Wochen angegriffen. Ein Life-Server mit fester Spielerschaft und einer Konkurrenzszene ist dafür der Regelfall, nicht die Ausnahme. Dafür gibt es die Advanced DDoS Protection ab 50,00 EUR im Monat, PrePaid, ohne Mindestlaufzeit und ohne Einrichtungsgebühr. Der Unterschied liegt nicht in mehr Kapazität, sondern in der Kontrolle:

• Dedizierte Schutz-IP aus dem Frankfurter Kern, auf die Ihr Server im eigenen Netz umgestellt wird. Auf Ihrer Seite ist kein Umbau nötig.
• Selbst verwaltbare Schutzregeln je Port und Protokoll im Kundenbereich: Sie stellen getrennt ein, was auf 2302 UDP erlaubt ist und was auf 2303 UDP, und können den Query-Port damit deutlich enger fahren als den Spielport.
• Änderungen greifen in Echtzeit, Sie können also während eines laufenden Angriffs nachjustieren, statt auf ein Wartungsfenster zu warten.
• Schutzprofil passend zum jeweiligen Spiel, ebenso für modifizierte und eigene Anwendungen auf beliebigen TCP- oder UDP-Ports.

Die beiden Stufen im Vergleich

Für die meisten Arma-3-Projekte reicht der inkludierte Dauerschutz zusammen mit einer sauberen Serverkonfiguration. Die Advanced DDoS Protection ist die Antwort darauf, dass jemand es persönlich nimmt.

Häufige Fehler und Lösungen

"Ich habe den Port von 2302 auf 2402 gelegt, der Angriff lief weiter": Das ist zu erwarten. Der Server meldet seinen neuen Port selbst am Steam-Masterserver an, und die Serverliste veröffentlicht ihn sofort wieder. Ein Portwechsel hilft nur gegen jemanden, der eine alte Adresse aus einem alten Screenshot benutzt.

"Ich habe 2303 komplett gesperrt, jetzt findet uns niemand mehr": Genau das passiert. Ohne Antwort auf dem Steam-Query-Port fehlt der Eintrag im Serverbrowser, und jede Statusseite und jeder Discord-Bot zeigt den Server als offline. Richtig ist eine Ratenbegrenzung je Quelladresse, keine Sperre.

"Im Protokoll steht NetServer::SendMsg: cannot find channel": Diese Meldung kommt, wenn der Server einer Verbindung schreiben will, die es nicht mehr gibt. Sie begleitet im Regelfall abreißende Spielerverbindungen und Leistungseinbrüche (Bohemia führt das unter T83936), nicht zwingend einen Angriff. Prüfen Sie zuerst, ob die Paketrate der Schnittstelle überhaupt auffällig ist.

"Meine iptables-Regeln greifen nicht": Drei Ursachen sind häufig. Die Regeln stehen hinter den UFW-Ketten und werden nie erreicht, sie waren nach dem letzten Neustart weg (dann helfen netfilter-persistent save oder ein Eintrag in /etc/ufw/before.rules), oder der Angriff ist volumetrisch und die Regel arbeitet korrekt an einer Leitung, die schon voll ist. Prüfen Sie mit iptables -L INPUT -n -v, ob die Trefferzähler steigen. Bleiben sie bei null, wird die Regel nicht erreicht.

"BattlEye kickt seit der neuen Firewall alle Spieler": Der Server erreicht arma31.battleye.com nicht mehr. Die ausgehenden Ports 2344 auf TCP und UDP sowie 2345 auf TCP müssen offen bleiben, sonst bricht die Anti-Cheat-Verbindung des Servers weg.

"Mein bisheriger Anbieter hat meine IP-Adresse gesperrt": Das ist Nullrouting. Der Anbieter schützt damit sein eigenes Netz, für Sie ist das Ergebnis identisch mit einem erfolgreichen Angriff, meist noch für Stunden danach. Fragen Sie im Zweifel nach, ob gefiltert oder nullgeroutet wird. Die Antwort entscheidet mehr über Ihre Verfügbarkeit als jede Hardwareangabe.

"Im tcpdump sehe ich nichts Auffälliges": Wenn der Verkehr schon im Netz davor gefiltert wird, kommt auf dem Server erwartungsgemäß nichts an. Das ist der Normalfall bei funktionierender Filterung. Umgekehrt gilt: Ist die Leitung gesättigt, erreicht Sie unter Umständen nicht einmal mehr die SSH-Sitzung, mit der Sie messen wollten. Nutzen Sie dann die VNC-Konsole im Kundenbereich, die unabhängig vom Netzwerk des Gastsystems funktioniert.

Kurz zusammengefasst

• Ein Arma-3-Server braucht nach außen genau drei UDP-Ports: 2302 für Spiel und Sprache, 2303 für die Steam-Query und 2304 für die Anmeldung am Steam-Masterserver. TCP braucht das Spiel nicht.
• Port 2306 UDP trägt BattlEye und die RCon-Schnittstelle und gehört ausschließlich auf Ihre eigenen Admin-Adressen, gesetzt über RConPort und RConIP in beserver_x64.cfg.
• Der Steam-Query-Port 2303 ist der empfindlichste Punkt: Das Steam-Protokoll hat laut US-CERT TA14-017A einen Amplifikationsfaktor von 5,5, und jede Abfrage kostet Rechenzeit auf dem Kern, der die Simulation trägt. Begrenzen statt sperren.
• steamProtocolMaxDataSize so klein halten, wie es die Mod-Liste erlaubt, und MaxCustomFileSize = 0; in der basic.cfg setzen: Beides verkleinert die Datenmenge, die Ihr Server ungefragt ausliefert.
• Bei Arma 3 entscheidet die Paketrate, nicht die Bandbreite. Bohemia dokumentiert seit 2015 unter T83469, dass bereits 4 Mbit/s auf den Query-Port genügten, um einen Server einzufrieren.
• Lokale Maßnahmen enden an der Leitung. Ab 1 Gbit/s Angriffsvolumen oder einigen hunderttausend Paketen pro Sekunde entscheidet ausschließlich die Filterung im Netz vor dem Server.
• Bei KernelHost ist der zweistufige Dauerschutz in jedem Serverpaket ohne Aufpreis enthalten und ab der Bereitstellung aktiv, ohne Nullrouting. Die Advanced DDoS Protection ergänzt ihn ab 50,00 EUR im Monat um eine dedizierte Schutz-IP und selbst verwaltbare Regeln je Port.

Läuft Ihr Projekt bereits bei KernelHost, ist die Filterung aktiv, ohne dass Sie etwas tun müssen. Bemerken Sie trotzdem Auffälligkeiten, eröffnen Sie ein Support-Ticket, damit die Filterregeln für Ihre IP-Adresse nachjustiert werden. Bei einem laufenden Angriff erreichen Sie uns zusätzlich über den WhatsApp-Notfallchat unter +43 650 8209883.