Counter-Strike-1.6- und GoldSrc-Server vor DDoS-Angriffen schützen

Ein Counter-Strike-1.6-Server fällt selten zum bequemen Zeitpunkt aus. Er fällt im entscheidenden Durchgang eines Clanwars aus, am Freitagabend mit vollem Server oder genau dann, wenn ein gesperrter Spieler zum dritten Mal abgewiesen wurde. Wer gerade beschossen wird, braucht keine Grundsatzdiskussion über Netzwerktechnik, sondern eine Reihenfolge. Dieser Beitrag zeigt zuerst, wie Sie einen Counter-Strike-1.6-Server vor DDoS-Angriffen schützen, solange das mit Bordmitteln geht, danach, wo diese Möglichkeiten physikalisch enden, und zum Schluss, was davor im Netz passieren muss.

Alle Angaben beziehen sich auf einen dedizierten GoldSrc-Server (HLDS) 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. Ein Punkt vorweg, weil er die Reihenfolge bestimmt: Ändern Sie während eines laufenden Angriffs nichts blind und starten Sie den Server nicht neu, bevor Sie die Messwerte gesichert haben. Nach dem Neustart sind sie weg, und ohne Messwerte bleibt jede weitere Maßnahme geraten.

Warum Counter-Strike-1.6-Server nach über fünfundzwanzig Jahren immer noch angegriffen werden

Die Szene lebt. In Osteuropa, der Türkei und Brasilien laufen weiterhin tausende öffentliche GoldSrc-Server, dazu kommen Liga- und Clanserver in ganz Europa. Ein Server mit 24 Plätzen und Stammpublikum ist für den Betreiber ein Abend Arbeit pro Woche und für einen Angreifer ein Ziel, das sich mit ein paar Euro für eine Stunde ausschalten lässt. Der Anreiz ist derselbe wie bei jedem anderen Spiel: Wer zurückliegt, gewinnt durch einen Abbruch Zeit, und wer eine konkurrierende Community betreibt, weiß, dass ein Abend voller Timeouts die Stammspieler weiterziehen lässt.

Der Unterschied liegt in der Engine. GoldSrc stammt aus einer Zeit, in der Verstärkungsangriffe über UDP kein Thema waren. Der Server beantwortet verbindungslose Abfragen bereitwillig, er kennt keine Ratenbegrenzung, die an der Leitung ansetzt, und er verlangt vor der teuersten Antwort keine Challenge. Das ist kein Vorwurf an eine Engine aus dem Jahr 1998, sondern eine Ausgangslage. Sie führt zu einer Aussage, die man selten liest: Ein Counter-Strike-1.6-Server braucht heute mehr Schutz von außen als ein moderner Spielserver, nicht weniger. Was bei einem aktuellen Titel die Engine selbst abfängt, muss hier das Netz davor erledigen.

Dazu kommt die Auffindbarkeit. Ein GoldSrc-Server ist mit IP-Adresse und Port öffentlich gelistet, und das ist Voraussetzung, kein Versehen: Ein Server, der keine Abfrage beantwortet, steht in keinem Serverbrowser und auf keiner Listenseite. Die Frage lautet also nie, ob ein Angreifer Ihre Adresse kennt, sondern nur, was passiert, wenn er darauf schießt. Was dabei technisch abläuft, erklärt der Beitrag Was ist ein DDoS-Angriff?.

Welche Spiele auf GoldSrc laufen und was schon zu Source gehört

GoldSrc ist die ursprüngliche Half-Life-Engine, im Netzwerk erkennbar an der Protokollversion 48. Source ist die Nachfolgerin aus dem Jahr 2004 und eine eigene, neuere Engine. Die Namensähnlichkeit sorgt für die häufigste Verwechslung in diesem Themenfeld: Half-Life ist GoldSrc, Half-Life 2: Deathmatch ist Source. Beide Engines teilen sich die Portlogik und die Idee der verbindungslosen Pakete, aber die Konsolenvariablen heißen unterschiedlich, und die Fernsteuerung arbeitet über verschiedene Protokolle.

Halten Sie beim Lesen zwei Ebenen auseinander. Die Abschnitte über Ports, über verbindungslose Pakete und über die Regeln im Kernel (nftables, iptables, sysctl) gelten für beide Engines gleichermaßen, denn der Kernel sieht nur UDP-Pakete. Die Abschnitte über Konsolenvariablen, über RCON und über die Serverbinärdatei gelten ausschließlich für GoldSrc. Wer eine Source-Anleitung auf einen 1.6-Server überträgt, schreibt Variablen in die server.cfg, die es dort nicht gibt, und wundert sich, dass nichts passiert.

Die Ports, um die es bei einem GoldSrc-Server tatsächlich geht

Ein GoldSrc-Server belegt genau einen UDP-Port für alles, was das Spiel ausmacht, dazu einen zweiten für die Anmeldung bei Steam. Der Spielport ist über -port festgelegt, die zugehörige Konsolenvariable heißt schlicht port und steht standardmäßig auf 27015. Der Steam-Port wird über -sport gesetzt und steht standardmäßig auf 26900:

./hlds_run -game cstrike -console \
  -port 27015 \
  -sport 26900 \
  +ip 203.0.113.10 \
  +maxplayers 24 \
  +map de_dust2

In der ersten Zeile steckt der wichtigste Unterschied zur Source-Engine, und er kostet regelmäßig einen Abend Fehlersuche. Bei Counter-Strike 1.6 läuft die Fernsteuerung nicht über TCP, sondern über verbindungslose UDP-Pakete auf demselben Spielport 27015. Die Serverbinärdatei öffnet überhaupt keinen TCP-Port. Wer aus einer Source-Anleitung die Zeile für 27015/TCP übernimmt, legt eine Firewall-Regel an, die auf nichts zeigt, und glaubt danach, RCON sei abgesichert. Die einzige Ausnahme ist Sven Co-op, das einen eigenen Zweig der Engine pflegt und im eigenen Handbuch 27015/TCP für RCON nennt.

Die zweite Besonderheit betrifft 26900/UDP. Über diesen Port meldet sich der Serverprozess bei Steam an und hält die Verbindung zum Masterserver. Er muss nicht von außen erreichbar sein, wohl aber ausgehend funktionieren. Ist der Port belegt, sucht der Prozess selbständig die nächste freie Nummer, weshalb auf einem Host mit vier Instanzen die Reihe 26900, 26901, 26902 und 26903 entsteht. Wer ausgehend pauschal filtert, verliert den Eintrag in der Serverliste, ohne dass der Server auch nur einen Tick langsamer läuft.

Verbindungslose Abfragen: warum ein GoldSrc-Server bereitwillig antwortet

Ein verbindungsloses Paket ist ein UDP-Paket, dessen erste vier Byte alle auf 0xFF stehen. Die Engine prüft genau das und nichts anderes: Steht dort FF FF FF FF, gilt das Paket als verbindungslos und wird sofort ausgewertet, ohne dass eine Sitzung, ein Spieler oder eine vorherige Anmeldung existieren müsste. Steht dort etwas anderes, sucht die Engine unter den bereits verbundenen Spielern nach einer passenden Absenderadresse und verwirft das Paket, wenn sie keine findet.

Hinter den vier Byte folgt entweder ein einzelnes Kennbyte oder ein Wort im Klartext. Genau diese Trennung ist der Ansatzpunkt für jede sinnvolle Ratenbegrenzung, denn der Spielverkehr eines verbundenen Spielers hat diesen Kopf nie.

Warum die Antwort größer ist als die Anfrage

Eine A2S_INFO-Anfrage ist genau 25 Byte lang: vier Byte FF FF FF FF, ein Byte 0x54 und die 20 Byte lange Zeichenkette "Source Engine Query" mit abschließender Null. Die Antwort enthält Servername, Kartenname, Verzeichnis, Spielbeschreibung, Spielerzahl, Höchstzahl, Botzahl, Servertyp, Betriebssystem, Passwortschutz, VAC-Status und Version. Das ist bei jedem normal benannten Server ein Vielfaches der Anfrage. Die US-Behörde CISA beziffert den Verstärkungsfaktor des Steam-Protokolls in Alert TA14-017A mit 5,5.

Am ergiebigsten ist aber nicht A2S_INFO, sondern A2S_RULES. Diese Abfrage liefert jede Konsolenvariable zurück, die als Servervariable markiert ist, also Name und Wert in Textform. Auf einem gepflegten Counter-Strike-1.6-Server mit Erweiterungen sind das schnell mehrere hundert Einträge, und die Antwort wächst entsprechend auf mehrere Kilobyte. Aus 25 Byte Anfrage werden dann keine 5,5, sondern deutlich mehr. Das ist der Grund, warum GoldSrc-Server seit Jahren in den Listen von Verstärkungsdiensten stehen.

Was gefälschte Absenderadressen daraus machen

UDP kennt keinen Verbindungsaufbau. Es gibt also keinen Punkt im Protokoll, an dem der Absender beweisen müsste, dass er wirklich unter der angegebenen Adresse erreichbar ist. Ein Angreifer schickt deshalb Abfragen an tausende fremde GoldSrc-Server und trägt als Absender die Adresse seines eigentlichen Opfers ein. Jeder dieser Server antwortet brav, und die Antworten laufen gesammelt beim Opfer auf. Ihr eigener Server wird dabei nicht angegriffen, sondern zum Werkzeug gegen einen Dritten.

Drei praktische Folgen ergeben sich daraus. Erstens sehen Sie in Ihrem Protokoll Abfragen von Adressen, die nie ein Spiel betreten. Zweitens erzeugt Ihr Server ausgehenden Verkehr, für den Sie im Zweifel bezahlen. Drittens landet Ihre Adresse in den Listen, die solche Dienste pflegen, und wird danach dauerhaft abgefragt. Eine Filterung, die vor dem Server arbeitet, löst beide Richtungen zugleich: Sie hält die Flut von Ihnen fern und verhindert, dass Ihr Server an einem fremden Angriff mitwirkt.

Ein Wort zur Gegenmaßnahme, die es in der Engine gibt: Die Konsolenvariable sv_enableoldqueries steht standardmäßig auf 0. In dieser Stellung beantwortet der Server die alten, aus der Zeit vor Steam stammenden Abfragen nicht mehr, sondern verlangt das moderne Format mit gültiger Kennzeichnung. Setzen Sie diese Variable nicht auf 1. Sie existiert für Werkzeuge, die seit anderthalb Jahrzehnten nicht mehr gepflegt werden, und sie macht Ihren Server wieder zu dem Verstärker, der er vor der Umstellung war.

Die Angriffsarten, die einen GoldSrc-Server wirklich treffen

Abfrageflut auf 27015/UDP

Die Abfrageflut ist der Normalfall. Ein Angreifer schickt A2S_INFO, A2S_PLAYER und A2S_RULES in schneller Folge an Ihren Spielport, oft aus vielen Quellen gleichzeitig. Jede einzelne Anfrage ist harmlos, die Summe nicht: Der Serverprozess muss jedes Paket lesen, zuordnen und beantworten, und er tut das in derselben Schleife, in der er auch das Spiel berechnet. Bei GoldSrc ist das besonders empfindlich, weil der Spielserver in einem einzigen Prozess läuft und praktisch einen Rechenkern nutzt. Die Spieler merken es an steigendem Ping und an Rucklern, lange bevor die Leitung voll ist.

Reflexion über fremde und über eigene Server

Die Reflexion ist der Fall aus dem vorigen Abschnitt, nur von der anderen Seite betrachtet. Wird Ihr Server als Ziel gewählt, treffen bei Ihnen die Antworten hunderter fremder Spielserver ein. Diese Pakete kommen aus echten, sauberen Netzen, sie sind protokollkonform, und sie lassen sich an der Absenderadresse nicht von legitimem Verkehr unterscheiden. Genau deshalb ist Reflexion für eine Firewall auf dem Server so unangenehm: Es gibt keine Adressliste, die man sperren könnte, ohne halb Europa mitzusperren.

Anmeldeflut über getchallenge und connect

Der Verbindungsaufbau bei GoldSrc läuft in zwei Schritten. Der Client schickt getchallenge, der Server vergibt eine Challenge und merkt sie sich zusammen mit der Absenderadresse, danach schickt der Client connect mit dieser Challenge zurück. Die Tabelle für diese Challenges fasst in der unveränderten Engine 1024 Einträge, und im Quelltext steht dazu ein bemerkenswerter Kommentar von Valve selbst: Die Tabelle sei absichtlich groß gehalten, um zu verhindern, dass ein Angriff alle Plätze durchrotiert, bevor sich legitime Nutzer verbinden konnten.

Das ist eine ehrliche Beschreibung des Problems und zugleich der Beweis, dass es bekannt ist. Eine Anmeldeflut aus gefälschten Adressen füllt diese Tabelle, und die legitime Challenge eines echten Spielers wird dabei überschrieben. Der Spieler sieht dann "No challenge for your address" und kommt nicht herein, obwohl der Server läuft und Plätze frei sind. Gepflegte Nachbauten der Engine lösen das anders: Sie berechnen die Challenge aus Adresse und einem zufälligen Wert, statt sie in einer Tabelle abzulegen, und haben damit nichts mehr, was überlaufen könnte.

RCON-Bruteforce über den Spielport

Weil RCON bei GoldSrc über verbindungslose UDP-Pakete auf dem Spielport läuft, kann ein Angreifer Passwortversuche einfach mitschicken, während die Spieler weiterspielen. Der Ablauf ist immer derselbe: challenge rcon anfragen, die Challenge zurückbekommen, dann rcon mit Challenge, Passwort und Befehl senden. Der Server prüft zuerst die Challenge, dann das Passwort, und protokolliert jeden Fehlversuch als "Bad Rcon".

Zwei Dinge helfen dabei mehr, als sie zunächst aussehen. Erstens muss die Challenge zurückkommen, der Angreifer kann seine Adresse also nicht fälschen: Eine Adressbeschränkung wirkt hier tatsächlich. Zweitens zählt die Engine Fehlversuche mit, allerdings nur in einer Tabelle mit 32 Plätzen. Ein Angreifer, der aus vielen Adressen gleichzeitig probiert, verdrängt die Einträge schneller, als die Sperrlogik greift. Die verlässliche Antwort ist deshalb nicht das Zählen, sondern die Beschränkung.

Flut gegen den Eintrag in der Serverliste

Dieser Fall wird fast immer falsch gedeutet, weil er nicht wie ein Angriff aussieht. Der Server läuft, die Spieler drin bleiben drin, aber der Server verschwindet aus dem Serverbrowser, und es kommt niemand Neues mehr herein. Ursache ist, dass der Prozess seine Anmeldung bei Steam über 26900/UDP nicht mehr aufrechterhalten kann, weil entweder der ausgehende Verkehr in der Last untergeht oder der Prozess mit dem Beantworten von Abfragen beschäftigt ist. Für den Betreiber ist das der teuerste Zustand überhaupt: Der Server kostet weiter, füllt sich aber nicht mehr.

Lastspitzen, die gar kein Angriff sind

Ein erheblicher Teil der als DDoS gemeldeten Ausfälle sind keine. Es sind Abstürze und Lastspitzen, die ein einzelner Client mit wenigen hundert Paketen auslöst, weil im Serverbinary oder in einer Erweiterung eine Grenze fehlt. Der Verkehr bleibt dabei winzig, der Server steigt trotzdem aus. Dagegen hilft keine Bandbreite. Wie Sie beide Fälle auseinanderhalten, steht im Beitrag DDoS-Angriff am Server erkennen.

Woran Sie einen laufenden Angriff erkennen

Fünf Messpunkte genügen, und drei davon stehen in der Serverkonsole. Beginnen Sie dort, weil Sie die Werte auch dann sehen, wenn Ihr SSH-Zugang gerade zäh ist.

Die Serverbildrate. Der Befehl stats in der Serverkonsole gibt eine Zeile mit den Spalten CPU, In, Out, Uptime, Users, FPS und Players aus. Die Spalte FPS ist die Bildrate des Servers und sollte in der Nähe des Werts liegen, den sys_ticrate vorgibt (Standard 100). Fällt sie unter die Hälfte, während die Spielerzahl normal ist, arbeitet der Prozess an etwas anderem als am Spiel. Die Spalten In und Out zeigen den Durchsatz in Kilobyte pro Sekunde und verraten sofort, ob eingehend deutlich mehr ankommt als ausgehend hinausgeht.

Die Spielerliste. status listet alle verbundenen Spieler mit Adresse, Ping und Paketverlust. Steigt der Verlust bei allen gleichzeitig, liegt es am Netz und nicht an einzelnen Verbindungen. Ist die Liste kurz und die Bildrate trotzdem im Keller, bestätigt das den Verdacht auf eine Abfrageflut.

Das Serverprotokoll. Mit log on schreibt der Server in das Verzeichnis, das logsdir vorgibt (Standard logs). Interessant sind dort zwei Muster: wiederholte Zeilen mit "Bad Rcon" und, sobald Sie sv_logblocks 1 setzen, Zeilen der Form "Traffic from ... was blocked for exceeding rate limits". Die zweite Zeile ist der direkte Beleg, dass die eingebaute Abfragebremse gerade arbeitet.

Die offenen Ports. ss -lnup zeigt, welche UDP-Dienste wirklich lauschen. Bei einem sauberen GoldSrc-Host stehen dort der Spielport und der Steam-Port, sonst nichts. Alles Weitere gehört geprüft.

Die Paketrate. Auf Systemebene sagen drei Befehle alles, was in den ersten Minuten zählt:

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

Den ersten Befehl führen Sie zweimal im Abstand von zehn Sekunden aus, dann haben Sie eine Rate statt eines Absolutwerts. Die dritte Zeile zeigt ausschließlich die verbindungslosen Pakete, also genau die Klasse, die eine Abfrageflut missbraucht. Läuft der Zähler in Sekunden auf 200, während kaum jemand verbunden ist, haben Sie Ihre Antwort. Halten Sie die Mitschrift kurz, weil sie unter Last selbst Rechenzeit kostet.

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

Der folgende Teil kostet nichts und lohnt sich unabhängig davon, wo Ihr Server steht. Er nimmt Ihnen keinen volumetrischen Angriff ab, lässt aber kleine und mittlere Angriffe verpuffen, und er beseitigt die Ausfälle, die fälschlich als DDoS-Angriff gemeldet werden.

1. Bestandsaufnahme: was lauscht wirklich

Bevor Sie eine Regel schreiben, klären Sie, welche Dienste erreichbar sind. Auf einem gewachsenen 1.6-Host sind das fast immer mehr als erwartet, weil neben HLDS oft noch ein Webserver für die Kartendateien, eine Statistikdatenbank und ein zweiter Server für den Clanwar laufen:

ss -lntup

Alles, was an 127.0.0.1 oder ::1 gebunden ist, braucht keine Freigabe. Alles, was auf 0.0.0.0 oder [::] lauscht, ist aus dem Internet erreichbar, auch die Datenbank, die ein Statistikmodul mitgebracht hat. Die Sicht des Angreifers liefert ein Portscan von außen, und die weicht erfahrungsgemäß von der eigenen Erwartung ab:

nmap -Pn -sU -p 26900-26910,27015-27020 IHRE.SERVER.IP.ADRESSE
nmap -Pn -sT -p 22,80,443,3306,27015 IHRE.SERVER.IP.ADRESSE

Der zweite Befehl ist der interessante. Findet er auf 27015/TCP einen offenen Port, läuft dort nicht Ihr Counter-Strike-Server, sondern etwas anderes, denn HLDS öffnet keinen TCP-Port. Ist der Unterbau frisch aufgesetzt oder wollen Sie ihn nachvollziehen, beschreibt der Beitrag Gameserver mit SteamCMD installieren den Weg von SteamCMD bis zum laufenden Dienst.

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

Ein UDP-Port nach außen, mehr braucht das Spiel nicht. Der Steam-Port muss nur ausgehend funktionieren:

ufw allow 27015/udp comment "CS 1.6 Spielport, Abfrage und RCON"
ufw allow from 203.0.113.10 to any port 22 proto tcp comment "SSH"
ufw default deny incoming
ufw default allow outgoing
ufw --force enable

Ersetzen Sie 203.0.113.10 durch Ihre eigene Adresse. Und beachten Sie, was hier nicht steht: Es gibt keine Zeile für RCON, weil RCON denselben Port benutzt wie das Spiel. Sie können die Fernsteuerung bei GoldSrc nicht über die Portfreigabe trennen, sondern nur über den Paketinhalt. Das erledigt Schritt 5.

Die Reihenfolge beim Scharfschalten entscheidet darüber, ob Sie sich selbst aussperren; sie steht samt Rückweg im Beitrag 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 erreichen den Server über die VNC-Konsole im Kundenbereich, und die hängt nicht am Netzwerkstack des Gastsystems.

3. Die eingebaute Abfragebremse richtig einstellen

Hier liegt der Fehler, den die Sorgfaltspflicht dieses Beitrags ausmacht. GoldSrc hat eine eingebaute Begrenzung für verbindungslose Pakete, aber die Variablen heißen anders als in der Source-Engine: ohne das Präfix sv_. Wer die Source-Namen in eine server.cfg für Counter-Strike 1.6 schreibt, legt damit stillschweigend neue, wirkungslose Variablen an.

Die Mechanik ist einfach und lohnt sich zu kennen, weil sie erklärt, warum eine zu strenge Einstellung schadet. Für jedes eintreffende Paket mit dem Kopf FF FF FF FF zählt die Engine zuerst den Zähler der Absenderadresse hoch und teilt ihn durch max_queries_window. Liegt das Ergebnis über max_queries_sec, wird das Paket verworfen, bevor es überhaupt ausgewertet wird. Danach läuft dieselbe Rechnung über alle Adressen zusammen gegen max_queries_sec_global. Ein brauchbarer Ausgangspunkt für einen öffentlichen Server:

max_queries_sec 2
max_queries_sec_global 40
max_queries_window 30
sv_logblocks 1
sv_enableoldqueries 0

Zwei Einschränkungen gehören dazu, und beide werden gern verschwiegen. Erstens merkt sich die Engine nur eine begrenzte Zahl von Absenderadressen gleichzeitig, in der Größenordnung einiger hundert Einträge, die nach zwei Minuten Ruhe verfallen. Bei einem Angriff mit gefälschten Absendern ist diese Tabelle in Sekundenbruchteilen voll und rotiert dann durch. Die Bremse schützt also Ihre Rechenzeit, nicht Ihre Leitung: Die Pakete sind längst angekommen. Zweitens zählen die Abfragen der Listenseiten und des Steam-Masterservers mit. Ein zu niedriger globaler Wert wirft Sie aus der Serverliste, und das ist für einen öffentlichen Server dasselbe wie ein erfolgreicher Angriff. Beginnen Sie großzügig und ziehen Sie erst an, wenn sv_logblocks 1 zeigt, dass die richtigen Adressen betroffen sind.

4. Verbindungslose Pakete im Kernel begrenzen

Eine Ebene tiefer lässt sich derselbe Verkehr abtrennen, bevor der Serverprozess ihn überhaupt sieht. Der Ansatzpunkt ist genau der Kopf aus vier gesetzten Byte, denn der Verkehr bereits verbundener Spieler hat ihn nicht. Mit nftables sieht das so aus:

table inet goldsrc {
    chain input {
        type filter hook input priority -10; policy accept;

        udp dport 27015 @th,64,32 0xffffffff @th,96,8 0x54 \
            meter kh_a2s { ip saddr limit rate over 5/second burst 10 packets } drop

        udp dport 27015 @th,64,32 0xffffffff \
            meter kh_connless { ip saddr limit rate over 20/second burst 40 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. @th,64,32 liest die ersten vier Byte hinter dem UDP-Kopf, @th,96,8 das fünfte Byte, also die Kennung der Abfrageart. Die erste Regel begrenzt damit gezielt A2S_INFO auf fünf Anfragen je Sekunde und Adresse, die zweite fängt alles übrige Verbindungslose bei zwanzig Anfragen je Sekunde ab. Der Spielverkehr Ihrer Spieler wird von keiner der beiden Regeln berührt.

Mit klassischem iptables erreicht ein Abgleich auf die A2S_INFO-Kennzeichnung dasselbe:

iptables -A INPUT -p udp --dport 27015 \
  -m string --algo bm --hex-string "|ffffffff54536f7572636520456e67696e6520517565727900|" \
  -m hashlimit --hashlimit-name a2sflood --hashlimit-mode srcip \
  --hashlimit-above 5/sec --hashlimit-burst 10 -j DROP

Prüfen Sie nach jeder Änderung, dass Ihr Server noch im Serverbrowser steht, und zwar von einem fremden Anschluss aus, nicht vom Server selbst. Eine Regel, die den Eintrag in der Serverliste kostet, hat den Angriff im Sinne des Angreifers beendet.

5. RCON abschalten oder auf die eigene Adresse beschränken

Ein offener RCON-Zugang mit schwachem Passwort ist kein DDoS-Problem, sondern eine Übernahme: Wer RCON hat, wechselt die Karte, sperrt alle Spieler und stoppt den Server. Die sauberste Lösung ist die radikale: Lassen Sie rcon_password leer, wenn Sie die Fernsteuerung nicht brauchen. Der Server antwortet dann auf jeden Versuch mit "No password set for this server" und führt nichts aus. Verwalten lässt er sich weiterhin über die Serverkonsole, über screen oder über Ihr Panel.

Brauchen Sie RCON, dann mit einem langen Zufallswert und mit den Bremsen, die die Engine mitbringt. Alle vier Variablen existieren in GoldSrc, und die Standardwerte in Klammern sind ausgesprochen großzügig:

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

sv_rcon_minfailures (Standard 5) ist die Zahl der Fehlversuche innerhalb von sv_rcon_minfailuretime (Standard 30 Sekunden), die zur Sperre führt. sv_rcon_maxfailures (Standard 10) ist die absolute Obergrenze. sv_rcon_banpenalty ist die Sperrdauer in Minuten, und hier liegt eine Falle: Der Standardwert ist 0, und 0 bedeutet beim zugrunde liegenden addip eine Sperre ohne Ablauf. Wer sich selbst vertippt, sperrt sich also dauerhaft aus. Ein Wert wie 1440 (ein Tag) ist in der Praxis die bessere Wahl. Ein Passwort erzeugen Sie mit openssl rand -base64 32.

Weil RCON auf dem Spielport liegt, lässt es sich nicht über die Portfreigabe einschränken, wohl aber über den Paketinhalt. Wer die Fernsteuerung gar nicht nutzt, verwirft die beiden zuständigen Klartextwörter direkt im Kernel:

table inet goldsrc_rcon {
    chain input {
        type filter hook input priority -11; policy accept;

        udp dport 27015 @th,64,32 0xffffffff @th,96,32 0x72636f6e drop
        udp dport 27015 @th,64,32 0xffffffff @th,96,32 0x6368616c drop
    }
}

Die erste Regel trifft Pakete, die nach dem Kopf mit rcon beginnen, die zweite solche, die mit chal beginnen, also die Challenge-Anfrage für RCON. Soll RCON nur von Ihrer eigenen Adresse aus funktionieren, stellen Sie den beiden Zeilen jeweils ein ip saddr != 203.0.113.10 voran. Der Verbindungsaufbau der Spieler nutzt getchallenge und ist von beiden Regeln nicht betroffen.

Ein Hinweis zu gepflegten Nachbauten der Engine: Sie bringen dafür eine eigene Liste mit, verwaltet über die Konsolenbefehle rcon_adduser mit einer IP-Adresse oder einem CIDR-Bereich, rcon_deluser und rcon_users. Das ist bequemer als eine Firewall-Regel, ersetzt sie aber nicht, weil der Versuch trotzdem bis zur Anwendung durchläuft.

6. Alte Binärdateien: was wirklich daran hängt

Die Frage kommt in jeder Diskussion, und sie wird meistens zu scharf beantwortet. Sachlich sieht es so aus: Die unveränderte Serverbinärdatei von Valve funktioniert, sie bekommt aber seit Jahren nur noch sporadisch Pflege, und sie bringt genau die Grenzwerte mit, die 2005 als ausreichend galten. Daneben steht ReHLDS, ein quelloffener Nachbau der HLDS-Engine, der Fehler behebt und zusätzliche Grenzen einzieht; die zuletzt veröffentlichte Fassung trägt die Nummer 3.15.0.896 und stammt vom Mai 2026. Für die Spielbibliothek gibt es mit ReGameDLL_CS ein entsprechendes Gegenstück, für Erweiterungen Metamod-r und darauf aufbauend AMX Mod X, das zuletzt als Version 1.9.0.5303 im April 2026 veröffentlicht wurde.

Die ehrliche Einordnung lautet: Wer eine alte, unveränderte Binärdatei fährt, hat kein akutes Loch, aber weniger eingebaute Gegenwehr. Der Unterschied liegt nicht in einer einzelnen Lücke, sondern in einer Reihe von Grenzwerten, die eine gepflegte Fassung mitbringt und die unveränderte nicht kennt:

• Gleichzeitige Verbindungen je Adresse. Die Variable sv_rehlds_maxclients_from_single_ip (Standard 5) deckelt, wie viele Verbindungen von derselben Adresse zugleich aufgebaut werden. Gegen eine Anmeldeflut aus einer Handvoll Quellen ist das die wirksamste einzelne Einstellung.
• Befehlsraten je Spieler. Die Gruppen sv_rehlds_movecmdrate_max_avg (Standard 400) und sv_rehlds_stringcmdrate_max_avg (Standard 80) begrenzen, wie viele Bewegungs- und Textbefehle ein einzelner Client schicken darf, jeweils mit einem Wert für kurze Spitzen und einer Sperrdauer in Minuten. Das fängt genau die Fälle ab, in denen ein einzelner Client den ganzen Server bremst.
• Dateianfragen. sv_rehlds_dlfile_refillrate (Standard 50) und die zugehörigen Werte begrenzen, wie schnell ein Client Dateien anfordern darf.
• Challenge ohne Tabelle. Statt 1024 Plätze zu verwalten, wird die Challenge aus Adresse und einem Zufallswert berechnet. Damit gibt es nichts mehr, was eine Anmeldeflut überlaufen lassen könnte.
• Grenzen beim Auspacken eingehender Daten. Eine Reihe von Werten begrenzt Verhältnis und Größe komprimierter Nutzlasten, die ein Client schickt.

Welche Fassung bei Ihnen läuft, beantwortet der Befehl version in der Serverkonsole. Zwei Dinge gehören trotzdem gesagt. Erstens ist ein Wechsel der Engine kein Notfallwerkzeug: Er gehört geplant, mit Sicherung und ohne laufenden Angriff, und die Erweiterungen müssen zur gewählten Fassung passen. Zweitens, und das ist wichtiger: Schalten Sie keine Prüfung ab, um einen Fehler loszuwerden. Wenn eine Karte nur startet, nachdem die Konsistenzprüfung aus ist, ist die Karte das Problem, nicht die Prüfung. Jede abgeschaltete Prüfung ist eine Tür, die danach offen bleibt, und in der Regel merkt es niemand, bis sie benutzt wird.

7. Plätze, Raten und Downloads begrenzen

GoldSrc kennt höchstens 32 Plätze je Server, und jeder belegte Platz kostet Bandbreite und Rechenzeit. Die Bandbreite je Spieler regelt die Engine über eine Obergrenze, die ab Werk nicht gesetzt ist: sv_maxrate steht auf 0, also unbegrenzt bis zur technischen Obergrenze von 100.000 Byte pro Sekunde je Client. Rechnen Sie das einmal hoch: 24 Spieler mal 100.000 Byte sind 2,4 Megabyte pro Sekunde allein ausgehend, also rund 19 Mbit/s, und zwar ohne jeden Angriff. Ein realistischer Deckel:

sv_maxrate 25000
sv_minrate 5000
sv_maxupdaterate 66
sv_minupdaterate 20
sv_timeout 45
sys_ticrate 100

sv_maxupdaterate (Standard 30) begrenzt, wie viele Aktualisierungen ein Client je Sekunde erhält; höhere Werte kosten Bandbreite und Rechenzeit gleichermaßen. sv_timeout (Standard 60) bestimmt, wie lange ein stummer Client seinen Platz behält, und ein kürzerer Wert gibt blockierte Plätze schneller frei. sys_ticrate (Standard 100) ist die angestrebte Bildrate des Servers und damit die Obergrenze dessen, was die Spalte FPS bei stats anzeigen kann. In der Szene sind deutlich höhere Werte verbreitet; sie kosten Rechenzeit, und genau die fehlt Ihnen unter einer Abfrageflut.

Bei den Dateien gilt dieselbe Regel wie bei allen Valve-Titeln: Was der Spielport ausliefert, zahlen Sie doppelt, nämlich mit Bandbreite und mit Rechenzeit im selben Prozess. Legen Sie Karten und Klänge auf einen Webserver und schalten Sie ab, was Sie nicht brauchen:

sv_downloadurl "https://cdn.example.org/cstrike/"
sv_allowdownload 1
sv_allowupload 0
sv_send_logos 0
mp_consistency 1

sv_allowupload steht ab Werk auf 1 und erlaubt Clients, ihre eigenen Sprühbilder hochzuladen. Das ist eine Datenquelle, die vom Client bestimmt wird, und sie bringt keinerlei Spielwert. sv_send_logos 0 verhindert zusätzlich, dass der Server diese Bilder an alle anderen weiterverteilt. mp_consistency steht ab Werk auf 1 und gehört dort gelassen.

Die Engine bringt außerdem eigene Sperrlisten mit: addip, removeip, listip und writeip für Adressen, banid, removeid, listid und writeid für Spielerkennungen, gesteuert über sv_filterban (Standard 1) und protokolliert mit sv_logbans 1. Wichtig ist, was diese Listen leisten und was nicht: Sie verhindern, dass jemand mitspielt. Sie verhindern nicht, dass seine Pakete ankommen, denn die Prüfung läuft im Serverprozess, nachdem der Kernel das Paket bereits zugestellt hat. Gegen einen Trollspieler ist banid das richtige Werkzeug, gegen eine Paketflut ist es wirkungslos. Vergessen Sie das writeip beziehungsweise writeid nicht, sonst sind die Sperren nach dem Neustart weg.

8. Verbindungsverfolgung und Empfangspuffer entlasten

Dieser Punkt wird oft übersehen und 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. Stand und Obergrenze zeigt ein Blick:

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, 26900 } notrack
    }
    chain output {
        type filter hook output priority raw; policy accept;
        udp sport { 27015, 26900 } 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 schneller an, als der Serverprozess sie abholt, läuft zusätzlich der Empfangspuffer über, und das sieht für die Spieler aus wie Paketverlust auf einer freien Leitung:

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

Die Datei legen Sie unter /etc/sysctl.d/ ab und aktivieren sie mit sysctl -p. Ob die Werte überhaupt 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. Eine Vergleichsbasis anlegen, solange alles normal läuft

Der wichtigste Schritt ist der, den fast niemand vorher macht. Notieren Sie an einem ruhigen Abend die Ausgabe von stats bei vollem Server, die Paketrate aus ip -s link show und die Zahl der Abfragen je Minute aus dem Protokoll. Ohne diesen Normalwert können Sie nach einem Vorfall nicht sagen, ob 40.000 Pakete pro Sekunde viel waren oder einfach Freitagabend auf einem gut besuchten Server. Mit dem Normalwert ist die Einordnung eine Sache von zwei Minuten, und genau darauf kommt es an, wenn gerade ein Match läuft.

Wo diese Maßnahmen aufhören

Jetzt der ehrliche Teil. Alles bisher Beschriebene wirkt erst, wenn die Pakete auf Ihrer Netzwerkkarte angekommen sind. 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. Bei kleinstmöglicher Paketgröße trägt diese Leitung rund 1,49 Millionen Pakete pro Sekunde, eine 10-Gbit/s-Leitung rund 14,88 Millionen. Das ist die physikalische Obergrenze, unabhängig von CPU, Kernel und Firewall. Ein normaler Serverkernel verarbeitet je nach Prozessor und Netzwerkkarte einige hunderttausend Pakete pro Sekunde, bevor er anfängt zu verwerfen.

Bei GoldSrc kommt eine Eigenheit dazu, die den Punkt nach vorn verschiebt. Der Spielserver läuft in einem einzigen Prozess und nutzt praktisch einen Rechenkern. Jedes verbindungslose Paket wird in derselben Schleife bearbeitet, die auch das Spiel berechnet. Ein Angriff, der Ihre Leitung nicht einmal zu einem Zehntel füllt, kann deshalb die Bildrate des Servers halbieren. Betreiber erleben das als "die Auslastung war doch gar nicht hoch, trotzdem war alles weg". Genau deshalb ist die Spalte FPS bei stats der aussagekräftigste einzelne Wert, den Sie haben.

Dem gegenüber stehen reale Angriffe. Zwei Beispiele aus dem Betrieb bei KernelHost, beide in Echtzeit gefiltert: ein UDP-Flood gegen einen Gameserver auf 7777/UDP mit über 112,2 Gbit/s und über 8,7 Millionen Paketen pro Sekunde, sowie ein Multi-Vektor-Angriff gegen einen Voice-Server auf 9987/UDP mit über 473,4 Gbit/s und über 41,5 Millionen Paketen pro Sekunde. Rechnen Sie das gegen Ihre Leitung: 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.

Deshalb sind die zwei verbreiteten Notbremsen unbefriedigend. Nullrouting (Blackholing) nimmt die angegriffene IP-Adresse aus dem Netz und beendet zwar den Angriff, aber auch Ihren Server: Für Ihre Spieler ist das Ergebnis identisch mit einem erfolgreichen Angriff. Eine reaktive Umleitung kostet in der Umschaltzeit genau die Minuten, in denen der Clanwar entschieden wird. Wirksam ist nur eine Filterung, die dauerhaft im Netz vor dem Server läuft.

Was KernelHost dagegen stellt

Der Dauerschutz, der in jedem Serverpaket enthalten ist

Der DDoS-Schutz von KernelHost ist zweistufig aufgebaut und permanent 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, lange bevor sie das Rechenzentrum erreichen.
• Stufe 2: Arbor-Echtzeitfilterung mit 3,2 Tbps in Frankfurt am Main. Direkt vor dem Server werden protokollspezifische Muster auf Layer 3 bis 7 erkannt und verworfen, Paket für Paket.

Zwei Eigenschaften sind entscheidend. Erstens läuft die Filterung dauerhaft, es gibt also keine Umschaltzeit, in der Ihre Spieler herausfliegen. Zweitens wird kein Nullrouting eingesetzt: Die angegriffene IP-Adresse bleibt im Netz, verworfen werden nur die schädlichen Pakete. Der Schutz ist in jedem Serverpaket ohne Aufpreis enthalten, ohne separates Schutzpaket und ohne Einrichtung, und er ist ab der Bereitstellung aktiv. Die Server stehen im maincubes Premium Datacenter in Frankfurt am Main. Welche Spiele und Protokolle abgedeckt sind, listet der Beitrag Gameserver-DDoS-Schutz in Echtzeit, und wie die Filterung für Spielprotokolle arbeitet, beschreibt der Beitrag Game-DDoS-Schutz mit Echtzeit-Filterung.

Advanced DDoS Protection für dauerhaft beschossene Projekte

Manche Projekte werden nicht gelegentlich, sondern gezielt und über Wochen angegriffen, mit wechselnden Mustern und immer genau zum verabredeten Matchtermin. Für diese Fälle 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. Ihr Server wird in unserem Netz auf diese Adresse umgestellt, ein Umbau auf Ihrer Seite ist nicht nötig.
• Selbst verwaltbare Schutzregeln je Port und Protokoll. Sie legen im Kundenbereich fest, welcher Port mit welchem Profil gefiltert wird, also 27015/UDP anders als der Webserver, der Ihre Karten ausliefert.
• Änderungen greifen in Echtzeit, ohne Ticket und ohne Wartezeit. Sie können also während eines laufenden Angriffs nachjustieren.
• Ein Schutzprofil passend zum jeweiligen Spiel. Counter-Strike 1.6, Sven Co-op und Half-Life 2: Deathmatch stehen ebenso in der Liste wie über 40 weitere Spiele und Protokolle, dazu freie TCP- und UDP-Profile für abweichend konfigurierte Server.

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.

Die beiden Stufen im Vergleich

Für die meisten Counter-Strike-1.6-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

Die Regel für 27015/TCP bewirkt nichts: Richtig, sie kann nichts bewirken. HLDS öffnet keinen TCP-Port, RCON läuft bei GoldSrc über verbindungslose UDP-Pakete auf dem Spielport. Die Zeile stammt aus einer Source-Anleitung. Arbeiten Sie stattdessen mit der Inhaltsprüfung aus Schritt 5, oder lassen Sie rcon_password gleich leer.

sv_max_queries_sec steht in der server.cfg und ändert nichts: Der Name gehört zur Source-Engine. In GoldSrc heißen die Variablen max_queries_sec, max_queries_sec_global und max_queries_window, alle ohne das Präfix sv_. Die Source-Schreibweise legt stillschweigend eine neue, unbenutzte Variable an, weshalb es auch keine Fehlermeldung gibt.

Der Server ist aus dem Serverbrowser verschwunden, läuft aber weiter: Prüfen Sie zuerst, ob der ausgehende Verkehr auf 26900/UDP funktioniert, denn darüber hält der Prozess die Anmeldung bei Steam. Prüfen Sie danach, ob sv_lan versehentlich auf 1 steht oder der Start mit -nomaster erfolgt ist. Dritte Möglichkeit: max_queries_sec_global ist zu niedrig, und die Abfragen der Listenseiten werden mitverworfen.

Alle Spieler haben hohen Ping, die Leitung ist aber nicht voll: Das deutet auf Paketrate statt Volumen hin. Sehen Sie sich die Spalte FPS in stats, die verworfenen Pakete in ip -s link show und die UDP-Zähler in nstat -az an. Steht im Systemprotokoll nf_conntrack: table full, nehmen Sie Spielport und Steam-Port mit notrack heraus.

Neue Spieler kommen nicht herein und sehen "No challenge for your address": Das ist das Muster einer Anmeldeflut. Die Challenge-Tabelle der unveränderten Engine fasst 1024 Einträge, und eine Flut aus gefälschten Adressen verdrängt die Challenge des echten Spielers, bevor er seinen connect schicken kann. Begrenzen Sie die verbindungslosen Pakete im Kernel und ziehen Sie eine gepflegte Fassung der Engine in Betracht, die die Challenge rechnet statt sie zu speichern.

Im Protokoll stehen laufend Zeilen mit "Bad Rcon": Jemand probiert Passwörter. Das ist kein volumetrischer Angriff, sondern ein Übernahmeversuch. Ändern Sie das Passwort, setzen Sie sv_rcon_banpenalty auf einen Wert über null und beschränken Sie RCON mit der Regel aus Schritt 5 auf Ihre eigene Adresse.

Die Firewall-Regel ist korrekt und wirkt trotzdem nicht: Prüfen Sie mit nft list ruleset beziehungsweise iptables -L INPUT -n -v, ob die Trefferzähler steigen. Bleiben sie bei null, wird die Regel nicht erreicht, weil sie hinter den UFW-Ketten steht oder nach dem letzten Neustart verloren ging. Steigen sie und es ändert sich nichts, ist die Leitung vor dem Server gesättigt, und ab da hilft nur Filterung im Netz.

Der Angriff pausiert nach einem IP-Wechsel und kommt nach ein bis zwei Tagen zurück: Das ist der Normalfall, denn Ihr Server veröffentlicht die neue Adresse selbst, sobald er wieder registriert ist, und ein vergessener DNS-Eintrag oder ein Bot mit Statusanzeige tut den Rest. Ein IP-Wechsel verschafft Stunden, keine Lösung.

Der Server stürzt reproduzierbar ab, ohne dass die Bandbreite auffällt: Meist kein DDoS-Angriff, sondern ein Absturzmuster in einer Erweiterung oder eine Serverbinärdatei, die nicht zu den geladenen Modulen passt. Bandbreite hilft hier nichts, eine passende Kombination aus Engine, Spielbibliothek und Erweiterungen schon.

Kurz zusammengefasst

• Ein Counter-Strike-1.6-Server braucht genau einen offenen Port nach außen: 27015/UDP. Spielverkehr, Serverabfrage und RCON teilen ihn sich, einen getrennten Query-Port gibt es bei GoldSrc nicht.
• RCON läuft bei GoldSrc über verbindungslose UDP-Pakete auf dem Spielport. Die Serverbinärdatei öffnet keinen TCP-Port, eine Freigabe für 27015/TCP zeigt ins Leere. Ausnahme ist Sven Co-op, dessen Handbuch 27015/TCP für RCON nennt.
• Die eingebaute Abfragebremse heißt in GoldSrc max_queries_sec, max_queries_sec_global und max_queries_window, ohne das Präfix sv_ der Source-Engine. Standardwerte sind 3.0, 30 und 60.
• Verbindungslose Pakete beginnen mit vier Byte 0xFF. Genau darauf gehört die Ratenbegrenzung im Kernel gelegt, denn der Verkehr verbundener Spieler hat diesen Kopf nicht und bleibt dadurch unberührt.
• Eine A2S_INFO-Anfrage ist 25 Byte lang, die Antwort ein Vielfaches davon; CISA beziffert den Verstärkungsfaktor des Steam-Protokolls mit 5,5. A2S_RULES liegt darüber, weil die Antwort mit der Zahl der Servervariablen wächst.
• sv_enableoldqueries gehört auf 0. Auf 1 beantwortet der Server wieder die alten Abfragen ohne Prüfung und wird damit zum Verstärker gegen Dritte.
• Bei 64 Byte großen Paketen trägt eine 1-Gbit/s-Leitung rund 1,49 Millionen Pakete pro Sekunde. Darüber entscheidet ausschließlich das Netz vor dem Server, keine Einstellung auf dem Server selbst.
• Bei KernelHost filtern 17 Tbps globales Scrubbing und eine Arbor-Echtzeitfilterung mit 3,2 Tbps in Frankfurt am Main dauerhaft und ohne Aufpreis, ohne Nullrouting und ohne Umschaltzeit.

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 unser Team die Filterregeln für Ihre IP-Adresse nachjustiert. Bei einem laufenden Angriff erreichen Sie uns zusätzlich über den WhatsApp-Notfallchat unter +43 650 8209883. Nennen Sie dabei gleich vier Angaben: IP-Adresse, Port, Zeitraum in Ihrer Zeitzone und was Sie sehen (Spieler fliegen heraus, Server nicht im Browser, hoher Ping). Das erspart eine Rückfragerunde, und die zählt, wenn gerade ein Match läuft.

Hosten Sie woanders und werden regelmäßig beschossen, ist der Umzug zu KernelHost der kürzere Weg als jede weitere Regel auf einem Server, dessen Leitung vorher endet. Der Dauerschutz ist Teil jedes Serverpakets, nicht ein Zusatz, den Sie erst im Ernstfall buchen.