Řešení 1:
DDOS (nebo dokonce DOS) je ve své podstatě vyčerpáním zdrojů. Úzká místa se vám nikdy nepodaří odstranit, protože je můžete pouze odsunout dál.
Na AWS máte štěstí, protože síťová komponenta je velmi silná – bylo by velmi překvapivé zjistit, že upstream link byl nasycen. Nicméně CPU, stejně jako disky I/O, je mnohem snazší zahltit.
Nejlepším postupem by bylo spustit nějaké monitorování (lokální, jako je SAR, vzdálené pomocí Nagios a/nebo ScoutApp) a nějaké vzdálené protokolovací zařízení (Syslog-ng). S takovým nastavením budete schopni identifikovat, které zdroje jsou nasyceny (síťový soket kvůli záplavě Syn; CPU kvůli špatným SQL dotazům nebo crawlerům; ram kvůli…). Nezapomeňte mít svůj oddíl protokolu (pokud nemáte povoleno vzdálené protokolování) na svazcích EBS (pro pozdější prostudování protokolů).
Pokud útok přichází přes webové stránky, může být velmi užitečný přístupový protokol (nebo jeho ekvivalent).
Řešení 2:
Můžete také dále izolovat své instance EC2 tak, že je umístíte za elastický nástroj pro vyrovnávání zatížení a budete přijímat provoz pouze z instance ELB. To klade větší břemeno na Amazon při správě útoků DDOS.
Předpokládám, že stále budete mít SSH otevřené pro všechny, takže je pravděpodobné, že tam stále budete přicházet nějaký podvodný provoz, pokud nemůžete uzamknout tento port na nějaké statické IP adresy. Můžete změnit port SSHd na něco nejasnějšího (tj. něco jiného než 22), abyste dále snížili počet zásahů DDOS (většina robotů kontroluje pouze známé porty).
Zmíním také fail2ban, který může monitorovat protokoly a dočasně upravit vaše IP tabulky tak, aby blokovaly konkrétní IP adresy (pokud například došlo k 6 neúspěšným pokusům o SSH do vašeho hostitele z jediné IP adresy, může tuto IP zablokovat na 30 minut nebo tak). Mějte na paměti, že (jak chytře poznamenal Jordan) fail2ban pravděpodobně není vhodný pro blokování provozu přes proxy (např. z ELB), protože zablokuje IP proxy, ne nutně původní vzdálenou IP.
Nepoužil jsem to, ale Apache mod_evasive může také stát za prozkoumání; může však mít stejnou slabinu jako fail2ban, pokud jde o blokování na základě IP.
Řešení 3:
Pokud používáte Apache, doporučuji použít mod_security. Sada základních pravidel, zabalená většinou dodavatelů, odvádí fantastickou práci.
Dalším zpřísňujícím krokem je omezení požadavků na úrovni webového serveru. Nginx., Apache může omezit a omezit příchozí požadavky.
Řešení 4:
Řešení, které používám pro blokování IP špatných aktivit v reálném čase vycházející z AWS a dalších, je toto... V mém CSF Firewallu v konfiguraci pro LFD Blocklists používám seznam zde - http://myip.ms/browse/blacklist/ Blacklist_IP_Blacklist_IP_Addresses_Live_Database_Real-time
Stáhnout Blacklist pro CSF Firewall » http://myip.ms/files/blacklist/csf/latest_blacklist.txt
Už žádný odporně nepříjemný provoz AWS.
Řešení 5:
Jsem zaujatý, protože pracuji pro síť pro doručování obsahu jako bezpečnostní technik předprodeje.
Využití řešení pro zmírnění Ddos v síti pro doručování obsahu však zajišťuje, že vám nikdy nedojdou zdroje v místě původu. Je to podobné, jako když před svůj web umístíte nástroj pro vyrovnávání zatížení F5, který se však rozšiřuje na tisíce míst po celém světě.
Dobré cdn vám umožní maskovat původ pomocí whitelistu, který nainstalujete na firewall aws. Takže když útočníci provedou svůj průzkum na Amazonu, vaše IP adresa bude prázdná, protože bude vše zablokováno.
Takže útoky Ddos jsou blokovány, když provoz zasáhne uzel co nejblíže k útočníkovi. To zajišťuje, že zmírníte útoky Ddos co nejdále od aktiva, které se snažíte chránit.
Dobrý cdn může také provádět kontroly stavu a failover provoz na jiná místa, např. další ego na zadku, Azure, rackový prostor, soft layer, fyzický DC atd. Měl by mít také WAF, aby bylo zajištěno, že můžete blokovat útoky vyčerpání aplikační vrstvy jako RUDY, slowpost, slowloris a také sqli, xss, rfi, lfi atd.
Ve výchozím nastavení cdn také blokuje útoky na síťové vrstvě, jako je teardrop, icmp útoky, synfloods atd. cdn je schopno zmírnit útoky Ddos, protože trey má obrovskou kapacitu pro přijímání požadavků, filtrování špatného provozu a předávání dobrého provozu. zesilující útoky jako ntp, DNS, ssdp, chargen a snmp objemové útoky lze blokovat.
Největší útok, který jsem doposud viděl, byl 321 gbps v červenci 2014. Během tohoto útoku došlo také k útoku protokolu DNS o rychlosti 20 gbps. Budete tedy muset zajistit, aby vaše infrastruktura DNS byla také odolná, aby odolala velkému počtu požadavků.
Z vámi poskytnutého popisu to vypadá, že jste byli vystaveni útoku vyčerpání, kdy útočník otevřel spoustu vláken, takže všechna vlákna byla spotřebována na webovém serveru, aplikačním serveru nebo firewallu. Je to podobné jako slowpost, slowloris nebo RUDY.
Chcete-li blokovat útoky vyčerpání aplikační vrstvy, budete si muset pořídit firewall webových aplikací (WAF). Typický síťový firewall (včetně amazonských firewallů a firewallů nové generace) jej nebude schopen blokovat. Firewally odeslané práce v dnešní době dokážou blokovat pouze asi 30 % všech útoků v těchto dnech (listopad 2014).