Skydda Lineage 2-servern mot DDoS-attacker

En privat Lineage 2-server där ingen längre kommer förbi inloggningsskärmen på kvällen, medan spelarna ute i världen fortsätter ostört, har inget hårdvaruproblem. Det är fingeravtrycket av en DDoS-attack mot inloggningsservern, och det är precis där ett DDoS-skydd för Lineage 2 måste sätta in. Den här artikeln visar först vad du kan säkra själv utan extra kostnad, därefter var dessa åtgärder tar slut rent tekniskt, och till sist vad som då måste hända i nätet framför servern.

Alla uppgifter gäller L2J och dess avläggare (L2J-Mobius, aCis) på Debian 12, Debian 13, Ubuntu 22.04 LTS eller Ubuntu 24.04 LTS samt L2OFF-paket med AuthD, CacheD och L2Server. Kommandona är skrivna för root, som vanlig användare sätter du sudo framför.

Om attacken pågår just nu: ändra ingenting i konfigurationen och starta varken om inloggningsservern eller spelservern. Säkra först mätvärdena (avsnitt 9), efter attacken är de borta.

Skydda Lineage 2-servern mot DDoS: varför privata L2-servrar attackeras

En privat Lineage 2-server förenar flera egenskaper som gör den till ett bekvämt mål, och ett DDoS-skydd för Lineage 2 måste sätta in exakt vid dessa egenskaper. För det första är din adress offentlig, och det från allra första början: spelarna laddar ner en patchad System-mapp, och i dess l2.ini står raden ServerAddr= med IP-adressen till din inloggningsserver. Alla som någon gång installerat ditt projekt känner till den adressen, oavsett om de någonsin skapat en karaktär.

För det andra är spelarskaran bunden till fasta tider. Belägringar, epic-raidbossar och event står i kalendern, ett avbrott exakt den timmen syns maximalt. För det tredje konkurrerar projekten direkt med varandra: den som öppnar en server slåss om samma par tusen spelare som tre andra projekt samma helg. Att slå ut en konkurrent är en vanlig strategi i den här scenen. En attack beställs då som en tjänst (i scenen går det under booter eller stresser) och kostar beställaren varken kunnande eller nämnvärda pengar. Vad en DDoS-attack är i detalj förklarar artikeln Vad är en DDoS-attack?.

Varför inloggningsservern på port 2106 är det egentliga målet

Lineage 2 är uppdelat på två separata processer: en inloggningsserver och en eller flera spelservrar. Klienten ansluter först på 2106 TCP till inloggningsservern, loggar in, får därifrån serverlistan med spelserverns externa adress och port, och bygger därefter upp en andra anslutning på 7777 TCP till spelservern. Båda processerna har egna konfigurationsfiler, egna portar och egna belastningsgränser.

Därav följer det attackmönster som L2-operatörer beskriver om och om igen: en flod mot 2106 blockerar uteslutande nya inloggningar. Den som redan står ute i världen spelar vidare tills anslutningen bryts av sig själv. Onlineräknaren sjunker alltså långsamt i stället för tvärt, och på forumet står det "servern går, men jag kommer inte in". Precis den bilden skiljer en attack mot inloggningsservern från en attack mot spelservern, där alla åker ut samtidigt.

Inloggningsservern är dessutom det billigare målet, eftersom arbetet är ojämnt fördelat. L2J-inloggningsservern skapar vid start ett förråd på tio RSA-nyckelpar med 1024 bitar och tjugo Blowfish-nycklar. Varje inloggningsförsök kostar klienten ett skickat paket och servern en dekryptering med den privata RSA-nyckeln. En halvfärdig session upptar samtidigt en plats tills den inbyggda timern förkastar den: LOGIN_TIMEOUT står i källkoden på 60 sekunder. Standardvärdet MaxConnectionPerIP = 50 tillåter varje källadress femtio samtidiga anslutningar. Tusen källadresser räcker därmed för 50 000 samtidigt öppna sessioner, som var och en består i upp till en minut.

Till det kommer en egenhet hos spelet som skiljer det från de flesta spelservrar: Lineage 2 går uteslutande över TCP. Tillverkaren anger TCP-portarna 80, 2009, 2106 och 7777 för spelet, och för UDP uteslutande port 53 för namnuppslagning. Det finns alltså ingen UDP-speltrafik att filtrera, i gengäld är den klassiska SYN-flooden med förfalskade avsändaradresser direkt verksam, och kärnans anslutningsspårning blir den första flaskhalsen.

Varför attacker mot Lineage 2-servrar kommer säsongsvis kring serverstarter

Attacker mot privata Lineage 2-servrar samlas kring serverstarter, eftersom datum och klockslag för öppningen är offentligt kända veckor i förväg. Öppningskalendrar för Lineage 2-projekt listar kommande starter efter krönika (Interlude, High Five, Classic, Essence), dessutom rater och exakt starttid, och de uppdateras dagligen. Angriparen behöver inte spana: den för honom gynnsammaste tidpunkten står i operatörens egen annonsering.

Det andra skälet är ekonomiskt. En privat Lineage 2-server tjänar sina pengar i början: hela spelarbasen värvas under de första dagarna, donationerna faller ut under de första veckorna, därefter krymper befolkningen stadigt. En spelare som inte kommer in under den första timmen byter till projektet som startar samma helg, och det projektet finns alltid. En timmes avbrott på öppningsdagen kostar därför inte en timmes omsättning, utan en del av serverns hela livslängd.

Det tredje skälet är tekniskt. Vid grand opening försöker tusentals spelare logga in samtidigt. Inloggningsservern är exakt den minuten ändå på gränsen, och en extra flod går knappt att skilja från toppbelastningen. En attack som en lugn tisdag skulle passera utan följder räcker under öppningstimmen. Samma sak gäller aviserade tider i löpande drift: borgbelägringar och epic-raidbossar står i kalendern och är av samma skäl populära attackfönster. Efter öppningsrusningen sjunker incitamentet igen, och därför upplever operatörer attackerna som vågformiga och inte som ett permanent tillstånd.

Portarna som det faktiskt handlar om

Följande tabell listar portarna på en privat Lineage 2-server, tillhörande konfigurationsfil och det direktiv som sätter värdet. Standardvärdena kommer från de medföljande konfigurationsfilerna i L2J respektive från installationsanvisningarna för L2OFF-paket.

Tabellen besvarar samtidigt två frågor: Lineage 2 har varken en query-port eller en RCON-port. Det finns ingen separat tjänst som levererar spelarantalet till en serverlista, och ingen fjärrstyrningsport som hos spel byggda på Source. Serverlistan skapar inloggningsservern själv och skickar den över samma anslutning på 2106 till den inloggade klienten. Fjärrstyrningen går i L2J via kommandon inne i spelet och via databasen. Därmed faller två angreppsvägar bort som andra spel har, och desto mer hamnar på port 2106.

Storleksordningar du bör känna till

Vad du kan göra själv innan du lägger pengar på saken

Det här avsnittet är det längsta, och det med avsikt. En rent konfigurerad Lineage 2-server klarar små och medelstora attacker av egen kraft, oavsett hos vem den står.

1. Inventering: vad lyssnar egentligen?

Innan du skriver en enda regel, se efter vad din server erbjuder utåt. Inte gissa, titta efter:

ss -lntp

Intressant är kolumnen med den lokala adressen. 0.0.0.0:2106 och 0.0.0.0:7777 hör hemma där. 0.0.0.0:9014 och 0.0.0.0:3306 är fel: det är de två portar genom vilka en angripare kan hänga in sig i din serverlista eller knacka på din databas. 127.0.0.1:3306 betyder däremot "bara lokalt" och behöver ingen brandväggsregel. Angriparens vy får du genom en portskanning utifrån:

nmap -Pn -p- --min-rate 1000 DIN.SERVER.IP.ADRESS

2. Håll port 9014 och databasen borta från öppna nätet

Port 9014 är kanalen genom vilken spelservern registrerar sig hos inloggningsservern, och den hör under inga omständigheter hemma på öppna nätet. L2J levererar redan rätt standardvärde för det: LoginHostname = 127.0.0.1 binder porten till loopback-gränssnittet, den är alltså inte nåbar utifrån över huvud taget. Kör du inloggningsserver och spelserver på två olika maskiner, skriver du in den konkreta interna adressen i stället för * och öppnar porten uteslutande för motparten.

Samma regel gäller databasen. Kontrollera i /etc/mysql/mariadb.conf.d/50-server.cnf att det står:

bind-address = 127.0.0.1

Och byt ut databasanvändaren. Den medföljande Server.properties står på Login = root, och filen kommenterar själv att just det inte rekommenderas. Hur du lägger upp en egen användare med minimala rättigheter står i Säkra MariaDB och MySQL. Därefter kontrollerar du resultatet:

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

Brandväggen ovanpå förblir kort. För en Lineage 2-server räcker två öppningar utåt, och det exakt i den här ordningen, så att du inte låser ute dig själv:

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

Den fullständiga anvisningen inklusive räddningsväg hittar du i Sätta upp UFW-brandväggen utan att låsa ute dig själv.

3. Stäng av AcceptNewGameServer så snart din server är registrerad

I LoginServer.properties står från fabrik AcceptNewGameServer = True, och kommentaren ovanför beskriver exakt vad det betyder: varje spelserver får registrera sig på en ledig plats hos din inloggningsserver. Så länge 9014 bara ligger på loopback-gränssnittet är det utan följder. Så snart porten av någon annan anledning blir nåbar är det en öppen dörr. Sätt därför värdet till False så snart din egen spelserver är registrerad en gång och har sin identitet:

AcceptNewGameServer = False

I motsvarigheten på spelserversidan står AcceptAlternateID = True. Det är bekvämt under uppbyggnaden, eftersom inloggningsservern då delar ut en annan identitet när den önskade är upptagen. På ett produktionssystem vill du ha motsatsen: en fast identitet, och ett fel om den är upptagen.

4. Ställ in inloggningsserverns flood protection rätt

L2J har en egen anslutningsbroms inbyggd i inloggningsservern. Den står i LoginServer.properties, och alla tidsvärden är millisekunder:

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

Värdena hänger ihop. En anslutning som kommer in mindre än FastConnectionTime efter den föregående från samma källadress räknas som snabb. Efter FastConnectionLimit sådana anslutningar avvisas adressen. NormalConnectionTime är avståndet från vilket räknaren byggs ner igen. MaxConnectionPerIP är den övre gränsen för samtidigt öppna anslutningar per adress.

Femtio samtidiga anslutningar är mycket generöst för en enskild spelare, och lägre värden hjälper märkbart. Ändå är försiktighet påkallad här: flera spelare i samma hushåll, ett internetkafé och framför allt anslutningar bakom en carrier-NAT (i L2-scenen gäller det många spelare från Turkiet, Brasilien och delar av Östeuropa) delar en offentlig adress. Den som ställer in 3 här låser ute riktiga spelare. Mät först en vecka i normal drift, sänk sedan stegvis.

Och en begränsning du måste känna till: den här bromsen körs i inloggningsserverns Java-process. Varje paket som den beslutar om har redan gått över din nätanslutning och redan kostat processortid. Mot en handfull källor fungerar den, mot ett botnät inte.

5. Begränsa misslyckade försök och använd banned_ip.cfg

Två ytterligare direktiv i LoginServer.properties styr hur länge någon får gissa:

LoginTryBeforeBan = 5
LoginBlockAfterBan = 900

LoginTryBeforeBan är antalet ogiltiga kombinationer av konto och lösenord efter vilket adressen spärras, LoginBlockAfterBan är spärrtiden i sekunder (900 motsvarar 15 minuter). Därefter börjar räkningen om från början.

Permanenta spärrar skriver du in i filen banned_ip.cfg i inloggningsserverns konfigurationskatalog. Tillåtna är enskilda adresser, hela nät och en valfri utgångstid som Unix-tidsstämpel i millisekunder, allt efter # är en kommentar:

198.51.100.7
203.0.113.0
198.51.100.44 1789689600000

Sätt dessutom AutoCreateAccounts = False. Standardvärdet True skapar automatiskt ett konto vid varje inloggning med ett okänt kontonamn. Det är praktiskt under uppbyggnaden och en present i drift: en angripare skapar därmed hur många konton som helst, och vart och ett av dem får hämta serverlistan med din spelservers adress. Låt i stället konton uppstå via registreringen på din webbplats, då kontrollerar du vem som får en inloggning.

6. Begränsa anslutningsfrekvensen på 2106 och 7777 i kärnan

Det som Java-bromsen beslutar för sent, beslutar kärnan tidigare och billigare. Mot små attacker och slarviga botar hjälper en övre gräns per källadress:

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

Den första regeln förkastar nya anslutningar till inloggningsservern så snart en adress har mer än åtta av dem öppna samtidigt. En vanlig klient behöver exakt en. Den andra begränsar frekvensen av nya anslutningar till sex per sekund och adress med en buffert på tjugo, vilket fortfarande släpper igenom en återanslutningsstorm efter en omstart av servern. Den tredje tillåter sex samtidiga anslutningar per adress på spelservern, eftersom flerinloggning (dualbox och triplebox) är normalt i Lineage 2 och en för snäv gräns drabbar dina betalande spelare.

Alla tre siffrorna är startvärden, inte sanningar. En server med 2000 samtidiga spelare beter sig annorlunda än en med 200. Mät först, ställ in sedan. Rena iptables-regler är borta efter en omstart, under Debian och Ubuntu sparar man dem så här:

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

Under UFW hör sådana regler hemma i /etc/ufw/before.rules, eftersom de annars försvinner vid nästa ufw reload.

7. Fånga upp SYN-flooden: syncookies, backlog och anslutningsspårning

Eftersom Lineage 2 går uteslutande över TCP är SYN-flooden den närmast liggande vektorn. En SYN-flood är en attack som skickar anslutningsförfrågningar med förfalskade avsändaradresser och aldrig besvarar bekräftelsen, så att servern reserverar minne för varje förfrågan som sedan aldrig används. Fyra inställningar dämpar det:

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 är därvid den viktigaste raden: kärnan besvarar förfrågan utan att lägga något på minnet, och lägger upp tillståndet först när motparten verkligen fullbordar anslutningen. Förfalskade avsändare går därmed i tomma intet. Permanent läggs värdena i en fil under /etc/sysctl.d/ och laddas med sysctl --system.

En ofta förbisedd flaskhals är kärnans anslutningsspårning. Går den full förkastar servern även legitima paket, och i loggen står "nf_conntrack: table full, dropping packet". Nuläge och övre gräns visar:

sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max

8. Webbplats, inloggningsserver och spelserver på separata IP-adresser

Projektets webbplats med registrering, donationsshop och vote-sidor går alltid att hitta via din domän. Ligger den på samma IP-adress som inloggningsservern slår en attack mot webbplatsen samtidigt ut inloggningen, och tvärtom. Dela upp de tre rollerna på olika adresser. Då förblir spelet nåbart vid en attack mot webbplatsen, och vid en attack mot 2106 spelar de redan anslutna spelarna vidare.

Håll DNS-posterna rena medan du gör det. Det vanligaste felet är en bortglömd A-post mot en tidigare adress: den gör varje adressbyte verkningslöst, eftersom angriparen hittar den nya adressen via samma namn som dina spelare.

Och här hör ärlighet hemma i stället för önsketänkande: adressen till din inloggningsserver går inte att hemlighålla. Den står i l2.ini i den System-mapp som varje spelare laddar ner. Spelserverns adress delar i sin tur inloggningsservern själv ut: i L2J står den som extern adress i ipconfig.xml (i äldre avläggare som ExternalHostname i Server.properties), och den meddelas varje klient som loggat in framgångsrikt. Att gömma sig är ingen strategi, att filtrera är en.

9. Logga, så att du har data när det gäller

Det viktigaste steget är det som nästan ingen tar i förväg: lägga upp en jämförelsegrund medan allt fungerar normalt. Utan ett normalvärde kan du efter en incident inte säga om 40 000 paket per sekund var mycket eller helt enkelt lördagskväll. Med apt-get install -y vnstat sysstat löper mätningen permanent i bakgrunden. Under en incident räcker fyra kommandon:

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

Den andra raden är den mest talande vid Lineage 2: den räknar de halvöppna anslutningarna. Ett femsiffrigt värde vid ett par hundra spelare är en SYN-flood och ingenting annat. För tcpdump gäller: begränsa alltid med -c, en inspelning under full belastning belastar en redan överlastad server ytterligare. Hur du tolkar värdena står i Upptäcka en DDoS-attack.

Var de här åtgärderna tar slut

Nu den del som ingen konfigurationsfil kan lösa. Alla åtgärder hittills går på din server, alltså i änden av nätanslutningen. En brandväggsregel avgör vad som händer med ett paket som redan har gått genom kabeln. Du kan förkasta det, men inte göra det oskickat.

Räkna på det en gång. En typisk spelserver hänger på 1 Gbit/s, det är 125 megabyte per sekund, och nätanslutningen är full så snart någon skickar mer. Mot en Lineage 2-server räcker det inte ens med en stor attack, eftersom den andra storheten slår till tidigare: paketfrekvensen. Vid små paket på 64 byte får cirka 1,49 miljoner paket per sekund plats i en nätanslutning med 1 Gbit/s. Kärnan i ett vanligt serversystem bearbetar beroende på CPU och nätverkskort några hundratusen av dem innan den börjar förkasta.

Vid ett rent TCP-spel kommer en tredje gräns till. Varje halvöppen anslutning upptar en post i anslutningsspårningen och i backloggen, och L2J-inloggningsservern håller sina sessioner i upp till 60 sekunder. En attack med några hundratusen paket per sekund, som inte ens fyller en tredjedel av din nätanslutning, kan alltså blockera inloggningen fullständigt. Operatörer upplever det som "belastningen var ju inte alls hög, ändå kom ingen in".

För att ge perspektiv på vilka storleksordningar som verkligen förekommer: på KernelHost-servrar har bland annat en attack med över 112,2 Gbit/s vid över 8,7 miljoner paket per sekund mot en spelserver och en multivektorattack med över 473,4 Gbit/s vid över 41,5 miljoner paket per sekund mot en voice-server filtrerats. För det finns ingen lokal inställning. Volymetriska attacker måste ta slut i nätet framför servern. Vad du gör i det akuta läget står i Kraftig DDoS-attack: vad gör man?.

Vad KernelHost ställer mot det

Det permanenta skyddet som ingår i varje server

KernelHosts DDoS-skydd är uppbyggt i två steg och permanent aktivt, utan att du måste slå på, beställa eller konfigurera något:

• Steg 1: 17 Tbps mitigeringskapacitet i det globala scrubbing-nätverket. Volymetriska attacker rensas nära sin källa innan de når datacentret.
• Steg 2: Arbor-realtidsfiltrering med 3,2 Tbps i Frankfurt am Main. Direkt framför servern känns protokollspecifika mönster igen och förkastas, paket för paket.

Två egenskaper är avgörande. Skyddet går permanent och behöver inte först reagera på en attack, det finns alltså inga minuter i början då servern är borta. Just vid ett grand opening är det skillnaden mellan en lyckad och en förlorad start. Och ingen null-routning används: din IP-adress blir kvar i nätet, bara de skadliga paketen förkastas. Den som tar IP-adressen ur nätet uppnår för dig samma resultat som angriparen. Vilka spel och protokoll som täcks listar DDoS-skydd för spelservrar i realtid.

Advanced DDoS Protection för projekt under ständig beskjutning

Vissa projekt attackeras inte tillfälligt utan riktat och under veckor, och i Lineage 2-scenen är det regelfallet för varje server som tar sig upp i de övre skikten av serverlistorna. För sådana fall finns Advanced DDoS Protection från 50,00 EUR i månaden, PrePaid, utan bindningstid och utan uppläggningsavgift. Skillnaden ligger inte i mer kapacitet, utan i kontrollen:

• Dedikerad skydds-IP ur Frankfurt-kärnan, som din server ställs om till inom det egna nätet. På din sida behövs ingen ombyggnad.
• Skyddsregler per port och protokoll som du hanterar själv i kundportalen: du ställer separat in vad som tillåts på 2106 TCP och vad som tillåts på 7777 TCP. Hos Lineage 2 är det den avgörande punkten, eftersom de båda portarna har helt olika trafikmönster: många korta anslutningar på den ena sidan, få mycket långa på den andra.
• Ändringar träder i kraft i realtid, du kan alltså justera under en pågående attack, och du kan skärpa reglerna inför öppningstimmen och lätta på dem igen efteråt.
• Skyddsprofil anpassad till applikationen, likaså för modifierade och egna serverfiler på valfria TCP- eller UDP-portar. Om du kör L2J, L2J-Mobius, aCis eller ett L2OFF-paket spelar ingen roll för regelverket, eftersom det bygger på port och protokoll.

De båda stegen i jämförelse

För de flesta Lineage 2-projekt räcker det inkluderade permanenta skyddet tillsammans med en ren serverkonfiguration. Advanced DDoS Protection är svaret på att någon tar det personligt, och det händer erfarenhetsmässigt veckan före grand opening.

Vanliga fel och lösningar

"Inloggningen fungerar inte, men spelservern går normalt": Det är ingen slump, utan den vanliga formen av en attack mot en Lineage 2-server. Inloggningsserver och spelserver är två processer på två portar. Mät ss -tn state syn-recv | wc -l och sar -n DEV 1 10. Stiger de halvöppna anslutningarna medan bandbredden förblir oförändrad är det en anslutningsflod mot 2106.

"Jag bytte IP-adress och var offline igen nästa dag": Angriparen får den nya adressen på samma väg som dina spelare, nämligen via den nya System-mappen med ändrad l2.ini, via din annonsering eller via en bortglömd DNS-post. Ett adressbyte är tidsvinst, ingen lösning.

"Jag satte MaxConnectionPerIP till 3, nu klagar spelarna": Dualbox är vanligt i Lineage 2, och spelare bakom en carrier-NAT delar en offentlig adress med hundratals andra. Gå tillbaka till ett värde som täcker dina mätvärden från normal drift, och begränsa i stället frekvensen av nya anslutningar i kärnan.

"Mina iptables-regler biter inte": Tre orsaker är vanliga. Reglerna står bakom UFW-kedjorna och nås aldrig, de var borta efter den senaste omstarten (då hjälper netfilter-persistent save eller en post i /etc/ufw/before.rules), eller så är attacken volymetrisk och regeln arbetar korrekt vid en nätanslutning som redan är full. Kontrollera med iptables -L INPUT -n -v om träffräknarna stiger. Står de kvar på noll nås regeln inte.

"Alla spelare har lagspikar, men nätanslutningen är lugn": Då är det ingen DDoS-attack. Hos en Java-server är de vanliga misstänkta pauser i skräpsamlingen, en databas utan passande index och ett skript eller ett custom-event i en slinga. Kontrollera först sar -n DEV 1 10: förblir paketfrekvenserna normala ligger orsaken i servern och inte i nätet.

"Min tidigare leverantör har spärrat min IP-adress": Det är null-routning. Leverantören skyddar därmed sitt eget nät, för dig är resultatet identiskt med en lyckad attack, oftast i timmar därefter. Fråga i tveksamma fall om det filtreras eller null-routas. Svaret avgör mer om din tillgänglighet än varje hårdvaruuppgift.

"I tcpdump ser jag inget anmärkningsvärt": Filtreras trafiken redan i nätet framför kommer som väntat ingenting fram på servern. Det är normalfallet vid fungerande filtrering. Omvänt gäller: är nätanslutningen mättad når dig under vissa omständigheter inte ens SSH-sessionen som du ville mäta med. Använd då VNC-konsolen i kundportalen, som fungerar oberoende av gästsystemets nätverk.

"Mitt grand opening är om två veckor": Då flyttar du nu och inte under startveckan. En flytt kostar en ny System-mapp för spelarna, en DNS-omställning och en testkörning. Allt det vill du ha bakom dig innan du annonserar datumet, för från annonseringen känner varje konkurrent till din mest ogynnsamma tidpunkt.

Kort sammanfattat

• En privat Lineage 2-server behöver exakt två portar ut på öppna nätet: 2106 TCP för inloggningsservern och 7777 TCP för spelservern. Port 9014, databasen (3306 vid L2J, 1433 vid L2OFF) och de interna L2OFF-portarna 2002, 2006, 2008, 2104 och 2108 hör inte dit.
• Lineage 2 går uteslutande över TCP och har varken en query-port eller en RCON-port. Den typiska attacken är därför en SYN- eller anslutningsflod mot port 2106 och ingen UDP-flood.
• En attack mot inloggningsservern blockerar bara nya inloggningar. Kommer ingen in medan spelarna ute i världen fortsätter spela ska orsaken sökas på port 2106 och inte på 7777.
• Ställ in EnableFloodProtection, MaxConnectionPerIP, LoginTryBeforeBan och AutoCreateAccounts medvetet, sätt AcceptNewGameServer till False efter registreringen och begränsa dessutom anslutningsfrekvensen i kärnan, eftersom Java-bromsen griper in först bakom nätanslutningen.
• Attacker mot Lineage 2-servrar samlas kring serverstarter, eftersom datum och klockslag är offentliga veckor i förväg och den ekonomiska skadan är störst på öppningsdagen. Skyddet måste stå före annonseringen, inte efter.
• Över nätanslutningens kapacitet och över några hundratusen paket per sekund avgör uteslutande filtreringen i nätet framför servern. Hos KernelHost är den uppbyggd i två steg, permanent aktiv, utan extra kostnad och utan null-routning.

Går ditt projekt redan hos KernelHost är filtreringen aktiv utan att du behöver göra något. Märker du ändå något anmärkningsvärt öppnar du ett supportärende, så att filterreglerna för din IP-adress justeras. Vid en pågående attack når du oss dessutom via WhatsApp-nödchatten på +43 650 8209883.