Garry's Mod Server vor DDoS-Angriffen schützen

Ein Garry's-Mod-Server, der abends um acht für drei Minuten verschwindet und danach wiederkommt, hat selten ein Hardwareproblem. In den allermeisten Fällen läuft ein Angriff, und er läuft genau dann, wenn die meisten Spieler verbunden sind. DDoS-Schutz für Garry's Mod heißt deshalb zuerst: wissen, welche Pakete überhaupt auf Ihrem Server ankommen dürfen. Dieser Beitrag zeigt in dieser Reihenfolge, was Sie in den nächsten zehn Minuten ohne einen Cent selbst absichern können, wo diese Maßnahmen physikalisch aufhören, und was danach im Netz vor dem Server passieren muss.

Alle Angaben beziehen sich auf einen srcds-Server unter Debian 12, Debian 13, Ubuntu 22.04 LTS oder Ubuntu 24.04 LTS. Die Konfigurationsdatei liegt unter garrysmod/cfg/server.cfg, die Befehle sind für root geschrieben, als normaler Benutzer stellen Sie sudo voran. Gemeint ist immer der Betrieb auf einem eigenen Root- oder Dedicated-Server, nicht ein Slot bei einem Gameserver-Anbieter.

Wenn der Angriff gerade läuft: Ändern Sie jetzt nichts an der server.cfg und starten Sie srcds nicht neu. Sichern Sie zuerst die Messwerte (Abschnitt 9), denn nach dem Angriff sind sie weg. Ein Neustart kostet Sie die Zähler und bringt den Server danach in dieselbe Flut zurück.

Warum ein Garry's-Mod-Server DDoS-Schutz braucht

Ein Garry's-Mod-Server veröffentlicht seine IP-Adresse und seinen Port selbst. Das ist kein Versehen, sondern Voraussetzung: Wer nicht im Serverbrowser steht, bekommt keine neuen Spieler. Der Eintrag entsteht, weil der Server sich beim Steam-Master-Server anmeldet und danach jede A2S-Abfrage beantwortet, die von außen kommt. Die Frage lautet also nie, ob ein Angreifer Ihre Adresse findet, sondern nur, was passiert, wenn er darauf schießt.

Dazu kommt die Art der Communities. Garry's Mod wird überwiegend nicht in Runden gespielt, sondern in dauerhaften Welten: Eine DarkRP-Community führt Spielerkonten, Besitz, Jobs und Fortschritt über Monate in einer Datenbank. Ein Ausfall am Freitagabend kostet damit mehr als ein verlorenes Match, er kostet Stammspieler. Genau deshalb sind konkurrierende Communities, gebannte Spieler und gekaufte Server-Booter (Dienste, die gegen wenige Euro im Monat Angriffe auf eine beliebige Adresse auslösen) die drei häufigsten Auslöser. Der Angreifer braucht dafür weder Können noch nennenswertes Geld.

Technisch kommen drei Eigenheiten zusammen. Der Spielverkehr läuft über UDP, und UDP kennt keinen Verbindungsaufbau, den man verlangen könnte: Absenderadressen lassen sich fälschen. Die Serverabfrage liegt auf demselben Port wie das Spiel, eine grobe Sperre trifft also immer beides. Und über allem liegt Lua: Jedes Workshop-Addon bringt eigenen Code in denselben Prozess, und ein einziges ungeschütztes Netzereignis genügt, damit ein einzelner Client den Server ohne jede Bandbreite ausbremst. Was ein DDoS-Angriff grundsätzlich ist, erklärt der Beitrag Was ist ein DDoS-Angriff?.

Die Ports, um die es bei Garry's Mod tatsächlich geht

Ein Garry's-Mod-Server startet standardmäßig auf Port 27015, und zwar auf UDP für das Spiel samt Serverabfrage und auf TCP für RCON. Geändert wird die Nummer beim Start mit -port, bei mehreren Instanzen zählt man hoch (27016, 27017 und so weiter). Ein typischer Startbefehl sieht so aus:

./srcds_run -game garrysmod -console \
  -port 27015 \
  +maxplayers 64 \
  +gamemode darkrp \
  +map rp_downtown_v4c_v2 \
  +sv_setsteamaccount IHR_GSLT_TOKEN \
  +host_workshop_collection 123456789 \
  -authkey IHR_STEAM_WEB_API_KEY

Daraus ergibt sich die gesamte Angriffsfläche. Die folgende Tabelle ist die Grundlage für jede Firewall-Regel weiter unten:

Von diesen acht Einträgen gehört genau einer uneingeschränkt ins offene Netz: 27015/UDP. Alles andere wird entweder auf Ihre eigene Adresse begrenzt, auf 127.0.0.1 gebunden oder gar nicht erst gestartet. Der teuerste Denkfehler in diesem Themenfeld ist die Annahme, es gäbe bei Garry's Mod einen getrennten Query-Port, den man einfach zumachen kann. Den gibt es nicht.

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

Dieser Abschnitt ist der längste, und das mit Absicht. Ein sauber konfigurierter Garry's-Mod-Server hält kleine und mittlere Angriffe aus eigener Kraft aus, unabhängig davon, bei wem er steht. Nichts davon kostet Geld, und das meiste davon ist in einer Viertelstunde erledigt.

1. Bestandsaufnahme: was lauscht überhaupt

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:27015 und [::]:27015 bedeuten "aus dem ganzen Internet erreichbar", 127.0.0.1:3306 bedeutet "nur lokal" und braucht keine Firewall-Regel. Auf einem gewachsenen DarkRP-Server finden sich dort fast immer mehr Dienste als erwartet: MySQL, ein Webserver für FastDL, ein Panel, ein Discord-Bot, ein zweiter Testserver auf 27016 und ein vergessener Voice-Dienst. Die Sicht des Angreifers liefert ein Portscan von außen:

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

2. Nur die Ports offen lassen, die srcds wirklich braucht

Für Garry's Mod genügt eine einzige Freigabe nach außen, dazu SSH und der eingeschränkte RCON-Zugang. Mit UFW sieht das so aus, und zwar genau in dieser Reihenfolge, damit Sie sich nicht selbst aussperren:

ufw allow 22/tcp comment 'SSH'
ufw allow 27015/udp comment 'Garrys Mod Spiel und A2S'
ufw allow from 203.0.113.10 to any port 27015 proto tcp comment '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. SourceTV auf 27020/UDP geben Sie nur frei, wenn Sie wirklich übertragen. Die vollständige Anleitung samt Rettungsweg steht in UFW-Firewall einrichten, ohne sich selbst auszusperren. Falls es doch passiert: KVM-Rootserver und Dedicated Server von KernelHost haben kein IPMI und kein iDRAC, Sie kommen über die VNC-Konsole im Kundenbereich zurück. Diese hängt nicht am Netzwerkstack des Gastsystems, eine Firewall-Regel im Gast kann sie nicht blockieren.

Die Datenbank gehört in keinem Fall ins offene Netz. Prüfen Sie in /etc/mysql/mariadb.conf.d/50-server.cnf, dass dort steht:

bind-address = 127.0.0.1

3. Die A2S-Abfrage begrenzen, ohne aus der Serverliste zu fliegen

Hier liegt der Fehler, der die meisten Garry's-Mod-Server kostet. Weil Spielverkehr und Serverabfrage denselben Port belegen, wirft eine pauschale Sperre oder eine zu enge Ratenbegrenzung auf 27015/UDP die eigenen Spieler heraus und bringt den Angriff selbst zu Ende. Der richtige Ansatzpunkt ist die Unterscheidung zwischen Abfrage- und Spielpaketen.

Die Engine bringt dafür drei Konsolenvariablen mit, die in der server.cfg stehen. Ihre Vorgabewerte sind konservativ, aber sie sind gesetzt:

sv_max_queries_sec 3
sv_max_queries_sec_global 60
sv_max_queries_window 30

sv_max_queries_sec begrenzt die beantworteten Abfragen je Absenderadresse (Vorgabe 3 je Sekunde), sv_max_queries_sec_global deckelt die Summe über alle Adressen (Vorgabe 60 je Sekunde), sv_max_queries_window legt das Mittelungsfenster fest (Vorgabe 30 Sekunden). Diese Werte schützen die CPU davor, sinnlos Antworten zu erzeugen. Sie verhindern nicht, dass die Pakete ankommen, und wer den globalen Wert sehr eng zieht, verschwindet während des Angriffs aus dem Serverbrowser, weil auch die Abfragen der Listenseiten unbeantwortet bleiben.

Eine Ebene tiefer lässt sich der Abfrageverkehr sauber abtrennen. Alle verbindungslosen Pakete der Source-Engine beginnen mit vier gesetzten Byte (0xffffffff), der Verkehr bereits verbundener Spieler hat diesen Kopf nicht. Genau darauf lässt sich mit nftables eine Ratenbegrenzung je Quelladresse legen:

table inet gmod {
    chain input {
        type filter hook input priority -10; policy accept;
        udp dport 27015 @th,64,32 0xffffffff \
            meter a2sflood { ip saddr limit rate over 8/second burst 20 packets } drop
    }
}

Die Datei laden Sie mit nft -f. Die Priorität -10 sorgt dafür, dass die Regel vor der Filterkette von UFW greift, und @th,64,32 liest die ersten vier Byte hinter dem UDP-Kopf. Mit klassischem iptables leistet ein u32-Abgleich dasselbe:

iptables -A INPUT -p udp --dport 27015 \
  -m u32 --u32 "0>>22&0x3C@8=0xFFFFFFFF" \
  -m hashlimit --hashlimit-name gmod_a2s --hashlimit-mode srcip \
  --hashlimit-above 8/sec --hashlimit-burst 20 -j DROP

Ein Punkt, den fast jede Anleitung im Netz unterschlägt: Nicht nur die Serverabfrage ist verbindungslos, sondern auch der Verbindungsaufbau. Ein beitretender Spieler sendet mehrere Pakete mit demselben Kopf, bevor er im Spiel ist. Eine zu enge Grenze sperrt deshalb neue Spieler aus, obwohl der Server erreichbar bleibt. Beginnen Sie großzügig (8 bis 15 Pakete je Sekunde und Adresse) und ziehen Sie die Grenze erst an, wenn Sie über eine Woche Normalbetrieb gemessen haben.

4. RCON absichern oder ganz abschalten

RCON ist bei Source-Servern ein beliebtes Ziel, und zwar aus drei Gründen zugleich. Erstens liegt es auf derselben Portnummer wie das Spiel, nur auf TCP, und ist damit ohne Suche gefunden. Zweitens überträgt das Source-RCON-Protokoll das Passwort im Klartext, ohne TLS und ohne Schlüsselaustausch: Wer den Verkehr mitliest, hat es. Drittens ist der Gewinn maximal, denn wer RCON hat, kann die Karte wechseln, alle Spieler sperren, die Konfiguration ändern und den Server stoppen. Ein Angreifer, der RCON übernimmt, braucht gar keine Bandbreite mehr.

Setzen Sie rcon_password nie leer und nie geraten, ein Wert aus openssl rand -base64 32 genügt. Gegen Anmeldeversuche bringt die Engine eine Bremse mit:

rcon_password "HIER_EIN_LANGES_ZUFALLSPASSWORT"
sv_rcon_minfailures 3
sv_rcon_maxfailures 5
sv_rcon_minfailuretime 30
sv_rcon_banpenalty 1440

Damit wird eine Adresse nach drei Fehlversuchen innerhalb von 30 Sekunden für einen Tag gesperrt. Zwei Warnungen dazu. Erstens sperrt genau dieser Mechanismus auch Ihr eigenes Adminpanel aus, wenn dort ein altes Passwort gespeichert ist: Was Betreiber als "RCON funktioniert plötzlich nicht mehr" melden, ist meistens die eigene Sperre. Zweitens bleibt die Firewall-Einschränkung aus Schritt 2 wirksamer, weil sie den Versuch gar nicht erst bis zur Anwendung durchlässt. Wer RCON nur gelegentlich braucht, lässt den Port ganz zu und arbeitet über eine SSH-Portweiterleitung:

ssh -N -L 27015:127.0.0.1:27015 root@IHRE.SERVER.IP.ADRESSE

5. Lua-Netznachrichten begrenzen, der häufigste hausgemachte Ausfall

Ein erheblicher Teil der als DDoS gemeldeten Garry's-Mod-Ausfälle ist keiner. Es sind Lua-Überlastungen, ausgelöst von einem einzigen verbundenen Client mit wenigen Kilobit pro Sekunde. Der Grund liegt in der Bauweise der net-Bibliothek: Sobald ein Addon mit util.AddNetworkString ein Netzereignis registriert und mit net.Receive darauf hört, kann jeder Client dieses Ereignis in einer Schleife auslösen. Ohne eigene Begrenzung führt der Server jede einzelne Nachricht aus. Facepunch hat das in den eigenen Fehlermeldungen mehrfach dokumentiert und keine Lösung in der Engine vorgesehen, die Begrenzung ist ausdrücklich Aufgabe des Addon-Autors.

Prüfen Sie deshalb jedes eigene und jedes zugekaufte Addon auf drei Dinge: eine Obergrenze je Spieler und Sekunde, eine Prüfung der Nachrichtenlänge, und dass der Spieler serverseitig aus dem zweiten Parameter ermittelt wird statt aus dem Inhalt der Nachricht. Ein tragfähiges Muster sieht so aus:

util.AddNetworkString("khrp_buy")

local budget = {}

net.Receive("khrp_buy", function(len, ply)
    if not IsValid(ply) then return end
    if len > 256 then return end

    local now = CurTime()
    local b = budget[ply]

    if not b or now - b.start >= 1 then
        b = { start = now, count = 0 }
        budget[ply] = b
    end

    b.count = b.count + 1
    if b.count > 10 then return end

    KHRP.HandleBuy(ply, net.ReadString())
end)

hook.Add("PlayerDisconnected", "khrp_budget_cleanup", function(ply)
    budget[ply] = nil
end)

Dazu gehören zwei Zeilen in der server.cfg. sv_allowcslua steht in Garry's Mod standardmäßig auf 1 und erlaubt Clients, mit lua_run_cl und lua_openscript_cl eigenen Code auszuführen: Für einen öffentlichen Server gehört der Wert auf 0. Und sv_kickerrornum trennt Clients, die mehr als die angegebene Zahl clientseitiger Fehler erzeugen (Vorgabe 0, also abgeschaltet):

sv_allowcslua 0
sv_kickerrornum 25

6. Workshop-Inhalte und FastDL vom Spielserver trennen

Workshop-Addons sind bei Garry's Mod kein Randthema, sondern der Normalfall: Eine DarkRP-Community bindet ihre Sammlung mit +host_workshop_collection ein, und die Clients laden diese Inhalte direkt von Steam. Das belastet Ihre Leitung nicht. Der Schlüssel aus -authkey ist ein Steam-Web-API-Schlüssel und gehört wie ein Passwort behandelt: in das Startskript, nicht in ein öffentliches Repository und nicht in einen Discord-Kanal.

Die Bandbreite kostet der zweite Weg. Alles, was nicht aus dem Workshop kommt (eigene Karten, Sounds, Materialien), geht über den Download-Kanal. Ohne sv_downloadurl läuft dieser Kanal über den Spielport selbst und konkurriert direkt mit dem Spielverkehr. Mit FastDL läuft er über HTTP. Wenn dieser Webserver auf demselben Host und derselben IP-Adresse liegt, teilen sich beide dieselbe Leitung: Eine Beitrittswelle oder ein Angriff auf 80/TCP trifft damit auch das Spiel. Sinnvoll sind diese Werte:

sv_downloadurl "https://fastdl.ihre-domain.de/garrysmod/"
sv_allowdownload 1
sv_allowupload 0
net_maxfilesize 64

sv_allowupload 0 nimmt Clients die Möglichkeit, eigene Dateien zum Server zu schicken, und schließt damit einen Weg, der weder gebraucht noch kontrolliert wird. net_maxfilesize begrenzt die Größe der über den Spielkanal übertragenen Dateien in Megabyte. Legen Sie FastDL nach Möglichkeit auf einen anderen Host oder hinter einen eigenen Namen, dann liegt die Last nicht auf derselben Adresse wie der Spielport.

7. Beitritts-Flood und Slot-Erschöpfung abfangen

Slot-Erschöpfung ist ein Angriff, der keine Bandbreite braucht: Der Angreifer belegt mit automatisierten Verbindungen alle freien Plätze, sodass echte Spieler ein volles Haus sehen. Bei Garry's Mod kommt erschwerend hinzu, dass jeder Beitritt den Server Arbeit kostet, weil Ressourcenliste und Gamemode ausgehandelt werden, lange bevor der Spieler im Spiel ist.

Dagegen wirken vier Dinge. Erstens eine realistische Obergrenze: +maxplayers höher zu setzen als Ihr Gamemode verträgt, vergrößert nur die Angriffsfläche. Zweitens sv_timeout, das festlegt, nach wie vielen Sekunden ohne Nachricht ein Client getrennt wird (in den verbreiteten Konfigurationen 120): Wer hängende Halbverbindungen schneller loswerden will, setzt den Wert niedriger. Drittens die Ratenbegrenzung der verbindungslosen Pakete aus Schritt 3, denn der Verbindungsaufbau läuft genau darüber. Viertens, für geschlossene Gruppen, ein Serverpasswort:

sv_password "stammgruppe_2026"
sv_timeout 90
sv_filterban 1
sv_region 3

Eine echte Whitelist bringt Garry's Mod nicht mit, sie kommt über Erweiterungen wie ULX oder über eine eigene Prüfung im Hook CheckPassword. Und eines muss klar sein: Eine Whitelist schützt Ihre Spiellogik, nicht Ihre Leitung. Ein Angreifer, der Ihren Server flutet, will gar nicht beitreten. Seine Pakete werden abgelehnt, sind aber trotzdem angekommen, und genau das ist der Punkt.

8. Den Kernel entlasten: Verbindungsverfolgung und Empfangspuffer

Dieser Schritt erklärt Ausfälle, die wie ein Volumenangriff aussehen, aber keiner sind. Der Kernel legt für UDP-Verkehr Einträge in der Verbindungsverfolgung (conntrack) an, und bei gefälschten Absenderadressen bedeutet jede Adresse einen neuen Eintrag. Ist die Tabelle voll, verwirft der Kernel Pakete ohne Unterschied: Der Angriff und Ihre Spieler fliegen gemeinsam heraus, und im Systemprotokoll steht "nf_conntrack: table full". Stand und Obergrenze zeigt:

sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max

Der wirksamste Schritt ist, den Spielverkehr gar nicht erst verfolgen zu lassen, denn die Engine verwaltet ihre Sitzungen selbst:

table inet raw {
    chain prerouting {
        type filter hook prerouting priority raw; policy accept;
        udp dport { 27015, 27020 } notrack
    }
    chain output {
        type filter hook output priority raw; policy accept;
        udp sport { 27015, 27020 } notrack
    }
}

Mit iptables lautet die Entsprechung iptables -t raw -A PREROUTING -p udp --dport 27015 -j NOTRACK und dieselbe Zeile für OUTPUT mit --sport. Der Port braucht danach eine ausdrückliche Freigabe, denn ohne Verfolgung greift keine Regel mehr, die auf einen bestehenden Zustand prüft. Kommen Pakete außerdem schneller an, als srcds sie abholt, läuft der Empfangspuffer über, und für die Spieler sieht das aus wie Paketverlust bei freier Leitung:

net.core.rmem_max = 16777216
net.core.rmem_default = 1048576
net.core.netdev_max_backlog = 16384

Die Zeilen gehören in eine Datei unter /etc/sysctl.d/ und werden mit sysctl --system aktiv. Ob sie nötig sind, verrät der Kernel selbst: Steigt UdpRcvbufErrors in nstat -az an, dann greifen sie. Bleibt der Zähler bei null, ändert die Anpassung nichts. Das ist Reserve, kein Schutz.

9. Messwerte sichern, solange alles normal läuft

Der wichtigste Schritt ist der, den fast niemand vorher macht: eine Vergleichsbasis anlegen. Ohne Normalwert können Sie nach einem Vorfall nicht sagen, ob 40.000 Pakete pro Sekunde viel waren oder einfach Samstagabend. Rechnen Sie den Normalwert für Ihren Server einmal aus: 64 Spieler mit cl_cmdrate 66 erzeugen rund 4.200 eingehende Pakete pro Sekunde, alles deutlich darüber ist erklärungsbedürftig. Mit apt-get install -y vnstat sysstat läuft die Messung dauerhaft mit. Während eines Vorfalls genügen vier Befehle:

sar -n DEV 1 10
ip -s link show eth0
nstat -az | grep -i udp
tcpdump -ni eth0 -c 200 "udp port 27015 and udp[8:4] = 0xffffffff"

Der erste zeigt Pakete und Bytes je Sekunde, der zweite die Verwurfszähler der Schnittstelle, der dritte die UDP-Fehlerzähler des Kernels. Die vierte Zeile zeigt ausschließlich die verbindungslosen Pakete, also genau die Klasse, die eine Abfrageflut missbraucht: Läuft der Zähler in Sekunden voll, während kaum jemand verbunden ist, haben Sie Ihre Antwort. Begrenzen Sie tcpdump immer mit -c, ein Mitschnitt unter Volllast belastet einen ohnehin überlasteten Server zusätzlich. Wie Sie die Werte auswerten, steht in DDoS-Angriff am Server erkennen.

Was ist die A2S-Reflection-Lücke und betrifft sie mich noch

A2S-Reflection ist ein Angriff, bei dem nicht Ihr Server das Ziel ist, sondern das Werkzeug. Der Angreifer sendet eine kleine Abfrage mit gefälschter Absenderadresse an tausende Gameserver, und deren deutlich größere Antworten laufen alle beim eigentlichen Opfer zusammen. Historisch war eine A2S_INFO-Anfrage 25 Byte groß (4 Byte 0xFFFFFFFF, 1 Byte 0x54, dazu 20 Byte für die Zeichenkette "Source Engine Query"), die Antwort dagegen mehrere hundert Byte. Das US-CERT führt das Steam-Protokoll in seiner Liste der Verstärkungsangriffe mit einem Faktor von 5,5, was bedeutet: Aus einem Gigabit beim Angreifer werden 5,5 Gigabit beim Opfer.

Valve hat diese Lücke ab November 2020 geschlossen, und zwar auf zwei Wegen. Verbindungslose Abfragepakete müssen seitdem vom Absender auf 1.200 Byte aufgefüllt werden, womit die Anfrage größer ist als die Antwort und der Verstärkungsfaktor unter 1 fällt. Während der Umstellung konnten Betreiber das strengere Verhalten mit der Umgebungsvariablen STEAM_GAMESERVER_MIN_CONNECTIONLESS_PACKET_SIZE=1200 vorab erzwingen. Zusätzlich antwortet der Server bei A2S_PLAYER und A2S_RULES nicht sofort mit Daten, sondern mit einer Challenge (S2C_CHALLENGE), die der Fragende in einer zweiten Anfrage zurückschicken muss. Wer die Absenderadresse fälscht, bekommt diese Challenge nie zu sehen.

Für Sie folgen daraus zwei Dinge. Halten Sie den Serverbinary aktuell, denn der Schutz steckt im Steam-Gameserver-Unterbau und nicht in Ihrer Konfiguration. Und verwechseln Sie Reflection nicht mit einer Abfrageflut gegen Sie selbst: Gegen die zweite Form hilft ausschließlich die Ratenbegrenzung aus Schritt 3 und, darüber hinaus, Filterung im Netz vor dem Server.

Wo diese Maßnahmen aufhören: Bandbreite und Paketrate

Jetzt der Teil, den keine Konfigurationsdatei lösen kann. Alles bisher Beschriebene läuft 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 schlägt meist früher zu: Bei kleinstmöglichen Paketen von 64 Byte passen in 1 Gbit/s rund 1,49 Millionen Pakete pro Sekunde, in 10 Gbit/s rund 14,88 Millionen. Ein normaler Serverkernel verarbeitet je nach CPU und Netzwerkkarte einige hunderttausend davon, 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 hatten alle Lag-Spikes".

Zur Einordnung, welche Größenordnungen real vorkommen: Auf KernelHost-Servern wurden unter anderem ein UDP-Flood mit über 112,2 Gbit/s und über 8,7 Millionen Paketen pro Sekunde gegen einen Gameserver gefiltert sowie ein Multi-Vektor-Angriff mit über 473,4 Gbit/s und über 41,5 Millionen Paketen pro Sekunde gegen einen Voice-Server. 473,4 Gbit/s sind rund das 470-Fache einer 1-Gbit/s-Anbindung und immer noch rund das 47-Fache einer 10-Gbit/s-Anbindung. Dafür gibt es keine lokale Einstellung. Volumetrische Angriffe müssen im Netz vor dem Server enden.

Was KernelHost dagegen stellt

Der Dauerschutz, der in jedem Serverpaket enthalten 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 überhaupt 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 Umschaltzeit, in der Ihre Spieler herausfliegen. 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. Der Standort ist Frankfurt am Main. Welche Spiele und Protokolle abgedeckt sind, listet Gameserver-DDoS-Schutz in Echtzeit.

Advanced DDoS Protection für dauerhaft beschossene Communities

Manche Projekte werden nicht gelegentlich, sondern gezielt und über Wochen angegriffen, mit wechselnden Mustern und immer genau zur Hauptzeit. Dafür gibt es die Advanced DDoS Protection ab 50,00 EUR im Monat, PrePaid und ohne Mindestlaufzeit. Der Unterschied liegt nicht in mehr Kapazität, sondern in der Kontrolle:

• Dedizierte Schutz-IP aus dem Frankfurter Kern, auf die Ihr Server in unserem eigenen Netz umgestellt wird. Auf Ihrer Seite ist kein Umbau nötig.
• Selbst verwaltbare Schutzregeln je Port und Protokoll im Kundenbereich: Sie stellen ein, was auf 27015/UDP erlaubt ist und was auf 27015/TCP, ohne dafür ein Ticket zu schreiben.
• Änderungen greifen in Echtzeit, Sie können also während eines laufenden Angriffs nachjustieren, statt auf das nächste Wartungsfenster zu warten.
• Schutzprofil passend zum jeweiligen Spiel, für Garry's Mod und die übrigen Source-Titel ebenso wie freie TCP- und UDP-Profile für modifizierte Server und eigene Anwendungen.

Auch hier gilt das PrePaid-Modell: keine Mindestlaufzeit, keine Kündigungsfrist, kein Vertrag und keine Einrichtungsgebühr. Ist die Angriffswelle vorbei, verlängern Sie einfach nicht. Wer seinen Garry's-Mod-Server bisher woanders betreibt, bekommt diesen Schutz über einen Umzug zu KernelHost, denn gefiltert wird im eigenen Netz und nicht auf fremder Infrastruktur.

Die beiden Schutzstufen im Vergleich

Für die meisten Garry's-Mod-Communities 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

"Der Server läuft, ist aber aus dem Serverbrowser verschwunden": Meist wurde 27015/UDP pauschal gesperrt oder zu eng ratenbegrenzt. Weil Spielverkehr und Abfrage denselben Port teilen, trifft eine grobe Regel beides. Arbeiten Sie stattdessen mit dem Abgleich auf die verbindungslosen Pakete. Bleibt der Server trotz erreichbarem Port unsichtbar, prüfen Sie sv_setsteamaccount: Ohne gültiges Game Server Login Token wird ein Garry's-Mod-Server in der Liste stark abgewertet, und jeder Server braucht ein eigenes Token.

"Meine iptables-Regel ist korrekt und wirkt trotzdem nicht": Drei Ursachen sind häufig. Die Regel steht hinter den UFW-Ketten und wird nie erreicht, sie war nach dem letzten Neustart weg (dann helfen apt-get install -y iptables-persistent und 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.

"Mein DarkRP-Server ruckelt für alle, die Leitung ist aber frei": Das ist fast immer Lua und kein Angriff auf die Leitung. Sehen Sie im Serverprotokoll nach, welches Netzereignis auffällig oft eintrifft, und prüfen Sie das zugehörige Addon auf eine Begrenzung je Spieler. Bleiben sar -n DEV 1 10 und die Verwurfszähler unauffällig, war es kein DDoS-Angriff.

"RCON funktioniert plötzlich nicht mehr": Kein DDoS, sondern meist die eigene Sperre. Ein Adminpanel mit altem Passwort löst sv_rcon_minfailures aus, und sv_rcon_banpenalty sperrt die Adresse für die eingestellte Zahl an Minuten. Passwort korrigieren, Sperre aufheben, danach den Port auf die eigene Adresse beschränken.

"Ich habe die IP-Adresse gewechselt und war zwei Tage später wieder offline": Das ist der Normalfall. Ihr Server veröffentlicht die neue Adresse selbst, sobald er wieder beim Master-Server angemeldet ist, und ein Gameserver ohne öffentliche Adresse hat keine Spieler. Ein Adresswechsel verschafft Stunden bis Tage, er ist keine Lösung.

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

Kurz zusammengefasst

• Ein Garry's-Mod-Server braucht genau einen offenen Port: 27015/UDP. Spielverkehr und A2S-Abfrage laufen dort gemeinsam, einen getrennten Query-Port gibt es nicht.
• RCON liegt auf 27015/TCP, überträgt das Passwort im Klartext und gehört ausschließlich auf die eigene Adresse freigegeben oder über eine SSH-Portweiterleitung erreicht.
• Begrenzen Sie nicht den Port, sondern die verbindungslosen Pakete mit dem Kopf 0xffffffff. Eine pauschale Sperre auf 27015/UDP wirft die eigenen Spieler heraus.
• Der häufigste Garry's-Mod-Ausfall ist kein DDoS-Angriff, sondern ein Netzereignis ohne Begrenzung: Jedes mit util.AddNetworkString registrierte Ereignis braucht eine Obergrenze je Spieler und Sekunde.
• Bei 64 Byte großen Paketen trägt eine 1-Gbit/s-Leitung rund 1,49 Millionen Pakete pro Sekunde. Darüber entsteht der Verlust am Router davor, und jede lokale Regel wird wirkungslos.
• Bei KernelHost ist der zweistufige Dauerschutz in jedem Serverpaket ohne Aufpreis enthalten: 17 Tbps Mitigationskapazität im globalen Scrubbing-Netzwerk und Arbor-Echtzeitfilterung mit 3,2 Tbps in Frankfurt am Main, ohne Nullrouting.
• Wer dauerhaft gezielt beschossen wird, ergänzt die Advanced DDoS Protection ab 50,00 EUR im Monat: dedizierte Schutz-IP, selbst verwaltbare Regeln je Port und Protokoll, in Echtzeit wirksam.

Läuft Ihr Server 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. Nennen Sie dabei gleich vier Angaben: IP-Adresse, Port, Zeitraum in Ihrer Zeitzone und was Sie sehen (Spieler fliegen heraus, Server nicht im Browser, Lag-Spikes). Bei einem laufenden Angriff erreichen Sie uns zusätzlich über den WhatsApp-Notfallchat unter +43 650 8209883.

Wer neben Garry's Mod weitere Source-Titel betreibt, findet die gemeinsamen Grundlagen in CS2- und Source-Server vor DDoS-Angriffen schützen, und wie der Unterbau sauber aufgesetzt wird, steht in Gameserver mit SteamCMD installieren.