Arresti gli attacchi DoS con una regola di tabelle IP?
Mi stavo chiedendo se potessi impedire piccoli attacchi (D) DoS con una semplice regola tabelle IP?
Con piccoli voglio dire che stanno inondando il mio server web con circa 400 richieste da uno o due indirizzi IP. Posso lasciare gli indirizzi IP dopo aver notato che hanno iniziato a colpire il mio server web, ma normalmente ci vogliono pochi minuti per le tabelle IP per sconfiggere contro quel IP e iniziare a far cadere completamente in modo che non influisca sul server web .
- IPTables: consente di uscire da SSH
- nf_conntrack: tabella piena, pacchetto di rilascio
- Spostare il traffico verso la networking VPN
- IPtables: esiste una dimensione minima del pacchetto UDP per una ricerca DNS?
- Keep IP sorgente dopo NAT
- OpenVPN - Il traffico client non è interamente routing tramite VPN
Lascio l'IP con il seguente command:
iptables -I INPUT -s "IP HERE" -j DROP
E poi ovviamente salvarlo:
/etc/init.d/iptables save
Normalmente ritrovo l'indirizzo IP (es) di attacco con il seguente command:
netstat -plan|grep :80|awk '{print $5}'|cut -d: -f 1|sort|uniq -c|sort -n
La questione di farlo è che devo essere lì, e mi impone di agire dopo il fatto. C'è una regola di tabelle IP che potrei utilizzare per abbandonare un indirizzo IP subito dopo che colpisce 150 connessioni? In questo modo non mi preoccupo di superare il server web, e non dovrei essere lì per bloccarlo.
A proposito, sto utilizzando Apache su CentOS se questo è importnte.
Grazie per il tuo tempo.
2 Solutions collect form web for “Arresti gli attacchi DoS con una regola di tabelle IP?”
Per qualcosa che offre flessibilità, esamina i moduli recenti (e limiti). Recente manterrà una traccia del numero di connessioni effettuate da un IP in un determinato intervallo di tempo e possono essere utilizzati per triggersre una regola specifica. Il module più recente è (relativamente) pesante della CPU, ma rispetto al caricamento di una pagina dynamic può essere abbastanza accettabile.
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT -A INPUT -p tcp -m multiport --dports 80,443 -m recent --update --seconds 3600 --name BANNED --rsource -j DROP -A INPUT -p tcp -m multiport --dports 80,443 -m state --state NEW -j ATTK_CHECK -A ATTACKED -m limit --limit 5/min -j LOG --log-prefix "IPTABLES (Rule ATTACKED): " --log-level 7 -A ATTACKED -m recent --set --name BANNED --rsource -j DROP -A ATTK_CHECK -m recent --set --name ATTK –-rsource -A ATTK_CHECK -m recent --update --seconds 600 --hitcount 150 --name ATTK --rsource -j ATTACKED -A ATTK_CHECK -m recent --update --seconds 60 --hitcount 50 --name ATTK --rsource -j ATTACKED -A ATTK_CHECK -j ACCEPT
In sostanza, quanto sopra impone:
- Accetta i collegamenti già stabiliti (cioè hanno superato le nostre regole)
- Spegnere tutte le connessioni sulle porte 80 e 443 (SSL) da IP bloccati – se continuano a tentare di connettersi, estendere il tempo – attendere un'ora (senza tentativi di connessione) prima di sbloccarli.
- Controllare le nuove connessioni nei confronti delle nostre regole:
- Prendi in considerazione più di 150 connessioni in 10 minuti di un attacco
- Prendi in considerazione più di 50 connessioni in un minuto di un attacco
- Registri l'attacco (ma non più di 5 voci al minuto – non vuoi inondare i nostri registri); e bloccare la connessione
Per una spiegazione più dettagliata e una versione a più livelli di quanto sopra, che uso, consulta questo articolo
Tieni presente che ipTables non aiuterà a congestione di networking affatto e è abbastanza inefficace nei confronti di qualsiasi attacco distribuito: il suo vantaggio è di sicurezza e riduce il carico sul server.
È ansible utilizzare iptables per bloccare un abusatore come questo, ma devi stare attenti perché iptables è molto intenso per la CPU. Ogni pacchetto viene controllato contro each regola, quindi aggiungere regole può causare rapidamente l'esaurimento dei loops. Avevo un cliente una volta che avrebbe aggiunto una nuova regola each volta che volevano bloccare qualcuno, e un giorno avevano un po 'più alto del traffico normale e il sistema cadde sopra. Le tabelle possono ridurre il numero di regole guardate, ma non puoi semplicemente lanciare molte regole in iptables.
Un'altra alternativa è il routing nero:
ip route add blackhole $IP_HERE ip route flush cache
La tabella di routing è rasata (con un hashtable ), mentre le regole iptables devono essere considerate in sequenza, che è molto less efficiente. In questo modo, è ansible avere centinaia di migliaia di routes senza un problema, in cui migliaia di regole di iptables diventerebbero problematiche da eseguire per each richiesta.
Per quanto riguarda la seconda domanda, è ansible utilizzare il module hashlimit per creare una list nera automatica per gli abusi. Vedi il mio post su come prevenire un attacco DDoS per ulteriori dettagli, ma il module corto è:
iptables -A INPUT -p tcp --dport 80 -m hashlimit --hashlimit-upto 50/min \ --hashlimit-burst 500 --hashlimit-mode srcip --hashlimit-name http -j ACCEPT iptables -A INPUT -p tcp --dport 80 -j DROP