Come posso prevenire un attacco DDOS su Amazon EC2?

Uno dei server che utilizzo è ospitato sul cloud Amazon EC2. Ogni pochi mesi sembriamo avere un attacco DDOS su questo server. Questo rallenta incredibilmente il server. Dopo circa 30 minuti, e talvolta un riavvio in seguito, tutto torna alla normalità.

Amazon ha gruppi di sicurezza e firewall, ma cos'altro dovrei avere in atto su un server EC2 per mitigare o prevenire un attacco?

Da domande simili ho imparato:

• Limitare la frequenza di richieste / minuto (o secondi) da un determinato indirizzo IP tramite qualcosa come tabelle IP (o forse UFW?)
• Hai abbastanza risorse per sopravvivere a un simile attacco - o -
• Possibilmente compilare l'applicazione Web in modo che sia elastica / abbia un bilanciamento del carico elastico e possa scalare rapidamente per soddisfare una domanda così elevata)
• Se si utilizza mySql, impostare le connessioni mySql in modo che vengano eseguite in sequenza in modo che le query lente non impantanino il sistema

Cos'altro mi manca? Mi piacerebbe avere informazioni su strumenti specifici e opzioni di configurazione (di nuovo, usando qui Linux) e / o qualsiasi cosa che sia specifica di Amazon EC2.

ps: anche le note sul monitoraggio di DDOS sarebbero gradite, forse con i nagios? ;)

Un DDOS (o anche un DOS), nella sua essenza, è un esaurimento delle risorse. Non sarai mai in grado di eliminare i colli di bottiglia, in quanto puoi solo spingerli più lontano.

Su AWS, sei fortunato perché il componente di rete è molto potente: sarebbe molto sorprendente apprendere che il collegamento a monte era saturo. Tuttavia, la CPU, così come l'I / O dei dischi, sono molto più facili da inondare.

Il miglior modo di agire sarebbe avviando un po 'di monitoraggio (locale come SAR, remoto con Nagios e / o ScoutApp) e alcune strutture di registrazione remota (Syslog-ng). Con tale impostazione, sarai in grado di identificare quali risorse vengono saturate (socket di rete a causa del diluvio di Syn; CPU a causa di query o crawler SQL errati; ram a causa di ...). Non dimenticare di avere la partizione di registro (se non hai abilitato la registrazione remota) su volumi EBS (per studiare in seguito i registri).

Se l'attacco arriva attraverso le pagine Web, il registro di accesso (o equivalente) può essere molto utile.

Puoi anche isolare ulteriormente le tue istanze EC2 mettendole dietro un bilanciamento del carico elastico e accettando solo il traffico dall'istanza ELB. Questo mette più dell'onere su Amazon per gestire gli attacchi DDOS.

Suppongo che avrai ancora SSH aperto a tutti, quindi è probabile che vedrai ancora un po 'di traffico non autorizzato, a meno che tu non riesca a bloccare quella porta su alcuni IP statici. È possibile modificare la porta SSHd in qualcosa di più oscuro (ovvero qualcosa di diverso da 22) per ridurre ulteriormente gli hit DDOS (la maggior parte dei robot controlla solo le porte note).

Parlerò anche di fail2ban, che può monitorare i registri e modificare temporaneamente le tabelle IP per bloccare IP specifici (ad esempio, se ci sono stati 6 tentativi falliti di SSH nell'host da un singolo indirizzo IP, può bloccare quell'IP per 30 minuti o giù di lì). Tenere presente che fail2ban (come ha commentato astutamente la Giordania) probabilmente non è appropriato per bloccare il traffico proxy (ad esempio quello proveniente da un ELB) perché bloccherà l'IP del proxy, non necessariamente l'IP remoto originale.

Non l'ho usato, ma vale la pena indagare anche su Apache mod_evasive; tuttavia, potrebbe avere la stessa debolezza di fail2ban quando si tratta di blocco basato su IP.

Se stai usando Apache, ti suggerisco di usare mod_security . Preparato dalla maggior parte dei fornitori, il set di regole di base fa un lavoro fantastico.

Un altro passo in avanti è limitare le richieste a livello di server web. Nginx ., Apache può limitare e limitare le richieste in arrivo.

La soluzione che uso per bloccare le cattive attività in tempo reale che IP proviene da AWS e altre è questa ... Nel mio CSF ​​Firewall nella configurazione per LFD Blocklists uso un elenco trovato qui - http://myip.ms/browse/blacklist/ Blacklist_IP_Blacklist_IP_Addresses_Live_Database_Real-time

Scarica Blacklist per CSF Firewall » http://myip.ms/files/blacklist/csf/latest_blacklist.txt

Niente più traffico scandalosamente odioso di AWS.

Sono di parte, mentre lavoro per una rete di distribuzione di contenuti come ingegnere prevendita di sicurezza.

Tuttavia, l'utilizzo di una soluzione di mitigazione Ddos su una rete di distribuzione dei contenuti garantisce che non si esauriscano mai le risorse all'origine. È simile a mettere un bilanciamento del carico F5 davanti al tuo sito, ma diffondersi in migliaia di posizioni in tutto il mondo.

Un buon cdn ti permetterà di nascondere l'origine con una whitelist che installi sul firewall aws. Quindi, quando gli attaccanti eseguono la loro ricognizione su Amazon, il tuo indirizzo IP apparirà vuoto poiché tutto verrà bloccato.

Quindi gli attacchi Ddos vengono bloccati quando il traffico colpisce un nodo il più vicino possibile all'attaccante. Questo ti assicura di mitigare gli attacchi Ddos il più lontano possibile dalla risorsa che stai cercando di proteggere.

Un buon cdn può anche eseguire controlli di integrità e traffico di failover verso altre posizioni, ad esempio un altro ego in culo, Azure, spazio su rack, soft layer, un dc fisico ecc. Dovrebbe anche avere un WAF per assicurarsi di poter bloccare attacchi di esaurimento a livello di applicazione come RUDY, slowpost, slowloris e sqli, xss, rfi, lfi ecc.

Di default il cdn blocca anche gli attacchi a livello di rete come lacrima, attacchi icmp, synfloods ecc. Un cdn è in grado di mitigare gli attacchi Ddos perché trey ha una grande quantità di capacità per accettare le richieste, filtrare il traffico cattivo e passare il traffico buono. In questo modo è possibile bloccare attacchi di amplificazione come gli attacchi volumetrici ntp, DNS, ssdp, chargen e snmp.

L'attacco più grande che ho visto finora è stato di 321 gbps a luglio 2014. Durante questo attacco c'è stato anche un attacco del protocollo DNS a 20 gbps. Quindi dovrai assicurarti che anche l'infrastruttura DNS sia resistente per resistere a un numero enorme di richieste.

Dalla descrizione che hai fornito, sembra che tu sia stato oggetto di un attacco di esaurimento, in cui l'attaccante ha aperto molti thread in modo tale che tutti i thread siano stati consumati sul server Web, sul server delle app o sul firewall. È simile a qualcosa come slowpost, slowloris o RUDY.

Per bloccare gli attacchi di esaurimento a livello di applicazione, è necessario ottenere un firewall per applicazioni Web (WAF). Un firewall di rete tipico (incluso il firewall delle amazzoni e i firewall di prossima generazione) non sarà in grado di bloccarlo. I firewall di lavoro inviati in questi giorni possono bloccare solo circa il 30% di tutti gli attacchi in questi giorni (novembre 2014).

Ecco uno strumento che ho creato per coloro che desiderano utilizzare Fail2Ban su aws con apache, ELB e ACL: https://github.com/anthonymartin/aws-acl-fail2ban

È utile per rilevare e prevenire attacchi DoS e abuso di istanze ec2.

Il firewall del server di configurazione è il migliore che abbia mai visto per la mitigazione DDoS nelle VM basate su software in EC2. Se si combina la funzione syslog, è possibile proteggerla da un ambiente con carico bilanciato.

http://configserver.com/cp/csf.html