Lineage-2-Server vor DDoS-Angriffen schützen

Ein privater Lineage-2-Server, bei dem abends niemand mehr über den Anmeldebildschirm hinauskommt, während die Spieler in der Welt ungestört weiterspielen, hat kein Hardwareproblem. Das ist der Fingerabdruck eines DDoS-Angriffs auf den Login-Server, und genau dort muss ein Lineage-2-DDoS-Schutz ansetzen. Dieser Beitrag zeigt zuerst, was Sie ohne Zusatzkosten selbst absichern können, danach, wo diese Maßnahmen technisch aufhören, und zum Schluss, was dann im Netz vor dem Server passieren muss.

Alle Angaben beziehen sich auf L2J und seine Ableger (L2J-Mobius, aCis) unter Debian 12, Debian 13, Ubuntu 22.04 LTS oder Ubuntu 24.04 LTS sowie auf L2OFF-Pakete mit AuthD, CacheD und L2Server. Die Befehle sind für root geschrieben, als normaler Benutzer stellen Sie sudo voran.

Wenn der Angriff gerade läuft: Ändern Sie jetzt nichts an der Konfiguration und starten Sie weder Login-Server noch Game-Server neu. Sichern Sie zuerst die Messwerte (siehe Abschnitt "Protokollieren"), nach dem Angriff sind sie weg.

Lineage-2-Server vor DDoS schützen: warum private L2-Server angegriffen werden

Ein privater Lineage-2-Server vereint mehrere Eigenschaften, die ihn zu einem bequemen Ziel machen, und der Lineage-2-DDoS-Schutz muss genau an diesen Eigenschaften ansetzen. Erstens ist Ihre Adresse öffentlich, und zwar von Anfang an: Spieler laden einen gepatchten System-Ordner herunter, und in dessen l2.ini steht die Zeile ServerAddr= mit der IP-Adresse Ihres Login-Servers. Jeder, der Ihr Projekt einmal installiert hat, kennt diese Adresse, unabhängig davon, ob er je eine Figur erstellt hat.

Zweitens ist die Spielerschaft an feste Zeiten gebunden. Belagerungen, Epic-Raidbosse und Events stehen im Kalender, ein Ausfall zu genau dieser Stunde ist maximal sichtbar. Drittens stehen Projekte in direkter Konkurrenz zueinander: Wer einen Server öffnet, wirbt um dieselben paar tausend Spieler wie drei andere Projekte am selben Wochenende. Das Ausschalten eines Konkurrenten ist in dieser Szene eine gängige Strategie. Ein Angriff wird dabei als Dienstleistung gebucht (in der Szene läuft das unter Booter oder Stresser) und kostet den Auftraggeber weder Können noch nennenswertes Geld. Was ein DDoS-Angriff im Detail ist, erklärt der Beitrag Was ist ein DDoS-Angriff?.

Warum der Login-Server auf Port 2106 das eigentliche Ziel ist

Lineage 2 ist auf zwei getrennte Prozesse aufgeteilt: einen Login-Server und einen oder mehrere Game-Server. Der Client verbindet sich zuerst auf 2106 TCP zum Login-Server, meldet sich an, bekommt von dort die Serverliste mit der externen Adresse und dem Port des Game-Servers und baut danach eine zweite Verbindung auf 7777 TCP zum Game-Server auf. Beide Prozesse haben eigene Konfigurationsdateien, eigene Ports und eigene Belastungsgrenzen.

Daraus folgt das Angriffsmuster, das L2-Betreiber immer wieder beschreiben: Ein Flood auf 2106 blockiert ausschließlich neue Anmeldungen. Wer bereits in der Welt steht, spielt weiter, bis er selbst die Verbindung verliert. Die Online-Anzeige sinkt also langsam statt schlagartig, und im Forum steht "Server läuft, aber ich komme nicht rein". Genau dieses Bild unterscheidet einen Angriff auf den Login-Server von einem Angriff auf den Game-Server, bei dem alle gleichzeitig herausfliegen.

Der Login-Server ist außerdem das billigere Ziel, weil der Aufwand ungleich verteilt ist. Der L2J-Login-Server erzeugt beim Start einen Vorrat von zehn RSA-Schlüsselpaaren mit 1024 Bit und zwanzig Blowfish-Schlüsseln. Jeder Anmeldeversuch kostet den Client das Absenden eines Pakets und den Server eine Entschlüsselung mit dem privaten RSA-Schlüssel. Eine halbfertige Sitzung belegt dabei einen Platz, bis der eingebaute Zeitgeber sie verwirft: LOGIN_TIMEOUT steht im Quelltext auf 60 Sekunden. Die Voreinstellung MaxConnectionPerIP = 50 erlaubt jeder Quelladresse fünfzig gleichzeitige Verbindungen. Tausend Quelladressen genügen damit für 50.000 gleichzeitig offene Sitzungen, die jeweils bis zu eine Minute bestehen bleiben.

Dazu kommt eine Eigenheit des Spiels, die es von den meisten Gameservern unterscheidet: Lineage 2 läuft ausschließlich über TCP. Der Hersteller nennt für das Spiel die TCP-Ports 80, 2009, 2106 und 7777, und bei UDP ausschließlich Port 53 für die Namensauflösung. Es gibt also keinen UDP-Spielverkehr, den man filtern müsste, dafür ist der klassische SYN-Flood mit gefälschten Absenderadressen direkt wirksam, und die Verbindungsverfolgung des Kernels wird zum ersten Engpass.

Warum Angriffe auf Lineage-2-Server saisonal zu Server-Starts auftreten

Angriffe auf private Lineage-2-Server treten gehäuft rund um Server-Starts auf, weil Datum und Uhrzeit der Eröffnung Wochen vorher öffentlich bekannt sind. Eröffnungskalender für Lineage-2-Projekte listen kommende Starts nach Chronik (Interlude, High Five, Classic, Essence), dazu die Raten und die genaue Startzeit, und sie werden täglich aktualisiert. Der Angreifer muss nichts auskundschaften: Der für ihn günstigste Zeitpunkt steht in der Ankündigung des Betreibers.

Der zweite Grund ist wirtschaftlich. Ein privater Lineage-2-Server verdient sein Geld vorn: Die gesamte Spielerbasis wird in den ersten Tagen geworben, die Spenden fallen in den ersten Wochen an, danach schrumpft die Bevölkerung stetig. Ein Spieler, der in der ersten Stunde nicht hineinkommt, wechselt zum Projekt, das am selben Wochenende startet, und dieses Projekt gibt es immer. Eine Stunde Ausfall am Eröffnungstag kostet deshalb nicht eine Stunde Umsatz, sondern einen Teil der gesamten Lebensdauer des Servers.

Der dritte Grund ist technisch. Am Grand Opening versuchen tausende Spieler gleichzeitig, sich anzumelden. Der Login-Server ist in genau dieser Minute ohnehin am Limit, und ein zusätzlicher Flood ist von der Spitzenlast kaum zu unterscheiden. Ein Angriff, der an einem ruhigen Dienstag folgenlos bliebe, reicht zur Eröffnungsstunde aus. Dasselbe gilt für angekündigte Termine im laufenden Betrieb: Burgbelagerungen und Epic-Raidbosse stehen im Kalender und sind aus demselben Grund beliebte Angriffsfenster. Nach dem Eröffnungsansturm sinkt der Anreiz wieder, weshalb Betreiber die Angriffe als wellenförmig und nicht als Dauerzustand erleben.

Die Ports, um die es tatsächlich geht

Die folgende Tabelle listet die Ports eines privaten Lineage-2-Servers, die zugehörige Konfigurationsdatei und die Direktive, die den Wert setzt. Die Voreinstellungen stammen aus den mitgelieferten Konfigurationsdateien von L2J beziehungsweise aus den Einrichtungsanleitungen für L2OFF-Pakete.

Zwei Fragen beantwortet diese Tabelle mit: Lineage 2 hat weder einen Query-Port noch einen RCON-Port. Es gibt keinen separaten Dienst, der den Spielerstand für eine Serverliste ausliefert, und keinen Fernsteuerungsport wie bei Spielen auf Source-Basis. Die Serverliste erzeugt der Login-Server selbst und schickt sie über dieselbe Verbindung auf 2106 an den angemeldeten Client. Die Fernsteuerung läuft in L2J über Befehle im Spiel und über die Datenbank. Damit entfallen zwei Angriffsvektoren, die andere Spiele haben, und es bleibt umso mehr an Port 2106 hängen.

Größenordnungen, die Sie kennen sollten

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

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

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 -lntp

Interessant ist die Spalte mit der lokalen Adresse. 0.0.0.0:2106 und 0.0.0.0:7777 gehören dorthin. 0.0.0.0:9014 und 0.0.0.0:3306 sind Fehler: Das sind die beiden Ports, über die sich ein Angreifer in Ihre Serverliste hängen oder Ihre Datenbank abklopfen kann. 127.0.0.1:3306 bedeutet dagegen "nur lokal" und braucht keine Firewall-Regel. Die Sicht des Angreifers liefert ein Portscan von außen:

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

2. Port 9014 und die Datenbank aus dem offenen Netz halten

Port 9014 ist der Kanal, über den sich der Game-Server beim Login-Server anmeldet, und er gehört unter keinen Umständen ins offene Netz. L2J liefert dafür bereits die richtige Voreinstellung aus: LoginHostname = 127.0.0.1 bindet den Port an die Loopback-Schnittstelle, er ist von außen also gar nicht erreichbar. Laufen Login-Server und Game-Server auf zwei verschiedenen Maschinen, tragen Sie statt * die konkrete interne Adresse ein und geben Sie den Port ausschließlich für die Gegenstelle frei.

Dieselbe Regel gilt für die Datenbank. Prüfen Sie in /etc/mysql/mariadb.conf.d/50-server.cnf, dass dort steht:

bind-address = 127.0.0.1

Und tauschen Sie den Datenbankbenutzer aus. Die mitgelieferte Server.properties steht auf Login = root, und die Datei selbst kommentiert das mit dem Hinweis, dass genau das nicht empfohlen ist. Wie Sie einen eigenen Benutzer mit minimalen Rechten anlegen, steht in MariaDB und MySQL absichern. Danach kontrollieren Sie das Ergebnis:

ss -lntp | grep -E ':9014|:3306'

Die Firewall darüber bleibt kurz. Für einen Lineage-2-Server reichen zwei Freigaben nach außen, und zwar genau in dieser Reihenfolge, damit Sie sich nicht selbst aussperren:

ufw allow 22/tcp comment 'SSH'
ufw allow 2106/tcp comment 'L2 Login'
ufw allow 7777/tcp comment 'L2 Game'
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

Die vollständige Anleitung samt Rettungsweg finden Sie unter UFW-Firewall einrichten, ohne sich selbst auszusperren.

3. AcceptNewGameServer abschalten, sobald Ihr Server registriert ist

In der LoginServer.properties steht ab Werk AcceptNewGameServer = True, und der Kommentar darüber beschreibt genau, was das bedeutet: Jeder Game-Server darf sich auf einem freien Platz Ihres Login-Servers registrieren. Solange 9014 nur auf der Loopback-Schnittstelle liegt, ist das folgenlos. Sobald der Port aus einem anderen Grund erreichbar wird, ist es eine offene Tür. Setzen Sie den Wert deshalb auf False, sobald Ihr eigener Game-Server einmal registriert ist und seine Kennung hat:

AcceptNewGameServer = False

Im Gegenstück auf der Game-Server-Seite steht AcceptAlternateID = True. Das ist beim Aufbau bequem, weil der Login-Server dann eine andere Kennung vergibt, wenn die gewünschte belegt ist. Auf einem Produktivsystem wollen Sie das Gegenteil: eine feste Kennung, und einen Fehler, wenn sie belegt ist.

4. Die Flood-Protection des Login-Servers richtig einstellen

L2J bringt eine eigene Verbindungsbremse im Login-Server mit. Sie steht in der LoginServer.properties, und alle Zeitwerte sind Millisekunden:

EnableFloodProtection = True
FastConnectionLimit = 15
NormalConnectionTime = 700
FastConnectionTime = 350
MaxConnectionPerIP = 50

Die Werte hängen zusammen. Eine Verbindung, die weniger als FastConnectionTime nach der vorigen aus derselben Quelladresse eintrifft, zählt als schnell. Nach FastConnectionLimit solchen Verbindungen wird die Adresse abgewiesen. NormalConnectionTime ist der Abstand, ab dem der Zähler wieder abgebaut wird. MaxConnectionPerIP ist die Obergrenze gleichzeitig offener Verbindungen je Adresse.

Fünfzig gleichzeitige Verbindungen sind für einen einzelnen Spieler sehr großzügig, und niedrigere Werte helfen spürbar. Trotzdem ist hier Vorsicht geboten: Mehrere Spieler im selben Haushalt, ein Internetcafé und vor allem Anschlüsse hinter einer Carrier-NAT (in der L2-Szene betrifft das viele Spieler aus der Türkei, aus Brasilien und aus Teilen Osteuropas) teilen sich eine öffentliche Adresse. Wer hier auf 3 stellt, sperrt echte Spieler aus. Messen Sie zuerst eine Woche im Normalbetrieb, senken Sie dann in Schritten.

Und eine Einschränkung, die Sie kennen müssen: Diese Bremse läuft im Java-Prozess des Login-Servers. Jedes Paket, über das sie entscheidet, ist bereits über Ihre Leitung gelaufen und hat bereits Rechenzeit gekostet. Gegen eine Handvoll Quellen wirkt sie, gegen ein Botnetz nicht.

5. Fehlversuche begrenzen und banned_ip.cfg nutzen

Zwei weitere Direktiven in der LoginServer.properties steuern, wie lange jemand raten darf:

LoginTryBeforeBan = 5
LoginBlockAfterBan = 900

LoginTryBeforeBan ist die Zahl ungültiger Kombinationen aus Konto und Kennwort, nach der die Adresse gesperrt wird, LoginBlockAfterBan ist die Sperrdauer in Sekunden (900 entspricht 15 Minuten). Danach beginnt die Zählung von vorn.

Dauerhafte Sperren tragen Sie in die Datei banned_ip.cfg im Konfigurationsverzeichnis des Login-Servers ein. Erlaubt sind einzelne Adressen, ganze Netze und ein optionaler Ablaufzeitpunkt als Unix-Zeitstempel in Millisekunden, alles nach # ist ein Kommentar:

198.51.100.7
203.0.113.0
198.51.100.44 1789689600000

Setzen Sie außerdem AutoCreateAccounts = False. Die Voreinstellung True legt bei jeder Anmeldung mit einem unbekannten Kontonamen automatisch ein Konto an. Das ist beim Aufbau praktisch und im Betrieb ein Geschenk: Ein Angreifer erzeugt damit beliebig viele Konten, und jedes davon darf die Serverliste mit der Adresse Ihres Game-Servers abrufen. Lassen Sie Konten stattdessen über die Registrierung auf Ihrer Webseite entstehen, dann kontrollieren Sie, wer eine Kennung bekommt.

6. Verbindungsraten auf 2106 und 7777 im Kernel begrenzen

Was die Java-Bremse zu spät entscheidet, entscheidet der Kernel früher und billiger. Gegen kleine Angriffe und unsaubere Bots hilft eine Obergrenze je Quelladresse:

iptables -I INPUT -p tcp --dport 2106 --syn -m connlimit --connlimit-above 8 --connlimit-mask 32 -j DROP
iptables -I INPUT -p tcp --dport 2106 --syn -m hashlimit --hashlimit-name l2login --hashlimit-mode srcip --hashlimit-above 6/sec --hashlimit-burst 20 -j DROP
iptables -I INPUT -p tcp --dport 7777 --syn -m connlimit --connlimit-above 6 --connlimit-mask 32 -j DROP

Die erste Regel verwirft neue Verbindungen zum Login-Server, sobald eine Adresse mehr als acht davon gleichzeitig offen hat. Ein regulärer Client braucht genau eine. Die zweite begrenzt die Neuverbindungsrate auf sechs pro Sekunde je Adresse mit einem Puffer von zwanzig, was einen Wiederverbindungssturm nach einem Serverneustart noch durchlässt. Die dritte erlaubt auf dem Game-Server sechs gleichzeitige Verbindungen je Adresse, weil Mehrfachanmeldung (Dualbox und Triplebox) in Lineage 2 normal ist und eine zu enge Grenze Ihre zahlenden Spieler trifft.

Alle drei Zahlen sind Startwerte, keine Wahrheiten. Ein Server mit 2000 gleichzeitigen Spielern verhält sich anders als einer mit 200. Messen Sie erst, stellen Sie dann ein. Reine iptables-Regeln sind nach einem Neustart weg, unter Debian und Ubuntu sichert man sie so:

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

Unter UFW gehören solche Regeln in /etc/ufw/before.rules, weil sie sonst beim nächsten ufw reload verschwinden.

7. SYN-Flood abfangen: syncookies, Backlog und Verbindungsverfolgung

Weil Lineage 2 ausschließlich über TCP läuft, ist der SYN-Flood der naheliegende Vektor. Ein SYN-Flood ist ein Angriff, der Verbindungsanfragen mit gefälschten Absenderadressen schickt und die Bestätigung nie beantwortet, sodass der Server für jede Anfrage Speicher reserviert, der nie benutzt wird. Vier Einstellungen entschärfen das:

sysctl -w net.ipv4.tcp_syncookies=1
sysctl -w net.ipv4.tcp_max_syn_backlog=8192
sysctl -w net.core.somaxconn=4096
sysctl -w net.ipv4.tcp_synack_retries=2

SYN-Cookies sind dabei die wichtigste Zeile: Der Kernel beantwortet die Anfrage, ohne sich etwas zu merken, und legt den Zustand erst an, wenn die Gegenstelle die Verbindung wirklich abschließt. Gefälschte Absender laufen damit ins Leere. Dauerhaft werden die Werte in einer Datei unter /etc/sysctl.d/ abgelegt und mit sysctl --system geladen.

Ein oft übersehener Engpass ist die Verbindungsverfolgung des Kernels. Läuft sie voll, verwirft der Server auch legitime Pakete, und im Protokoll steht "nf_conntrack: table full, dropping packet". Stand und Obergrenze zeigt:

sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max

8. Webseite, Login-Server und Game-Server auf getrennte IP-Adressen

Die Projektwebseite mit Registrierung, Spendenshop und Vote-Seiten ist über Ihre Domain immer auffindbar. Liegt sie auf derselben IP-Adresse wie der Login-Server, legt ein Angriff auf die Webseite gleichzeitig die Anmeldung lahm, und umgekehrt. Trennen Sie die drei Rollen auf verschiedene Adressen. Dann bleibt bei einem Angriff auf die Webseite das Spiel erreichbar, und bei einem Angriff auf 2106 spielen die bereits verbundenen Spieler weiter.

Halten Sie dabei die DNS-Einträge sauber. Der häufigste Fehler ist ein vergessener A-Eintrag auf eine frühere Adresse: Er macht jeden Adresswechsel wirkungslos, weil der Angreifer die neue Adresse über denselben Namen findet wie Ihre Spieler.

Und hier gehört Ehrlichkeit statt Wunschdenken hin: Die Adresse Ihres Login-Servers lässt sich nicht geheim halten. Sie steht in der l2.ini im System-Ordner, den jeder Spieler herunterlädt. Die Adresse des Game-Servers wiederum verteilt der Login-Server selbst: In L2J steht sie als externe Adresse in der ipconfig.xml (in älteren Ablegern als ExternalHostname in der Server.properties), und sie wird jedem Client mitgeteilt, der sich erfolgreich angemeldet hat. Verstecken ist keine Strategie, Filtern ist eine.

9. Protokollieren, damit Sie im Ernstfall Daten haben

Der wichtigste Schritt ist der, den fast niemand vorher macht: eine Vergleichsbasis anlegen, solange alles normal läuft. Ohne Normalwert können Sie nach einem Vorfall nicht sagen, ob 40.000 Pakete pro Sekunde viel waren oder einfach Samstagabend. 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
ss -tn state syn-recv | wc -l
ip -s link show eth0
tcpdump -ni eth0 'tcp port 2106' -c 200 -q

Die zweite Zeile ist bei Lineage 2 die aussagekräftigste: Sie zählt die halboffenen Verbindungen. Ein fünfstelliger Wert bei ein paar hundert Spielern ist ein SYN-Flood und nichts anderes. Bei tcpdump gilt: immer mit -c begrenzen, ein Mitschnitt unter Volllast belastet einen ohnehin überlasteten Server zusätzlich. Wie Sie die Werte auswerten, steht in DDoS-Angriff erkennen.

Wo diese Maßnahmen aufhören

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

Rechnen Sie einmal mit. Ein typischer Gameserver hängt an 1 Gbit/s, das sind 125 Megabyte pro Sekunde, und die Leitung ist voll, sobald jemand mehr schickt. Gegen einen Lineage-2-Server genügt dafür nicht einmal ein großer Angriff, weil die zweite Größe früher zuschlägt: die Paketrate. Bei kleinen Paketen von 64 Byte passen in eine Leitung mit 1 Gbit/s rund 1,49 Millionen Pakete pro Sekunde. Ein normaler Serverkernel verarbeitet je nach CPU und Netzwerkkarte einige hunderttausend davon, bevor er anfängt zu verwerfen.

Bei einem reinen TCP-Spiel kommt eine dritte Grenze dazu. Jede halboffene Verbindung belegt einen Eintrag in der Verbindungsverfolgung und im Backlog, und der L2J-Login-Server hält seine Sitzungen bis zu 60 Sekunden. Ein Angriff mit wenigen hunderttausend Paketen pro Sekunde, der Ihre Leitung nicht einmal zu einem Drittel füllt, kann die Anmeldung also vollständig blockieren. Betreiber erleben das als "die Auslastung war doch gar nicht hoch, trotzdem kam niemand rein".

Zur Einordnung, welche Größenordnungen real vorkommen: Auf KernelHost-Servern wurden unter anderem ein Angriff mit über 112,2 Gbit/s bei über 8,7 Millionen Paketen pro Sekunde gegen einen Gameserver und ein Multi-Vektor-Angriff mit über 473,4 Gbit/s bei über 41,5 Millionen Paketen pro Sekunde gegen einen Voice-Server gefiltert. Dafür gibt es keine lokale Einstellung. Volumetrische Angriffe müssen im Netz vor dem Server enden. Was im akuten Fall zu tun ist, steht in Schwerer DDoS-Angriff: was tun?.

Was KernelHost dagegen stellt

Der Dauerschutz, der auf jedem Server inklusive ist

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

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

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

Advanced DDoS Protection für dauerhaft beschossene Projekte

Manche Projekte werden nicht gelegentlich, sondern gezielt und über Wochen angegriffen, und in der Lineage-2-Szene ist das der Normalfall für jeden Server, der es in die oberen Ränge der Serverlisten schafft. 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 im eigenen Netz umgestellt wird. Auf Ihrer Seite ist kein Umbau nötig.
• Selbst verwaltbare Schutzregeln je Port und Protokoll im Kundenbereich: Sie stellen getrennt ein, was auf 2106 TCP erlaubt ist und was auf 7777 TCP. Das ist bei Lineage 2 der entscheidende Punkt, weil die beiden Ports völlig unterschiedliche Verkehrsmuster haben: viele kurze Verbindungen auf der einen Seite, wenige sehr lange auf der anderen.
• Änderungen greifen in Echtzeit, Sie können also während eines laufenden Angriffs nachjustieren, und Sie können die Regeln vor der Eröffnungsstunde schärfer stellen und danach wieder lockern.
• Schutzprofil passend zur Anwendung, auch für modifizierte und eigene Serverdateien auf beliebigen TCP- oder UDP-Ports. Ob Sie L2J, L2J-Mobius, aCis oder ein L2OFF-Paket betreiben, spielt für das Regelwerk keine Rolle, weil es auf Port und Protokoll aufsetzt.

Die beiden Stufen im Vergleich

Für die meisten Lineage-2-Projekte reicht der inkludierte Dauerschutz zusammen mit einer sauberen Serverkonfiguration. Die Advanced DDoS Protection ist die Antwort darauf, dass jemand es persönlich nimmt, und das passiert erfahrungsgemäß in der Woche vor dem Grand Opening.

Häufige Fehler und Lösungen

"Der Login geht nicht, aber der Game-Server läuft normal": Das ist kein Zufall, sondern die übliche Form eines Angriffs auf einen Lineage-2-Server. Login-Server und Game-Server sind zwei Prozesse auf zwei Ports. Messen Sie ss -tn state syn-recv | wc -l und sar -n DEV 1 10. Steigen die halboffenen Verbindungen, während die Bandbreite unauffällig bleibt, ist es ein Verbindungs-Flood auf 2106.

"Ich habe die IP-Adresse gewechselt und war am nächsten Tag wieder offline": Der Angreifer bekommt die neue Adresse auf demselben Weg wie Ihre Spieler, nämlich über den neuen System-Ordner mit der geänderten l2.ini, über Ihre Ankündigung oder über einen vergessenen DNS-Eintrag. Ein Adresswechsel ist Zeitgewinn, keine Lösung.

"Ich habe MaxConnectionPerIP auf 3 gesetzt, jetzt beschweren sich Spieler": Dualbox ist in Lineage 2 üblich, und Spieler hinter einer Carrier-NAT teilen sich eine öffentliche Adresse mit hunderten anderen. Gehen Sie zurück auf einen Wert, der Ihre Messwerte aus dem Normalbetrieb abdeckt, und begrenzen Sie stattdessen die Neuverbindungsrate im Kernel.

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

"Alle Spieler haben Lag-Spikes, die Leitung ist aber ruhig": Dann ist es kein DDoS-Angriff. Bei einem Java-Server sind die üblichen Verdächtigen Pausen der Speicherbereinigung, eine Datenbank ohne passende Indizes und ein Skript oder ein Custom-Event in einer Schleife. Prüfen Sie zuerst sar -n DEV 1 10: Bleiben die Paketraten normal, liegt die Ursache im Server und nicht im Netz.

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

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

"Mein Grand Opening ist in zwei Wochen": Dann ziehen Sie jetzt um und nicht in der Startwoche. Ein Umzug kostet einen neuen System-Ordner für die Spieler, eine DNS-Umstellung und einen Testlauf. All das wollen Sie hinter sich haben, bevor Sie das Datum ankündigen, denn ab der Ankündigung kennt jeder Konkurrent Ihren ungünstigsten Zeitpunkt.

Kurz zusammengefasst

• Ein privater Lineage-2-Server braucht genau zwei Ports im offenen Netz: 2106 TCP für den Login-Server und 7777 TCP für den Game-Server. Port 9014, die Datenbank (3306 bei L2J, 1433 bei L2OFF) und die internen L2OFF-Ports 2002, 2006, 2008, 2104 und 2108 gehören nicht dazu.
• Lineage 2 läuft ausschließlich über TCP und hat weder einen Query-Port noch einen RCON-Port. Der typische Angriff ist deshalb ein SYN- oder Verbindungs-Flood auf Port 2106 und kein UDP-Flood.
• Ein Angriff auf den Login-Server blockiert nur neue Anmeldungen. Wenn niemand hereinkommt, während die Spieler in der Welt weiterspielen, ist die Ursache auf Port 2106 zu suchen und nicht auf 7777.
• Stellen Sie EnableFloodProtection, MaxConnectionPerIP, LoginTryBeforeBan und AutoCreateAccounts bewusst ein, setzen Sie AcceptNewGameServer nach der Registrierung auf False und begrenzen Sie Verbindungsraten zusätzlich im Kernel, weil die Java-Bremse erst hinter der Leitung greift.
• Angriffe auf Lineage-2-Server häufen sich zu Server-Starts, weil Datum und Uhrzeit Wochen vorher öffentlich sind und der wirtschaftliche Schaden am Eröffnungstag am größten ist. Der Schutz muss vor der Ankündigung stehen, nicht danach.
• Oberhalb der Leitungskapazität und oberhalb einiger hunderttausend Pakete pro Sekunde entscheidet ausschließlich die Filterung im Netz vor dem Server. Bei KernelHost ist sie zweistufig, dauerhaft aktiv, ohne Aufpreis und ohne Nullrouting.

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