DDoS-Erkennung, Mitigation, Management und Bedrohungsanalyse
Umfassende Sicherheit & CGNAT
TLS/SSL Inspection
Web-Application-Firewall
Anwendungssicherheit und Load Balancing
Analytik und Management
CGNAT und IPv6-Migration
In einer komplexen Infrastruktur ist der Systemzustand eher fließend. Adressen, Hostnamen, Routing, Verfügbarkeit und Zustand der Dienste ändern sich häufig. Folglich muss jedes Gerät, das dieses System "schützen" soll, auf die dynamischen Zustandsänderungen reagieren, um wirksam zu sein.
Eines der Ziele von A10 Thunder TPS ist es, das System sofort über alle relevanten Änderungen des Dienststatus zu informieren. Mit diesem dynamischen Kontextbewusstsein bietet A10 erstklassigen DDoS-Schutz. In diesem Beitrag geben wir Ihnen einen umfassenden Überblick über dieses Konzept und wie wir es auf TPS anwenden.
Abgesehen von der RESTful-API, die ACOS für TPS bereitstellt (auf die wir in anderen Beiträgen eingehen werden), gibt es einige dynamische Mechanismen, die TPS nutzen kann, um Folgendes zu lernen.
Als Einführung werde ich beschreiben, wie man Ziele lernt und die entsprechende Richtlinie mit BGP hinzufügt. Mit TPS kann ich eine Art "Policy Peering" erstellen. Dadurch kann TPS eine Aktualisierung von der Gegenstelle erfahren, und anstatt sie zur RIB/FIB hinzuzufügen, werden diese Präfix-Informationen an die TPS-DDoS-Anwendung gesendet.
Zur Veranschaulichung habe ich unten Ausschnitte aus einer Konfiguration aufgeführt.
ip community-list 1 permit 101:50 #I define a community which TPS will listen for ! router bgp 1 bgp router-id 1.1.1.1 #local TPS BGP information neighbor 2.2.2.2 remote-as 2 neighbor 2.2.2.2 description policy-peer neighbor 2.2.2.2 acos-application-only #”Policy Peer” definition seen here as “acos-application-only" neighbor 2.2.2.2 route-map protection-context in #now we add the route-map we see below to process #inbound prefixes received from the policy peer ! route-map protection-context permit 1 match community 1 set ddos zone protected-servers #much like any BGP aware system we create route-maps to #control policy. The difference here however is we have #added A10 specific set statements. The one I show here #is “set ddos zone.”
Was bedeutet das nun alles? Nun, wir haben jetzt die Möglichkeit, den Schutz extrem dynamisch zu gestalten. TPS fügt der entsprechenden Zone sofort nach der Ankündigung ein Präfix hinzu. TPS wird es auch wieder entfernen, sobald es die Rücknahme hört (natürlich nach einer Wartezeit).
Dies ist sozusagen nur die Spitze des Eisbergs. Hier ist eine sehr einfache Darstellung einer DDoS-"Zone" und wie der Kontext dazugehört. Auf dem TPS sieht die Konfiguration für die Zone dann wie folgt aus:
ddos dst zone protected-servers #The name of our zone operational-mode monitor from-l3-peer #command to allow the route map to add prefixes #directly to the zone port 53 dns-udp level 0 indicator pkt-rate zone-threshold 1 #Very basic DNS protection example with a static PPS threshold
Zu diesem Zeitpunkt wird jede Route, die vom Richtlinien-Peer mit der Community 101:50 empfangen wird, zu dieser Zone hinzugefügt und erbt diese sehr grundlegende DNS-Richtlinie. In späteren Beiträgen werde ich mich eingehender mit der DNS-Richtlinie befassen.
Sehen ist Glauben. Vereinbaren Sie noch heute eine Live-Demo.
