Redundanz bei LiveShield: Was passiert, wenn ein Worker, ein Analyser oder ein ganzer Standort ausfällt?
Wie lässt sich hohe Verfügbarkeit beim DDoS-Schutz in einem Netz mit mehreren Standorten planen?
Der LiveShield-Worker wird an jedem Standort separat benötigt, an dem Verkehr vom Upstream empfangen wird, weil er eine lokale Kopie des Verkehrs analysiert, die per Port-Mirror (SPAN) oder optischem TAP abgegriffen wird. Analyser und Manager, die Module für Mitigationsentscheidungen und Konfiguration, können dagegen zentralisiert werden.
Diese Frage stellt sich in jedem Netz, das mehr als einen Edge-Standort mit unabhängigen Sessions zu Transit-Betreibern hat, und die Architektur von LiveShield hat darauf eine eindeutige Antwort, die sich unmittelbar aus der Funktionsweise der Angriffserkennung ergibt.
Warum der Worker an jedem Standort separat laufen muss
Der LiveShield-Worker analysiert den Verkehr, der physisch bei ihm ankommt, also die Kopie des Verkehrs aus dem lokalen Port-Mirror oder TAP-Link, der an den Edge-Router oder Switch am jeweiligen Standort angeschlossen ist. Hat ein Netz zwei unabhängige Standorte mit separaten BGP-Sessions zu Upstreams, braucht jeder von ihnen einen eigenen Worker, der an die lokale Verkehrsquelle angeschlossen ist. Den Worker kann man nicht über das Netz an einen entfernten Standort „schicken“, weil er dann den Rohverkehr über die WAN-Verbindung empfangen müsste, was ineffizient und bei größeren Durchsätzen praktisch nicht machbar ist.
Nach der Analyse übermittelt der Worker an den Analyser nur noch aggregierte statistische Daten, nicht den Rohverkehr, über eine gewöhnliche TCP-Verbindung auf der Management-Schnittstelle des Servers. Dieser Kanal benötigt nur einige Megabit pro Sekunde und kann daher sogar zwischen Standorten geführt werden, ohne die Produktivleitungen zu belasten.
Warum ein Analyser für mehrere Standorte besser ist als eine separate Konfiguration an jedem
Wird an jedem Standort ein separater, vollständig unabhängiger Satz aus Worker, Analyser und Manager aufgebaut, berechnet jede dieser Instanzen die Erkennungsschwellenwerte ausschließlich anhand des Verkehrs, den sie lokal sieht. Das öffnet eine Erkennungslücke: Ein Angreifer kann das Angriffsvolumen so auf zwei Standorte verteilen, dass keiner von ihnen für sich den eingestellten Schwellenwert überschreitet, obwohl der Gesamtverkehr an beiden Netzeintrittspunkten bereits ein Angriff ist.
Beispiel: Ist der UDP-Erkennungsschwellenwert an beiden Standorten separat auf 5 Gb/s gesetzt, wird ein Angreifer, der über jeden von ihnen 3 Gb/s sendet (insgesamt 6 Gb/s), an keinem der beiden erkannt, obwohl der tatsächliche Angriff den angesetzten Schwellenwert überschreitet.
Die Übermittlung aggregierter Daten aller Worker an einen gemeinsamen Analyser löst dieses Problem: Der Analyser sieht das vollständige Verkehrsbild aller Standorte gleichzeitig und trifft Entscheidungen auf Grundlage der tatsächlichen Verkehrssumme statt eines lokalen Ausschnitts. Ein zusätzlicher Vorteil ist, dass der Betreiber eine einzige Schwellenwert-Konfiguration pflegt, statt mehrere parallele Konfigurationen zu unterhalten, die bei jeder Änderung manuell synchronisiert werden müssen.
Was mit dem Produktivverkehr passiert, wenn ein Worker ausfällt
LiveShield arbeitet in einer Architektur außerhalb des Produktivverkehrspfads (Off-Path): Der Worker analysiert eine aus dem Mirror abgegriffene Kopie des Verkehrs, nicht den Verkehr, der physisch durch das Gerät läuft. Dadurch unterbricht der Ausfall eines Workers den Produktivverkehr am jeweiligen Standort nicht. Verloren geht lediglich die Fähigkeit, neue Angriffe zu erkennen und darauf zu reagieren, bis der Worker wiederhergestellt ist.
Das ist ein grundlegender Unterschied zu Lösungen, die Inline arbeiten, bei denen der Ausfall eines Filtergeräts direkt zu einer Unterbrechung des Kundenverkehrs führen kann.
Ausfall des Workers
Zusammenfassung
Die Redundanz von LiveShield in einem Netz mit mehreren Standorten beruht auf zwei Grundsätzen: Der Worker muss an jedem Standort separat laufen, weil er eine lokale Verkehrsquelle braucht, während Analyser und Manager zentralisiert werden sollten, damit die Erkennung auf dem vollständigen Verkehrsbild aller Standorte gleichzeitig beruht. Dank der Off-Path-Architektur unterbricht der Ausfall eines Workers den Produktivverkehr nicht, sondern schränkt nur die Fähigkeit zur Erkennung neuer Angriffe bis zu seiner Wiederherstellung ein.
Häufig gestellte Fragen
Reicht ein LiveShield-Worker für ein Netz mit zwei Standorten? Nein, wenn beide Standorte unabhängige BGP-Sessions zu Upstreams haben und Verkehr getrennt empfangen: Jeder von ihnen benötigt einen eigenen Worker, der an den lokalen Verkehrs-Mirror angeschlossen ist.
Müssen Analyser und Manager an jedem Standort separat installiert werden? Das wird nicht empfohlen. Ein gemeinsamer Analyser für alle Standorte liefert ein vollständiges Verkehrsbild und verbessert die Erkennungsgenauigkeit im Vergleich zu separaten, unabhängigen Konfigurationen.
Unterbricht der Ausfall eines Workers den Kundenverkehr? Nein. LiveShield arbeitet in einer Off-Path-Architektur und analysiert eine Kopie des Verkehrs aus dem Port-Mirror oder TAP-Link. Der Ausfall eines Workers schränkt die Fähigkeit zur Erkennung neuer Angriffe ein, beeinträchtigt aber nicht den Produktivverkehr im Netz.
