Lösung 1:
Ein DDOS (oder sogar ein DOS) ist im Wesentlichen eine Ressourcenerschöpfung. Sie werden Engpässe niemals beseitigen können, da Sie sie nur weiter wegschieben können.
Bei AWS haben Sie Glück, weil die Netzwerkkomponente sehr stark ist – es wäre sehr überraschend zu erfahren, dass die Upstream-Verbindung gesättigt war. Die CPU sowie die Festplatten-E/A sind jedoch viel einfacher zu überfluten.
Die beste Vorgehensweise wäre, eine Überwachung (lokal wie SAR, entfernt mit Nagios und/oder ScoutApp) und einige entfernte Protokollierungsfunktionen (Syslog-ng) zu starten. Mit einem solchen Setup können Sie erkennen, welche Ressourcen gesättigt sind (Netzwerk-Socket aufgrund von Syn-Flood; CPU aufgrund schlechter SQL-Abfragen oder Crawler; RAM aufgrund von …). Vergessen Sie nicht, Ihre Protokollpartition (wenn Sie die Remote-Protokollierung nicht aktiviert haben) auf einem EBS-Volume zu haben (um später die Protokolle zu studieren).
Wenn der Angriff über die Webseiten erfolgt, kann das Zugriffsprotokoll (oder das Äquivalent) sehr nützlich sein.
Lösung 2:
Sie können Ihre EC2-Instances auch weiter isolieren, indem Sie sie hinter einen Elastic Load Balancer stellen und nur Datenverkehr von der ELB-Instance akzeptieren. Dadurch wird Amazon stärker in die Pflicht genommen, DDOS-Angriffe zu verwalten.
Ich gehe davon aus, dass Sie SSH immer noch für alle offen haben, daher ist es wahrscheinlich, dass Sie dort immer noch unerwünschten Datenverkehr sehen, es sei denn, Sie können diesen Port für einige statische IPs sperren. Sie könnten den SSHd-Port in etwas Undurchsichtigeres ändern (d. h. etwas anderes als 22), um DDOS-Treffer weiter zu reduzieren (die meisten Bots prüfen nur bekannte Ports).
Ich werde auch fail2ban erwähnen, das Protokolle überwachen und Ihre IP-Tabellen vorübergehend ändern kann, um bestimmte IPs zu blockieren (wenn beispielsweise 6 fehlgeschlagene Versuche unternommen wurden, von einer einzigen IP-Adresse aus eine SSH-Verbindung zu Ihrem Host herzustellen, kann es diese IP für 30 blockieren Minuten oder so). Denken Sie daran, dass (wie Jordan scharfsinnig kommentierte) fail2ban wahrscheinlich nicht geeignet ist, Proxy-Verkehr (z. B. den von einem ELB) zu blockieren, da es die IP des Proxys blockiert, nicht unbedingt die ursprüngliche Remote-IP.
Ich habe es nicht verwendet, aber Apache mod_evasive könnte auch eine Untersuchung wert sein; Es kann jedoch die gleiche Schwäche wie fail2ban haben, wenn es um IP-basiertes Blockieren geht.
Lösung 3:
Wenn Sie Apache verwenden, empfehle ich die Verwendung von mod_security. Das Kernregelwerk wird von den meisten Anbietern gepackt und leistet fantastische Arbeit.
Ein weiterer Härtungsschritt ist die Begrenzung der Anfragen auf Webserver-Ebene. Nginx., Apache kann eingehende Anfragen drosseln und begrenzen.
Lösung 4:
Die Lösung, die ich verwende, um IPs mit schlechten Aktivitäten in Echtzeit zu blockieren, die von AWS und anderen kommen, ist diese ... In meiner CSF-Firewall in der Konfiguration für LFD-Blocklisten verwende ich eine Liste, die hier zu finden ist - http://myip.ms/browse/blacklist/ Blacklist_IP_Blacklist_IP_Addresses_Live_Database_Real-time
Blacklist für CSF-Firewall herunterladen » http://myip.ms/files/blacklist/csf/latest_blacklist.txt
Kein unverschämt widerlicher AWS-Verkehr mehr.
Lösung 5:
Ich bin voreingenommen, da ich als Security Presales Engineer für ein Content Delivery Network arbeite.
Die Nutzung einer Ddos-Minderungslösung in einem Content-Delivery-Netzwerk stellt jedoch sicher, dass Ihnen am Ursprung nie die Ressourcen ausgehen. Es ist vergleichbar mit dem Platzieren eines F5-Load-Balancers vor Ihrer Website, aber auf Tausende von Standorten auf der ganzen Welt verteilt.
Mit einem guten CDN können Sie den Ursprung mit einer Whitelist tarnen, die Sie auf der AWS-Firewall installieren. Wenn Angreifer also ihre Erkundung bei Amazon durchführen, wird Ihre IP-Adresse leer angezeigt, da alles blockiert wird.
Die Ddos-Angriffe werden also blockiert, wenn der Datenverkehr auf einen Knoten trifft, der dem Angreifer so nahe wie möglich ist. Dadurch wird sichergestellt, dass Sie Ddos-Angriffe so weit entfernt von dem Asset abwehren, das Sie zu schützen versuchen.
Ein gutes CDN kann auch Zustandsprüfungen und Failover-Datenverkehr zu anderen Standorten durchführen, z. B. ein anderes Ego in Ass, Azure, Rackspace, Soft Layer, ein physisches DC usw. Es sollte auch eine WAF haben, um sicherzustellen, dass Sie Erschöpfungsangriffe auf Anwendungsebene wie blockieren können RUDY, slowpost, slowloris sowie sqli, xss, rfi, lfi etc.
Standardmäßig blockiert das cdn auch Angriffe auf die Netzwerkschicht wie Teardrop, icmp-Angriffe, Synfloods usw. Ein cdn ist in der Lage, Ddos-Angriffe abzuschwächen, da es über enorme Kapazitäten verfügt, um die Anforderungen anzunehmen, schlechten Datenverkehr herauszufiltern und den guten Datenverkehr weiterzuleiten verstärkende angriffe wie ntp, DNS, ssdp, chargen und volumetrische snmp-angriffe können blockiert werden.
Der größte Angriff, den ich bisher gesehen habe, war im Juli 2014 mit 321 Gbit/s. Während dieses Angriffs gab es auch einen Angriff auf das DNS-Protokoll mit 20 Gbit/s. Sie müssen also sicherstellen, dass Ihre DNS-Infrastruktur auch robust ist, um einer großen Anzahl von Anfragen standzuhalten.
Aus der von Ihnen bereitgestellten Beschreibung geht hervor, dass Sie einem Erschöpfungsangriff ausgesetzt waren, bei dem der Angreifer viele Threads geöffnet hat, sodass alle Threads auf dem Webserver, App-Server oder der Firewall verbraucht wurden. Es ähnelt so etwas wie Slowpost, Slowloris oder RUDY.
Um Angriffe auf Anwendungsebene zu blockieren, benötigen Sie eine Web Application Firewall (WAF). Eine typische Netzwerk-Firewall (einschließlich Amazon-Firewall und Firewalls der nächsten Generation) kann sie nicht blockieren. Gesendete Arbeitsfirewalls können heutzutage nur etwa 30 % aller Angriffe blockieren (November 2014).