Ochrona serwera Lineage 2 przed atakami DDoS

Prywatny serwer Lineage 2, na którym wieczorami nikt nie przechodzi już poza ekran logowania, podczas gdy gracze w świecie grają dalej bez zakłóceń, nie ma problemu ze sprzętem. To odcisk palca ataku DDoS na serwer logowania, i dokładnie tam musi działać ochrona DDoS dla Lineage 2. Ten artykuł pokazuje najpierw, co możesz zabezpieczyć sam i bez dodatkowych kosztów, potem, gdzie te działania kończą się technicznie, a na koniec, co musi wydarzyć się w sieci przed serwerem.

Wszystkie informacje dotyczą L2J i jego odmian (L2J-Mobius, aCis) na Debianie 12, Debianie 13, Ubuntu 22.04 LTS albo Ubuntu 24.04 LTS oraz pakietów L2OFF z AuthD, CacheD i L2Server. Polecenia są napisane dla użytkownika root, jako zwykły użytkownik poprzedź je poleceniem sudo.

Jeśli atak trwa właśnie teraz: nie zmieniaj niczego w konfiguracji i nie restartuj ani serwera logowania, ani serwera gry. Zabezpiecz najpierw pomiary (patrz rozdział „Zapisuj logi”), po ataku już ich nie będzie.

Ochrona serwera Lineage 2 przed DDoS: dlaczego prywatne serwery L2 są atakowane

Prywatny serwer Lineage 2 łączy kilka cech, które czynią z niego wygodny cel, a ochrona DDoS dla Lineage 2 musi działać dokładnie na tych cechach. Po pierwsze twój adres jest publiczny, i to od samego początku: gracze pobierają spatchowany folder System, a w jego pliku l2.ini stoi wiersz ServerAddr= z adresem IP twojego serwera logowania. Każdy, kto raz zainstalował twój projekt, zna ten adres, niezależnie od tego, czy kiedykolwiek stworzył postać.

Po drugie społeczność gra o stałych porach. Oblężenia, epiccy bossowie i eventy stoją w kalendarzu, więc awaria dokładnie o tej godzinie jest widoczna maksymalnie. Po trzecie projekty konkurują ze sobą bezpośrednio: kto otwiera serwer, zabiega o te same kilka tysięcy graczy co trzy inne projekty w ten sam weekend. Wyłączenie konkurenta jest w tym środowisku powszechną strategią. Atak zamawia się przy tym jako usługę (w tej scenie mówi się o booterach albo stresserach) i nie kosztuje zlecającego ani umiejętności, ani liczących się pieniędzy. Czym dokładnie jest atak DDoS, wyjaśnia wpis Czym jest atak DDoS?.

Dlaczego prawdziwym celem jest serwer logowania na porcie 2106

Lineage 2 jest podzielone na dwa oddzielne procesy: serwer logowania oraz jeden albo kilka serwerów gry. Klient łączy się najpierw na 2106 TCP z serwerem logowania, loguje się, dostaje stamtąd listę serwerów z zewnętrznym adresem i portem serwera gry, a potem buduje drugie połączenie na 7777 TCP do serwera gry. Oba procesy mają własne pliki konfiguracyjne, własne porty i własne granice obciążenia.

Z tego wynika wzorzec ataku, który operatorzy L2 opisują raz po raz: flood na 2106 blokuje wyłącznie nowe logowania. Kto już stoi w świecie, gra dalej, dopóki sam nie straci połączenia. Licznik online spada więc powoli, a nie gwałtownie, a na forum pojawia się „serwer działa, ale nie mogę wejść”. Dokładnie ten obraz odróżnia atak na serwer logowania od ataku na serwer gry, przy którym wszyscy wylatują jednocześnie.

Serwer logowania jest poza tym celem tańszym, bo nakład jest rozłożony nierówno. Serwer logowania L2J tworzy przy starcie zapas dziesięciu par kluczy RSA po 1024 bity oraz dwudziestu kluczy Blowfish. Każda próba logowania kosztuje klienta wysłanie jednego pakietu, a serwer deszyfrowanie prywatnym kluczem RSA. Niedokończona sesja zajmuje przy tym miejsce, dopóki wbudowany zegar jej nie odrzuci: LOGIN_TIMEOUT stoi w kodzie źródłowym na 60 sekundach. Ustawienie domyślne MaxConnectionPerIP = 50 pozwala każdemu adresowi źródłowemu na pięćdziesiąt jednoczesnych połączeń. Tysiąc adresów źródłowych wystarczy więc do 50 000 jednocześnie otwartych sesji, z których każda utrzymuje się nawet przez minutę.

Dochodzi do tego cecha gry, która odróżnia ją od większości serwerów gier: Lineage 2 działa wyłącznie po TCP. Producent podaje dla gry porty TCP 80, 2009, 2106 i 7777, a przy UDP wyłącznie port 53 dla rozwiązywania nazw. Nie ma więc ruchu gry po UDP, który trzeba by filtrować, za to klasyczny SYN-flood z podrobionymi adresami nadawcy działa bezpośrednio, a śledzenie połączeń w kernelu staje się pierwszym wąskim gardłem.

Dlaczego ataki na serwery Lineage 2 pojawiają się sezonowo przy startach serwerów

Ataki na prywatne serwery Lineage 2 kumulują się wokół startów serwerów, bo data i godzina otwarcia są publicznie znane wiele tygodni wcześniej. Kalendarze otwarć projektów Lineage 2 wymieniają nadchodzące starty według kroniki (Interlude, High Five, Classic, Essence), do tego mnożniki (rate) oraz dokładną godzinę startu, a aktualizuje się je codziennie. Atakujący nie musi niczego rozpoznawać: najdogodniejszy dla niego moment stoi w ogłoszeniu operatora.

Drugi powód jest ekonomiczny. Prywatny serwer Lineage 2 zarabia z przodu: całą bazę graczy zdobywa się w pierwszych dniach, wpłaty przychodzą w pierwszych tygodniach, a potem populacja stale się kurczy. Gracz, który w pierwszej godzinie nie wejdzie, przechodzi do projektu startującego w ten sam weekend, a taki projekt istnieje zawsze. Godzina niedostępności w dniu otwarcia kosztuje więc nie godzinę obrotu, tylko część całego czasu życia serwera.

Trzeci powód jest techniczny. Na grand openingu tysiące graczy próbuje zalogować się jednocześnie. Serwer logowania jest w tej właśnie minucie i tak na granicy, a dodatkowy flood ledwie da się odróżnić od szczytu obciążenia. Atak, który w spokojny wtorek pozostałby bez skutku, w godzinie otwarcia wystarcza. To samo dotyczy zapowiedzianych terminów w trakcie normalnej pracy: oblężenia zamków i epiccy bossowie stoją w kalendarzu i z tego samego powodu są lubianymi oknami ataku. Po szturmie otwarcia zachęta znowu spada, dlatego operatorzy przeżywają ataki jako falowe, a nie jako stan trwały.

Porty, o które naprawdę chodzi

Poniższa tabela wymienia porty prywatnego serwera Lineage 2, przypisany plik konfiguracyjny oraz dyrektywę, która ustawia wartość. Ustawienia domyślne pochodzą z dołączonych plików konfiguracyjnych L2J względnie z instrukcji instalacji pakietów L2OFF.

Ta tabela odpowiada przy okazji na dwa pytania: Lineage 2 nie ma ani portu query, ani portu RCON. Nie istnieje osobna usługa, która wydawałaby stan graczy dla listy serwerów, ani port zdalnego sterowania jak w grach na silniku Source. Listę serwerów tworzy sam serwer logowania i wysyła ją tym samym połączeniem na 2106 do zalogowanego klienta. Zdalne sterowanie działa w L2J przez komendy w grze oraz przez bazę danych. Odpadają więc dwa wektory ataku, które mają inne gry, a tym więcej zostaje na porcie 2106.

Rzędy wielkości, które warto znać

Co możesz zrobić sam, zanim wydasz pieniądze

Ten rozdział jest najdłuższy i to celowo. Czysto skonfigurowany serwer Lineage 2 wytrzyma małe i średnie ataki o własnych siłach, niezależnie od tego, u kogo stoi.

1. Inwentaryzacja: co w ogóle nasłuchuje?

Zanim napiszesz choć jedną regułę, sprawdź, co twój serwer wystawia na zewnątrz. Nie zgaduj, sprawdź:

ss -lntp

Interesuje cię kolumna z adresem lokalnym. 0.0.0.0:2106 i 0.0.0.0:7777 należą tam. 0.0.0.0:9014 i 0.0.0.0:3306 to błędy: to dwa porty, przez które atakujący może wpiąć się w twoją listę serwerów albo obmacać twoją bazę danych. 127.0.0.1:3306 oznacza natomiast „tylko lokalnie” i nie potrzebuje żadnej reguły firewalla. Spojrzenie oczami atakującego daje skan portów z zewnątrz:

nmap -Pn -p- --min-rate 1000 TWOJ.ADRES.IP.SERWERA

2. Trzymaj port 9014 i bazę danych z dala od otwartej sieci

Port 9014 to kanał, przez który serwer gry rejestruje się w serwerze logowania, i pod żadnym pozorem nie należy do otwartej sieci. L2J dostarcza już właściwe ustawienie domyślne: LoginHostname = 127.0.0.1 wiąże port z interfejsem loopback, z zewnątrz jest więc w ogóle nieosiągalny. Jeśli serwer logowania i serwer gry działają na dwóch różnych maszynach, wpisz zamiast * konkretny adres wewnętrzny i udostępnij port wyłącznie dla drugiej strony.

Ta sama zasada dotyczy bazy danych. Sprawdź w pliku /etc/mysql/mariadb.conf.d/50-server.cnf, czy stoi tam:

bind-address = 127.0.0.1

I wymień użytkownika bazy danych. Dołączony plik Server.properties stoi na Login = root, a sam plik komentuje to uwagą, że dokładnie tak robić nie należy. Jak założyć własnego użytkownika z minimalnymi uprawnieniami, opisuje wpis Zabezpieczanie MariaDB i MySQL. Potem skontroluj wynik:

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

Firewall nad tym zostaje krótki. Dla serwera Lineage 2 wystarczą dwa udostępnienia na zewnątrz, dokładnie w tej kolejności, żebyś nie zamknął dostępu samemu sobie:

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

Pełną instrukcję razem z drogą ratunkową znajdziesz we wpisie Konfiguracja firewalla UFW bez zamykania sobie dostępu.

3. Wyłącz AcceptNewGameServer, gdy twój serwer jest już zarejestrowany

W pliku LoginServer.properties fabrycznie stoi AcceptNewGameServer = True, a komentarz nad tym opisuje dokładnie, co to znaczy: każdy serwer gry może zarejestrować się na wolnym miejscu twojego serwera logowania. Dopóki 9014 leży tylko na interfejsie loopback, jest to bez konsekwencji. Gdy tylko port stanie się osiągalny z innego powodu, są to otwarte drzwi. Ustaw więc wartość na False, gdy tylko twój własny serwer gry zarejestruje się raz i dostanie swój identyfikator:

AcceptNewGameServer = False

W odpowiedniku po stronie serwera gry stoi AcceptAlternateID = True. To wygodne przy budowie, bo serwer logowania przydziela wtedy inny identyfikator, gdy żądany jest zajęty. Na systemie produkcyjnym chcesz czegoś odwrotnego: stałego identyfikatora oraz błędu, gdy jest zajęty.

4. Ustaw poprawnie flood protection serwera logowania

L2J ma własny hamulec połączeń w serwerze logowania. Stoi on w LoginServer.properties, a wszystkie wartości czasu podawane są w milisekundach:

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

Wartości są ze sobą powiązane. Połączenie, które przychodzi z tego samego adresu źródłowego mniej niż FastConnectionTime po poprzednim, liczy się jako szybkie. Po FastConnectionLimit takich połączeniach adres zostaje odrzucony. NormalConnectionTime to odstęp, od którego licznik znowu się zmniejsza. MaxConnectionPerIP to górna granica jednocześnie otwartych połączeń na adres.

Pięćdziesiąt jednoczesnych połączeń jest dla pojedynczego gracza bardzo hojne, a niższe wartości pomagają odczuwalnie. Mimo to trzeba tu ostrożności: kilku graczy w tym samym gospodarstwie domowym, kafejka internetowa i przede wszystkim łącza za carrier-NAT (w scenie L2 dotyczy to wielu graczy z Turcji, z Brazylii i z części Europy Wschodniej) dzielą jeden adres publiczny. Kto ustawi tu 3, wyrzuci prawdziwych graczy. Najpierw mierz przez tydzień w normalnej pracy, potem obniżaj stopniowo.

I jedno ograniczenie, które musisz znać: ten hamulec działa w procesie Javy serwera logowania. Każdy pakiet, o którym on decyduje, przeszedł już przez twoje łącze i kosztował już czas procesora. Przeciw garstce źródeł działa, przeciw botnetowi nie.

5. Ogranicz nieudane próby i korzystaj z banned_ip.cfg

Dwie kolejne dyrektywy w LoginServer.properties sterują tym, jak długo ktoś może zgadywać:

LoginTryBeforeBan = 5
LoginBlockAfterBan = 900

LoginTryBeforeBan to liczba nieprawidłowych kombinacji konta i hasła, po której adres zostaje zablokowany, a LoginBlockAfterBan to czas blokady w sekundach (900 odpowiada 15 minutom). Potem liczenie zaczyna się od nowa.

Trwałe blokady wpisujesz do pliku banned_ip.cfg w katalogu konfiguracyjnym serwera logowania. Dozwolone są pojedyncze adresy, całe sieci oraz opcjonalny moment wygaśnięcia jako uniksowy znacznik czasu w milisekundach, a wszystko po # jest komentarzem:

198.51.100.7
203.0.113.0
198.51.100.44 1789689600000

Ustaw poza tym AutoCreateAccounts = False. Ustawienie domyślne True zakłada automatycznie konto przy każdym logowaniu nieznaną nazwą konta. To praktyczne przy budowie, a w normalnej pracy jest prezentem: atakujący tworzy w ten sposób dowolnie wiele kont, a każde z nich może pobrać listę serwerów z adresem twojego serwera gry. Pozwól zamiast tego, żeby konta powstawały przez rejestrację na twojej stronie, wtedy kontrolujesz, kto dostaje identyfikator.

6. Ogranicz tempo połączeń na portach 2106 i 7777 w kernelu

To, o czym hamulec w Javie decyduje za późno, kernel rozstrzyga wcześniej i taniej. Przeciw małym atakom i niechlujnym botom pomaga górny limit na adres źródłowy:

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

Pierwsza reguła odrzuca nowe połączenia do serwera logowania, gdy jeden adres ma ich jednocześnie otwartych więcej niż osiem. Regularny klient potrzebuje dokładnie jednego. Druga ogranicza tempo nowych połączeń do sześciu na sekundę na adres z buforem dwudziestu, co przepuszcza jeszcze sztorm ponownych połączeń po restarcie serwera. Trzecia pozwala na serwerze gry na sześć jednoczesnych połączeń na adres, bo wielokrotne logowanie (dualbox i triplebox) jest w Lineage 2 normalne, a zbyt ciasna granica uderza w twoich płacących graczy.

Wszystkie trzy liczby to wartości startowe, a nie prawdy objawione. Serwer z 2000 jednoczesnych graczy zachowuje się inaczej niż ten z 200. Najpierw mierz, potem ustawiaj. Same reguły iptables znikają po restarcie, na Debianie i Ubuntu zapisuje się je tak:

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

Przy UFW takie reguły należą do /etc/ufw/before.rules, bo inaczej znikną przy następnym ufw reload.

7. Zatrzymaj SYN-flood: syncookies, backlog i śledzenie połączeń

Ponieważ Lineage 2 działa wyłącznie po TCP, SYN-flood jest oczywistym wektorem. SYN-flood to atak, który wysyła prośby o połączenie z podrobionymi adresami nadawcy i nigdy nie odpowiada na potwierdzenie, przez co serwer rezerwuje dla każdego zapytania pamięć, która nigdy nie zostaje użyta. Cztery ustawienia to rozbrajają:

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 są przy tym najważniejszym wierszem: kernel odpowiada na zapytanie, nie zapamiętując niczego, a stan zakłada dopiero wtedy, gdy druga strona naprawdę zestawi połączenie. Podrobieni nadawcy trafiają tym samym w pustkę. Na stałe wartości odkłada się w pliku pod /etc/sysctl.d/ i ładuje poleceniem sysctl --system.

Często przeoczonym wąskim gardłem jest śledzenie połączeń w kernelu. Gdy się zapełni, serwer odrzuca także legalne pakiety, a w logu stoi „nf_conntrack: table full, dropping packet”. Stan i górny limit pokazuje:

sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max

8. Strona WWW, serwer logowania i serwer gry na oddzielnych adresach IP

Strona projektu z rejestracją, sklepem z wpłatami i stronami głosowania jest przez twoją domenę zawsze do znalezienia. Jeśli leży na tym samym adresie IP co serwer logowania, atak na stronę kładzie jednocześnie logowanie, i odwrotnie. Rozdziel te trzy role na różne adresy. Wtedy przy ataku na stronę gra zostaje osiągalna, a przy ataku na 2106 gracze już połączeni grają dalej.

Trzymaj przy tym wpisy DNS w czystości. Najczęstszym błędem jest zapomniany rekord A wskazujący na wcześniejszy adres: unieważnia on każdą zmianę adresu, bo atakujący znajduje nowy adres tą samą nazwą co twoi gracze.

I tutaj należy się szczerość zamiast myślenia życzeniowego: adresu twojego serwera logowania nie da się utrzymać w tajemnicy. Stoi on w pliku l2.ini w folderze System, który pobiera każdy gracz. Adres serwera gry rozdaje z kolei sam serwer logowania: w L2J stoi on jako adres zewnętrzny w ipconfig.xml (w starszych odmianach jako ExternalHostname w Server.properties) i jest przekazywany każdemu klientowi, który zalogował się pomyślnie. Ukrywanie nie jest strategią, filtrowanie jest.

9. Zapisuj logi, żeby w razie ataku mieć dane

Najważniejszy krok to ten, którego prawie nikt nie robi wcześniej: przygotuj bazę porównawczą, dopóki wszystko działa normalnie. Bez wartości normalnej po incydencie nie powiesz, czy 40 000 pakietów na sekundę to dużo, czy po prostu sobotni wieczór. Po apt-get install -y vnstat sysstat pomiar chodzi na stałe w tle. W trakcie incydentu wystarczą cztery polecenia:

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

Drugi wiersz jest przy Lineage 2 najbardziej wymowny: liczy połączenia półotwarte. Pięciocyfrowa wartość przy kilkuset graczach to SYN-flood i nic innego. Przy tcpdump obowiązuje zasada: zawsze ograniczaj przez -c, bo zrzut przy pełnym obciążeniu dodatkowo obciąża i tak przeciążony serwer. Jak odczytać te wartości, opisuje wpis Jak rozpoznać atak DDoS.

Gdzie te działania się kończą

Teraz część, której nie rozwiąże żaden plik konfiguracyjny. Wszystkie dotychczasowe działania dzieją się na twoim serwerze, czyli na końcu łącza. Reguła firewalla decyduje o pakiecie, który już przeszedł przez kabel. Możesz go odrzucić, ale nie możesz sprawić, żeby nie został wysłany.

Policz to razem ze mną. Typowy serwer gier wisi na 1 Gbit/s, czyli 125 megabajtów na sekundę, a łącze jest pełne, gdy tylko ktoś wyśle więcej. Przeciw serwerowi Lineage 2 nie potrzeba do tego nawet dużego ataku, bo druga wielkość uderza wcześniej: liczba pakietów. Przy małych pakietach po 64 bajty w łącze 1 Gbit/s mieści się około 1,49 miliona pakietów na sekundę. Zwykły kernel serwera przetworzy z tego, zależnie od CPU i karty sieciowej, kilkaset tysięcy, zanim zacznie odrzucać.

Przy grze działającej wyłącznie po TCP dochodzi trzecia granica. Każde półotwarte połączenie zajmuje wpis w śledzeniu połączeń oraz w backlogu, a serwer logowania L2J trzyma swoje sesje nawet przez 60 sekund. Atak z kilkuset tysiącami pakietów na sekundę, który nie zapełnia twojego łącza nawet w jednej trzeciej, może więc całkowicie zablokować logowanie. Operatorzy przeżywają to jako „przecież obciążenie wcale nie było wysokie, a mimo to nikt nie wchodził”.

Dla porządku wielkości, które zdarzają się naprawdę: na serwerach KernelHost odfiltrowano między innymi atak o wolumenie ponad 112,2 Gbit/s przy ponad 8,7 miliona pakietów na sekundę wymierzony w serwer gier oraz atak wielowektorowy o wolumenie ponad 473,4 Gbit/s przy ponad 41,5 miliona pakietów na sekundę w serwer głosowy. Na to nie ma żadnego ustawienia lokalnego. Ataki wolumetryczne muszą kończyć się w sieci przed serwerem. Co robić w ostrym przypadku, opisuje wpis Ciężki atak DDoS: co robić?.

Co przeciwstawia temu KernelHost

Stała ochrona wliczona w każdy serwer

Ochrona DDoS w KernelHoście jest zbudowana dwuwarstwowo i stale aktywna, bez konieczności włączania, zamawiania czy konfigurowania czegokolwiek:

• Warstwa 1: 17 Tbps pojemności mitygacji w globalnej sieci scrubbing. Ataki wolumetryczne są oczyszczane blisko źródła, zanim dotrą do centrum danych.
• Warstwa 2: filtrowanie Arbor w czasie rzeczywistym o wydajności 3,2 Tbps we Frankfurcie nad Menem. Bezpośrednio przed serwerem rozpoznawane i odrzucane są wzorce specyficzne dla protokołów, pakiet po pakiecie.

Decydujące są dwie cechy. Ochrona działa nieprzerwanie i nie musi dopiero reagować na atak, nie ma więc kilku minut na starcie, w których serwer znika. Właśnie przy grand openingu to różnica między udanym a przegranym startem. I nie stosuje się null-routingu: twój adres IP zostaje w sieci, odrzucane są wyłącznie szkodliwe pakiety. Kto zdejmuje adres IP z sieci, osiąga dla ciebie ten sam efekt co atakujący. Które gry i protokoły są objęte ochroną, wylicza wpis Ochrona DDoS serwerów gier w czasie rzeczywistym.

Advanced DDoS Protection dla projektów pod stałym ostrzałem

Niektóre projekty są atakowane nie okazjonalnie, tylko celowo i przez wiele tygodni, a w scenie Lineage 2 to przypadek normalny dla każdego serwera, który wchodzi na wyższe pozycje list serwerów. Dla nich jest Advanced DDoS Protection od 50,00 € miesięcznie, w modelu PrePaid i bez minimalnego okresu umowy. Różnica nie polega na większej pojemności, tylko na kontroli:

• Dedykowany chroniony adres IP z rdzenia sieci we Frankfurcie, na który twój serwer zostaje przełączony w naszej sieci. Po twojej stronie nie trzeba niczego przebudowywać.
• Samodzielnie zarządzane reguły ochrony na port i protokół w panelu klienta: sam ustawiasz oddzielnie, co jest dozwolone na 2106 TCP, a co na 7777 TCP. W Lineage 2 to punkt decydujący, bo oba porty mają zupełnie inne wzorce ruchu: wiele krótkich połączeń po jednej stronie, niewiele bardzo długich po drugiej.
• Zmiany działają w czasie rzeczywistym, możesz więc korygować ustawienia w trakcie trwającego ataku, a reguły przed godziną otwarcia zaostrzyć i potem znowu poluzować.
• Profil ochrony dopasowany do aplikacji, także dla zmodyfikowanych i własnych plików serwerowych na dowolnych portach TCP albo UDP. To, czy prowadzisz L2J, L2J-Mobius, aCis czy pakiet L2OFF, nie ma dla zestawu reguł znaczenia, bo opiera się on na porcie i protokole.

Porównanie obu wariantów

Dla większości projektów Lineage 2 wystarczy wliczona stała ochrona razem z czystą konfiguracją serwera. Advanced DDoS Protection jest odpowiedzią na sytuację, w której ktoś bierze to do siebie osobiście, a z doświadczenia dzieje się to w tygodniu przed grand openingiem.

Typowe błędy i ich rozwiązania

„Logowanie nie działa, ale serwer gry chodzi normalnie”: to nie przypadek, tylko zwykła postać ataku na serwer Lineage 2. Serwer logowania i serwer gry to dwa procesy na dwóch portach. Zmierz ss -tn state syn-recv | wc -l oraz sar -n DEV 1 10. Jeśli rosną połączenia półotwarte, podczas gdy przepustowość pozostaje niepodejrzana, to flood połączeń na 2106.

„Zmieniłem adres IP i następnego dnia znowu byłem offline”: atakujący dostaje nowy adres tą samą drogą co twoi gracze, czyli przez nowy folder System ze zmienionym l2.ini, przez twoje ogłoszenie albo przez zapomniany wpis DNS. Zmiana adresu to zysk na czasie, a nie rozwiązanie.

„Ustawiłem MaxConnectionPerIP na 3 i teraz gracze się skarżą”: dualbox jest w Lineage 2 rzeczą zwyczajną, a gracze za carrier-NAT dzielą jeden adres publiczny z setkami innych. Wróć do wartości, która pokrywa twoje pomiary z normalnej pracy, a zamiast tego ogranicz tempo nowych połączeń w kernelu.

„Moje reguły iptables nie działają”: częste są trzy przyczyny. Reguły stoją za łańcuchami UFW i nigdy nie zostają osiągnięte, zniknęły po ostatnim restarcie (wtedy pomogą netfilter-persistent save albo wpis w /etc/ufw/before.rules) albo atak jest wolumetryczny, a reguła pracuje poprawnie na łączu, które jest już pełne. Sprawdź przez iptables -L INPUT -n -v, czy liczniki trafień rosną. Jeśli stoją na zerze, reguła nie jest osiągana.

„Wszyscy gracze mają lag spikes, ale łącze jest spokojne”: wtedy to nie jest atak DDoS. Przy serwerze w Javie zwykłymi podejrzanymi są przerwy odśmiecania pamięci, baza danych bez odpowiednich indeksów oraz skrypt albo własny event chodzący w pętli. Sprawdź najpierw sar -n DEV 1 10: jeśli liczba pakietów pozostaje normalna, przyczyna leży w serwerze, a nie w sieci.

„Mój dotychczasowy dostawca zablokował mój adres IP”: to null-routing. Dostawca chroni w ten sposób własną sieć, a dla ciebie wynik jest identyczny z udanym atakiem, zwykle jeszcze przez wiele godzin po nim. W razie wątpliwości zapytaj, czy ruch jest filtrowany, czy null-routowany. Ta odpowiedź decyduje o twojej dostępności bardziej niż jakakolwiek specyfikacja sprzętu.

„W tcpdump nie widzę nic nietypowego”: jeśli ruch jest filtrowany już w sieci przed serwerem, to zgodnie z oczekiwaniem nic na serwer nie dociera. To normalny stan przy działającym filtrowaniu. Odwrotnie też jest prawdą: gdy łącze jest wysycone, może cię nie dosięgnąć nawet sesja SSH, którą chciałeś użyć do pomiaru. Skorzystaj wtedy z konsoli VNC w panelu klienta, która działa niezależnie od sieci systemu gościa.

„Moje grand opening jest za dwa tygodnie”: to przenoś się teraz, a nie w tygodniu startu. Przeprowadzka kosztuje nowy folder System dla graczy, przestawienie DNS oraz próbny przebieg. To wszystko chcesz mieć za sobą, zanim ogłosisz datę, bo od ogłoszenia każdy konkurent zna twój najgorszy moment.

Krótkie podsumowanie

• Prywatny serwer Lineage 2 potrzebuje w otwartej sieci dokładnie dwóch portów: 2106 TCP dla serwera logowania i 7777 TCP dla serwera gry. Port 9014, baza danych (3306 przy L2J, 1433 przy L2OFF) oraz wewnętrzne porty L2OFF 2002, 2006, 2008, 2104 i 2108 do nich nie należą.
• Lineage 2 działa wyłącznie po TCP i nie ma ani portu query, ani portu RCON. Typowym atakiem jest dlatego SYN-flood albo flood połączeń na port 2106, a nie flood UDP.
• Atak na serwer logowania blokuje tylko nowe logowania. Jeśli nikt nie wchodzi, podczas gdy gracze w świecie grają dalej, przyczyny szukaj na porcie 2106, a nie na 7777.
• Ustaw świadomie EnableFloodProtection, MaxConnectionPerIP, LoginTryBeforeBan i AutoCreateAccounts, przestaw AcceptNewGameServer po rejestracji na False i ogranicz tempo połączeń dodatkowo w kernelu, bo hamulec w Javie działa dopiero za łączem.
• Ataki na serwery Lineage 2 kumulują się przy startach serwerów, bo data i godzina są publiczne wiele tygodni wcześniej, a szkoda ekonomiczna jest największa w dniu otwarcia. Ochrona musi stać przed ogłoszeniem, a nie po nim.
• Powyżej pojemności łącza i powyżej kilkuset tysięcy pakietów na sekundę decyduje wyłącznie filtrowanie w sieci przed serwerem. W KernelHoście jest ono dwuwarstwowe, stale aktywne, bez dopłat i bez null-routingu.

Jeśli twój projekt działa już w KernelHoście, filtrowanie jest aktywne i nie musisz nic robić. Gdybyś mimo to zauważył coś nietypowego, załóż zgłoszenie wsparcia, żeby reguły filtrowania dla twojego adresu IP zostały skorygowane. Przy trwającym ataku dotrzesz do nas dodatkowo przez awaryjny czat WhatsApp pod numerem +43 650 8209883.