Ieri sera mi sono trovato a gestire una situazione spiacevole: uno dei server web che seguo per lavoro risultava sotto attacco Distributed denial of service (DDoS) da parte di una batteria di aggressori che generava centinaia di connessioni contemporaneamente, saturando le risorse disponibili. Fortunatamente, tutte le connessioni utilizzavano la stessa rete IP di origine, ovvero indirizzi più o meno sequenziali simili a 106.11.228.191, 106.11.230.3 e via dicendo. Di conseguenza, dopo aver discusso le conseguenze, ho proceduto a bloccare sul firewall ogni richiesta proveniente da qualsiasi IP della rete 106.11.xxx.xxxx: questo articolo vuole essere tanto un promemoria in caso dovessi ripetere l'operazione, tanto quanto un aiuto per chiunque si trovi in una situazione analoga. Vediamo allora come bloccare sul firewall del server Linux una rete o un range di indirizzi IP
Questo articolo è focalizzato sulla procedura per bloccare le connessioni provenienti da una rete o un intervallo di indirizzi IP sul firewall con Linux. Per maggiori informazioni sull'uso del firewall di Linux in generale, fare riferimento a questi approfondimenti:
» Leggi: Aprire le porte sul firewall di Linux CentOS - guida rapida a firewalld
Come scoprire se il server è sotto attacco DDoS?
Il primo passo per capire se il server sia sotto assedio e dare un'occhiata all'utilizzo delle risorse. Personalmente installo l'utility htop:
-
Ubuntu:
sudo apt-get install htop -
CentOS:
sudo yum install htop
A questo punto, lanciando htop possiamo visualizzare lo stato delle CPU e della RAM in alto, e una lista dei processi in esecuzione. Nel caso in esame, notiamo che tutti gli 8 core del server erano impegnati al 100% da una lista infinita di processi php-fpm:
» Leggi anche: Guida: come installare PHP 7 (PHP-FPM) su Linux (Ubuntu/CentOS)
Sebbene questo, da solo, non indichi obbligatoriamente un attacco in corso (potrebbe trattarsi solo di un carico improvviso di traffico legittimo), è un segnale di sofferenza: in questa situazione, i visitatori probabilmente non riescono a visualizzare le pagine o, comunque, ottengono risposta solo dopo un numero inaccettabile di secondi.
Per uscire da htop premere F10 sulla tastiera.
Ora passiamo ad ottenere una lista delle connessioni attive:
sudo netstat -tuanp
L'argomento -tuanp è la contrazione di una serie di opzioni, nella quale ogni lettera ha un significato a sé stante:
-
tu: mostra solo le connessioni TCP (t) e UDP (u) -
a: mostra tutte le porte, sia quelle in statoLISTENING(in attesa di connessione), sia quelle sulle quali la connessione sia stabilita -
n: mostra gli indirizzi IP al posto degli hostname -
p: mostra il nome del processo che utilizza ogni porta
Il risultato è un lungo elenco di processi e porte. Ricordiamo che la colonna Local address mostra l'indirizzo IP del server e quella Foreign address l'indirizzo dell'eventuale client connesso.
Se si tratta di un server web, possiamo filtrare i risultati in questo modo:
sudo netstat -tuanp | grep -E ':80|:443'
Così facendo, otteniamo una lista delle connessioni alle sole porte HTTP (porta 80) e HTTPS (443)
Ora possiamo ispezionare il risultato visivamente alla ricerca di un numero importante di connessioni originatesi da uno stesso indirizzo IP oppure dalla stessa rete.
Nel caso in esame, ho notato che pressoché la totalità dei client impiegava un IP della rete 106.11.xxx.xxx. Per isolarle ho ripetuto il comando precedente, filtrando per questa origine:
sudo netstat -tuanp | grep -E ':80|:443' | grep -F '106.11.'
La lista completa occupava un paio di schermate almeno! Per contarle spannometricamente, ho ripetuto l'ultimo comando per poi passarlo all'utility conta-caratteri di Linux:
sudo netstat -tuanp | grep -E ':80|:443' | grep -F '106.11.' | wc -l
Nel mio caso il conteggio è arrivato a 667 connessioni: non è un numero altissimo in senso assoluto, ma era comunque più di quanto la macchina potesse gestire.
Scoprire l'origine delle connessioni
Per capire chi fossero costoro ho preso un indirizzo IP a caso fra quelli della rete che mi stava dando problemi e l'ho inserito in uno dei servizi di geolocalizzazione
» Leggi: Come localizzare geograficamente un indirizzo IP
Ho così scoperto che si trattava di una rete cinese gestita dall'azienda Hangzhou Alibaba Advertising Co.,Ltd..
Stando così le cose, ritengo che l'azione possa non essere stata intenzionalmente ostile, ma forse frutto di una indicizzazione troppo intensa da parte di un aggregatore o motore di ricerca asiatico. Sia come sia, la cosa stava creando enormi problemi.
Poiché il server web sotto assedio in questione si rivolgeva ad un pubblico europeo e non offriva alcun contenuto rivolto al mondo asiatico, abbiamo deciso di bloccare interamente la rete 106.11.xxx.xxx sul firewall. Ovviamente questo implica che anche eventuali visitatori legittimi con un indirizzo IP di questa rete sarebbero stati bloccati, ma abbiamo reputato che la cosa fosse ininfluente agli scopi del sito: una decisione analoga dovrebbe comunque sempre essere discussa a livello strategico e di operations, non presa autonomamente dal tecnico.
Bloccare un indirizzo IP sul firewall
Per bloccare la rete in questione sul firewall ho impartito questo semplice comando:
sudo iptables -I INPUT -s 106.11.0.0/16 -j DROP
Così facendo, si inserisce una regola in cima alla lista (-I, come la prima lettera della città "Imola") relativa alle connessioni in ingresso (INPUT) per gli indirizzi IP con la sorgente indicata (-s). Il comportamento deve essere "scarta senza dare risposta" (DROP).
La regola ha effetto immediato: nel mio caso, le connessioni sono sparite entro alcuni secondi ed il servizio è tornato disponibile.
Evidenzio però che, al primo riavvio del server o del servizio iptables, la regola andrà persa. Affinché divenga permanente, è necessario inserirla in uno script da eseguirsi automaticamente all'avvio del server oppure salvare permanentemente la configurazione attuale con
sudo service iptables save
Conclusioni
In questo articolo abbiamo visto come bloccare un intervallo di IP che generi problemi al nostro server. L'operazione è certamente molto efficace, ma dovrebbe essere solo la prima parte di un piano di rafforzamento più strutturato: nel nostro caso, in particolare, l'indomani abbiamo attivato il servizio di protezione DDoS offerto dal provider.
