Uso Apache Tomcat 7 per eseguire la mia webapp su Linux. L'ho scansionato da Acunetix e mi sta dicendo che la mia webapp è vulnerabile a "Slow HTTP Denial of Service Attack". Come posso proteggerlo?
Acunetix mi sta chiedendo di qui , ma si tratta di proteggere Apache, non Tomcat.
Un CVE è stato assegnato specificamente per questo problema in quanto si applica ad Apache Tomcat: CVE-2012-5568 . Riferimenti più appropriati lì di quello che ti è stato dato.
Gli sviluppatori Tomcat non considerano questa vulnerabilità e non hanno piani per risolverli.
Soluzioni potenziali:
Utilizza le regole del firewall per impedire troppe connessioni da un singolo host. Ciò mitigherà gli attacchi Denial of Service run-of-the-mill ma non quelli distribuiti (DDoS).
Here is an example of an iptables command which can be used to limit the number of concurrent connections that can be established to port 80 from a single client host:
# iptables -A INPUT -p tcp --syn --dport 80
-m connlimit --connlimit-above 50 -j REJECT
Ciò avrebbe, tuttavia, effetti collaterali se molti utenti si collegassero legittimamente da un singolo IP (es. mega-proxy), quindi il numero di connessioni dovrebbe essere regolato ragionevolmente, in base al traffico previsto.
Sfortunatamente, l'opzione migliore è quella di collocare il servizio Tomcat a valle da un server web in grado di gestire meglio le connessioni HTTP, come Apache. Quindi usa una soluzione Apache come mod_reqtimeout o mod_antiloris.
Esiste un modulo Apache che applica alcune euristiche per (provare a) rilevare l'attacco "slowloris" e contrastarlo. Si chiama mod_antiloris (questo è un modulo per Apache, non un modulo da la Apache Software Foundation ). Vedi questa risposta per i dettagli.
Ricorda che, come per tutti gli attacchi Denial-of-Service , non c'è soluzione , solo attenuazione .
Note that Tomcat is part of the Apache Foundation, so technically it's called Apache Tomcat. However, the traditional Apache webserver (officially called "The Apache HTTP Server Project") is frequently referred to simply as Apache. Below, "Apache" refers to the Apache HTTP Server, and not Tomcat.
In genere Tomcat non viene eseguito come server Web, ma viene eseguito come un server delle applicazioni. Se Tomcat è esposto direttamente a Internet (senza essere associato a Apache), la soluzione dovrebbe essere una delle seguenti:
Configura un server reverse proxy davanti a Tomcat, come Nginx, Lighttpd o anche Apache.
Configura Apache e Tomcat insieme come configurato tradizionalmente .
Se usi Apache nella tua soluzione, allora anche devi usare una stragegia di attenuazione di slowloris. C'è mod_antiloris, che lo farà per te come descritto nell'articolo che hai collegato. E c'è anche mod_reqtimeout , che spesso fa parte di Apache Core spesso non è incluso in Apache installazioni.
mod_antiloris funziona limitando il numero di connessioni simultanee che un dato IP può creare.
mod_reqtimeout funziona limitando la quantità di tempo in cui una singola richiesta può rimanere inattiva.
Entrambi hanno il loro posto, e una buona difesa probabilmente impiegherà entrambi.
Inoltre, la mpm_event configurazione dei lavoratori di Apache funziona allo stesso modo degli altri server, come Nginx, Cherokee e lighttpd, e non è suscettibile all'attacco di Slowloris. Questo è disponibile sulla maggior parte delle installazioni moderne, ma è contrassegnato come "sperimentale". In paritcolare, potrebbe non essere compatibile con alcuni moduli precedenti che si basano sul concetto di thread-per-connection. Un esempio spesso citato è mod_php , sebbene ciò potrebbe non essere applicabile alle versioni più recenti.
hai un apache (il webserver) di fronte al tuo tomcat? se è così - > l'aggiornamento. Apache non è vulnerabile a slowloris dal 2.2.16 IIRC, e 2.2.16 viene fornito con debian squeeze, cioè oldstable.
se non hai un reverse-proxy davanti al tuo tomcat: usa uno, preferibile vernice o nginx.
per ragioni di utilizzo di un proxy inverso, vedi questa risposta @ serverfault
Ecco una soluzione. Questo non influenzerà le persone che utilizzano un proxy. Il team Apache Tomcat non considera questa vulnerabilità in Tomcat o prevede di rilasciare una patch. Questo codice bloccherà anche altri metodi di attacco ddos. ps non l'ho scritto.
BLACKLIST = cat /usr/local/AS/etc/blacklist.txt
per i in $ BLACKLIST; fare iptables -A INPUT -p tcp -m tcp --dport http -s $ i -j DROP fatto
- # IP che non verranno mai rifiutati - host partner
WHITELIST = * *** INSERISCI IL TUO WHITELIST IPS QUI ** * ***
per i in $ WHITELIST; fare iptables -A INPUT -p tcp -m tcp --dport http -s $ i -j ACCEPT fatto
- # non abbassare troppo - i browser aprono più connessioni
OVERLIM_NEW = 500
- # limite generale per le nuove connessioni al secondo
INDILIM_NEW = 30
- # limite per singolo IP, nuove connessioni al secondo - impedisce alluvioni
INDILIM_CURRENT = 200
- # limite per IP individuale, connessioni totali - previene il sovradosaggio
CURRENT_EVAL_INTERVAL = 300
- # intervallo di lunghezza per la valutazione dell'uso IP
iptables -N LIMIT_INDIVIDUAL_NEW
iptables -N LIMIT_INDIVIDUAL_CURRENT
iptables -N LIMIT_OVERALL_NEW
iptables -A INPUT -p tcp --dport 80 -m state --state ESTABLISHED -j LIMIT_INDIVIDUAL_CURRENT
iptables -A INPUT -p tcp -dip 80 --syn -m state --state NEW -j LIMIT_INDIVIDUAL_NEW
iptables -A LIMIT_INDIVIDUAL_CURRENT -m recente --set
iptables -A LIMIT_INDIVIDUAL_CURRENT -p tcp --tcp-flags FIN FIN -m recente --remove
iptables -A LIMIT_INDIVIDUAL_CURRENT -m recente --update --seconds $ CURRENT_EVAL_INTERVAL --hitcount $ INDILIM_CURRENT -j DROP
iptables -A LIMIT_INDIVIDUAL_CURRENT -j ACCEPT
iptables -A LIMIT_INDIVIDUAL_NEW -m recent --set
iptables -A LIMIT_INDIVIDUAL_NEW -m recent --update --seconds 1 --hitcount $ INDILIM_NEW -j DROP
iptables -A LIMIT_INDIVIDUAL_NEW -j LIMIT_OVERALL_NEW
iptables -A LIMIT_OVERALL_NEW -m limit --limit $ OVERLIM_NEW / second -j ACCEPT
iptables -A LIMIT_OVERALL_NEW -j DROP
Leggi altre domande sui tag tomcat attacks denial-of-service