MTA:SA-Server vor DDoS-Angriffen schützen

Ein Server für Multi Theft Auto: San Andreas verhält sich unter einem DDoS-Angriff anders als jedes andere GTA-Multiplayer-Projekt, weil er drei getrennte Netzwerkdienste gleichzeitig anbietet: den Spielverkehr auf 22003 UDP, einen vollwertigen HTTP-Server auf 22005 TCP und die ASE-Abfrage auf 22126 UDP. Jeder dieser drei Dienste lässt sich einzeln angreifen, und jeder fällt anders aus. Dieser Beitrag zeigt zuerst, was Sie ohne Zusatzkosten selbst absichern können, danach, wo diese Maßnahmen an der Physik der Leitung enden, und zum Schluss, was ein wirksamer DDoS-Schutz für MTA:SA im Netz vor dem Server leisten muss.

Wenn der Angriff gerade läuft, ist die wichtigste Frage, welcher der drei Dienste getroffen wird. Bleiben Spieler verbunden, laden aber beim Beitritt keine Ressourcen mehr, trifft es den HTTP-Server auf 22005. Verschwindet der Server aus dem Browser, während die verbundenen Spieler normal weiterspielen, trifft es die ASE-Abfrage auf 22126. Brechen alle Verbindungen gleichzeitig ab, ist entweder 22003 das Ziel oder die Leitung ist voll. Alle Angaben beziehen sich auf einen MTA-Server 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.

Warum MTA:SA-Server so oft Ziel von DDoS-Angriffen werden

MTA:SA-Projekte sind bequeme Ziele, weil sie ihre Adresse selbst veröffentlichen müssen. Ein Server erscheint nur dann im Spielbrowser, wenn er sich bei der Masterserverliste anmeldet und danach Abfragen von außen beantwortet. Die Liste enthält IP-Adresse und Port im Klartext, eine Vorabaufklärung ist für einen Angreifer also überflüssig.

Dazu kommt die Szene selbst. Deutschsprachige und brasilianische Rollenspiel-Server, Drift-Server und DayZ-Umsetzungen konkurrieren um dieselbe Spielerschaft, und ein Ausfall zur Hauptspielzeit ist maximal sichtbar. Ein gebannter Spieler, ein zerstrittenes Team oder ein Konkurrenzprojekt braucht weder Können noch nennenswertes Geld, um einen Abend unbrauchbar zu machen. Buchbare Angriffsdienste, in der Szene Booter oder Stresser genannt, verkaufen für wenige Euro im Monat genau zwei Ergebnisse: den MTA-Server für Minuten offline zu nehmen oder ihn mit Lag-Spitzen unspielbar zu machen. Was ein DDoS-Angriff technisch ist und welche Angriffsarten es gibt, erklärt der Beitrag Was ist ein DDoS-Angriff?.

Technisch macht MTA:SA es Angreifern an zwei Stellen leichter als andere Multiplayer-Modifikationen. Erstens liegt die Abfrage auf einem eigenen UDP-Port, der auf ein einziges Byte hin eine mehrere Kilobyte große Antwort schickt. Zweitens gehört zu jedem MTA-Server ein HTTP-Server, der die clientseitigen Dateien aller Ressourcen ausliefert, und zwar ohne Anmeldung an jeden, der danach fragt.

Die Ports, um die es tatsächlich geht

Ein MTA:SA-Server braucht genau drei Ports: 22003 UDP für das Spiel, 22005 TCP für den internen HTTP-Server und 22126 UDP für die ASE-Abfrage. Der dritte Port ist keine frei wählbare Einstellung, sondern ergibt sich fest aus dem Spielport plus 123. Wer serverport auf 22010 setzt, bekommt die Abfrage auf 22133.

Zwei Feinheiten stehen so in der mitgelieferten mtaserver.conf und werden regelmäßig übersehen. httpport darf denselben Zahlenwert wie serverport haben, weil der eine Port TCP und der andere UDP ist. Und serverip steht auf auto und soll dort bleiben: Ein fest eingetragener Wert bindet den ASE-Socket auf genau diese Adresse und bricht den Listeneintrag, sobald sich die Adresse ändert.

Das ASE-Abfrageprotokoll und warum es ein Verstärker ist

ASE (All-Seeing Eye) ist ein reines UDP-Abfrageprotokoll: Der erste Byte des Pakets bestimmt die Antwort, einen Verbindungsaufbau gibt es nicht. Der MTA-Server kennt fünf Abfragen und beantwortet sie auf 22126:

• s ist die vollständige ASE-Abfrage. Die Antwort beginnt mit EYE1 und enthält Servername, Spieltyp, Kartenname, Version, Passwortstatus, Spielerzahl, die vollständige Liste aller per setRuleValue gesetzten Regeln und danach jeden verbundenen Spieler mit Name, Punktzahl und Ping. Diese Antwort hat keine Größenbegrenzung.
• b und r sind die schlankeren Abfragen für den Spielbrowser. Die Antwort beginnt mit EYE2 und wird im Quelltext bei 1.340 Byte abgeschnitten, um Fragmentierung zu vermeiden.
• x liefert eine verkürzte Statusmeldung, v nur die ASE-Versionskennung.

Daraus ergibt sich das Problem. Eine Anfrage besteht aus einem einzigen Nutzlast-Byte, auf dem Draht also aus 29 Byte (20 Byte IP-Kopf, 8 Byte UDP-Kopf, 1 Byte Nutzlast). Eine Antwort von 1.400 Byte Nutzlast sind auf dem Draht 1.428 Byte. Das Verhältnis beträgt rund das 49-Fache, und weil UDP keinen Verbindungsaufbau kennt, lässt sich die Absenderadresse fälschen. Ein Angreifer kann Ihren Server also als Verstärker gegen ein drittes Ziel benutzen, ohne Ihr Spiel je zu betreten. Bei der Vollabfrage wächst der Faktor mit der Spielerzahl und mit jeder Regel, die Ihr Gamemode setzt.

MTA bringt dagegen zwei eingebaute Bremsen mit, die man kennen sollte, weil sie erklären, warum manche Fluten wirken und andere nicht. Der Server beantwortet je Quelladresse höchstens fünf Abfragen in sechs Sekunden und ignoriert die Adresse danach sieben Sekunden lang. Außerdem hält er die Antworten zehn Sekunden lang zwischengespeichert, statt sie je Anfrage neu zusammenzubauen. Die Zählung je Quelladresse wird aber vollständig übersprungen, sobald mehr als 100 verschiedene Absenderadressen gleichzeitig in der Liste stehen. Genau das ist bei einer verteilten Flut aus einem Botnetz oder mit gefälschten Absendern der Normalfall, und deshalb hilft die eingebaute Bremse gegen einen ernsthaften Angriff nicht.

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

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

1. Bestandsaufnahme: was lauscht überhaupt?

Sehen Sie zuerst nach, was Ihr Server nach außen anbietet. Nicht raten, nachsehen:

ss -lntup

Erwartbar sind drei Zeilen des MTA-Prozesses: 0.0.0.0:22003 auf UDP, 0.0.0.0:22005 auf TCP und 0.0.0.0:22126 auf UDP. Taucht dort zusätzlich eine Datenbank auf 0.0.0.0:3306, ein Webserver oder ein vergessener Voice-Dienst auf, gehört das abgestellt. Die Sicht des Angreifers liefert ein Portscan von außen:

nmap -Pn -sU -p 22003,22126 IHRE.SERVER.IP.ADRESSE
nmap -Pn -p 22005 IHRE.SERVER.IP.ADRESSE

Der Server bringt dafür auch einen eigenen Konsolenbefehl mit. In der Serverkonsole prüft openports, ob alle drei Ports von außen erreichbar sind.

2. Nur die drei Ports offen lassen, die MTA wirklich braucht

Mit UFW sieht eine tragfähige Ausgangskonfiguration so aus, und zwar genau in dieser Reihenfolge, damit Sie sich nicht selbst aussperren:

ufw allow 22/tcp comment 'SSH'
ufw allow 22003/udp comment 'MTA Spiel'
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

Die vollständige Anleitung samt Rettungsweg steht im Beitrag UFW-Firewall einrichten. Bei KVM-Rootservern und Dedicated Servern von KernelHost kommen Sie im Notfall über die VNC-Konsole im Kundenbereich auf das System, auch wenn die Leitung gesättigt ist.

Die Datenbank gehört nicht ins offene Netz. Zeigt ss -lntp | grep 3306 ein 0.0.0.0:3306, setzen Sie in /etc/mysql/mariadb.conf.d/50-server.cnf die Zeile bind-address = 127.0.0.1 und starten den Dienst neu.

3. Den ASE-Port begrenzen, ohne aus der Serverliste zu fliegen

Im Unterschied zu SA-MP liegt die Abfrage bei MTA:SA auf einem eigenen Port, Sie können sie also unabhängig vom Spielbetrieb begrenzen. Das ist der größte praktische Vorteil dieser Architektur: Eine Regel auf 22126 wirft keinen einzigen Spieler heraus.

Mit nftables in einer eigenen Tabelle, damit der Regelsatz UFW nicht in die Quere kommt:

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

Die erste Regel begrenzt jede einzelne Quelladresse, die zweite den gesamten Port. Beide zusammen sind wichtig: Eine verteilte Flut läuft durch die Lücke zwischen vielen Einzelquellen, wenn nur je Adresse begrenzt wird. Die Werte sind eng gewählt, und das ist hier vertretbar, weil ein echter Serverbrowser Ihren Server nur alle paar Sekunden abfragt. Mit iptables erreicht das hashlimit-Modul dasselbe:

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

Der Versuch, den Port ganz zu schließen, ist eine Abwägung und kein Geheimtipp: Ohne ASE verschwindet Ihr Server aus dem Spielbrowser und damit aus dem organischen Zulauf. Wenn Sie es trotzdem wollen, reicht <ase>0</ase> nicht aus. Im Quelltext hängt die Port-Freigabe an der Oder-Verknüpfung von Internet-Modus und LAN-Modus, der Socket bleibt bei <ase>0</ase> also weiter offen, solange <donotbroadcastlan>0</donotbroadcastlan> steht. Wer den Port wirklich schließen will, setzt beides:

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

Der ehrlichere Weg für ein wachsendes Projekt ist: Port offen lassen, Rate begrenzen, und den Verstärkungseffekt dadurch klein halten, dass Ihr Gamemode keine unnötigen Regeln per setRuleValue veröffentlicht. Jede Regel steht in der Vollabfrage und vergrößert die Antwort.

4. Den internen HTTP-Server entlasten

Der HTTP-Server auf 22005 ist bei MTA:SA eine eigene Angriffsfläche, weil jeder beitretende Spieler dort sämtliche clientseitigen Dateien aller laufenden Ressourcen herunterlädt. Bei einem Rollenspiel-Projekt mit eigenen Modellen sind das schnell mehrere hundert Megabyte, verteilt auf hunderte Einzeldateien. Der eingebaute Server ist bewusst schlicht gehalten: keine Komprimierung, ein festes Kontingent an Arbeitssträngen. Ein paar Dutzend gleichzeitige Abrufe reichen, damit echte Spieler minutenlang im Ladebildschirm hängen.

Die wirksamste Maßnahme ist, die Downloads ganz aus dem Spielserver herauszunehmen. MTA legt die auszuliefernden Dateien dafür selbst bereit, unter mods/deathmatch/resource-cache/http-client-files. Diesen Ordner geben Sie über nginx oder lighttpd aus und tragen die Adresse in die mtaserver.conf ein:

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

Das bringt zwei Dinge auf einmal. Die Downloads laufen über einen Webserver, der dafür gebaut ist, und sie laufen nicht mehr über die Adresse Ihres Spielservers. Liegt der Webserver auf einer anderen Maschine oder hinter einem Content Delivery Network, trifft eine Flut gegen die Downloads nicht mehr den Spielbetrieb. Wichtig: Ist die externe Adresse falsch oder nicht erreichbar, schaltet MTA stillschweigend auf den internen Server zurück.

Bleibt der interne Server im Einsatz, nutzen Sie seine eigenen Grenzen. In der mtaserver.conf:

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

httpmaxconnectionsperclient begrenzt die gleichzeitigen Verbindungen je Client auf 5 im zulässigen Bereich 1 bis 8. httpdosthreshold begrenzt, wie viele Verbindungen eine einzelne IP-Adresse in kurzer Zeit aufbauen darf, Voreinstellung 20. http_dos_exclude nimmt einzelne Adressen davon aus, etwa Ihre eigene Statusseite. httpthreadcount bestimmt die Zahl der Arbeitsstränge, Voreinstellung 8 im Bereich 1 bis 20. Ein höherer Wert hilft bei vielen kleinen Dateien, kostet aber Rechenzeit, die dem Spielbetrieb fehlt.

Denken Sie außerdem daran, was auf demselben Port noch ausgeliefert wird. Die Ressourcen webadmin und resourcebrowser sind in der mitgelieferten Konfiguration gestartet und über 22005 im Browser erreichbar. Eine Verwaltungsoberfläche gehört nicht ungeschützt ins offene Netz: Vergeben Sie in der acl.xml saubere Rechte, setzen Sie ein eigenes Konto mit langem Zufallspasswort, und stoppen Sie die Ressource, wenn Sie sie nicht brauchen.

5. Die eingebauten Grenzen in mtaserver.conf nutzen

MTA bringt mehr Schutzgrenzen mit, als die meisten Projekte nutzen. Einige stehen fest im Quelltext, andere in der mtaserver.conf. Diese Tabelle fasst die zusammen, die bei einem Angriff eine Rolle spielen:

Drei Einstellungen lohnen eine bewusste Entscheidung. maxplayers steht auf 32 und sollte der Realität entsprechen: Jeder zusätzliche Slot vergrößert die Vollabfrage und erhöht die Zahl der Verbindungen, die ein Angreifer belegen kann. bandwidth_reduction steht auf medium, der Wert maximum senkt die ausgehende Last spürbar, kostet aber Synchronisationsgenauigkeit. Und <password></password> macht Ihren Server ohne Aufwand zu einem geschlossenen Kreis, während der Listeneintrag bestehen bleibt: die schnellste Notbremse bei einer laufenden Beitritts-Flut.

6. Beitritts-Fluten und Ereignis-Fluten auseinanderhalten

Zwei Angriffsmuster zielen nicht auf die Leitung, sondern auf die Spiellogik, und sie werden regelmäßig verwechselt.

Eine Beitritts-Flut baut in schneller Folge echte Verbindungen auf, bis alle Slots belegt sind oder der Server mit dem Aufbau nicht mehr nachkommt. MTA begrenzt das von sich aus auf vier Verbindungen je Quelladresse in 30 Sekunden und ignoriert die Adresse danach 30 Sekunden lang. Was die Bremse gerade tut, zeigt der Konsolenbefehl debugjoinflood. Die Grenze greift je Adresse, ein Botnetz mit tausend Adressen läuft daran vorbei. Dagegen helfen ein Serverpasswort, eine Whitelist im Gamemode und eine Ratenbegrenzung auf 22003.

Eine Ereignis-Flut kommt dagegen von bereits verbundenen Spielern: Ein manipulierter Client setzt triggerServerEvent in einer Schleife ab, bis der Server die Rechenzeit nicht mehr aufbringt. MTA erlaubt dafür ab Werk 100 Ereignisse je Spieler und Sekunde und wirft darüber hinaus mit einer Meldung über Ereignis-Fluten. Wenn Ihr Gamemode viele kleine Ereignisse nutzt, prüfen Sie den Wert, bevor Sie ihn senken: Zu eng gesetzt, wirft er eigene Spieler heraus.

Unabhängig davon gilt serverseitig dieselbe Regel wie überall: Verlassen Sie sich nie auf Werte, die der Client mitschickt, ermitteln Sie den Spieler aus dem Absender des Ereignisses, und begrenzen Sie alles, was eine Datenbankabfrage auslöst. Ein einzelnes ungeprüftes Ereignis, das eine Abfrage startet, reicht, um einen Server ohne jeden Netzwerkangriff zum Stehen zu bringen.

7. Serverliste, IP-Adresse und was sie sonst noch verrät

Ihre IP-Adresse lässt sich nicht geheim halten. Jeder Spieler, der einmal verbunden war, kennt sie, und der Eintrag in der Masterserverliste veröffentlicht sie ohnehin. Eine Domain davor hilft nicht: Der Client löst den Namen einmal auf und spricht danach direkt mit der Adresse.

Prüfen Sie stattdessen, was Ihre Adresse sonst noch verrät. Typische Lecks bei MTA-Projekten sind alte A- und AAAA-Einträge im DNS, die Projektseite auf derselben Maschine, ein Discord-Bot mit Statusanzeige, der die ASE-Abfrage öffentlich ausliest, TLS-Zertifikate mit alten Hostnamen und Forenbeiträge aus der Anfangszeit. Daraus folgt eine Regel, die viele Projekte zu spät lernen: Wenn Sie auf eine geschützte Adresse umziehen, wechseln Sie gleichzeitig die alte Adresse. Bleibt sie bestehen, steht sie in jeder Scanner-Datenbank, und der Angriff läuft am Schutz vorbei.

Zwei Einträge in der mtaserver.conf betreffen die Sichtbarkeit direkt. <serverip>auto</serverip> bleibt auf auto, außer Sie wissen genau, warum nicht. Und <owner_email_address> gehört ausgefüllt: Fehlt der Eintrag oder ist er falsch, kann das die Sichtbarkeit in der Masterserverliste beeinträchtigen.

8. Protokollieren, damit Sie im Ernstfall Daten haben

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 Freitagabend. Mit apt-get install -y vnstat sysstat läuft die Messung dauerhaft mit.

Während eines Vorfalls trennen Sie zuerst die drei Ports voneinander. Diese vier Befehle genügen:

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

Die Auswertung ist einfacher, als sie aussieht. Steigen die Puffer-Fehler bei niedriger CPU-Last, erreicht Sie mehr Verkehr, als der Prozess abarbeiten kann. Läuft ein Kern auf Anschlag, während der Verkehr normal aussieht, liegt das Problem im Gamemode und nicht im Netz. Zeigt der Mitschnitt auf 22126 viele Pakete mit einem einzigen Byte Nutzlast, ist es eine ASE-Flut. Steht die Zahl der offenen Verbindungen auf 22005 dauerhaft im vierstelligen Bereich, trifft es den HTTP-Server. Bei tcpdump gilt immer: mit -c begrenzen, ein Mitschnitt unter Volllast belastet einen ohnehin überlasteten Server zusätzlich. Wie Sie die Werte im Einzelnen auswerten, beschreibt der Beitrag DDoS-Angriff am Server erkennen.

Das Serverprotokoll selbst liegt unter logs/server.log, das Skriptprotokoll unter logs/scripts.log. Beide Pfade stehen in der mtaserver.conf und lassen sich umlegen.

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 entspricht 125 Megabyte pro Sekunde, und bei 64 Byte großen Paketen rund 1,49 Millionen Paketen pro Sekunde. Angriffe gegen Gameserver-Projekte dieser Größenordnung liegen üblicherweise zwischen 5 und 50 Gbit/s, also beim Fünf- bis Fünfzigfachen Ihrer Leitung. Ob Ihre nftables-Regel dahinter gut ist, spielt dann keine Rolle mehr, denn die Pakete Ihrer Spieler kommen schon vorher nicht durch.

Die Paketrate schlägt dabei oft früher zu als die Bandbreite. Ein normaler Serverkernel verarbeitet je nach CPU und Netzwerkkarte einige hunderttausend Pakete pro Sekunde, bevor er anfängt zu verwerfen. Ein Angriff, der Ihre Leitung nicht einmal zu einem Drittel füllt, kann Ihren Server also lahmlegen, weil die Rechenzeit für das Verwerfen draufgeht. Betreiber erleben das als "die Auslastung war doch gar nicht hoch, trotzdem war alles weg".

Bei MTA:SA kommt eine dritte Grenze dazu, und sie greift am frühesten. Der Server liest die Netzwerkports in einem einzigen Arbeitsablauf. Eine Abfrage-Flut auf 22126 beschäftigt diesen Ablauf so, dass die Synchronisationspakete echter Spieler im Empfangspuffer verfallen, lange bevor die Leitung voll ist. Der Prozess stürzt dabei nicht ab, er wird nur langsam, und die Spieler sehen Gummiband-Effekte. Dasselbe gilt für den HTTP-Server: Er teilt sich die Rechenzeit mit dem Spielbetrieb.

Zur Einordnung, welche Größenordnungen real vorkommen: Auf KernelHost-Servern wurden unter anderem ein Angriff mit über 473,4 Gbit/s bei über 41,5 Millionen Paketen pro Sekunde auf einen Voice-Server und ein UDP-Flood mit über 112,2 Gbit/s bei über 8,7 Millionen Paketen pro Sekunde auf einen Gameserver gefiltert. Der erste Fall ist rund das 473-Fache der Bandbreite und etwa das 28-Fache der Paketrate, die eine Leitung mit 1 Gbit/s überhaupt aufnehmen kann. Dafür gibt es keine lokale Einstellung. Volumetrische Angriffe müssen im Netz vor dem Server enden.

Was KernelHost dagegenstellt

Der Dauerschutz, der auf jedem Server inklusive ist

Jeder Server bei KernelHost steht hinter einer permanent aktiven, zweistufigen Filterung:

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

Drei Eigenschaften sind entscheidend. Der Schutz ist dauerhaft aktiv, es gibt also keine Erkennungsphase, in der Ihr Server offline geht. Es wird kein Nullrouting eingesetzt: Die angegriffene Adresse bleibt im Netz, verworfen werden nur die schädlichen Pakete, während die Verbindungen echter Spieler weiterlaufen. Und er kostet nichts extra, sondern ist ab der Bereitstellung in jedem Serverpaket enthalten, vom KVM-Rootserver über den Gameserver bis zum Dedicated Server. Gefiltert wird auf Layer 3, 4 und 7 auf jedem TCP- oder UDP-Port, also auf 22003 UDP, 22005 TCP und 22126 UDP gleichzeitig. Betrieben wird das im Rechenzentrum maincubes in Frankfurt am Main, Deutschland. Welche Spiele und Protokolle eigene Profile haben, zeigt der Beitrag Gameserver-DDoS-Schutz in Echtzeit.

Advanced DDoS Protection für dauerhaft beschossene Projekte

Manche Projekte werden nicht gelegentlich getroffen, sondern über Wochen gezielt. Für diesen Fall gibt es die Advanced DDoS Protection ab 50,00 € im Monat, PrePaid und ohne Mindestlaufzeit. Der Unterschied liegt nicht in mehr Kapazität, sondern in der Kontrolle:

• Eine dedizierte Schutz-IP aus dem Frankfurter Kern. Ihr Server wird innerhalb des KernelHost-Netzes darauf umgestellt, Sie bauen auf Ihrer Seite nichts um.
• Selbst verwaltbare Schutzregeln je Port und Protokoll im Kundenbereich. Genau das ist bei MTA:SA der Punkt: Sie stellen für 22003 UDP, 22005 TCP und 22126 UDP getrennte Regeln ein, statt drei sehr unterschiedliche Dienste über einen Kamm zu scheren.
• Änderungen greifen in Echtzeit, ohne Ticket und ohne Wartezeit. Sie können also mitten in einem laufenden Angriff nachjustieren.
• Ein Schutzprofil passend zum Spiel. Multi Theft Auto ist als eigenes Profil vorhanden, ebenso Webserver, Voice-Server und eigene TCP- oder UDP-Anwendungen, die hinter dieselbe Schutzadresse passen.

Die beiden Stufen im Vergleich

Für die meisten MTA:SA-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 22126 gesperrt, der Server steht trotzdem in keiner Liste, aber es kommen weiter Abfragen an": Dann ist der Socket noch offen. <ase>0</ase> allein schließt den Port nicht, solange <donotbroadcastlan>0</donotbroadcastlan> gesetzt ist. Prüfen Sie mit ss -lnup | grep 22126, ob wirklich nichts mehr lauscht.

"Spieler hängen im Ladebildschirm, das Spiel selbst läuft normal": Das ist kein Angriff auf 22003, sondern der HTTP-Server auf 22005 am Limit. Lagern Sie die Downloads über httpdownloadurl aus und prüfen Sie httpmaxconnectionsperclient und httpthreadcount.

"Der Server ist aus dem Browser verschwunden, die Spieler drauf merken nichts": Dann trifft es ausschließlich 22126. Für die verbundenen Spieler ist das folgenlos, für den Zulauf neuer Spieler nicht. Eine Ratenbegrenzung auf diesen einen Port ist die richtige Antwort, nicht eine auf den Spielport.

"Wir haben die IP-Adresse gewechselt und waren zwei Stunden später wieder offline": Der Angreifer hat die neue Adresse aus derselben Quelle wie die alte, meist dem Listeneintrag, einem Discord-Bot mit Statusabfrage oder einem alten DNS-Eintrag. Ein Adresswechsel ist Zeitgewinn, keine Lösung.

"Wir haben ein Rate-Limit von 20 Paketen pro Sekunde je Adresse auf 22003 gesetzt": Das ist zu eng. Schon ein einzelner Spieler liegt bei aktiver Synchronisation darüber, und mehrere Spieler hinter derselben NAT-Adresse teilen sich dasselbe Kontingent. Sie werfen damit Ihre eigenen Spieler heraus. Auf 22126 sind enge Werte dagegen unproblematisch.

"Wir haben uns per Firewall ausgesperrt": Ein Neustart hilft nicht, weil UFW seine Regeln beim Hochfahren wiederherstellt. Bei KernelHost öffnen Sie die VNC-Konsole im Kundenbereich und führen dort ufw disable aus. Die VNC-Konsole arbeitet unabhängig vom Netzwerk des Gastsystems.

"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.

"Wir warten den Angriff einfach ab": Angriffe, die wirken, werden wiederholt. Dokumentieren Sie Zeitpunkt mit Zeitzone, Dauer, Spitzenwerte und den betroffenen Port. Genau diese Angaben braucht auch ein Support-Ticket, damit die Filterung gezielt nachgezogen wird.

Kurz zusammengefasst

• Ein MTA:SA-Server braucht genau drei Ports: 22003 UDP für das Spiel, 22005 TCP für den internen HTTP-Server und 22126 UDP für die ASE-Abfrage. Der dritte ergibt sich fest aus dem Spielport plus 123.
• Die ASE-Abfrage liegt auf einem eigenen Port und lässt sich deshalb begrenzen, ohne einen einzigen Spieler auszusperren. Das ist der wichtigste Unterschied zu SA-MP, wo Spiel und Abfrage denselben Port teilen.
• Ein einziges Anfrage-Byte auf 22126 erzeugt eine Antwort von bis zu mehreren Kilobyte, und die Absenderadresse ist fälschbar. Ein ungebremster ASE-Port ist damit Ziel und Verstärker zugleich.
• Die eingebauten Bremsen von MTA wirken je Quelladresse: fünf Abfragen in sechs Sekunden, vier Beitritte in 30 Sekunden. Bei mehr als 100 gleichzeitigen Quelladressen wird die Abfrage-Zählung übersprungen, eine verteilte Flut läuft also durch.
• Der interne HTTP-Server auf 22005 ist eine eigene Angriffsfläche. Wer die Downloads über httpdownloadurl auf einen externen Webserver auslagert, nimmt sie aus dem Spielbetrieb heraus.
• Alles, was auf dem Server läuft, entscheidet nur über kleine Angriffe. Bei 1 Gbit/s ist bei rund 1,49 Millionen Paketen pro Sekunde Schluss, unabhängig von der Qualität Ihrer Regeln.
• Der zweistufige Dauerschutz bei KernelHost ist in jedem Serverpaket ohne Aufpreis enthalten und arbeitet ohne Nullrouting. Wer die Regeln je Port selbst steuern will, nimmt die Advanced DDoS Protection ab 50,00 € im Monat dazu.

Läuft Ihr Projekt bereits bei KernelHost, ist die Filterung permanent aktiv, Sie müssen nichts einschalten. Bemerken Sie dennoch Auffälligkeiten, eröffnen Sie ein Support-Ticket mit Zeitraum, Port und beobachtetem Verhalten, damit die Regeln für Ihre Adresse nachjustiert werden. Bei einem laufenden Angriff erreichen Sie uns zusätzlich über den WhatsApp-Notfallchat unter +43 650 8209883. Hosten Sie noch woanders und werden regelmäßig getroffen, ist der Umzug nach Frankfurt am Main die kürzere Lösung: Weitere Schritte für den akuten Fall stehen im Beitrag Schwerer DDoS-Angriff: was tun?.