Optimierung von DDoS-Schutzmaßnahmen durch Analyse von Testdaten

Details

Prozentual ausgewertet ist zu erkennen, dass die Angriffe mit geringem Skilllevel, vornehmlich UDP Reflection/Amplification, zu knapp 90% mitigiert werden. TCP und Layer 7 Angriffe, egal ob Web, IPSec, DNS, SIP etc, stellen trotzdem weiterhin ein Problem dar; deswegen werden diese Arten von Angriffen auch bevorzugt von versierten Angreifern eingesetzt.

Je höher das Skill-Level der Angreifer, desto größere Probleme gibt es auf der Verteidigerseite, vor allem wenn man an die Komplexität heutiger IT-Systeme denkt. Das Thema DDoS-Angriffsoberfläche ist und bleibt ein zu oft vernachlässigter Punkt, den Gruppen wie KillNet und NoName geschickt zu ihrem Vorteil zu nutzen wissen .

Ein weiterer Aspekt, den wir zwar schon immer vermutet haben, den wir jetzt aber mit echten Zahlen untermauern können: Testen zahlt sich aus. Fehlkonfigurationen werden schnell erkannt und können behoben werden. Potentielle Angriffspunkte können getestet werden, bevor Angreifer dies tun.

Wir begleiten Teams, die die Herausforderung angenommen und es geschafft haben, innerhalb eines Jahres den riesen Schritt vom „wir haben gerade erst unsere DDoS-Mitigation implementiert“ – Status zum RedTeaming gegangen zu sein.

Ableitung für BlueTeams

Wir haben mehrere Problemfelder identifiziert, an denen wirksame DDoS-Mitigation scheitern kann. Neben einer sauberen Architektur und Implementierung sind auch die organisatorischen Workflows oder die Netztopologie entscheidend.

Wir können jedem Team nur empfehlen, das eigene DDoS-Schutzlevel kontinuierlich zu testen und an die sich laufend ändernden Bedingungen anzupassen. Da die Angreifer nicht schlafen, sondern im Gegenteil sehr aktiv sind und sich ständig weiterentwickeln, sollte jede Organisation unter DDoS-Bedrohung mindestens jährlich das eigene ThreatLevel vs Schutzniveau evaluieren.

Wir haben gesehen, dass sich das Testen bezahlt macht.

Methodologie

Wir führen für unsere Kunden koordinierte DDoS-Stresstests durch, größtenteils als Leistungsnachweise, zunehmend aber auch RedTeamings. Dabei bewerten wir die durchgeführten Angriffe anhand des DDoS Resiliency Score DRS (1) , den man grob anhand der definierten Attacker-Capabilities folgendermaßen beschreiben kann:

• DRS 3 // Stresser/Booter-Services, DDoS-as-a-Service
• DRS 4 // Aktivistengruppen (Killnet, Noname), DDoS-Erpressergangs
• DRS 5 // Advanced Attacker, DDoS-For-Hire, Profis
• DRS 6 // High-End-Profis (selten zu sehen)

Den einzelnen DRS-Leveln kann man Angriffstypen zuordnen: UDP-Reflection ist z.B. DRS 3, TCP-Handshakes DRS 4, CarpetBombing, Browserangriffe und und Multi-Vektor-Angriffe mit hohem Randomisierungsgrad fallen eher in die Kategorie DRS 5.

Wir haben also für alle durchgeführten Tests den Angriffsvektor (TCP/UDP/Layer 7), das DRS-Level des Angriffs und den Status aufgezeichnet. Der Status kann sein:

• OK : Angriff mitigiert, maximale Mitigationszeit 30 Sekunden
• Prob: Problematisch, Angriff entweder nur teilweise oder manuell mitigiert, hoher Impact für mindestens 10 Minuten
• Fail: keine Mitigation

Dabei wurden Tests mit gleichem Vektor und DRS-Level zusammengefasst und das schlechtere Ergebnis gewertet. Wenn wir z.B. 3 UDP-Test nach DRS 3 durchgeführt haben, zwei davon OK und ein FAIL, dann ging ein FAIL in die Wertung ein.

Wenn alle 3 Bestanden wurden, dann ging ein OK in die Wertung ein. Damit erklärt sich auch die Diskrepanz zwischen den insgesamt durchgeführten Test (408) und der Summe gem. Grafik.

IPv6

Wir haben 10 IPv6 – Tests durchgeführt und ALLE sind fehlgeschlagen. Die Gründe dafür möchten wir derzeit nicht offenlegen.

Anmerkungen

• [1] wir legen den DRS v2.0 zugrunde, der aktuell dem DRS-Advisory-Board zur Abstimmung vorliegt und die Attacker-Capabilities in den Vordergrund stellt

Webseite von zeroBS

Quelle: zeroBS