SA-MP- und open.mp-Server vor DDoS-Angriffen schützen

Ein SA-MP- oder open.mp-Projekt wächst meist nach demselben Muster: Die Spielerzahl steigt, der Server rutscht in der Liste nach oben, und wenige Tage später brechen die Verbindungen reihenweise ab. Der längste Teil dieser Anleitung beschreibt, was Sie ohne Zusatzkosten selbst an Ihrem Server ändern können. Danach steht, wo diese Maßnahmen technisch aufhören, und erst dann, was KernelHost dagegenstellt.

Warum ausgerechnet SA-MP und open.mp so häufig getroffen werden

Die Szene ist eng und konkurrierend. Viele Rollenspiel- und Freeroam-Server bewerben sich um dieselbe Spielerschaft, und die Hemmschwelle, einen Konkurrenten für ein paar Stunden aus der Liste zu schießen, ist niedrig. Dazu kommen gebannte Spieler und Erpressungsversuche gegen Projekte mit eigenem Shop.

Technisch macht das Spiel es Angreifern leicht. Der gesamte Spielverkehr läuft über UDP, und UDP kennt keinen Verbindungsaufbau, der den Angreifer etwas kosten würde; Absenderadressen lassen sich zudem fälschen. Der Listeneintrag veröffentlicht Adresse und Port, eine Vorabaufklärung ist also überflüssig. Und weil die meisten Projekte auf einem einzelnen Server laufen, liegen Spielserver, Datenbank, Nutzerpanel und oft der Voice-Server auf derselben Adresse: Ein Treffer legt alles gleichzeitig lahm.

Die Ports und Protokolle, um die es geht

• SA-MP-Server: UDP 7777 in der Voreinstellung, einstellbar über port in der server.cfg.
• open.mp-Server: ebenfalls UDP 7777 in der Voreinstellung, einstellbar über network.port in der config.json.
• Query: derselbe UDP-Port. Es gibt keinen getrennten Abfrageport. Serverbrowser, Statusseiten und Discord-Bots sprechen den Port an, über den auch gespielt wird.
• RCON: ebenfalls derselbe UDP-Port, als eigener Opcode innerhalb des Query-Protokolls, im Klartext.
• Der Listeneintrag geht ausgehend an die jeweilige Serverliste, eingehend muss dafür nichts geöffnet werden.
• Alles Übrige auf derselben Maschine: SSH auf TCP 22, MariaDB oder MySQL auf TCP 3306, das Nutzerpanel auf TCP 80 und 443.

Die Folge: Sie können den Query-Zugang nicht per Firewall vom Spielbetrieb trennen, weil beides auf demselben Port liegt. Wer UDP 7777 sperrt, sperrt seine Spieler aus.

Eine Query-Anfrage beginnt mit elf Byte: vier Byte Kennung, vier Byte Serveradresse, zwei Byte Port, ein Byte Opcode. Der Opcode bestimmt die Antwort: i liefert die Serverinformationen, r die Regeln, c eine kurze Spielerliste, d eine ausführliche Spielerliste mit Name, Punktzahl und Ping je Spieler, p spiegelt vier Byte zur Pingmessung zurück, x ist RCON. Auf einem gut besuchten Server erzeugen elf Byte Anfrage mehrere Kilobyte Antwort. Das macht einen offenen Query-Zugang doppelt interessant: als Ziel und als Verstärker gegen Dritte. Was hinter dem Angriffsmuster steckt, erklärt der Beitrag Was ist ein DDoS-Angriff?.

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

Die folgenden Schritte kosten nichts und wirken gegen die Angriffe, die den Alltag ausmachen: Join-Fluten, Query-Fluten und einzelne Quellen mit hoher Paketrate. Alle Befehle setzen root voraus, sonst stellen Sie sudo voran.

1. Bestandsaufnahme: was lauscht überhaupt?

ss -lnup
ss -lntp

Was auf 127.0.0.1 oder ::1 lauscht, braucht keine Firewall-Regel. Was auf 0.0.0.0 oder [::] steht, ist von außen ansprechbar und muss begründet sein.

2. Alles schließen, was der Spielbetrieb nicht braucht

Ein Paketfilter beseitigt keinen Volumenangriff, verkleinert aber die Angriffsfläche. Eine tragfähige Ausgangskonfiguration mit UFW:

ufw allow 22/tcp comment 'SSH'
ufw allow 7777/udp comment 'SA-MP / open.mp'
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

Die Reihenfolge ist kein Zufall: Die Erlaubnisregeln stehen vor dem Einschalten, sonst sperren Sie sich selbst aus. Details samt Rückweg stehen 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.

Die Datenbank gehört nicht ins offene Netz. Zeigt ss -lntp | grep 3306 ein 0.0.0.0:3306, setzen Sie bind-address = 127.0.0.1 und starten den Dienst neu. Auch den Spielserver binden Sie an eine feste Adresse, in SA-MP über bind, in open.mp über network.bind.

3. Den Query-Zugang entschärfen, ohne die Spieler auszusperren

SA-MP kennt in der server.cfg den Schalter query 0, mit dem der Server auf keine Abfrage mehr antwortet. Das wirkt, hat aber einen hohen Preis: Der Server verschwindet aus dem Browser, Spielerzahl und Regeln sind nicht mehr ablesbar, Statusseiten und Discord-Bots zeigen ihn als offline. Für einen geschlossenen Kreis ist das eine Option, für ein wachsendes Projekt nicht. In open.mp liegt die Umschaltung im Abschnitt network der config.json; prüfen Sie den genauen Schlüsselnamen in Ihrer Version, statt ihn zu raten.

Der realistische Weg ist deshalb begrenzen statt abschalten. Diese Filterregel zeigt live nur die Pakete mit der Query-Kennung:

tcpdump -ni any -c 100 'udp port 7777 and udp[8:4] = 0x53414d50'

Welche Absenderadressen den meisten Verkehr auf den Spielport schicken:

tcpdump -nn -q -c 2000 'udp dst port 7777' 2>/dev/null \
  | awk '{print $3}' | cut -d. -f1-4 | sort | uniq -c | sort -rn | head -20

4. Rate-Limits im Netzwerk-Stack setzen

Mit nftables begrenzen Sie die Paketrate je Absenderadresse. Der folgende Satz legt eine eigene Tabelle an, damit er UFW nicht in die Quere kommt:

nft add table inet gameguard
nft add chain inet gameguard input '{ type filter hook input priority -150 ; policy accept ; }'
nft add rule inet gameguard input udp dport 7777 meter perip '{ ip saddr limit rate over 60/second burst 120 packets }' drop
nft list table inet gameguard

Sinnvoll ist zusätzlich eine Obergrenze für den gesamten Port, damit eine breit verteilte Flut nicht durch die Lücke zwischen vielen Einzelquellen läuft:

nft add rule inet gameguard input udp dport 7777 limit rate over 20000/second burst 5000 packets drop

Mit iptables erreicht das hashlimit-Modul dasselbe:

iptables -N SAMPGUARD
iptables -A INPUT -p udp --dport 7777 -j SAMPGUARD
iptables -A SAMPGUARD -m hashlimit --hashlimit-name samp --hashlimit-mode srcip \
  --hashlimit-above 60/sec --hashlimit-burst 120 --hashlimit-htable-expire 30000 -j DROP

Diese Zahlen sind Startwerte, keine Empfehlung für Ihren Server. Ein einzelner Spieler erzeugt allein durch die Positionssynchronisation einige Dutzend Pakete pro Sekunde; die Taktung steuern Sie in SA-MP über onfoot_rate, incar_rate und weapon_rate. Kritisch wird es, wenn mehrere Spieler hinter derselben Adresse sitzen, etwa im selben Haushalt oder hinter dem Carrier-NAT eines Mobilfunkanbieters. Eine zu enge Grenze wirft genau diese Spieler heraus, und das sieht aus wie ein Angriff. Erst messen, dann setzen, dann die Abbrüche beobachten.

5. Grenzwerte in server.cfg und config.json

Beide Implementierungen bringen eigene Schutzgrenzen mit, die oft auf den Voreinstellungen stehen bleiben. Für SA-MP in der server.cfg:

lanmode 0
query 1
announce 1
rcon 0
conncookies 1
connseedtime 300000
minconnectiontime 1000
messageslimit 500
messageholelimit 3000
ackslimit 3000
playertimeout 10000

Für open.mp stehen dieselben Größen in der config.json:

{
  "network": {
    "port": 7777,
    "bind": "",
    "use_lan_mode": false,
    "cookie_reseed_time": 300000,
    "minimum_connection_time": 1000,
    "messages_limit": 500,
    "message_hole_limit": 3000,
    "acks_limit": 3000,
    "player_timeout": 10000,
    "limits_ban_time": 60000
  },
  "rcon": {
    "enable": false
  }
}

Was diese Werte bewirken:

• Verbindungs-Cookies (conncookies beziehungsweise cookie_reseed_time) verlangen vom Client eine Antwort auf eine Rückfrage, bevor ein Slot belegt wird. Eine gefälschte Absenderadresse bekommt diese Rückfrage nie zu sehen und kann sie folglich nicht beantworten. Das ist die wirksamste eingebaute Bremse gegen Verbindungsfluten, lassen Sie sie eingeschaltet.
• Mindestabstand zwischen Verbindungsversuchen (minconnectiontime beziehungsweise minimum_connection_time, in Millisekunden) verhindert, dass dieselbe Adresse im Sekundentakt neue Verbindungen aufbaut. Gegen Bot-Joins ist das die zweite wichtige Stellschraube.
• Nachrichten-, Lücken- und Bestätigungsgrenzen (messageslimit, messageholelimit, ackslimit) begrenzen, wie viel eine bestehende Verbindung schicken darf. Sie schützen vor manipulierten Clients, nicht vor Volumen.
• Zeitüberschreitung (playertimeout, player_timeout) bestimmt, wie lange eine stille Verbindung einen Slot blockiert. Ein niedriger Wert gibt Plätze bei einer Join-Flut schneller frei, wirft aber Spieler mit schlechter Leitung früher heraus. Die Sperrdauer (limits_ban_time in open.mp) legt fest, wie lange eine auffällige Adresse ausgesperrt bleibt.

Zwei Hinweise: Die config.json muss gültiges JSON bleiben, ein überzähliges Komma verhindert den Start. Und open.mp ergänzt fehlende Vorgaben beim Start selbst, bearbeiten Sie die Datei deshalb bei gestopptem Server.

Zu RCON noch ein Wort: Das Passwort läuft im Klartext über UDP und ist auf dem gesamten Weg mitlesbar. Brauchen Sie RCON nicht, schalten Sie es mit rcon 0 beziehungsweise "enable": false ab, sonst gilt: langes Zufallspasswort und Zugriff nur über ein VPN.

6. Abwehr im Gamemode und in den Plugins

SA-MP ruft OnIncomingConnection auf, bevor ein Spieler-Slot belegt wird. Dort können Sie mitzählen und auffällige Adressen zeitweise sperren:

public OnIncomingConnection(playerid, ip_address[], port)
{
    if (ConnectAttemptsTooHigh(ip_address))
    {
        BlockIpAddress(ip_address, 60000);
    }
    return 1;
}

ConnectAttemptsTooHigh ist bewusst Ihre eigene Zählfunktion: Sinnvolle Schwellen hängen von Ihrer Spielerzahl ab. BlockIpAddress erwartet die Sperrdauer in Millisekunden, UnBlockIpAddress hebt sie vorzeitig auf. Die Sperrliste liegt im Arbeitsspeicher und ist nach einem Neustart leer.

Ergänzend gehören zwei Werkzeuge in jedes Projekt. Das Plugin crashdetect zeigt bei einem Absturz die betroffene Funktion und die Zeile im Gamemode; ohne es sieht ein Laufzeitfehler im eigenen Code von außen aus wie ein Angriff. Ein gepflegtes Anti-Cheat wie Nex-AC deckt Manipulationen auf Client-Seite ab, arbeitet aber ausschließlich an verbundenen Spielern innerhalb der Spiellogik. Eine Flut gefälschter Pakete wird nie zu einem Spieler und läuft daran vorbei. Das sind zwei verschiedene Probleme.

Halten Sie außerdem Includes und Plugins aktuell: Mehrere bekannte SA-MP-Absturzmethoden beruhen auf Werten außerhalb des gültigen Bereichs, die an native Funktionen übergeben werden. Und geben Sie ungeprüfte Spielereingaben nie an SendRconCommand oder an eine Datenbankabfrage weiter.

7. Der Eintrag in der Serverliste und Ihre echte Adresse

Der Listeneintrag macht Sie auffindbar, für Spieler wie für Angreifer. Mit announce 0 verschwinden Sie aus beiden Listen, und damit auch aus dem organischen Zulauf. Das ist eine Abwägung, kein Geheimtipp.

Eine Domain davor hilft nicht: Der Client löst den Namen einmal auf und spricht danach direkt mit der Adresse, und auflösen kann diesen Namen jeder. Prüfen Sie stattdessen, was Ihre Adresse sonst verrät: alte A- und AAAA-Einträge im DNS, das Nutzerpanel auf derselben Maschine, die Statusanzeige eines Discord-Bots, ein offenes Datenbank-Webinterface, 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 Ursprungsadresse. Sonst steht die alte in jeder Scanner-Datenbank, und der Angriff läuft am Schutz vorbei.

8. Whitelist und geschlossener Betrieb

Für den Spielport ist eine Whitelist selten praktikabel, weil Spieler von wechselnden Adressen kommen. Ein Serverpasswort (password in beiden Implementierungen) macht den Server ohne Aufwand zu einem geschlossenen Kreis, während der Listeneintrag bleibt. Für die Verwaltungszugänge ist die Whitelist dagegen Pflicht, also für SSH, Datenbank, Panel und, falls Sie es behalten, RCON:

ufw allow from 203.0.113.10 to any port 22 proto tcp comment 'Admin'
ufw delete allow 22/tcp
ufw status numbered

Bei wechselnder Anschlussadresse ist ein VPN sauberer als eine wachsende Ausnahmeliste.

9. Protokollieren: erst messen, dann handeln

SA-MP schreibt sein Protokoll in die server_log.txt im Serververzeichnis, open.mp in die im Abschnitt logging konfigurierte Datei. Welche Adressen am häufigsten anklopfen:

grep "Incoming connection" server_log.txt \
  | grep -oE '([0-9]{1,3}\.){3}[0-9]{1,3}' \
  | sort | uniq -c | sort -rn | head -20

Eine hohe Zahl angeforderter Verbindungs-Cookies weist auf eine Join-Flut hin:

grep -c "requests connection cookie" server_log.txt

Der aussagekräftigste Wert steht aber nicht im Spielprotokoll, sondern im Kernel. Holt der Serverprozess die Pakete nicht schnell genug aus dem Empfangspuffer, zählt der Kernel die Verluste mit:

nstat -az | grep -E 'Udp(InDatagrams|InErrors|NoPorts|RcvbufErrors)'
ip -s -s link show

Daraus ergibt sich die wichtigste Unterscheidung überhaupt: Steigen die Puffer-Fehler bei niedriger CPU-Last, erreicht Sie mehr Verkehr, als der Prozess abarbeiten kann. Läuft dagegen ein Kern auf Anschlag, während der Verkehr normal aussieht, liegt das Problem im Gamemode und nicht im Netz. Wie Sie beide Fälle auseinanderhalten, beschreibt der Beitrag DDoS-Angriff am Server erkennen.

Wo diese Maßnahmen aufhören

Alle bisherigen Schritte greifen erst, wenn die Pakete bereits über Ihre Leitung gelaufen sind: Der Kernel verwirft sie nach der Ankunft. Damit ist eine harte Obergrenze gesetzt, die nichts mit der Qualität Ihrer Regeln zu tun hat.

Ein Anschluss mit 1 Gbit/s nimmt bei kleinstmöglicher Paketgröße rund 1,49 Millionen Pakete pro Sekunde entgegen, mehr passt physikalisch nicht durch. Zum Vergleich zwei Angriffe, die auf KernelHost-Servern gemessen und gefiltert wurden: über 473,4 Gbit/s bei über 41,5 Millionen Paketen pro Sekunde gegen einen Voice-Server auf UDP 9987, und über 112,2 Gbit/s bei über 8,7 Millionen Paketen pro Sekunde gegen einen Gameserver auf UDP 7777. Der erste Fall ist rund das 473-Fache der Bandbreite und etwa das 28-Fache der Paketrate, die eine 1-Gbit/s-Leitung überhaupt aufnehmen kann. Selbst ein perfekter Filter auf dem Server ändert daran nichts, weil die Pakete gar nicht bis zu ihm kommen: Der Anschluss davor ist voll, und mit ihm fallen auch die Pakete Ihrer Spieler.

Zwei weitere Grenzen greifen noch früher. Erstens liest der Spielserver den Port in einem einzigen Ausführungsstrang. Eine Query-Flut kann diesen Strang so beschäftigen, dass die Synchronisationspakete echter Spieler im Empfangspuffer verfallen, lange bevor die Leitung gesättigt ist. Der Prozess stürzt dabei nicht ab, er wird nur langsam, und die Spieler sehen Rubberbanding. Zweitens sind Absenderadressen bei UDP fälschbar; Sperren nach Adresse treffen dann Unbeteiligte und den Angreifer gar nicht.

Nüchtern zusammengefasst: Ihre Arbeit auf dem Server entscheidet darüber, ob ein kleiner Angriff durchkommt. Ob ein großer Angriff durchkommt, entscheidet das Netz vor dem Server.

Was KernelHost dagegenstellt

Auf jedem Server enthalten: der zweistufige Dauerschutz

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

• Stufe 1: globales Scrubbing-Netzwerk mit 17 Tbps Mitigationskapazität. Volumetrische Angriffe werden nah an ihrer Quelle abgefangen und 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 dabei 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, nur die schädlichen Pakete fallen weg, während die Verbindungen echter Spieler weiterlaufen. Und er kostet nichts extra, sondern ist 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 auch auf UDP 7777. Betrieben wird das im Rechenzentrum maincubes in Frankfurt am Main, Deutschland, durch die KernelHost GmbH mit Sitz in Wien, Österreich. Welche Spiele und Protokolle eigene Profile haben, zeigt der Beitrag Gameserver-DDoS-Schutz in Echtzeit.

Für dauerhaft beschossene Projekte: Advanced DDoS Protection

Manche Projekte werden nicht gelegentlich getroffen, sondern über Wochen gezielt. Für diesen Fall gibt es die Advanced DDoS Protection ab 50,00 EUR im Monat, PrePaid und ohne Mindestlaufzeit. Sie ergänzt den Dauerschutz um drei Dinge:

• 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. Änderungen greifen in Echtzeit, ohne Ticket und ohne Wartezeit, Sie können also mitten in einem Angriff nachjustieren.
• Ein Schutzprofil passend zum Spiel. Fertige Profile für über 40 Spiele, Dienste und Protokolle, darunter SA-MP und open.mp sowie eigene TCP- und UDP-Anwendungen. Auch Nutzerpanel, Voice-Server und VPN passen hinter dieselbe Schutzadresse.

Die beiden Stufen im Vergleich

Häufige Fehler und Lösungen

"Der Server ist weg, also ist es ein Angriff." Prüfen Sie zuerst, ob der Prozess noch läuft. Ein Laufzeitfehler im Gamemode sieht von außen identisch aus. Mit crashdetect steht die Ursache im Protokoll, ohne es raten Sie.

"Wir haben den Query-Port gesperrt." Es gibt keinen getrennten Query-Port. Wer UDP 7777 sperrt, sperrt den Spielbetrieb. Gemeint ist entweder query 0 (Server verschwindet aus der Liste) oder eine Ratenbegrenzung auf demselben Port.

"Wir haben die IP gewechselt und sind wieder online." Ohne das Leck zu schließen ist die neue Adresse binnen Stunden wieder öffentlich. Alte DNS-Einträge, das Panel auf derselben Maschine und die Statusanzeige eines Discord-Bots verraten sie zuverlässig.

"Wir haben ein Rate-Limit von 20 Paketen pro Sekunde je Adresse gesetzt." Das ist zu eng. Schon ein einzelner Spieler liegt darüber, und mehrere Spieler hinter einer NAT-Adresse teilen sich dasselbe Kontingent. Sie werfen damit Ihre eigenen Spieler heraus.

"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 schalten dort ufw disable. Ein IPMI oder iDRAC gibt es bei KVM-Rootservern und Dedicated Servern nicht, der Weg führt über die VNC-Konsole.

"Das RCON-Passwort steht im Team-Chat." RCON läuft im Klartext über UDP und ist auf dem gesamten Weg mitlesbar. Wenn Sie es nicht brauchen, schalten Sie es ab, sonst gilt: langes Zufallspasswort und Zugriff nur über ein VPN.

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

Wenn Sie gerade angegriffen werden

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-Notfall-Chat unter +43 650 8209883.