Proteggere un server Lineage 2 dagli attacchi DDoS

Un server Lineage 2 privato su cui la sera nessuno riesce più a superare la schermata di accesso, mentre i giocatori già nel mondo continuano indisturbati, non ha un problema hardware. Questa è l'impronta di un attacco DDoS contro il login server, ed è esattamente lì che deve agire una protezione DDoS per Lineage 2. Questo articolo mostra prima che cosa puoi mettere in sicurezza da solo senza costi aggiuntivi, poi dove queste misure si fermano dal punto di vista tecnico e infine che cosa deve succedere nella rete, prima del server.

Tutte le indicazioni si riferiscono a L2J e ai suoi derivati (L2J-Mobius, aCis) su Debian 12, Debian 13, Ubuntu 22.04 LTS o Ubuntu 24.04 LTS, oltre che ai pacchetti L2OFF con AuthD, CacheD e L2Server. I comandi sono scritti per root; se lavori come utente normale, anteponi sudo.

Se l'attacco è in corso proprio adesso: non modificare nulla nella configurazione e non riavviare né il login server né il game server. Metti prima al sicuro i valori misurati (vedi il paragrafo "Registrare i log"), perché dopo l'attacco non ci sono più.

Proteggere un server Lineage 2 dal DDoS: perché i server L2 privati vengono attaccati

Un server Lineage 2 privato mette insieme diverse caratteristiche che ne fanno un bersaglio comodo, e la protezione DDoS per Lineage 2 deve agire esattamente su queste caratteristiche. Primo, il tuo indirizzo è pubblico, e lo è fin dall'inizio: i giocatori scaricano una cartella System già modificata, e nel suo l2.ini c'è la riga ServerAddr= con l'indirizzo IP del tuo login server. Chiunque abbia installato una volta il tuo progetto conosce questo indirizzo, a prescindere dal fatto che abbia mai creato un personaggio.

Secondo, il pubblico è legato a orari fissi. Assedi, epic raid boss ed eventi sono a calendario, e un disservizio proprio in quell'ora è quello che si nota di più. Terzo, i progetti sono in concorrenza diretta fra loro: chi apre un server corteggia le stesse poche migliaia di giocatori di altri tre progetti nello stesso fine settimana. Mettere fuori uso un concorrente, in questo ambiente, è una strategia corrente. Un attacco viene per giunta acquistato come servizio (nell'ambiente si parla di booter o stresser) e non costa a chi lo commissiona né competenze né soldi degni di nota. Che cosa sia nel dettaglio un attacco DDoS lo spiega l'articolo Che cos'è un attacco DDoS?.

Perché il vero bersaglio è il login server sulla porta 2106

Lineage 2 è suddiviso in due processi separati: un login server e uno o più game server. Il client si collega prima su 2106 TCP al login server, effettua l'accesso, riceve da lì la lista dei server con l'indirizzo esterno e la porta del game server e apre poi una seconda connessione su 7777 TCP verso il game server. I due processi hanno file di configurazione propri, porte proprie e limiti di carico propri.

Da qui deriva lo schema di attacco che gli operatori L2 descrivono di continuo: un flood sulla 2106 blocca esclusivamente i nuovi accessi. Chi è già nel mondo di gioco continua a giocare, finché non perde a sua volta la connessione. Il contatore degli utenti online scende quindi lentamente invece che di colpo, e sul forum compare la frase "il server gira, ma io non riesco a entrare". È esattamente questo quadro a distinguere un attacco al login server da un attacco al game server, nel quale tutti vengono buttati fuori insieme.

Il login server è inoltre il bersaglio più economico, perché lo sforzo è distribuito in modo sbilanciato. All'avvio il login server di L2J genera una scorta di dieci coppie di chiavi RSA da 1024 bit e venti chiavi Blowfish. Ogni tentativo di accesso costa al client l'invio di un pacchetto e al server una decifratura con la chiave RSA privata. Una sessione lasciata a metà occupa intanto un posto, finché il timer integrato non la scarta: LOGIN_TIMEOUT nel codice sorgente è impostato a 60 secondi. L'impostazione predefinita MaxConnectionPerIP = 50 permette a ogni indirizzo sorgente cinquanta connessioni contemporanee. Mille indirizzi sorgente bastano quindi per 50.000 sessioni aperte insieme, ciascuna delle quali resta in piedi fino a un minuto.

A questo si aggiunge una particolarità del gioco che lo distingue dalla maggior parte dei game server: Lineage 2 funziona esclusivamente su TCP. Il produttore indica per il gioco le porte TCP 80, 2009, 2106 e 7777, e su UDP soltanto la porta 53 per la risoluzione dei nomi. Non esiste quindi traffico di gioco UDP da filtrare, in compenso il classico SYN flood con indirizzi mittente falsificati è direttamente efficace, e il tracciamento delle connessioni del kernel diventa il primo collo di bottiglia.

Perché gli attacchi ai server Lineage 2 arrivano a ondate intorno alle aperture

Gli attacchi ai server Lineage 2 privati si concentrano intorno alle aperture, perché data e ora dell'apertura sono pubbliche già settimane prima. I calendari delle aperture per i progetti Lineage 2 elencano le partenze in arrivo per cronaca (Interlude, High Five, Classic, Essence), insieme ai moltiplicatori e all'ora esatta di avvio, e vengono aggiornati ogni giorno. Chi attacca non deve fare alcuna ricognizione: il momento per lui più favorevole è scritto nell'annuncio dell'operatore.

Il secondo motivo è economico. Un server Lineage 2 privato guadagna all'inizio: l'intera base di giocatori viene acquisita nei primi giorni, le donazioni arrivano nelle prime settimane, poi la popolazione cala di continuo. Un giocatore che nella prima ora non riesce a entrare passa al progetto che apre nello stesso fine settimana, e quel progetto c'è sempre. Un'ora di disservizio nel giorno dell'apertura non costa quindi un'ora di fatturato, ma una parte dell'intera vita del server.

Il terzo motivo è tecnico. Al grand opening migliaia di giocatori provano ad accedere nello stesso momento. In quel preciso minuto il login server è comunque al limite, e un flood aggiuntivo è difficilmente distinguibile dal picco di carico. Un attacco che un tranquillo martedì resterebbe senza conseguenze, nell'ora di apertura basta e avanza. Lo stesso vale per gli appuntamenti annunciati durante la normale attività: assedi ai castelli ed epic raid boss sono a calendario e per lo stesso motivo sono finestre di attacco molto gettonate. Dopo l'assalto dell'apertura l'incentivo cala di nuovo, ed è per questo che gli operatori vivono gli attacchi come ondate e non come condizione permanente.

Le porte di cui si tratta davvero

La tabella seguente elenca le porte di un server Lineage 2 privato, il file di configurazione corrispondente e la direttiva che imposta il valore. Le impostazioni predefinite provengono dai file di configurazione forniti con L2J e dalle guide di installazione dei pacchetti L2OFF.

Questa tabella risponde anche a due domande: Lineage 2 non ha né una porta di query né una porta RCON. Non esiste un servizio separato che consegni lo stato dei giocatori a una lista server, e non esiste una porta di controllo remoto come nei giochi basati su Source. La lista dei server la genera il login server stesso e la invia sulla stessa connessione sulla 2106 al client che ha effettuato l'accesso. Il controllo remoto in L2J passa dai comandi in gioco e dal database. Vengono così a mancare due vettori di attacco che altri giochi hanno, e tanto più resta appeso alla porta 2106.

Ordini di grandezza da conoscere

Che cosa puoi fare da solo prima di spendere

Questa è la sezione più lunga, e non per caso. Un server Lineage 2 configurato bene regge con le proprie forze gli attacchi piccoli e medi, a prescindere da chi lo ospita.

1. Inventario: che cosa è in ascolto?

Prima di scrivere anche una sola regola, guarda che cosa offre il tuo server verso l'esterno. Non tirare a indovinare, controlla:

ss -lntp

La colonna interessante è quella dell'indirizzo locale. 0.0.0.0:2106 e 0.0.0.0:7777 ci stanno per forza. 0.0.0.0:9014 e 0.0.0.0:3306 sono errori: sono le due porte attraverso cui chi attacca può agganciarsi alla tua lista server oppure sondare il tuo database. 127.0.0.1:3306 significa invece "solo in locale" e non richiede alcuna regola firewall. Il punto di vista di chi attacca te lo dà una scansione delle porte dall'esterno:

nmap -Pn -p- --min-rate 1000 IP.DEL.TUO.SERVER

2. Tenere la porta 9014 e il database fuori dalla rete aperta

La porta 9014 è il canale attraverso cui il game server si registra presso il login server, e non deve stare in nessun caso sulla rete aperta. L2J fornisce già l'impostazione predefinita giusta: LoginHostname = 127.0.0.1 lega la porta all'interfaccia di loopback, dall'esterno non è quindi raggiungibile affatto. Se login server e game server girano su due macchine diverse, al posto di * inserisci l'indirizzo interno concreto e apri la porta esclusivamente per la controparte.

La stessa regola vale per il database. Verifica in /etc/mysql/mariadb.conf.d/50-server.cnf che ci sia scritto:

bind-address = 127.0.0.1

E sostituisci l'utente del database. La Server.properties fornita di serie è impostata su Login = root, e il file stesso commenta la cosa con l'avvertenza che proprio questo non è consigliato. Come creare un utente dedicato con permessi minimi è spiegato in Proteggere MariaDB e MySQL. Dopodiché controlla il risultato:

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

La firewall sopra tutto questo resta breve. A un server Lineage 2 bastano due aperture verso l'esterno, e proprio in questo ordine, per non restare chiuso fuori dal tuo server:

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

La guida completa, via di fuga compresa, la trovi in Configurare il firewall UFW senza bloccarsi fuori.

3. Disattivare AcceptNewGameServer una volta registrato il server

Nella LoginServer.properties di serie c'è AcceptNewGameServer = True, e il commento sopra descrive esattamente che cosa significa: qualsiasi game server può registrarsi su uno slot libero del tuo login server. Finché la 9014 sta solo sull'interfaccia di loopback, la cosa resta senza conseguenze. Nel momento in cui la porta diventa raggiungibile per un altro motivo, è una porta aperta. Imposta quindi il valore su False, una volta che il tuo game server si è registrato e ha il suo identificativo:

AcceptNewGameServer = False

La controparte sul lato game server è AcceptAlternateID = True. In fase di costruzione è comodo, perché il login server assegna un altro identificativo se quello desiderato è occupato. Su un sistema in produzione vuoi il contrario: un identificativo fisso, e un errore se è occupato.

4. Impostare correttamente la flood protection del login server

L2J porta con sé un freno alle connessioni nel login server. Si trova nella LoginServer.properties, e tutti i valori di tempo sono in millisecondi:

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

I valori sono collegati fra loro. Una connessione che arriva dallo stesso indirizzo sorgente a meno di FastConnectionTime dalla precedente conta come veloce. Dopo FastConnectionLimit connessioni di questo tipo l'indirizzo viene respinto. NormalConnectionTime è l'intervallo a partire dal quale il contatore torna a scendere. MaxConnectionPerIP è il limite massimo di connessioni aperte contemporaneamente per indirizzo.

Cinquanta connessioni contemporanee sono molto generose per un singolo giocatore, e valori più bassi aiutano in modo percepibile. Qui però serve prudenza: più giocatori nella stessa abitazione, un internet caffè e soprattutto le linee dietro una Carrier-NAT (nell'ambiente L2 riguarda molti giocatori di Turchia, Brasile e parti dell'Europa orientale) condividono un indirizzo pubblico. Chi qui imposta 3 taglia fuori giocatori veri. Misura prima una settimana di funzionamento normale, poi abbassa a piccoli passi.

E una limitazione che devi conoscere: questo freno gira nel processo Java del login server. Ogni pacchetto su cui decide ha già percorso la tua linea e ha già consumato tempo di calcolo. Contro una manciata di sorgenti funziona, contro una botnet no.

5. Limitare i tentativi falliti e usare banned_ip.cfg

Altre due direttive nella LoginServer.properties stabiliscono per quanto tempo qualcuno può tirare a indovinare:

LoginTryBeforeBan = 5
LoginBlockAfterBan = 900

LoginTryBeforeBan è il numero di combinazioni non valide di account e password dopo il quale l'indirizzo viene bloccato, LoginBlockAfterBan è la durata del blocco in secondi (900 corrispondono a 15 minuti). Dopodiché il conteggio ricomincia da capo.

I blocchi permanenti li inserisci nel file banned_ip.cfg, nella cartella di configurazione del login server. Sono ammessi indirizzi singoli, intere reti e un momento di scadenza facoltativo come timestamp Unix in millisecondi; tutto ciò che segue # è un commento:

198.51.100.7
203.0.113.0
198.51.100.44 1789689600000

Imposta inoltre AutoCreateAccounts = False. L'impostazione predefinita True crea automaticamente un account a ogni accesso con un nome di account sconosciuto. In fase di costruzione è pratico, in esercizio è un regalo: chi attacca genera così quanti account vuole, e ciascuno di essi può richiamare la lista server con l'indirizzo del tuo game server. Fai invece nascere gli account dalla registrazione sul tuo sito, così controlli tu chi ottiene un identificativo.

6. Limitare nel kernel la frequenza delle connessioni su 2106 e 7777

Quello che il freno Java decide troppo tardi, il kernel lo decide prima e a minor costo. Contro gli attacchi piccoli e i bot fatti male aiuta un limite massimo per indirizzo sorgente:

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

La prima regola scarta le nuove connessioni al login server non appena un indirizzo ne tiene aperte contemporaneamente più di otto. Un client regolare ne ha bisogno esattamente di una. La seconda limita la frequenza di nuove connessioni a sei al secondo per indirizzo, con un margine di venti, il che lascia ancora passare un'ondata di riconnessioni dopo un riavvio del server. La terza permette sul game server sei connessioni contemporanee per indirizzo, perché l'accesso multiplo (dualbox e triplebox) in Lineage 2 è normale e un limite troppo stretto colpisce i tuoi giocatori paganti.

Tutti e tre i numeri sono valori di partenza, non verità assolute. Un server con 2000 giocatori contemporanei si comporta diversamente da uno con 200. Misura prima, imposta dopo. Le semplici regole iptables spariscono dopo un riavvio; su Debian e Ubuntu si salvano così:

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

Con UFW, invece, regole di questo tipo vanno in /etc/ufw/before.rules, altrimenti al prossimo ufw reload spariscono.

7. Intercettare il SYN flood: syncookies, backlog e tracciamento delle connessioni

Dato che Lineage 2 funziona esclusivamente su TCP, il SYN flood è il vettore più ovvio. Un SYN flood è un attacco che invia richieste di connessione con indirizzi mittente falsificati e non risponde mai alla conferma, cosicché il server riserva per ogni richiesta memoria che non verrà mai usata. Quattro impostazioni attenuano il problema:

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

I SYN cookie sono la riga più importante: il kernel risponde alla richiesta senza memorizzare nulla e crea lo stato solo quando la controparte porta davvero a termine la connessione. I mittenti falsificati finiscono così nel vuoto. Per renderli permanenti, i valori vanno salvati in un file sotto /etc/sysctl.d/ e caricati con sysctl --system.

Un collo di bottiglia spesso trascurato è il tracciamento delle connessioni del kernel. Se si riempie, il server scarta anche i pacchetti legittimi e nel log compare "nf_conntrack: table full, dropping packet". Valore attuale e limite li mostra:

sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max

8. Sito, login server e game server su indirizzi IP separati

Il sito del progetto, con registrazione, shop delle donazioni e pagine di voto, è sempre rintracciabile attraverso il tuo dominio. Se sta sullo stesso indirizzo IP del login server, un attacco al sito paralizza allo stesso tempo l'accesso al gioco, e viceversa. Separa i tre ruoli su indirizzi diversi. Così, durante un attacco al sito, il gioco resta raggiungibile, e durante un attacco alla 2106 i giocatori già collegati continuano a giocare.

Tieni intanto puliti i record DNS. L'errore più frequente è un record A dimenticato che punta a un indirizzo precedente: rende inutile qualsiasi cambio di indirizzo, perché chi attacca trova il nuovo indirizzo attraverso lo stesso nome dei tuoi giocatori.

E qui conviene l'onestà invece dei desideri: l'indirizzo del tuo login server non si può tenere segreto. Sta nel file l2.ini della cartella System che ogni giocatore scarica. L'indirizzo del game server, a sua volta, lo distribuisce il login server stesso: in L2J è l'indirizzo esterno nel file ipconfig.xml (nei derivati più vecchi come ExternalHostname nella Server.properties), e viene comunicato a ogni client che ha effettuato l'accesso con successo. Nascondersi non è una strategia, filtrare sì.

9. Registrare i log, per avere dati in caso di emergenza

Il passo più importante è quello che quasi nessuno compie in anticipo: creare una base di confronto mentre tutto funziona normalmente. Senza un valore di riferimento, dopo un incidente non puoi dire se 40.000 pacchetti al secondo fossero tanti oppure semplicemente un sabato sera. Con apt-get install -y vnstat sysstat la misurazione resta sempre attiva. Durante un incidente bastano quattro comandi:

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

Con Lineage 2 la seconda riga è la più significativa: conta le connessioni semiaperte. Un valore a cinque cifre con qualche centinaio di giocatori è un SYN flood e nient'altro. Per tcpdump vale una regola: limita sempre con -c, perché una cattura a pieno carico appesantisce ancora di più un server già sovraccarico. Come interpretare i valori lo trovi in Riconoscere un attacco DDoS.

Dove queste misure si fermano

Adesso la parte che nessun file di configurazione può risolvere. Tutte le misure viste finora girano sul tuo server, quindi all'estremità della linea. Una regola firewall decide di un pacchetto che ha già percorso il cavo. Puoi scartarlo, ma non puoi fare in modo che non sia mai stato spedito.

Fai due conti. Un game server tipico ha una connettività da 1 Gbit/s, cioè 125 megabyte al secondo, e la linea è satura non appena qualcuno spedisce di più. Contro un server Lineage 2 non serve nemmeno un attacco grande, perché la seconda grandezza colpisce prima: la frequenza dei pacchetti. Con pacchetti piccoli da 64 byte, in una linea da 1 Gbit/s entrano circa 1,49 milioni di pacchetti al secondo. Un normale kernel di server ne elabora, a seconda di CPU e scheda di rete, qualche centinaio di migliaia prima di cominciare a scartare.

In un gioco puramente TCP si aggiunge un terzo limite. Ogni connessione semiaperta occupa una voce nel tracciamento delle connessioni e nel backlog, e il login server di L2J tiene le sue sessioni fino a 60 secondi. Un attacco con qualche centinaio di migliaia di pacchetti al secondo, che non riempie nemmeno un terzo della tua linea, può quindi bloccare completamente l'accesso. Chi gestisce un server lo vive così: "l'utilizzo non era nemmeno alto, eppure non entrava nessuno".

Per dare un ordine di grandezza reale: sui server di KernelHost sono stati filtrati, fra gli altri, un attacco da oltre 112,2 Gbit/s con oltre 8,7 milioni di pacchetti al secondo contro un game server e un attacco multivettore da oltre 473,4 Gbit/s con oltre 41,5 milioni di pacchetti al secondo contro un server vocale. Per casi del genere non esiste alcuna impostazione locale. Gli attacchi volumetrici devono finire nella rete, prima del server. Che cosa fare nel caso acuto è spiegato in Attacco DDoS grave: che cosa fare adesso.

Che cosa mette davanti KernelHost

La protezione permanente inclusa su ogni server

La protezione DDoS di KernelHost è costruita su due livelli ed è permanentemente attiva, senza che tu debba attivare, ordinare o configurare nulla:

• Livello 1: 17 Tbps di capacità di mitigazione nella rete di scrubbing globale. Gli attacchi volumetrici vengono ripuliti vicino alla loro origine, prima che raggiungano il datacenter.
• Livello 2: filtraggio Arbor in tempo reale da 3,2 Tbps a Francoforte sul Meno. Subito davanti al server vengono riconosciuti e scartati gli schemi specifici di protocollo, pacchetto per pacchetto.

Due caratteristiche sono decisive. La protezione è sempre attiva e non deve prima reagire a un attacco, quindi non ci sono minuti iniziali in cui il server sparisce. Proprio a un grand opening questa è la differenza fra una partenza riuscita e una persa. E non viene usato il null-routing: il tuo indirizzo IP resta in rete e vengono scartati solo i pacchetti dannosi. Chi toglie l'indirizzo IP dalla rete ottiene per te lo stesso risultato di chi attacca. Quali giochi e protocolli siano coperti lo elenca Protezione DDoS per game server in tempo reale.

Advanced DDoS Protection per progetti sotto attacco continuo

Certi progetti non vengono colpiti ogni tanto, ma in modo mirato e per settimane, e nell'ambiente Lineage 2 questa è la normalità per ogni server che arriva nelle posizioni alte delle liste. Per questi casi c'è la Advanced DDoS Protection a partire da 50,00 € al mese, PrePaid e senza durata minima. La differenza non sta in una capacità maggiore, ma nel controllo:

• IP di protezione dedicato dal core di Francoforte, sul quale il tuo server viene spostato all'interno della nostra rete. Dalla tua parte non serve alcuna modifica.
• Regole di protezione gestibili da te per porta e protocollo nell'area clienti: imposti separatamente che cosa è permesso sulla 2106 TCP e che cosa sulla 7777 TCP. Con Lineage 2 questo è il punto decisivo, perché le due porte hanno schemi di traffico completamente diversi: molte connessioni brevi da una parte, poche molto lunghe dall'altra.
• Le modifiche hanno effetto in tempo reale, quindi puoi correggere il tiro durante un attacco in corso, e puoi stringere le regole prima dell'ora di apertura per poi allentarle di nuovo.
• Profilo di protezione adatto all'applicazione, anche per file server modificati e propri su porte TCP o UDP a piacere. Che tu usi L2J, L2J-Mobius, aCis o un pacchetto L2OFF non cambia nulla per il set di regole, perché si basa su porta e protocollo.

I due livelli a confronto

Per la maggior parte dei progetti Lineage 2 basta la protezione permanente inclusa, insieme a una configurazione pulita del server. La Advanced DDoS Protection è la risposta al caso in cui qualcuno se la prenda sul personale, e per esperienza questo succede nella settimana prima del grand opening.

Errori frequenti e soluzioni

"Il login non funziona, ma il game server gira normalmente": non è un caso, ma la forma abituale di un attacco a un server Lineage 2. Login server e game server sono due processi su due porte. Misura ss -tn state syn-recv | wc -l e sar -n DEV 1 10. Se le connessioni semiaperte salgono mentre la banda resta normale, è un flood di connessioni sulla 2106.

"Ho cambiato indirizzo IP ed ero di nuovo offline il giorno dopo": chi attacca ottiene il nuovo indirizzo per la stessa via dei tuoi giocatori, cioè dalla nuova cartella System con il l2.ini modificato, dal tuo annuncio oppure da un record DNS dimenticato. Cambiare indirizzo fa guadagnare tempo, non è una soluzione.

"Ho impostato MaxConnectionPerIP su 3 e adesso i giocatori si lamentano": il dualbox in Lineage 2 è la norma, e i giocatori dietro una Carrier-NAT condividono un indirizzo pubblico con centinaia di altri. Torna a un valore che copra le tue misurazioni in funzionamento normale e limita invece nel kernel la frequenza delle nuove connessioni.

"Le mie regole iptables non funzionano": tre cause sono frequenti. Le regole stanno dopo le catene di UFW e non vengono mai raggiunte, oppure sono sparite con l'ultimo riavvio (allora servono netfilter-persistent save o una voce in /etc/ufw/before.rules), oppure l'attacco è volumetrico e la regola lavora correttamente su una linea che è già satura. Verifica con iptables -L INPUT -n -v se i contatori dei match salgono. Se restano a zero, la regola non viene raggiunta.

"Tutti i giocatori hanno lag spike, ma la linea è tranquilla": allora non è un attacco DDoS. Su un server Java i soliti sospetti sono le pause della garbage collection, un database senza gli indici giusti e uno script o un evento personalizzato in un ciclo. Controlla prima sar -n DEV 1 10: se le frequenze dei pacchetti restano normali, la causa è nel server e non nella rete.

"Il mio provider precedente ha bloccato il mio indirizzo IP": quello è null-routing. Il provider protegge così la propria rete, mentre per te il risultato è identico a un attacco riuscito, di solito ancora per ore dopo. Nel dubbio chiedi se filtrano oppure se fanno null-routing. La risposta decide della tua disponibilità più di qualsiasi dato sull'hardware.

"In tcpdump non vedo nulla di anomalo": se il traffico viene già filtrato nella rete a monte, sul server come previsto non arriva nulla. È la situazione normale quando il filtraggio funziona. Vale però anche il contrario: se la linea è satura, può darsi che non ti raggiunga nemmeno la sessione SSH con cui volevi misurare. In quel caso usa la console VNC nell'area clienti, che funziona indipendentemente dalla rete del sistema ospite.

"Il mio grand opening è fra due settimane": allora trasferisciti adesso e non nella settimana della partenza. Un trasferimento costa una nuova cartella System per i giocatori, un cambio DNS e una prova generale. Tutto questo lo vuoi avere alle spalle prima di annunciare la data, perché dall'annuncio in poi ogni concorrente conosce il tuo momento peggiore.

In breve

• Un server Lineage 2 privato ha bisogno di esattamente due porte sulla rete aperta: 2106 TCP per il login server e 7777 TCP per il game server. La porta 9014, il database (3306 con L2J, 1433 con L2OFF) e le porte interne L2OFF 2002, 2006, 2008, 2104 e 2108 non ne fanno parte.
• Lineage 2 funziona esclusivamente su TCP e non ha né una porta di query né una porta RCON. L'attacco tipico è quindi un SYN flood o un flood di connessioni sulla porta 2106 e non un UDP flood.
• Un attacco al login server blocca solo i nuovi accessi. Se nessuno riesce a entrare mentre i giocatori nel mondo continuano a giocare, la causa va cercata sulla porta 2106 e non sulla 7777.
• Imposta consapevolmente EnableFloodProtection, MaxConnectionPerIP, LoginTryBeforeBan e AutoCreateAccounts, porta AcceptNewGameServer su False dopo la registrazione e limita in più la frequenza delle connessioni nel kernel, perché il freno Java agisce solo a valle della linea.
• Gli attacchi ai server Lineage 2 si concentrano intorno alle aperture, perché data e ora sono pubbliche settimane prima e il danno economico è massimo nel giorno dell'apertura. La protezione deve esserci prima dell'annuncio, non dopo.
• Oltre la capacità della linea e oltre qualche centinaio di migliaia di pacchetti al secondo decide esclusivamente il filtraggio nella rete davanti al server. Su KernelHost è a due livelli, sempre attivo, senza sovrapprezzo e senza null-routing.

Se il tuo progetto gira già su KernelHost, il filtraggio è attivo senza che tu debba fare nulla. Se noti comunque delle anomalie, apri un ticket di supporto, così le regole di filtraggio per il tuo indirizzo IP vengono affinate. Durante un attacco in corso ci raggiungi anche tramite la chat WhatsApp di emergenza al numero +43 650 8209883.