Soluzione 1:
Un DDOS (o anche un DOS), nella sua essenza, è un esaurimento delle risorse. Non sarai mai in grado di eliminare i colli di bottiglia, poiché puoi solo spingerli più lontano.
Su AWS, sei fortunato perché la componente di rete è molto forte:sarebbe molto sorprendente apprendere che il collegamento a monte fosse saturo. Tuttavia, la CPU, così come l'I/O dei dischi, sono molto più facili da inondare.
La migliore linea d'azione sarebbe avviare un monitoraggio (locale come SAR, remoto con Nagios e/o ScoutApp) e alcune strutture di registrazione remota (Syslog-ng). Con tale configurazione, sarai in grado di identificare quali risorse vengono saturate (socket di rete a causa di Syn flood; CPU a causa di query SQL errate o crawler; ram a causa di ...). Non dimenticare di avere la tua partizione di registro (se non hai abilitato la registrazione remota) su un volume EBS (per studiare successivamente i registri).
Se l'attacco arriva attraverso le pagine web, il log di accesso (o l'equivalente) può essere molto utile.
Soluzione 2:
Puoi anche isolare ulteriormente le tue istanze EC2 mettendole dietro un Elastic Load Balancer e accettando solo il traffico dall'istanza ELB. Ciò pone più onere su Amazon nella gestione degli attacchi DDOS.
Presumo che avrai ancora SSH aperto a tutti, quindi è probabile che vedrai ancora del traffico non autorizzato in arrivo, a meno che tu non riesca a bloccare quella porta su alcuni IP statici. Potresti cambiare la porta SSHd in qualcosa di più oscuro (ad esempio, qualcosa di diverso da 22) per ridurre ulteriormente gli accessi DDOS (la maggior parte dei bot controlla solo le porte conosciute).
Menzionerò anche fail2ban, che può monitorare i log e modificare temporaneamente le tue tabelle IP per bloccare IP specifici (ad esempio, se ci sono stati 6 tentativi falliti di SSH nel tuo host da un singolo indirizzo IP, può bloccare quell'IP per 30 minuti o giù di lì). Tieni presente che (come ha commentato astutamente Jordan) fail2ban 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.
Soluzione 3:
Se stai usando Apache, ti suggerisco di usare mod_security. Confezionato dalla maggior parte dei fornitori, il set di regole di base fa un lavoro fantastico.
Un altro passaggio di rafforzamento è la limitazione delle richieste a livello di server web. Nginx., Apache può rallentare e limitare le richieste in entrata.
Soluzione 4:
La soluzione che utilizzo per bloccare gli IP di attività negative in tempo reale che escono da AWS e altri è questa ... Nel mio firewall CSF nella configurazione per le blocklist LFD utilizzo 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 AWS oltraggiosamente odioso.
Soluzione 5:
Sono di parte, poiché lavoro per una rete di distribuzione di contenuti come ingegnere di prevendita per la sicurezza.
Tuttavia, l'utilizzo di una soluzione di mitigazione Ddos su una rete di distribuzione dei contenuti garantisce di non rimanere mai senza risorse all'origine. È simile a mettere un bilanciamento del carico F5 davanti al tuo sito, ma diffuso in migliaia di località in tutto il mondo.
Un buon cdn ti consentirà di mascherare l'origine con una whitelist che installi sul firewall aws. Quindi, quando gli aggressori eseguono la loro ricognizione su Amazon, il tuo indirizzo IP risulterà vuoto poiché tutto verrà bloccato.
Quindi gli attacchi Ddos vengono bloccati quando il traffico colpisce un nodo il più vicino possibile all'aggressore. Ciò ti garantisce di mitigare gli attacchi Ddos il più lontano possibile dall'asset 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 rack, soft layer, un dc fisico ecc. Dovrebbe anche avere un WAF per garantire di poter bloccare gli attacchi di esaurimento del livello dell'applicazione come RUDY, slowpost, slowloris ma anche sqli, xss, rfi, lfi ecc.
Per impostazione predefinita, il cdn blocca anche gli attacchi a livello di rete come teardrop, attacchi icmp, synfloods ecc. Un cdn è in grado di mitigare gli attacchi Ddos perché trey ha una grande capacità di accettare le richieste, filtrare il traffico cattivo e trasmettere il traffico buono. Quindi gli attacchi di amplificazione come gli attacchi volumetrici ntp, DNS, ssdp, chargen e snmp possono essere bloccati.
Il più grande attacco che ho visto fino ad oggi è stato di 321 gbps nel luglio 2014. Durante questo attacco c'è stato anche un attacco al protocollo DNS a 20 gbps. Quindi dovrai assicurarti che anche la tua infrastruttura DNS sia resiliente 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'aggressore 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 del livello dell'applicazione sarà necessario ottenere un web application firewall (WAF). Un tipico firewall di rete (compresi i firewall Amazon e i firewall di nuova 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).