Protejarea unui server Lineage 2 împotriva atacurilor DDoS

Un server privat de Lineage 2 la care seara nimeni nu mai trece de ecranul de autentificare, în timp ce jucătorii aflați deja în lume continuă netulburați, nu are o problemă de hardware. Aceasta este amprenta unui atac DDoS asupra serverului de login, și exact acolo trebuie să acționeze o protecție DDoS pentru Lineage 2. Articolul arată mai întâi ce puteți securiza singur, fără costuri suplimentare, apoi unde se opresc tehnic aceste măsuri și, la final, ce trebuie să se întâmple în rețeaua din fața serverului.

Toate informațiile se referă la L2J și la derivatele sale (L2J-Mobius, aCis) pe Debian 12, Debian 13, Ubuntu 22.04 LTS sau Ubuntu 24.04 LTS, precum și la pachetele L2OFF cu AuthD, CacheD și L2Server. Comenzile sunt scrise pentru root, ca utilizator obișnuit puneți sudo în față.

Dacă atacul este în desfășurare chiar acum: nu modificați nimic în configurație și nu reporniți nici serverul de login, nici serverul de joc. Salvați mai întâi valorile măsurate (vedeți secțiunea „Înregistrați date”), după atac ele nu mai există.

Protecție DDoS pentru serverul Lineage 2: de ce sunt atacate serverele private L2

Un server privat de Lineage 2 reunește mai multe caracteristici care îl transformă într-o țintă comodă, iar protecția DDoS pentru Lineage 2 trebuie să acționeze exact asupra acestor caracteristici. În primul rând, adresa dumneavoastră este publică, și asta de la bun început: jucătorii descarcă un folder System modificat, iar în fișierul l2.ini din acel folder se află linia ServerAddr= cu adresa IP a serverului dumneavoastră de login. Oricine a instalat o dată proiectul dumneavoastră cunoaște această adresă, indiferent dacă a creat vreodată un personaj.

În al doilea rând, comunitatea de jucători este legată de ore fixe. Asediile, epic raid bossii și evenimentele sunt în calendar, iar o cădere exact la ora respectivă este maxim de vizibilă. În al treilea rând, proiectele se află în concurență directă: cine deschide un server se luptă pentru aceleași câteva mii de jucători ca alte trei proiecte din același weekend. Scoaterea din joc a unui concurent este o strategie curentă în această scenă. Un atac se comandă ca serviciu (în scenă asta se numește booter sau stresser) și nu îl costă pe comanditar nici pricepere, nici bani demni de menționat. Ce este în detaliu un atac DDoS explică articolul Ce este un atac DDoS?.

De ce serverul de login de pe portul 2106 este ținta reală

Lineage 2 este împărțit în două procese separate: un server de login și unul sau mai multe servere de joc. Clientul se conectează mai întâi pe 2106 TCP la serverul de login, se autentifică, primește de acolo lista de servere cu adresa externă și portul serverului de joc, iar apoi deschide o a doua conexiune pe 7777 TCP către serverul de joc. Ambele procese au fișiere de configurare proprii, porturi proprii și limite de încărcare proprii.

Din asta rezultă tiparul de atac pe care operatorii de L2 îl descriu mereu: un flood pe 2106 blochează exclusiv autentificările noi. Cine se află deja în lume joacă mai departe până când pierde singur conexiunea. Contorul de jucători online scade deci lent, nu brusc, iar pe forum apare „serverul merge, dar eu nu intru”. Exact această imagine deosebește un atac asupra serverului de login de un atac asupra serverului de joc, la care toți sunt deconectați în același timp.

Serverul de login este în plus ținta mai ieftină, pentru că efortul este împărțit inegal. Serverul de login L2J generează la pornire un stoc de zece perechi de chei RSA de 1024 de biți și douăzeci de chei Blowfish. Fiecare încercare de autentificare costă clientul trimiterea unui pachet, iar serverul o decriptare cu cheia RSA privată. O sesiune neterminată ocupă între timp un loc până când temporizatorul integrat o elimină: LOGIN_TIMEOUT este setat în codul sursă pe 60 de secunde. Valoarea implicită MaxConnectionPerIP = 50 permite fiecărei adrese sursă cincizeci de conexiuni simultane. O mie de adrese sursă sunt deci suficiente pentru 50.000 de sesiuni deschise în același timp, fiecare rămânând valabilă până la un minut.

La asta se adaugă o particularitate a jocului care îl deosebește de majoritatea serverelor de joc: Lineage 2 funcționează exclusiv prin TCP. Producătorul indică pentru joc porturile TCP 80, 2009, 2106 și 7777, iar la UDP exclusiv portul 53 pentru rezolvarea numelor. Nu există deci trafic de joc pe UDP care să trebuiască filtrat, în schimb clasicul SYN-flood cu adrese sursă falsificate este direct eficient, iar urmărirea conexiunilor din kernel devine primul punct critic.

De ce atacurile asupra serverelor Lineage 2 apar sezonier, la lansările de server

Atacurile asupra serverelor private de Lineage 2 se aglomerează în jurul lansărilor de server, pentru că data și ora deschiderii sunt publice cu săptămâni înainte. Calendarele de deschidere pentru proiecte de Lineage 2 listează lansările viitoare după cronică (Interlude, High Five, Classic, Essence), adaugă ratele și ora exactă de start și se actualizează zilnic. Atacatorul nu trebuie să cerceteze nimic: momentul cel mai convenabil pentru el se află în anunțul operatorului.

Al doilea motiv este economic. Un server privat de Lineage 2 își face banii la început: întreaga bază de jucători se atrage în primele zile, donațiile vin în primele săptămâni, apoi populația scade constant. Un jucător care nu intră în prima oră trece la proiectul care se lansează în același weekend, și acest proiect există întotdeauna. O oră de indisponibilitate în ziua deschiderii nu costă deci o oră de încasări, ci o parte din întreaga durată de viață a serverului.

Al treilea motiv este tehnic. La Grand Opening, mii de jucători încearcă să se autentifice în același timp. Serverul de login este în acel minut oricum la limită, iar un flood suplimentar aproape nu se distinge de vârful de sarcină. Un atac care într-o marți liniștită ar rămâne fără urmări este suficient la ora deschiderii. Același lucru este valabil pentru termenele anunțate în timpul funcționării normale: asediile de castel și evenimentele cu boși epici stau în calendar și sunt, din același motiv, fereastra preferată de atac. După asaltul de la deschidere, stimulentul scade din nou, motiv pentru care operatorii percep atacurile ca valuri și nu ca o stare permanentă.

Porturile despre care este vorba în realitate

Tabelul de mai jos listează porturile unui server privat de Lineage 2, fișierul de configurare aferent și directiva care stabilește valoarea. Valorile implicite provin din fișierele de configurare livrate cu L2J, respectiv din ghidurile de instalare pentru pachetele L2OFF.

Tabelul răspunde totodată la două întrebări: Lineage 2 nu are nici un port de query, nici un port RCON. Nu există un serviciu separat care să livreze numărul de jucători pentru o listă de servere și nu există un port de control la distanță ca la jocurile bazate pe Source. Lista de servere o generează serverul de login însuși și o trimite prin aceeași conexiune pe 2106 către clientul autentificat. Controlul la distanță se face în L2J prin comenzi din joc și prin baza de date. Astfel dispar doi vectori de atac pe care alte jocuri îi au, și rămâne cu atât mai mult în sarcina portului 2106.

Ordinele de mărime pe care ar trebui să le cunoașteți

Ce puteți face singur, înainte de a da bani

Această secțiune este cea mai lungă, și asta intenționat. Un server de Lineage 2 configurat curat rezistă singur atacurilor mici și medii, indiferent la cine este găzduit.

1. Inventar: ce ascultă, de fapt?

Înainte să scrieți o singură regulă, vedeți ce oferă serverul dumneavoastră către exterior. Nu ghiciți, verificați:

ss -lntp

Interesantă este coloana cu adresa locală. 0.0.0.0:2106 și 0.0.0.0:7777 au ce căuta acolo. 0.0.0.0:9014 și 0.0.0.0:3306 sunt erori: acestea sunt cele două porturi prin care un atacator se poate agăța de lista dumneavoastră de servere sau vă poate pipăi baza de date. 127.0.0.1:3306 înseamnă, în schimb, „numai local” și nu are nevoie de o regulă de firewall. Perspectiva atacatorului o oferă o scanare de porturi din exterior:

nmap -Pn -p- --min-rate 1000 ADRESA.IP.A.SERVERULUI

2. Țineți portul 9014 și baza de date în afara internetului deschis

Portul 9014 este canalul prin care serverul de joc se înregistrează la serverul de login, și nu are ce căuta, în nicio situație, în internetul deschis. L2J livrează deja valoarea implicită corectă: LoginHostname = 127.0.0.1 leagă portul la interfața loopback, deci din exterior nu este deloc accesibil. Dacă serverul de login și serverul de joc rulează pe două mașini diferite, introduceți în locul lui * adresa internă concretă și deschideți portul exclusiv pentru celălalt capăt.

Aceeași regulă este valabilă pentru baza de date. Verificați în /etc/mysql/mariadb.conf.d/50-server.cnf că acolo scrie:

bind-address = 127.0.0.1

Și schimbați utilizatorul bazei de date. Fișierul Server.properties livrat are Login = root, iar fișierul însuși comentează asta cu observația că exact acest lucru nu este recomandat. Cum creați un utilizator propriu cu drepturi minime este descris în Securizarea MariaDB și MySQL. După aceea verificați rezultatul:

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

Firewallul de deasupra rămâne scurt. Pentru un server de Lineage 2 sunt suficiente două deschideri către exterior, și anume exact în această ordine, ca să nu vă blocați singur accesul:

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

Ghidul complet, inclusiv calea de salvare, îl găsiți în Configurarea firewallului UFW fără să vă blocați singur accesul.

3. Dezactivați AcceptNewGameServer imediat ce serverul este înregistrat

În LoginServer.properties scrie din fabrică AcceptNewGameServer = True, iar comentariul de deasupra descrie exact ce înseamnă asta: orice server de joc are voie să se înregistreze pe un loc liber al serverului dumneavoastră de login. Atât timp cât 9014 se află doar pe interfața loopback, asta rămâne fără urmări. În momentul în care portul devine accesibil din alt motiv, este o ușă deschisă. Puneți deci valoarea pe False imediat ce serverul dumneavoastră de joc s-a înregistrat o dată și are identificatorul său:

AcceptNewGameServer = False

În corespondentul de pe partea serverului de joc scrie AcceptAlternateID = True. Asta este comod la construcție, pentru că serverul de login atribuie atunci un alt identificator dacă cel dorit este ocupat. Pe un sistem de producție vreți exact invers: un identificator fix și o eroare dacă este ocupat.

4. Reglați corect flood protection-ul serverului de login

L2J aduce cu el o frână proprie pentru conexiuni în serverul de login. Ea se află în LoginServer.properties, iar toate valorile de timp sunt milisecunde:

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

Valorile depind una de alta. O conexiune care sosește de la aceeași adresă sursă la mai puțin de FastConnectionTime după precedenta este numărată ca rapidă. După FastConnectionLimit astfel de conexiuni, adresa este respinsă. NormalConnectionTime este intervalul de la care contorul scade din nou. MaxConnectionPerIP este limita superioară a conexiunilor deschise simultan per adresă.

Cincizeci de conexiuni simultane sunt foarte generoase pentru un singur jucător, iar valorile mai mici ajută sensibil. Totuși, aici este nevoie de prudență: mai mulți jucători din aceeași gospodărie, un internet café și mai ales conexiunile din spatele unui Carrier-NAT (în scena L2 asta îi privește pe mulți jucători din Turcia, din Brazilia și din părți ale Europei de Est) împart o singură adresă publică. Cine pune aici valoarea 3 blochează jucători reali. Măsurați mai întâi o săptămână în funcționare normală, apoi coborâți în pași mici.

Și o limitare pe care trebuie să o cunoașteți: această frână rulează în procesul Java al serverului de login. Fiecare pachet despre care ea decide a trecut deja prin conexiunea dumneavoastră și a consumat deja timp de calcul. Împotriva câtorva surse funcționează, împotriva unui botnet nu.

5. Limitați încercările eșuate și folosiți banned_ip.cfg

Alte două directive din LoginServer.properties controlează cât timp are voie cineva să ghicească:

LoginTryBeforeBan = 5
LoginBlockAfterBan = 900

LoginTryBeforeBan este numărul de combinații invalide de cont și parolă după care adresa este blocată, LoginBlockAfterBan este durata blocării în secunde (900 corespund la 15 minute). După aceea numărătoarea începe de la capăt.

Blocările permanente le introduceți în fișierul banned_ip.cfg din directorul de configurare al serverului de login. Sunt permise adrese individuale, rețele întregi și un moment de expirare opțional, ca marcaj temporal Unix în milisecunde, iar tot ce urmează după # este comentariu:

198.51.100.7
203.0.113.0
198.51.100.44 1789689600000

Puneți în plus AutoCreateAccounts = False. Valoarea implicită True creează automat un cont la fiecare autentificare cu un nume de cont necunoscut. Asta este practic la construcție și un cadou în funcționarea normală: un atacator creează astfel oricâte conturi dorește, și fiecare dintre ele are voie să solicite lista de servere cu adresa serverului dumneavoastră de joc. Lăsați conturile să apară în schimb prin înregistrarea de pe site-ul dumneavoastră, atunci controlați cine primește un identificator.

6. Limitați în kernel rata conexiunilor pe 2106 și 7777

Ce decide prea târziu frâna din Java decide kernelul mai devreme și mai ieftin. Împotriva atacurilor mici și a boților neglijenți ajută o limită superioară per adresă sursă:

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

Prima regulă elimină conexiunile noi către serverul de login în momentul în care o adresă are mai mult de opt deschise simultan. Un client obișnuit are nevoie de exact una. A doua limitează rata conexiunilor noi la șase pe secundă per adresă, cu un buffer de douăzeci, ceea ce încă lasă să treacă un val de reconectări după o repornire a serverului. A treia permite pe serverul de joc șase conexiuni simultane per adresă, pentru că autentificarea multiplă (dualbox și triplebox) este normală în Lineage 2, iar o limită prea strânsă îi lovește pe jucătorii dumneavoastră care plătesc.

Toate cele trei numere sunt valori de start, nu adevăruri. Un server cu 2000 de jucători simultani se comportă altfel decât unul cu 200. Măsurați mai întâi, reglați apoi. Regulile iptables simple dispar după o repornire, pe Debian și Ubuntu se salvează astfel:

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

Sub UFW, astfel de reguli aparțin în /etc/ufw/before.rules, pentru că altfel dispar la următorul ufw reload.

7. Opriți SYN-flood-ul: syncookies, backlog și urmărirea conexiunilor

Pentru că Lineage 2 funcționează exclusiv prin TCP, SYN-flood-ul este vectorul evident. Un SYN-flood este un atac care trimite cereri de conexiune cu adrese sursă falsificate și nu răspunde niciodată la confirmare, astfel încât serverul rezervă pentru fiecare cerere memorie care nu este folosită niciodată. Patru setări atenuează asta:

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 sunt linia cea mai importantă: kernelul răspunde la cerere fără să rețină nimic și creează starea abia atunci când capătul celălalt finalizează într-adevăr conexiunea. Adresele sursă falsificate ajung astfel în gol. Permanent, valorile se pun într-un fișier sub /etc/sysctl.d/ și se încarcă cu sysctl --system.

Un punct critic trecut adesea cu vederea este urmărirea conexiunilor din kernel. Dacă se umple, serverul elimină și pachete legitime, iar în jurnal apare „nf_conntrack: table full, dropping packet”. Starea și limita superioară le arată:

sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max

8. Site, server de login și server de joc pe adrese IP separate

Site-ul proiectului, cu înregistrare, magazin de donații și pagini de vote, este oricând de găsit prin domeniul dumneavoastră. Dacă se află pe aceeași adresă IP ca serverul de login, un atac asupra site-ului paralizează în același timp autentificarea, și invers. Separați cele trei roluri pe adrese diferite. Atunci, la un atac asupra site-ului, jocul rămâne accesibil, iar la un atac pe 2106, jucătorii deja conectați continuă să joace.

Păstrați totodată înregistrările DNS curate. Cea mai frecventă greșeală este o înregistrare A uitată, care indică o adresă anterioară: ea face orice schimbare de adresă ineficientă, pentru că atacatorul găsește noua adresă pe aceeași cale ca jucătorii dumneavoastră.

Și aici este locul pentru onestitate, nu pentru iluzii: adresa serverului dumneavoastră de login nu poate fi ținută secretă. Ea se află în l2.ini din folderul System, pe care îl descarcă fiecare jucător. Adresa serverului de joc o distribuie, la rândul său, chiar serverul dumneavoastră de login: în L2J ea stă ca adresă externă în ipconfig.xml (în derivatele mai vechi ca ExternalHostname în Server.properties) și este comunicată fiecărui client care s-a autentificat cu succes. Ascunderea nu este o strategie, filtrarea este.

9. Înregistrați date, ca să aveți cifre la nevoie

Pasul cel mai important este cel pe care aproape nimeni nu îl face din timp: să creați o bază de comparație cât timp totul merge normal. Fără o valoare normală nu puteți spune, după un incident, dacă 40.000 de pachete pe secundă erau mult sau pur și simplu sâmbătă seara. Cu apt-get install -y vnstat sysstat măsurarea rulează permanent. În timpul unui incident sunt suficiente patru comenzi:

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

A doua linie este cea mai concludentă la Lineage 2: ea numără conexiunile pe jumătate deschise. O valoare de cinci cifre la câteva sute de jucători este un SYN-flood și nimic altceva. La tcpdump este valabil: limitați întotdeauna cu -c, o captură sub sarcină maximă încarcă suplimentar un server deja suprasolicitat. Cum interpretați valorile scrie în Cum recunoașteți un atac DDoS.

Unde se termină aceste măsuri

Acum partea pe care nu o poate rezolva niciun fișier de configurare. Toate măsurile de până acum rulează pe serverul dumneavoastră, deci la capătul conexiunii. O regulă de firewall decide despre un pachet care a trecut deja prin cablu. Îl puteți elimina, dar nu îl puteți face netrimis.

Faceți o dată calculul. Un server de joc obișnuit atârnă pe 1 Gbit/s, adică 125 de megaocteți pe secundă, iar conexiunea este plină imediat ce cineva trimite mai mult. Împotriva unui server de Lineage 2 nu este nevoie nici măcar de un atac mare, pentru că a doua mărime lovește mai devreme: rata de pachete. La pachete mici, de 64 de octeți, într-o conexiune de 1 Gbit/s încap circa 1,49 milioane de pachete pe secundă. Un kernel obișnuit de server procesează, în funcție de procesor și de placa de rețea, câteva sute de mii dintre ele înainte să înceapă să le elimine.

La un joc exclusiv pe TCP se adaugă o a treia limită. Fiecare conexiune pe jumătate deschisă ocupă o intrare în urmărirea conexiunilor și în backlog, iar serverul de login L2J își ține sesiunile până la 60 de secunde. Un atac cu câteva sute de mii de pachete pe secundă, care nu vă umple conexiunea nici pe o treime, poate deci bloca complet autentificarea. Operatorii trăiesc asta ca „încărcarea nu era deloc mare, și totuși nu intra nimeni”.

Pentru încadrare, ce ordine de mărime apar în realitate: pe serverele KernelHost au fost filtrate, printre altele, un atac cu peste 112,2 Gbit/s la peste 8,7 milioane de pachete pe secundă împotriva unui server de joc și un atac multi-vector cu peste 473,4 Gbit/s la peste 41,5 milioane de pachete pe secundă împotriva unui server de voce. Pentru asta nu există nicio setare locală. Atacurile volumetrice trebuie să se termine în rețeaua din fața serverului. Ce este de făcut în cazul acut scrie în Atac DDoS sever: ce faceți?.

Ce pune KernelHost în fața atacurilor

Protecția permanentă, inclusă pe fiecare server

Protecția DDoS de la KernelHost este construită pe două niveluri și este activă permanent, fără să trebuiască să porniți, să comandați sau să configurați ceva:

• Nivelul 1: 17 Tbps capacitate de mitigare în rețeaua globală de scrubbing. Atacurile volumetrice sunt curățate aproape de sursa lor, înainte să ajungă la centrul de date.
• Nivelul 2: filtrare Arbor în timp real cu 3,2 Tbps în Frankfurt pe Main. Direct în fața serverului sunt recunoscute și eliminate tiparele specifice protocolului, pachet cu pachet.

Două proprietăți sunt decisive. Protecția rulează permanent și nu trebuie să reacționeze abia la un atac, deci nu există minute la început în care serverul lipsește. Tocmai la un Grand Opening asta este diferența dintre o lansare reușită și una pierdută. Și nu se folosește nullrouting: adresa dumneavoastră IP rămâne în rețea, sunt eliminate doar pachetele dăunătoare. Cine scoate adresa IP din rețea obține pentru dumneavoastră același rezultat ca atacatorul. Ce jocuri și protocoale sunt acoperite listează Protecție DDoS pentru servere de joc în timp real.

Advanced DDoS Protection pentru proiectele atacate constant

Unele proiecte nu sunt atacate ocazional, ci țintit și săptămâni la rând, iar în scena Lineage 2 acesta este cazul normal pentru orice server care ajunge în primele poziții ale listelor de servere. Pentru asta există Advanced DDoS Protection, de la 50,00 EUR pe lună, PrePaid și fără durată minimă. Diferența nu stă în mai multă capacitate, ci în control:

• IP de protecție dedicat din nucleul de la Frankfurt, pe care serverul dumneavoastră este comutat în rețeaua noastră. La dumneavoastră nu este nevoie de nicio modificare.
• Reguli de protecție administrabile de dumneavoastră, per port și protocol, în panoul clientului: stabiliți separat ce este permis pe 2106 TCP și ce pe 7777 TCP. La Lineage 2 acesta este punctul decisiv, pentru că cele două porturi au tipare de trafic complet diferite: multe conexiuni scurte pe o parte, puține foarte lungi pe cealaltă.
• Modificările intră în vigoare în timp real, deci puteți ajusta în timpul unui atac în desfășurare și puteți face regulile mai stricte înainte de ora deschiderii, iar apoi le puteți relaxa din nou.
• Profil de protecție potrivit aplicației, și pentru fișiere de server modificate sau proprii, pe orice porturi TCP sau UDP. Dacă folosiți L2J, L2J-Mobius, aCis sau un pachet L2OFF nu are importanță pentru set de reguli, pentru că acesta se bazează pe port și protocol.

Cele două niveluri în comparație

Pentru majoritatea proiectelor de Lineage 2 este suficientă protecția permanentă inclusă, împreună cu o configurație de server curată. Advanced DDoS Protection este răspunsul la situația în care cineva o ia personal, iar asta se întâmplă, din experiență, în săptămâna dinaintea Grand Opening-ului.

Erori frecvente și soluții

„Loginul nu merge, dar serverul de joc funcționează normal”: asta nu este o coincidență, ci forma obișnuită a unui atac asupra unui server de Lineage 2. Serverul de login și serverul de joc sunt două procese pe două porturi. Măsurați ss -tn state syn-recv | wc -l și sar -n DEV 1 10. Dacă urcă conexiunile pe jumătate deschise în timp ce lățimea de bandă rămâne neremarcabilă, este un flood de conexiuni pe 2106.

„Am schimbat adresa IP și a doua zi eram iar offline”: atacatorul primește noua adresă pe aceeași cale ca jucătorii dumneavoastră, adică prin noul folder System cu l2.ini modificat, prin anunțul dumneavoastră sau printr-o înregistrare DNS uitată. O schimbare de adresă este timp câștigat, nu o soluție.

„Am pus MaxConnectionPerIP pe 3 și acum jucătorii se plâng”: dualbox-ul este uzual în Lineage 2, iar jucătorii din spatele unui Carrier-NAT împart o adresă publică cu alte sute. Întoarceți-vă la o valoare care acoperă măsurătorile dumneavoastră din funcționarea normală și limitați în schimb rata conexiunilor noi în kernel.

„Regulile mele iptables nu se aplică”: trei cauze sunt frecvente. Regulile stau după lanțurile UFW și nu sunt atinse niciodată, ele au dispărut după ultima repornire (atunci ajută netfilter-persistent save sau o intrare în /etc/ufw/before.rules), sau atacul este volumetric și regula lucrează corect pe o conexiune care este deja plină. Verificați cu iptables -L INPUT -n -v dacă urcă contoarele de potriviri. Dacă rămân la zero, regula nu este atinsă.

„Toți jucătorii au vârfuri de lag, dar conexiunea este liniștită”: atunci nu este un atac DDoS. La un server Java, suspecții obișnuiți sunt pauzele colectorului de memorie, o bază de date fără indecși potriviți și un script sau un eveniment propriu rulat în buclă. Verificați mai întâi sar -n DEV 1 10: dacă ratele de pachete rămân normale, cauza este în server și nu în rețea.

„Furnizorul meu anterior mi-a blocat adresa IP”: acesta este nullrouting. Furnizorul își protejează astfel propria rețea, pentru dumneavoastră rezultatul este identic cu un atac reușit, de obicei încă ore după aceea. Întrebați la nevoie dacă se filtrează sau dacă se aplică nullrouting. Răspunsul decide mai mult despre disponibilitatea dumneavoastră decât orice specificație de hardware.

„În tcpdump nu văd nimic ieșit din comun”: dacă traficul este filtrat deja în rețeaua din față, pe server nu ajunge, previzibil, nimic. Acesta este cazul normal la o filtrare funcțională. Invers este valabil: dacă conexiunea este saturată, este posibil să nu vă mai ajungă nici măcar sesiunea SSH cu care voiați să măsurați. Folosiți atunci consola VNC din panoul clientului, care funcționează independent de rețeaua sistemului oaspete.

„Grand Opening-ul meu este în două săptămâni”: atunci mutați acum și nu în săptămâna lansării. O mutare costă un folder System nou pentru jucători, o comutare DNS și o rulare de test. Toate acestea vreți să le aveți în spate înainte să anunțați data, pentru că de la anunț fiecare concurent cunoaște momentul dumneavoastră cel mai nefavorabil.

Pe scurt

• Un server privat de Lineage 2 are nevoie de exact două porturi în internetul deschis: 2106 TCP pentru serverul de login și 7777 TCP pentru serverul de joc. Portul 9014, baza de date (3306 la L2J, 1433 la L2OFF) și porturile interne L2OFF 2002, 2006, 2008, 2104 și 2108 nu fac parte din ele.
• Lineage 2 funcționează exclusiv prin TCP și nu are nici port de query, nici port RCON. Atacul tipic este de aceea un SYN-flood sau un flood de conexiuni pe portul 2106 și nu un flood UDP.
• Un atac asupra serverului de login blochează doar autentificările noi. Dacă nimeni nu intră în timp ce jucătorii din lume continuă să joace, cauza este de căutat pe portul 2106 și nu pe 7777.
• Setați conștient EnableFloodProtection, MaxConnectionPerIP, LoginTryBeforeBan și AutoCreateAccounts, puneți AcceptNewGameServer pe False după înregistrare și limitați suplimentar rata conexiunilor în kernel, pentru că frâna din Java acționează abia în spatele conexiunii.
• Atacurile asupra serverelor de Lineage 2 se aglomerează la lansările de server, pentru că data și ora sunt publice cu săptămâni înainte și pentru că paguba economică este cea mai mare în ziua deschiderii. Protecția trebuie să existe înainte de anunț, nu după.
• Peste capacitatea conexiunii și peste câteva sute de mii de pachete pe secundă decide exclusiv filtrarea în rețeaua din fața serverului. La KernelHost ea este pe două niveluri, activă permanent, fără cost suplimentar și fără nullrouting.

Dacă proiectul dumneavoastră rulează deja la KernelHost, filtrarea este activă fără să fie nevoie să faceți ceva. Dacă totuși observați nereguli, deschideți un tichet de suport, pentru ca regulile de filtrare pentru adresa dumneavoastră IP să fie ajustate. În timpul unui atac în desfășurare ne găsiți în plus prin chatul WhatsApp de urgență la +43 650 8209883.