Proteggere un server ARK dagli attacchi DDoS

Un cluster ARK non va quasi mai giù in un momento casuale. Chi gestisce server PvP conosce lo schema: poco prima che cada una base nemica il server diventa irraggiungibile, tutti i giocatori vengono espulsi e, quando torna online, il raid è ormai finito. Questo articolo mostra prima che cosa puoi impostare sul server stesso, poi dove queste misure si fermano dal punto di vista tecnico e infine che cosa mette davanti KernelHost.

Perché proprio ARK viene attaccato in modo così mirato

Nella maggior parte dei giochi un server che cade è solo una seccatura. In ARK: Survival Evolved e ARK: Survival Ascended è una mossa di gioco. Le perdite in partita sono definitive, una finestra di raid dura pochi minuti e qualsiasi protezione contro i raid offline funziona soltanto finché il server è raggiungibile. Chi toglie dal gioco i difensori per dieci minuti guadagna risorse e creature. L'attacco ha quindi un guadagno concreto e un momento pianificato, e si ripete non appena ha funzionato una volta.

A questo si aggiunge il modo in cui è costruito un cluster. Di solito più mappe girano sulla stessa macchina, dietro lo stesso indirizzo IP. Un attacco non colpisce quindi un singolo server, ma The Island, Ragnarok, Aberration e il trasferimento tra le mappe tutti insieme. I giocatori che restano bloccati proprio durante un trasferimento nel caso peggiore perdono personaggio e oggetti. Che cosa succede tecnicamente durante un attacco DDoS lo spiega l'articolo Che cos'è un attacco DDoS?.

Le porte coinvolte

ARK trasmette il traffico di gioco interamente via UDP. È questo il motivo per cui molte guide sui firewall qui non servono a niente: aprono TCP.

Survival Evolved occupa in più la porta subito successiva a quella di gioco, perché l'engine apre lì un secondo socket UDP. Survival Ascended non ha più bisogno di questa seconda porta. La porta di query risponde alle richieste di stato in formato Steam (nome del server, mappa, numero di giocatori, tempo di gioco) ed è la porta più interessante per chi attacca.

In un cluster le porte si assegnano a passi di due, così il secondo socket non entra in conflitto con l'istanza successiva: 7777 e 7778 per la prima mappa, 7779 e 7780 per la seconda, più 27015 e 27016 come porte di query.

Che cosa puoi fare da solo prima di spendere soldi

I passaggi seguenti non costano nulla e funzionano contro i casi più frequenti: piccoli flood mirati da poche sorgenti, porte di query sfruttate in modo improprio e tentativi di prendere il controllo via RCON. Restano utili anche quando davanti lavora già un filtro di rete.

1. Apri solo quello che serve davvero al cluster

Su un host ARK le porte aperte diventano in fretta più di quante ne immagini: pannello, database, un webserver per la mappa e in più le istanze di gioco. Ognuna di esse è un bersaglio per i pacchetti. Il set di regole nftables qui sotto, per /etc/nftables.conf, lascia passare quello che serve a un cluster con due mappe e scarta il resto.

#!/usr/sbin/nft -f

flush ruleset

table inet ark {
    set adminips {
        type ipv4_addr
        flags interval
        elements = { 203.0.113.10 }
    }

    set queryflood {
        type ipv4_addr
        size 65535
        flags dynamic,timeout
        timeout 1m
    }

    chain input {
        type filter hook input priority 0; policy drop;

        iif lo accept
        ct state established,related accept
        ct state invalid drop

        ip saddr @adminips tcp dport { 22, 27020 } accept

        udp dport { 7777-7780 } accept

        udp dport { 27015-27016 } add @queryflood { ip saddr limit rate over 10/second burst 20 packets } drop
        udp dport { 27015-27016 } accept

        icmp type echo-request limit rate 5/second accept
        icmpv6 type { echo-request, nd-neighbor-solicit, nd-neighbor-advert, nd-router-solicit, nd-router-advert } accept

        counter drop
    }

    chain forward {
        type filter hook forward priority 0; policy drop;
    }

    chain output {
        type filter hook output priority 0; policy accept;
    }
}

Prima di caricare il set di regole inserisci in adminips il tuo indirizzo IP fisso, altrimenti ti chiudi fuori da SSH.

nft -c -f /etc/nftables.conf
systemctl enable --now nftables
nft list ruleset

nft -c controlla soltanto la sintassi e non modifica nulla. È il secondo comando a caricare il set di regole e a renderlo persistente al riavvio. Se preferisci lavorare con UFW, trovi la procedura in Configurare il firewall UFW. Attenzione: flush ruleset cancella anche le regole di UFW e di Docker. Se uno dei due è in funzione, ometti questa riga.

2. Limita la porta di query invece di chiuderla

La porta di query è l'unica porta su cui il tuo server risponde a qualsiasi sconosciuto, e a una richiesta minuscola contrappone una risposta molto più grande. Da qui nascono due problemi. Primo, il tuo server può essere sfruttato come amplificatore: chi attacca falsifica l'indirizzo del mittente, il tuo server risponde a una vittima estranea e la tua linea si fa carico del traffico in uscita. Secondo, ogni risposta consuma tempo di calcolo proprio nel processo che gestisce anche il gioco. Per questo un flood sulla 27015 si manifesta spesso con scatti e non con la caduta della connessione.

Chiudere la porta non è una soluzione, perché così il server sparisce dalla lista dei server. La regola qui sopra limita invece per singolo indirizzo sorgente: dieci richieste al secondo con un buffer di venti pacchetti bastano per i giocatori e per il monitoring, mentre una sorgente con migliaia di richieste al secondo viene scartata. Quali indirizzi sono limitati in questo momento lo mostra:

nft list set inet ark queryflood

3. Togli RCON da internet

RCON dà il controllo completo: chi ha la password espelle giocatori, spegne il server e interviene nel mondo di gioco. La porta è TCP, la password sta in chiaro nella configurazione e si può tentare l'accesso quante volte si vuole. Per questo nel set di regole qui sopra resta aperta solo per l'indirizzo dell'amministratore.

[ServerSettings]
RCONEnabled=True
RCONPort=27020
ServerAdminPassword=<password casuale lunga>

Il file GameUserSettings.ini si trova in ShooterGame/Saved/Config/ nella directory del server. Una password utilizzabile la generi così:

openssl rand -base64 24

Se un pannello web sulla stessa macchina usa RCON, basta l'accesso tramite 127.0.0.1 e la porta resta chiusa dall'esterno. Se il pannello gira altrove, il suo indirizzo va in adminips e da nessun'altra parte.

4. Alleggerisci il tracciamento delle connessioni

Spesso un UDP flood non stende un server Linux con la banda, ma con il tracciamento delle connessioni. Il kernel crea una voce per ogni pacchetto UDP in ingresso, la tabella si riempie e da quel momento vengono scartati anche i pacchetti dei giocatori veri, cosa che si riconosce da nf_conntrack: table full, dropping packet nel log di sistema. Per il traffico di gioco questo tracciamento non serve a nulla, quindi togli le porte di gioco:

table inet arkraw {
    chain prerouting {
        type filter hook prerouting priority -300; policy accept;
        udp dport { 7777-7780, 27015-27016 } notrack
    }

    chain output {
        type filter hook output priority -300; policy accept;
        udp sport { 7777-7780, 27015-27016 } notrack
    }
}

Servono entrambe le direzioni, altrimenti si creano voci a metà per il traffico in uscita. In più qualche parametro del kernel in /etc/sysctl.d/90-ark.conf:

net.netfilter.nf_conntrack_max = 262144
net.netfilter.nf_conntrack_udp_timeout = 15
net.netfilter.nf_conntrack_udp_timeout_stream = 60
net.core.netdev_max_backlog = 16384
net.core.rmem_max = 16777216
net.ipv4.tcp_syncookies = 1

sysctl --system
cat /proc/sys/net/netfilter/nf_conntrack_count

Se durante un attacco il secondo valore si avvicina al massimo, il collo di bottiglia era il tracciamento delle connessioni e non la linea.

5. Whitelist e password del server

Se il tuo cluster serve comunque un gruppo chiuso, una lista di accesso è la misura più efficace contro i disturbatori. ARK la mette già a disposizione, basta avviare il server con -exclusivejoin:

./ShooterGameServer "TheIsland?listen?SessionName=IlMioCluster?Port=7777?QueryPort=27015?RCONEnabled=True?RCONPort=27020" -server -log -exclusivejoin

I giocatori ammessi finiscono poi, un identificativo per riga, in PlayersExclusiveJoinList.txt nella directory del binario del server. Con il server in funzione la lista si aggiorna dalla console del server oppure via RCON:

AllowPlayerToJoinNoCheck <identificativo giocatore>
DisallowPlayerToJoinNoCheck <identificativo giocatore>

Una password del server impostata con ServerPassword ha un effetto simile, ma per esperienza gira in fretta di mano in mano. Entrambe le soluzioni hanno lo stesso limite netto: il controllo avviene nel processo di gioco, quindi solo dopo che il pacchetto è arrivato. Contro un flood di pacchetti una whitelist non serve, contro il giocatore che prima va a sondare il tuo cluster invece sì.

6. Che cosa fanno l'anti-cheat e i plugin, e che cosa no

Su entrambi i titoli gira di serie un sistema anti-cheat, e attraverso la rispettiva API del server esistono anche i plugin. Sono cose utili, ma risolvono un altro problema. L'anti-cheat verifica se un client collegato è manipolato, un plugin può contare i tentativi di connessione o disconnettere i giocatori con un comportamento sospetto. Tutti questi controlli girano nello stesso processo del gioco e intervengono solo quando il pacchetto viene elaborato. Se il processo è saturo, la logica di protezione cade insieme a lui. Per questo motivo un plugin che respinge gli attacchi DDoS non può esistere. Quello che aiuta comunque: tieni aggiornati i file del server e le mod, e mantieni basso il loro numero, perché buona parte dei crash nei cluster ARK dipende da mod difettose e non da attacchi.

7. Il tuo indirizzo è nella lista dei server

Un server ARK elencato pubblicamente rende noti indirizzo IP e porta di query, altrimenti nessuno potrebbe trovarlo, e queste liste vengono interrogate e archiviate di continuo in modo automatico. Il tuo indirizzo è quindi noto dal momento in cui il server è comparso in lista anche una sola volta. Nascondersi non è un'opzione, perché chi non si fa elencare non cresce. Restano le vie secondarie da cui un indirizzo trapela comunque:

• Vecchi record DNS. Un record A che punta ancora al server precedente rivela il vecchio indirizzo. Record del genere vanno cancellati.
• Altri servizi sullo stesso indirizzo. Sito web, mappa online, pannello, server voice e database sono ognuno una seconda via per colpire il cluster.
• Il tuo Discord. Bot di stato, screenshot della console e guide di connessione contengono spesso l'indirizzo in chiaro.

8. Misura invece di tirare a indovinare

L'errore più frequente nel bel mezzo di un disservizio è la diagnosi sbagliata. Per i giocatori una mod andata in crash, un filesystem pieno e un attacco vero si somigliano tutti. Distinguerli richiede un minuto. Per prima cosa la frequenza dei pacchetti sulla scheda di rete:

r1=$(cat /sys/class/net/eth0/statistics/rx_packets)
sleep 1
r2=$(cat /sys/class/net/eth0/statistics/rx_packets)
echo "$((r2-r1)) pacchetti al secondo"

Un cluster con cinquanta giocatori si muove normalmente su valori a cinque cifre basse, valori a sei o sette cifre sono un attacco. Poi i contatori dello stack di rete:

nstat -az UdpInDatagrams UdpNoPorts UdpRcvbufErrors
ss -ulnp | grep -E '7777|27015'

UdpNoPorts cresce quando arrivano pacchetti su porte dove non è in ascolto nulla, segno tipico di un flood sparato alla cieca. UdpRcvbufErrors cresce quando il processo del server non riesce più a prelevare i pacchetti abbastanza in fretta. Per finire il log del gioco:

tail -n 200 ShooterGame/Saved/Logs/ShooterGame.log

Se lì compare un rapporto di crash mentre i contatori dei pacchetti sono normali, non era un attacco. Durante un disservizio rinuncia a tcpdump, perché la cattura consuma tempo di calcolo su un sistema che in quel momento non ne ha. Altri indizi li trovi nell'articolo Riconoscere un attacco DDoS sul server.

Dove queste misure si fermano

Tutto quello descritto finora agisce sul server, ed è proprio lì che sta il limite. Una regola del firewall può scartare soltanto ciò che è già arrivato. Il collo di bottiglia però si trova prima, sulla linea.

I numeri parlano chiaro. Una connettività da 1 Gbit/s, con i pacchetti più piccoli possibili, è satura dopo circa 1,49 milioni di pacchetti al secondo, a prescindere da che cosa il server voglia farne. Un UDP flood reale contro un game server ARK di KernelHost, sulla porta 7777, ha raggiunto oltre 112,2 Gbit/s e oltre 8,7 milioni di pacchetti al secondo, quindi in media circa 1,6 kilobyte per pacchetto. Equivale a 112 volte una linea da 1 Gbit/s e comunque a più di undici volte una linea da 10 Gbit/s.

Anche il secondo collo di bottiglia si raggiunge in fretta: con un set di regole normale un core della CPU scarta, a seconda dell'hardware, qualche centinaio di migliaia di pacchetti al secondo. Con 8,7 milioni il conto non torna nemmeno con molti core. La regola funziona correttamente e il server è offline lo stesso.

Per questo gli attacchi volumetrici vanno filtrati nella rete, prima del server. Sul server stesso il problema non è risolvibile, né con più hardware né con un set di regole migliore.

Che cosa mette davanti KernelHost

La protezione permanente inclusa su ogni server

Su ogni server di KernelHost gira una protezione DDoS permanente a due livelli, senza ordinare nulla e senza configurare nulla. Il primo livello è una rete di scrubbing globale con 17 Tbps di capacità di mitigazione: gli attacchi volumetrici vengono intercettati vicino alla loro origine, molto prima che raggiungano il datacenter. Il secondo livello è un filtraggio Arbor in tempo reale da 3,2 Tbps direttamente in loco, nel datacenter maincubes di Francoforte sul Meno, in Germania. Si occupa del lavoro di dettaglio sui livelli 3, 4 e 7 e conosce gli schemi di protocollo dei game server più diffusi.

Tre caratteristiche sono decisive. La protezione è sempre attiva, quindi non esiste un tempo di reazione durante il quale un attacco debba prima essere riconosciuto. Non viene usato il null-routing: l'indirizzo IP attaccato resta in rete e cadono solo i pacchetti dannosi. E non costa nulla in più. Come funziona tutto questo per i game server lo spiega l'articolo Protezione DDoS in tempo reale per server di gioco.

Advanced DDoS Protection per progetti attaccati di continuo

Certi cluster non vengono colpiti una volta sola, ma per settimane, ogni sera alla stessa ora e con schemi sempre diversi. Per questi casi c'è la Advanced DDoS Protection a partire da 50,00 € al mese, PrePaid e quindi senza durata minima, senza preavviso di disdetta, senza contratto e senza costi di attivazione.

Ricevi un indirizzo IP di protezione dedicato dal core di Francoforte. Il tuo server viene spostato su quell'indirizzo all'interno della rete di KernelHost, senza che tu debba modificare nulla dalla tua parte. La differenza sta in quello che viene dopo: le regole di protezione le gestisci tu stesso nell'area clienti, separate per porta e protocollo, e le modifiche hanno effetto in tempo reale, senza ticket. Come profilo di protezione scegli il titolo servito da quella porta, con oltre 40 giochi, servizi e protocolli disponibili, tra cui ARK: Survival Evolved. Per un cluster significa: profilo di gioco sulle porte di gioco, un limite più stretto sulla porta di query, una regola dedicata per un pannello web, invece dello stesso compromesso ovunque.

I due livelli a confronto

Errori frequenti e soluzioni

Aperto solo TCP, il server gira ma nessuno riesce a entrare: il traffico di gioco di ARK è UDP, una regola per tcp dport 7777 non cambia nulla. Verifica con ss -ulnp e apri le porte come udp dport.

Il server è raggiungibile ma non compare nella lista dei server: di solito la porta di query è chiusa oppure il rate limit è troppo stretto. Apri la 27015 UDP e alza il limite. Per controllare, nft list set inet ark queryflood mostra quali indirizzi vengono limitati.

Il tuo bot di stato segnala il server offline anche se ci sono giocatori collegati: un bot Discord interroga da un unico indirizzo sorgente, spesso più volte al secondo e per ogni mappa separatamente, e finisce così nello stesso limite di chi attacca. Metti un'eccezione per quell'indirizzo prima della regola di limite.

Dopo aver caricato il set di regole SSH non funziona più: in adminips c'era l'indirizzo sbagliato, oppure SSH gira su un'altra porta. Puoi tornare sul server tramite la console VNC nell'area clienti, dato che sui server dedicati e sui server root KVM non esistono IPMI o iDRAC. Lì esegui nft flush ruleset come freno d'emergenza e poi correggi il file.

sysctl non riesce a impostare i valori di conntrack: i parametri sotto net.netfilter esistono solo quando il modulo è caricato. Caricalo con modprobe nf_conntrack e richiama di nuovo sysctl --system.

Un presunto attacco in realtà è una mod: se i contatori dei pacchetti sono normali e in ShooterGame.log compare un rapporto di crash, la causa non era la rete. Dopo un aggiornamento nel Workshop è la spiegazione più probabile, soprattutto se a essere colpita è sempre la stessa mappa.

Tutto il cluster va offline nello stesso momento: tutte le istanze sono agganciate allo stesso indirizzo IP, quindi un attacco colpisce tutto in una volta, trasferimenti compresi. Un IP di protezione dedicato risolve proprio questo schema, perché il filtraggio si trova davanti all'indirizzo invece che sul server dietro.

In breve

Apri solo le porte di gioco, la porta di query e l'accesso per il tuo indirizzo, limita la porta di query per singola sorgente, tieni RCON fuori da internet e misura la frequenza dei pacchetti prima di dare per certa una causa. Tutto questo non costa nulla e copre la normale amministrazione. Quello che va oltre non si decide più sul server: la protezione permanente inclusa, con 17 Tbps di capacità di mitigazione nella rete di scrubbing globale e 3,2 Tbps di filtraggio Arbor in tempo reale a Francoforte sul Meno, lo assorbe senza sovrapprezzo e senza null-routing. In caso di attacchi continui la Advanced DDoS Protection aggiunge un IP di protezione dedicato con regole impostate da te. L'operatore è KernelHost GmbH, con sede a Vienna, in Austria.