Perché NginX e Lighttpd non sono interessati da Slowloris?

23

Sto indagando sulla vulnerabilità a Slowloris e penso di capire come e perché funziona questo tipo di attacco.

Quello che non capisco è perché Lighttpd e NginX non sono interessati (secondo lo stesso articolo come linkato sopra). Cosa rendono così diverso?

— The Shurrican
fonte

25

Apache ha una teoria dei "Clienti massimi"

Questo è il numero di connessioni simultanee che può gestire. IE se un server apache ha un limite di "max client" di 100 e ogni richiesta richiede 1 secondo per essere completata, può gestire un massimo di 100 richieste al secondo.

Un'applicazione come SlowLoris invaderà un server con connessioni, nel nostro esempio se SlowLoris invia 200 connessioni al secondo e Apache può gestire solo 100 connessioni al secondo, la coda delle connessioni continuerà a ingrandirsi e consumerà tutta la memoria della macchina portandola a un hault. Questo è simile al modo in cui funziona LOIC anonimo.

NGINX e Lighttpd (tra gli altri) non hanno connessioni massime, usano invece thread di lavoro, quindi, in teoria, non c'è limite al numero di connessioni che possono gestire.
Se controlli le tue connessioni Apache, vedrai che la maggior parte delle connessioni attive sono "Invio" o "Ricezione" di dati dal client. In NGINX / Lighttpd semplicemente ignorano queste richieste e le lasciano funzionare in background, non utilizzando risorse di sistema, e deve solo elaborare le connessioni con qualcosa in corso (Analisi delle risposte, lettura dei dati dai server back-end, ecc.)

Ho effettivamente risposto a una domanda simile questo pomeriggio, quindi le informazioni in essa contenute potrebbero essere interessanti anche per te Ridurre la coda delle richieste di Apache

— macchia
fonte

Risposta buona e molto dettagliata. +1

— Oldskool,

6

Correzione minore: nginx non utilizza i thread di lavoro per ottenere un numero elevato di connessioni. Da nginx.org : "Nginx non si basa sui thread per gestire le richieste. Utilizza invece un'architettura molto più scalabile basata su eventi (asincrona)"

— Giorno

2

Sebbene un possibile effetto collaterale, l'intento di Slowloris non è "esaurire tutta la memoria della macchina", ma esaurire la massima capacità di connessione negando il successo delle connessioni successive.

— wulfgarpro,

@Day Nginx utilizza i thread di lavoro per supportare l'operazione asincrona. Un utile schema dell'architettura dell'applicazione è fornito qui: aosabook.org/en/nginx.html#fig.nginx.arch

— Terry Burton

13

Nginx è in realtà vulnerabile all'attacco di slowloris. La risorsa scarsa è il numero massimo di connessioni di lavoro simultanee. Questo numero può essere calcolato come worker_connections * worker_processes ed equivale a 512 nella configurazione predefinita di nginx. Quindi, è abbastanza facile abbattere nginx non protetto con strumenti come goloris .

— valyala
fonte

golorissembra lo strumento di cui ho bisogno per assicurarmi che la mia implementazione / configurazione funzioni come previsto!

— Alexis Wilke,

8

Il commento di Valyala dovrebbe essere accettato come risposta.

La maggior parte dei server nginx utilizza configurazioni predefinite e quindi vulnerabili all'attacco slowloris. Ho usato slowloris per eliminare alcuni dei siti Web nginx del mio amico usando solo il mio laptop e di solito ci sono voluti meno di 5 minuti (i miei amici mi hanno sfidato a farlo).

Come affermato da Valyala, tecnicamente, nginx non è vulnerabile a slowloris, ma le configurazioni predefinite limitano il numero massimo di connessioni, quindi quando le connessioni superano quel numero, nginx rilascia la nuova richiesta, il che comporta un rifiuto del servizio.

I modi noti per proteggere nginx da slowloris includono la limitazione del numero di connessioni dallo stesso IP e l'aumento della configurazione di worker_connections. L'attacco può ancora funzionare, ma diventa più difficile (forse impiegando più di 5 minuti?: D)

— Nguyen Phan Tan
fonte