Lineage-2-server beschermen tegen DDoS-aanvallen

Een private Lineage-2-server waar 's avonds niemand meer voorbij het inlogscherm komt terwijl de spelers in de wereld ongestoord doorspelen, heeft geen hardwareprobleem. Dat is de vingerafdruk van een DDoS-aanval op de loginserver, en precies daar moet een Lineage-2-DDoS-bescherming aangrijpen. Dit artikel laat eerst zien wat u zonder extra kosten zelf kunt afschermen, daarna waar die maatregelen technisch ophouden, en tot slot wat er dan in het netwerk vóór de server moet gebeuren.

Alle informatie hier gaat uit van L2J en zijn afgeleiden (L2J-Mobius, aCis) onder Debian 12, Debian 13, Ubuntu 22.04 LTS of Ubuntu 24.04 LTS, en van L2OFF-pakketten met AuthD, CacheD en L2Server. De commando's zijn voor root geschreven; als gewone gebruiker zet u er sudo voor.

Loopt de aanval op dit moment: verander nu niets aan de configuratie en start noch de loginserver noch de gameserver opnieuw op. Leg eerst de meetwaarden vast (zie de paragraaf "Vastleggen"), na de aanval zijn ze verdwenen.

Lineage-2-server beschermen tegen DDoS: waarom private L2-servers worden aangevallen

Een private Lineage-2-server verenigt meerdere eigenschappen die hem tot een gemakkelijk doelwit maken, en de Lineage-2-DDoS-bescherming moet precies bij die eigenschappen aangrijpen. Ten eerste is uw adres openbaar, en wel vanaf het begin: spelers downloaden een gepatchte System-map, en in de l2.ini daarvan staat de regel ServerAddr= met het IP-adres van uw loginserver. Iedereen die uw project ooit heeft geïnstalleerd, kent dat adres, ongeacht of hij ooit een personage heeft aangemaakt.

Ten tweede zit de spelersgroep vast aan vaste tijden. Belegeringen, epic-raidbosses en events staan in de kalender, een uitval op precies dat uur is maximaal zichtbaar. Ten derde staan projecten in directe concurrentie met elkaar: wie een server opent, werft om dezelfde paar duizend spelers als drie andere projecten in hetzelfde weekend. Het uitschakelen van een concurrent is in deze scene een gangbare strategie. Een aanval wordt daarbij als dienst geboekt (in de scene heet dat booter of stresser) en kost de opdrachtgever kunde noch noemenswaardig geld. Wat een DDoS-aanval precies is, legt het artikel Wat is een DDoS-aanval? uit.

Waarom de loginserver op poort 2106 het eigenlijke doelwit is

Lineage 2 is opgesplitst in twee gescheiden processen: een loginserver en een of meer gameservers. De client verbindt eerst op 2106 TCP met de loginserver, meldt zich aan, krijgt daar de serverlijst met het externe adres en de poort van de gameserver, en bouwt daarna een tweede verbinding op naar 7777 TCP bij de gameserver. Beide processen hebben eigen configuratiebestanden, eigen poorten en eigen belastingsgrenzen.

Daaruit volgt het aanvalspatroon dat L2-beheerders steeds opnieuw beschrijven: een flood op 2106 blokkeert uitsluitend nieuwe aanmeldingen. Wie al in de wereld staat, speelt door totdat hij zelf de verbinding verliest. De online-teller daalt dus langzaam in plaats van abrupt, en op het forum staat "server draait, maar ik kom er niet in". Precies dat beeld onderscheidt een aanval op de loginserver van een aanval op de gameserver, waarbij iedereen tegelijk eruit vliegt.

De loginserver is bovendien het goedkopere doelwit, omdat de inspanning ongelijk verdeeld is. De L2J-loginserver maakt bij het starten een voorraad van tien RSA-sleutelparen van 1024 bit en twintig Blowfish-sleutels aan. Elke aanmeldpoging kost de client het versturen van één pakket en de server een ontsleuteling met de private RSA-sleutel. Een halfafgemaakte sessie bezet daarbij een plaats totdat de ingebouwde timer haar verwerpt: LOGIN_TIMEOUT staat in de broncode op 60 seconden. De standaardinstelling MaxConnectionPerIP = 50 staat elk bronadres vijftig gelijktijdige verbindingen toe. Duizend bronadressen volstaan daarmee voor 50.000 gelijktijdig open sessies, die elk tot een minuut lang blijven bestaan.

Daar komt een eigenaardigheid van het spel bij die het van de meeste gameservers onderscheidt: Lineage 2 loopt uitsluitend over TCP. De fabrikant noemt voor het spel de TCP-poorten 80, 2009, 2106 en 7777, en bij UDP uitsluitend poort 53 voor de naamomzetting. Er is dus geen UDP-spelverkeer dat gefilterd zou moeten worden, maar daardoor is de klassieke SYN-flood met vervalste afzenderadressen direct werkzaam, en wordt de verbindingsregistratie van de kernel het eerste knelpunt.

Waarom aanvallen op Lineage-2-servers seizoensgebonden rond serverstarts optreden

Aanvallen op private Lineage-2-servers treden geconcentreerd rond serverstarts op, omdat datum en tijdstip van de opening weken van tevoren openbaar bekend zijn. Openingskalenders voor Lineage-2-projecten vermelden komende starts per chronicle (Interlude, High Five, Classic, Essence), daarbij de rates en de exacte starttijd, en ze worden dagelijks bijgewerkt. De aanvaller hoeft niets te verkennen: het voor hem gunstigste moment staat in de aankondiging van de beheerder.

De tweede reden is economisch. Een private Lineage-2-server verdient zijn geld vooraan: de volledige spelersbasis wordt in de eerste dagen geworven, de donaties vallen in de eerste weken, daarna krimpt de bevolking gestaag. Een speler die in het eerste uur niet binnenkomt, stapt over naar het project dat in hetzelfde weekend start, en dat project is er altijd. Een uur uitval op de openingsdag kost daarom niet één uur omzet, maar een deel van de volledige levensduur van de server.

De derde reden is technisch. Bij de grand opening proberen duizenden spelers zich tegelijk aan te melden. De loginserver zit op precies die minuut toch al aan zijn grens, en een extra flood is nauwelijks van de piekbelasting te onderscheiden. Een aanval die op een rustige dinsdag zonder gevolgen zou blijven, volstaat op het openingsuur. Hetzelfde geldt voor aangekondigde momenten tijdens het lopende bedrijf: kasteelbelegeringen en epic-raidbosses staan in de kalender en zijn om dezelfde reden geliefde aanvalsvensters. Na de openingsdrukte daalt de prikkel weer, waardoor beheerders de aanvallen als golfbeweging ervaren en niet als permanente toestand.

De poorten waar het werkelijk om gaat

De volgende tabel vermeldt de poorten van een private Lineage-2-server, het bijbehorende configuratiebestand en de directive die de waarde zet. De standaardinstellingen komen uit de meegeleverde configuratiebestanden van L2J respectievelijk uit de installatiehandleidingen voor L2OFF-pakketten.

Twee vragen beantwoordt deze tabel meteen: Lineage 2 heeft noch een querypoort noch een RCON-poort. Er is geen aparte dienst die de spelersstand voor een serverlijst uitlevert, en geen afstandsbedieningspoort zoals bij spellen op Source-basis. De serverlijst maakt de loginserver zelf en stuurt die over dezelfde verbinding op 2106 naar de aangemelde client. De afstandsbediening loopt in L2J via commando's in het spel en via de database. Daarmee vervallen twee aanvalsvectoren die andere spellen wel hebben, en blijft er des te meer aan poort 2106 hangen.

Ordes van grootte die u moet kennen

Wat u zelf kunt doen voordat u geld uitgeeft

Dit hoofdstuk is het langste, en dat met opzet. Een netjes geconfigureerde Lineage-2-server houdt kleine en middelgrote aanvallen op eigen kracht uit, ongeacht bij wie hij staat.

1. Inventarisatie: wat luistert er eigenlijk?

Voordat u ook maar één regel schrijft, kijkt u na wat uw server naar buiten aanbiedt. Niet gokken, maar kijken:

ss -lntp

Interessant is de kolom met het lokale adres. 0.0.0.0:2106 en 0.0.0.0:7777 horen daar thuis. 0.0.0.0:9014 en 0.0.0.0:3306 zijn fouten: dat zijn de twee poorten waarmee een aanvaller zich in uw serverlijst kan hangen of uw database kan aftasten. 127.0.0.1:3306 betekent daarentegen "alleen lokaal" en heeft geen firewallregel nodig. Het beeld van de aanvaller levert een poortscan van buitenaf:

nmap -Pn -p- --min-rate 1000 UW.SERVER.IP.ADRES

2. Poort 9014 en de database uit het open internet houden

Poort 9014 is het kanaal waarmee de gameserver zich bij de loginserver registreert, en die hoort onder geen beding op het open internet. L2J levert daarvoor al de juiste standaardinstelling: LoginHostname = 127.0.0.1 bindt de poort aan de loopback-interface, hij is van buitenaf dus helemaal niet bereikbaar. Draaien loginserver en gameserver op twee verschillende machines, vul dan in plaats van * het concrete interne adres in en geef de poort uitsluitend vrij voor het andere systeem.

Dezelfde regel geldt voor de database. Controleer in /etc/mysql/mariadb.conf.d/50-server.cnf of daar staat:

bind-address = 127.0.0.1

En vervang de databasegebruiker. De meegeleverde Server.properties staat op Login = root, en het bestand zelf becommentarieert dat met de opmerking dat precies dat niet wordt aanbevolen. Hoe u een eigen gebruiker met minimale rechten aanmaakt, staat in MariaDB en MySQL beveiligen. Daarna controleert u het resultaat:

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

De firewall daarboven blijft kort. Voor een Lineage-2-server volstaan twee openstellingen naar buiten, en wel precies in deze volgorde, zodat u zichzelf niet buitensluit:

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

De volledige handleiding inclusief reddingsweg vindt u onder UFW-firewall instellen zonder uzelf buiten te sluiten.

3. AcceptNewGameServer uitschakelen zodra uw server geregistreerd is

In de LoginServer.properties staat af fabriek AcceptNewGameServer = True, en het commentaar daarboven beschrijft precies wat dat betekent: elke gameserver mag zich op een vrije plaats van uw loginserver registreren. Zolang 9014 alleen op de loopback-interface ligt, is dat zonder gevolgen. Zodra de poort om een andere reden bereikbaar wordt, is het een open deur. Zet de waarde daarom op False zodra uw eigen gameserver eenmaal geregistreerd is en zijn ID heeft:

AcceptNewGameServer = False

In de tegenhanger aan de kant van de gameserver staat AcceptAlternateID = True. Dat is bij de opbouw handig, omdat de loginserver dan een andere ID toekent wanneer de gewenste bezet is. Op een productiesysteem wilt u het tegendeel: een vaste ID, en een foutmelding wanneer die bezet is.

4. De flood protection van de loginserver juist instellen

L2J brengt een eigen verbindingsrem in de loginserver mee. Die staat in de LoginServer.properties, en alle tijdwaarden zijn milliseconden:

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

De waarden hangen samen. Een verbinding die minder dan FastConnectionTime na de vorige uit hetzelfde bronadres binnenkomt, telt als snel. Na FastConnectionLimit van zulke verbindingen wordt het adres geweigerd. NormalConnectionTime is de tussenpoos vanaf welke de teller weer wordt afgebouwd. MaxConnectionPerIP is de bovengrens van gelijktijdig open verbindingen per adres.

Vijftig gelijktijdige verbindingen zijn voor één enkele speler zeer royaal, en lagere waarden helpen merkbaar. Toch is hier voorzichtigheid geboden: meerdere spelers in hetzelfde huishouden, een internetcafé en vooral aansluitingen achter een carrier-NAT (in de L2-scene betreft dat veel spelers uit Turkije, uit Brazilië en uit delen van Oost-Europa) delen één openbaar adres. Wie hier op 3 instelt, sluit echte spelers buiten. Meet eerst een week in normaal bedrijf, verlaag daarna in stappen.

En een beperking die u moet kennen: deze rem draait in het Java-proces van de loginserver. Elk pakket waarover hij beslist, is al over uw lijn gelopen en heeft al rekentijd gekost. Tegen een handvol bronnen werkt hij, tegen een botnet niet.

5. Mislukte pogingen begrenzen en banned_ip.cfg gebruiken

Twee andere directives in de LoginServer.properties sturen hoe lang iemand mag raden:

LoginTryBeforeBan = 5
LoginBlockAfterBan = 900

LoginTryBeforeBan is het aantal ongeldige combinaties van account en wachtwoord waarna het adres wordt geblokkeerd, LoginBlockAfterBan is de blokkadeduur in seconden (900 komt overeen met 15 minuten). Daarna begint de telling opnieuw.

Permanente blokkades voert u in het bestand banned_ip.cfg in de configuratiemap van de loginserver in. Toegestaan zijn losse adressen, hele netwerken en een optioneel verlooptijdstip als Unix-tijdstempel in milliseconden; alles na # is commentaar:

198.51.100.7
203.0.113.0
198.51.100.44 1789689600000

Zet bovendien AutoCreateAccounts = False. De standaardinstelling True maakt bij elke aanmelding met een onbekende accountnaam automatisch een account aan. Dat is bij de opbouw praktisch en in bedrijf een cadeau: een aanvaller maakt daarmee willekeurig veel accounts aan, en elk daarvan mag de serverlijst met het adres van uw gameserver opvragen. Laat accounts in plaats daarvan via de registratie op uw website ontstaan, dan bepaalt u zelf wie een aanmelding krijgt.

6. Verbindingssnelheden op 2106 en 7777 in de kernel begrenzen

Wat de Java-rem te laat beslist, beslist de kernel eerder en goedkoper. Tegen kleine aanvallen en slordige bots helpt een bovengrens per bronadres:

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

De eerste regel verwerpt nieuwe verbindingen naar de loginserver zodra één adres er meer dan acht tegelijk open heeft staan. Een reguliere client heeft er precies één nodig. De tweede begrenst het aantal nieuwe verbindingen tot zes per seconde per adres met een buffer van twintig, wat een stormloop aan herverbindingen na een serverherstart nog doorlaat. De derde staat op de gameserver zes gelijktijdige verbindingen per adres toe, omdat meervoudig inloggen (dualbox en triplebox) in Lineage 2 normaal is en een te krappe grens uw betalende spelers raakt.

Alle drie de getallen zijn startwaarden, geen waarheden. Een server met 2000 gelijktijdige spelers gedraagt zich anders dan een met 200. Meet eerst, stel daarna in. Kale iptables-regels zijn na een herstart verdwenen; onder Debian en Ubuntu bewaart u ze zo:

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

Onder UFW horen zulke regels in /etc/ufw/before.rules, omdat ze anders bij de volgende ufw reload verdwijnen.

7. SYN-flood opvangen: syncookies, backlog en verbindingsregistratie

Omdat Lineage 2 uitsluitend over TCP loopt, is de SYN-flood de voor de hand liggende vector. Een SYN-flood is een aanval die verbindingsaanvragen met vervalste afzenderadressen stuurt en de bevestiging nooit beantwoordt, zodat de server voor elke aanvraag geheugen reserveert dat nooit wordt gebruikt. Vier instellingen ontscherpen dat:

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 zijn daarbij de belangrijkste regel: de kernel beantwoordt de aanvraag zonder iets te onthouden en legt de toestand pas aan wanneer de tegenpartij de verbinding werkelijk afrondt. Vervalste afzenders lopen daarmee in het niets. Permanent worden de waarden in een bestand onder /etc/sysctl.d/ opgeslagen en met sysctl --system geladen.

Een vaak over het hoofd gezien knelpunt is de verbindingsregistratie van de kernel. Loopt die vol, dan verwerpt de server ook legitieme pakketten en staat er in het logboek "nf_conntrack: table full, dropping packet". Stand en bovengrens toont:

sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max

8. Website, loginserver en gameserver op gescheiden IP-adressen

De projectwebsite met registratie, donatieshop en vote-pagina's is via uw domein altijd vindbaar. Ligt die op hetzelfde IP-adres als de loginserver, dan legt een aanval op de website tegelijk de aanmelding plat, en omgekeerd. Scheid de drie rollen over verschillende adressen. Dan blijft bij een aanval op de website het spel bereikbaar, en bij een aanval op 2106 spelen de reeds verbonden spelers door.

Houd daarbij de DNS-records schoon. De meest gemaakte fout is een vergeten A-record naar een eerder adres: het maakt elke adreswissel zinloos, omdat de aanvaller het nieuwe adres via dezelfde naam vindt als uw spelers.

En hier hoort eerlijkheid in plaats van wensdenken: het adres van uw loginserver laat zich niet geheimhouden. Het staat in de l2.ini in de System-map die elke speler downloadt. Het adres van de gameserver verspreidt de loginserver op zijn beurt zelf: in L2J staat het als extern adres in de ipconfig.xml (in oudere afgeleiden als ExternalHostname in de Server.properties), en het wordt meegedeeld aan elke client die zich met succes heeft aangemeld. Verstoppen is geen strategie, filteren wel.

9. Vastleggen, zodat u in geval van nood cijfers hebt

De belangrijkste stap is die welke bijna niemand vooraf zet: een vergelijkingsbasis aanleggen zolang alles normaal draait. Zonder normaalwaarde kunt u na een incident niet zeggen of 40.000 pakketten per seconde veel was of gewoon zaterdagavond. Met apt-get install -y vnstat sysstat loopt de meting permanent mee. Tijdens een incident volstaan vier commando's:

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

De tweede regel is bij Lineage 2 de meest veelzeggende: hij telt de halfopen verbindingen. Een vijfcijferige waarde bij een paar honderd spelers is een SYN-flood en niets anders. Voor tcpdump geldt: altijd met -c begrenzen, want een opname onder volle belasting belast een toch al overbelaste server nog extra. Hoe u de waarden uitleest, staat in DDoS-aanval herkennen.

Waar deze maatregelen ophouden

Nu het deel dat geen enkel configuratiebestand kan oplossen. Alle maatregelen tot hier draaien op uw server, dus aan het einde van de lijn. Een firewallregel beslist over een pakket dat al over de kabel is gekomen. U kunt het verwerpen, maar u kunt niet terugdraaien dat het verstuurd is.

Rekent u even mee. Een typische gameserver hangt aan 1 Gbit/s, dat is 125 megabyte per seconde, en de lijn zit vol zodra iemand meer stuurt. Tegen een Lineage-2-server is daarvoor niet eens een grote aanval nodig, omdat de tweede grootheid eerder toeslaat: de pakketsnelheid. Bij kleine pakketten van 64 byte passen er in een lijn van 1 Gbit/s ongeveer 1,49 miljoen pakketten per seconde. Een gewone serverkernel verwerkt daarvan, afhankelijk van CPU en netwerkkaart, enkele honderdduizenden voordat hij begint te verwerpen.

Bij een puur TCP-spel komt er een derde grens bij. Elke halfopen verbinding bezet een vermelding in de verbindingsregistratie en in de backlog, en de L2J-loginserver houdt zijn sessies tot 60 seconden vast. Een aanval met enkele honderdduizenden pakketten per seconde, die uw lijn niet eens voor een derde vult, kan de aanmelding dus volledig blokkeren. Beheerders ervaren dat als "de belasting was helemaal niet hoog en toch kwam er niemand binnen".

Ter oriëntatie, welke ordes van grootte werkelijk voorkomen: op KernelHost-servers zijn onder meer een aanval met meer dan 112,2 Gbit/s bij meer dan 8,7 miljoen pakketten per seconde op een gameserver en een multivector-aanval met meer dan 473,4 Gbit/s bij meer dan 41,5 miljoen pakketten per seconde op een voiceserver weggefilterd. Daarvoor bestaat geen lokale instelling. Volumetrische aanvallen moeten in het netwerk vóór de server eindigen. Wat er in een acuut geval te doen staat, leest u in Zware DDoS-aanval: wat nu te doen?.

Wat KernelHost daartegenover zet

De permanente bescherming die bij elke server inbegrepen is

De DDoS-bescherming van KernelHost is in twee lagen opgebouwd en permanent actief, zonder dat u iets hoeft in te schakelen, te bestellen of te configureren:

• Laag 1: 17 Tbps mitigatiecapaciteit in het globale scrubbing-netwerk. Volumetrische aanvallen worden dicht bij hun bron geschoond, nog voordat ze het datacenter bereiken.
• Laag 2: Arbor realtime filtering met 3,2 Tbps in Frankfurt am Main. Direct vóór de server worden protocolspecifieke patronen herkend en verworpen, pakket voor pakket.

Twee eigenschappen zijn doorslaggevend. De bescherming loopt permanent en hoeft niet eerst op een aanval te reageren, dus er zijn geen eerste minuten waarin de server weg is. Juist bij een grand opening is dat het verschil tussen een geslaagde en een verloren start. En er wordt geen null-routing toegepast: uw IP-adres blijft in het netwerk, alleen de kwaadaardige pakketten worden verworpen. Wie het IP-adres uit het netwerk haalt, bereikt voor u hetzelfde resultaat als de aanvaller. Welke games en protocollen gedekt zijn, somt Gameserver-DDoS-bescherming in realtime op.

Advanced DDoS Protection voor projecten die permanent onder vuur liggen

Sommige projecten worden niet af en toe, maar gericht en wekenlang aangevallen, en in de Lineage-2-scene is dat het normale geval voor elke server die de bovenste plaatsen van de serverlijsten haalt. Daarvoor is er de Advanced DDoS Protection vanaf 50,00 € per maand, PrePaid en zonder minimale looptijd. Het verschil zit niet in meer capaciteit, maar in de controle:

• Een dedicated beschermd IP-adres uit het Frankfurtse kernnetwerk, waarnaar uw server binnen ons eigen netwerk wordt omgezet. Aan uw kant is geen enkele aanpassing nodig.
• Zelf beheerbare beschermingsregels per poort en protocol in het klantenpaneel: u stelt gescheiden in wat op 2106 TCP is toegestaan en wat op 7777 TCP. Dat is bij Lineage 2 het doorslaggevende punt, omdat de twee poorten volkomen verschillende verkeerspatronen hebben: veel korte verbindingen aan de ene kant, weinig zeer lange aan de andere.
• Wijzigingen gelden in realtime, u kunt dus tijdens een lopende aanval bijsturen, en u kunt de regels vóór het openingsuur scherper zetten en daarna weer losser.
• Een beschermingsprofiel dat bij de toepassing past, ook voor aangepaste en eigen serverbestanden op willekeurige TCP- of UDP-poorten. Of u L2J, L2J-Mobius, aCis of een L2OFF-pakket draait, maakt voor de regelset niet uit, omdat die op poort en protocol aangrijpt.

De twee lagen naast elkaar

Voor de meeste Lineage-2-projecten volstaat de inbegrepen permanente bescherming samen met een nette serverconfiguratie. De Advanced DDoS Protection is het antwoord op iemand die het persoonlijk maakt, en dat gebeurt ervaringsgewijs in de week vóór de grand opening.

Veelgemaakte fouten en oplossingen

"De login werkt niet, maar de gameserver draait normaal": dat is geen toeval, maar de gebruikelijke vorm van een aanval op een Lineage-2-server. Loginserver en gameserver zijn twee processen op twee poorten. Meet ss -tn state syn-recv | wc -l en sar -n DEV 1 10. Stijgen de halfopen verbindingen terwijl de bandbreedte onopvallend blijft, dan is het een verbindingsflood op 2106.

"Ik heb het IP-adres gewisseld en was de volgende dag weer offline": de aanvaller krijgt het nieuwe adres langs dezelfde weg als uw spelers, namelijk via de nieuwe System-map met de gewijzigde l2.ini, via uw aankondiging of via een vergeten DNS-record. Een adreswissel levert tijd op, geen oplossing.

"Ik heb MaxConnectionPerIP op 3 gezet, nu klagen spelers": dualbox is in Lineage 2 gebruikelijk, en spelers achter een carrier-NAT delen een openbaar adres met honderden anderen. Ga terug naar een waarde die uw meetwaarden uit het normale bedrijf dekt, en begrens in plaats daarvan het aantal nieuwe verbindingen in de kernel.

"Mijn iptables-regels grijpen niet": drie oorzaken komen vaak voor. De regels staan achter de UFW-ketens en worden nooit bereikt, ze waren na de laatste herstart verdwenen (dan helpen netfilter-persistent save of een regel in /etc/ufw/before.rules), of de aanval is volumetrisch en de regel werkt correct aan een lijn die al vol zit. Controleer met iptables -L INPUT -n -v of de tellers oplopen. Blijven ze op nul staan, dan wordt de regel niet bereikt.

"Alle spelers hebben lag spikes, maar de lijn is rustig": dan is het geen DDoS-aanval. Bij een Java-server zijn de gebruikelijke verdachten pauzes van de garbage collection, een database zonder passende indexen en een script of een custom event in een lus. Controleer eerst sar -n DEV 1 10: blijven de pakketsnelheden normaal, dan ligt de oorzaak in de server en niet in het netwerk.

"Mijn vorige aanbieder heeft mijn IP-adres geblokkeerd": dat is null-routing. De aanbieder beschermt daarmee zijn eigen netwerk; voor u is het resultaat identiek aan een geslaagde aanval, meestal nog urenlang daarna. Vraag bij twijfel na of er wordt gefilterd of null-geroutet. Dat antwoord bepaalt meer over uw beschikbaarheid dan welke hardwarespecificatie ook.

"In de tcpdump zie ik niets opvallends": wordt het verkeer al in het netwerk ervoor gefilterd, dan komt er op de server zoals verwacht niets aan. Dat is het normale beeld bij een werkende filtering. Omgekeerd geldt: zit de lijn vol, dan bereikt u onder omstandigheden zelfs de SSH-sessie niet meer waarmee u wilde meten. Gebruik dan de VNC-console in het klantenpaneel, die losstaat van het netwerk van het gastsysteem.

"Mijn grand opening is over twee weken": verhuis dan nu en niet in de startweek. Een verhuizing kost een nieuwe System-map voor de spelers, een DNS-omzetting en een testrun. Dat alles wilt u achter de rug hebben voordat u de datum aankondigt, want vanaf de aankondiging kent elke concurrent uw ongunstigste moment.

Kort samengevat

• Een private Lineage-2-server heeft precies twee poorten op het open internet nodig: 2106 TCP voor de loginserver en 7777 TCP voor de gameserver. Poort 9014, de database (3306 bij L2J, 1433 bij L2OFF) en de interne L2OFF-poorten 2002, 2006, 2008, 2104 en 2108 horen daar niet bij.
• Lineage 2 loopt uitsluitend over TCP en heeft noch een querypoort noch een RCON-poort. De typische aanval is daarom een SYN- of verbindingsflood op poort 2106 en geen UDP-flood.
• Een aanval op de loginserver blokkeert alleen nieuwe aanmeldingen. Komt er niemand binnen terwijl de spelers in de wereld doorspelen, dan moet u de oorzaak op poort 2106 zoeken en niet op 7777.
• Stel EnableFloodProtection, MaxConnectionPerIP, LoginTryBeforeBan en AutoCreateAccounts bewust in, zet AcceptNewGameServer na de registratie op False en begrens verbindingssnelheden bovendien in de kernel, omdat de Java-rem pas achter de lijn aangrijpt.
• Aanvallen op Lineage-2-servers concentreren zich rond serverstarts, omdat datum en tijdstip weken van tevoren openbaar zijn en de economische schade op de openingsdag het grootst is. De bescherming moet vóór de aankondiging staan, niet erna.
• Boven de capaciteit van de lijn en boven enkele honderdduizenden pakketten per seconde beslist uitsluitend de filtering in het netwerk vóór de server. Bij KernelHost is die opgebouwd in twee lagen, permanent actief, zonder meerprijs en zonder null-routing.

Draait uw project al bij KernelHost, dan is de filtering actief zonder dat u iets hoeft te doen. Merkt u toch iets ongewoons, open dan een supportticket, zodat de filterregels voor uw IP-adres worden bijgesteld. Bij een lopende aanval bereikt u ons daarnaast via de WhatsApp-noodchat op +43 650 8209883.