Nginx (si pronuncia “engine-x“) è un server Web open source ad alte prestazioni. Può gestire richieste HTTP e HTTPS, offrendo prestazioni elevate, stabilità e un basso consumo di risorse; è inoltre noto per gestire efficacemente un gran numero di connessioni simultanee. Così come Apache, anche Nginx può essere utilizzato per allestire un proprio server Web ed è presente in un gran numero di server cloud, fungendo da base per un ampio numero di progetti.
Un prodotto come Nginx può fungere anche da proxy inverso, collocandosi tra gli utenti e i server di backend. In questo modo è possibile bilanciare il traffico Web su più server, migliorando così le prestazioni e garantendo la disponibilità dei servizi. Offre inoltre funzionalità di balancer, di caching, il supporto per protocolli avanzati come WebSocket e HTTP/2.
Proprio a HTTP/2 e a un attacco che di recente ha permesso di sferrare aggressioni DDoS (Distributed Denial of Service) estremamente efficaci è dedicata una nota ufficiale condivisa dal team di sviluppo di Nginx.
Come bloccare gli attacchi HTTP/2 Stream Reset su Nginx
Degli attacchi HTTP/2 Stream Reset abbiamo parlato di recente: denunciati da AWS, Google e Cloudflare, si tratta di aggressioni che sfruttano un problema nell’implementazione del protocollo HTTP/2 per impedire la corretta erogazione dei servizi Web. Tutti i sistemi, quindi anche i server Web, che supportano HTTP/2 sono potenzialmente vulnerabili e potrebbero quindi improvvisamente cessare di erogare pagine ai client nel momento in cui la vulnerabilità dovesse essere sfruttata da remoto nell’ambito di un attacco DoS o DDoS HTTP/2 Stream Reset.
I tecnici che si occupano dello sviluppo di Nginx fanno presente che per proteggere i sistemi affacciati sulla rete Internet da qualunque tentativo di attacco, è necessario procedere con un aggiornamento immediato sulla configurazione di Nginx.
Qual è l’impatto della vulnerabilità su Nginx
Per motivi di prestazioni e consumo di risorse, Nginx limita il numero di stream simultanei a un valore predefinito di 128 (direttiva http2_max_concurrent_streams
). Inoltre, per bilanciare ottimamente le performance di rete e del server, il server Web open source consente al client di mantenere connessioni HTTP fino a un massimo di 1.000 richieste (parametro keepalive_requests
). La creazione di connessioni aggiuntive per aggirare questo limite espone l’attività degli aggressori attraverso gli abituali strumenti di monitoraggio e allerta che agiscono al livello 4 della pila ISO/OSI. Si tratta del livello di trasporto che fornisce servizi di controllo di flusso, di errore e di segmentazione e ricomposizione dei dati (è responsabile della trasmissione end-to-end dei dati tra due host).
I passaggi per scongiurare gli attacchi
Secondo Nginx, le impostazioni predefinite contenute nel file di configurazione (di solito è /etc/nginx/nginx.conf
) sono adeguate per difendersi dagli attacchi HTTP/2 Stream Reset. Gli sviluppatori, quindi, suggeriscono di verificare che http2_max_concurrent_streams
sia impostato a 128 mentre keepalive_requests
su 1000.
Per contrastare in maniera ancora più efficace i tentativi di attacco, Nginx consiglia di aggiungere al file di configurazione di ciascun server Web in uso le seguenti due direttive:
limit_conn
Impone un limite al numero di connessioni consentite per ciascun client.limit_req
Consente di impostare un limite al numero di richieste elaborate entro un determinato periodo di tempo per ogni singolo client.
Entrambi i parametri dovrebbero essere definiti, aggiunge ancora Nginx, specificando valori ragionevoli, utili a bilanciare le prestazioni delle applicazioni Web con la sicurezza della configurazione.
Se il server può gestire comodamente 1000 connessioni simultanee, si potrebbe specificare quanto segue – almeno come approccio iniziale – per configurare una limitazione chiamata perip
che può contenere fino a 20 connessioni simultanee da uno stesso indirizzo IP:
limit_conn_zone $binary_remote_addr zone=perip:10m; limit_conn perip 20;
Allo stesso modo, si possono ad esempio limitare le richieste a 10 al secondo per singolo client:
limit_req_zone $binary_remote_addr zone=one:10m rate=10r/s; limit_req zone=one burst=20;
Questa specifica impostazione configura una limitazione chiamata one
che tollera un tasso di 10 richieste al secondo, con un burst ovvero un valore di picco massimo consentito pari a 20 richieste al secondo.
Gli interventi messi in campo da Nginx
Da Nginx si spiega, inoltre, che i tecnici hanno fatto molteplici esperimenti per capire come gli attacchi HTTP/2 Stream Reset possano influenzare ogni genere di utenza. La ricerca ha fatto emergere che il server Web Nginx è già piuttosto robusto per contrastare eventuali tentativi di aggressione e, quindi, anche gli attacchi DDoS meglio orchestrati.
Purtuttavia, i tecnici di Nginx hanno sviluppato una patch (qui tutti i dettagli tecnici) che aumenta la stabilità del sistema in condizioni di attacco. Gli utenti del server Web open source sono quindi invitati a installare quanto prima gli aggiornamenti disponibili (le versioni che ergono un’ulteriore difesa sono quelle contraddistinte dagli identificativi di pacchetto R29p1 o R30p1).
La patch per Nginx pone un limite al numero di nuovi stream che possono essere richiesti, nell’ambito del protocollo HTTP/2, da uno o più client. Tale limite è impostato al doppio del valore configurato utilizzando la direttiva http2_max_concurrent_streams
. Il limite è automaticamente applicato anche se la soglia massima non viene mai raggiunta, come nel caso in cui gli stream vengono resettati subito dopo l’invio della richiesta (è il caso degli attacchi HTTP/2 Stream Reset).
L’immagine in apertura è tratta dal sito ufficiale del progetto Nginx.