Rapid Reset
Oggi ci immergiamo in un argomento caldo: la mitigazione della vulnerabilità CVE-2023-44487, un attacco DoS che sfrutta il protocollo HTTP/2, noto come “Rapid Reset”, che è stato cavalcato pesantemente da agosto a ottobre 2023.
a vulnerabilità CVE-2023-44487 sfrutta una funzionalità specifica del protocollo HTTP/2: il multiplexing di stream. Questa caratteristica permette a HTTP/2 di inviare numerose richieste simultaneamente sulla stessa connessione TCP, rendendo il traffico web più efficiente e riducendo la latenza. Tuttavia, questa efficienza diventa un punto debole con l’attacco “Rapid Reset”.
Nello specifico, gli aggressori inviano ripetutamente richieste e le cancellano immediatamente, creando un carico di lavoro notevole sul server con un costo minimo per il client. La frequenza rapida e massiccia con cui vengono generati e annullati gli stream consuma le risorse del server, causando un aumento dell’uso della CPU e, potenzialmente, un Denial of Service (DoS). HTTP/2 ha una funzione di sicurezza che tenta di limitare il numero di stream attivi per proteggersi dagli attacchi DoS, ma questa difesa non è sempre efficace. Il protocollo consente ai client di annullare gli stream senza il consenso del server, che è esattamente ciò che viene sfruttato in questo attacco.
NGINX
Per NGINX, la risposta è duplice: aggiornamenti e configurazioni sagge. NGINX di default è già predisposto a mitigare questo tipo di attacco grazie al limite di keepalive e al numero massimo di stream concorrenti. Tuttavia, se NGINX è configurato con un keepalive molto più alto rispetto al default, il rischio aumenta. Le raccomandazioni includono:
- mantenere keepalive_requests al valore predefinito di 1000 richieste.
- mantenere http2_max_concurrent_streams al valore predefinito di 128 stream.
- aggiungere le direttive limit_conn e limit_req per limitare rispettivamente il numero di connessioni e il numero di richieste per un dato periodo di tempo da un singolo client2.
Inoltre, NGINX ha rilasciato una patch che introduce un limite sul numero di nuovi stream che possono essere introdotti in un singolo ciclo di eventi, impostando questo limite al doppio del valore configurato con la direttiva http2_max_concurrent_streams.
Apache HTTPD
Per Apache HTTPD, la situazione è leggermente diversa. Non è pienamente affetto dalla vulnerabilità CVE-2023-44487 come NGINX. Tuttavia, c’è il rischio di un aumento dell’uso della CPU se qualcuno tenta un attacco. La correzione completa dipende da una versione patchata della libreria libnghttp2, che potrebbe non essere ancora disponibile e potrebbe richiedere l’attesa di una nuova versione di Apache che includa la libreria corretta3.
Misure Generali
Una soluzione generale suggerisce l’uso di un CDN con mitigazioni DDoS in atto per questa vulnerabilità. Servizi come CloudFlare, Microsoft Azure, Fastly, AWS e Google Cloud offrono protezione completa contro la vulnerabilità di Rapid Reset HTTP/2. Un’altra opzione, sebbene possa avere un impatto sulle prestazioni, è disabilitare completamente l’uso di HTTP/2 e passare a HTTP/1.13.
Conclusioni
La difesa migliore è un attacco anticipato: implementare rate controls e assicurarsi di aggiornare e patchare i sistemi tempestivamente è cruciale. La sicurezza informatica è una battaglia continua, e con le giuste configurazioni e aggiornamenti, possiamo rendere le nostre infrastrutture web meno vulnerabili a questi attacchi ingegnosi.
Extra
Non dimentichiamoci mai di mettere al sicuro le nostre installazioni esposte con Crowdsec .
Le opinioni in quanto tali sono opinabili e nulla ti vieta di approfondire l’argomento.
Risorse: