Defense Fabric: Leitfaden für den Netzbetrieb

Aufgaben der Software

Defense Fabric führt Erkennung, Paketfilterung und Richtliniensteuerung auf Ihren Servern aus. Die lokale Kapazität hängt von diesen Servern und ihren Anschlüssen ab. Die Upstream-Kapazität des geschützten IP-Transits von Peeryx ist darin nicht enthalten.

Flow Collector ist ein separates, kostenloses Werkzeug zur Beobachtung und zur Steuerung der Verkehrsumleitung. Er ersetzt die Filter-Engine von Defense Fabric nicht. Peeryx Transit ist der separat bereitgestellte Netzdienst, der Verkehr bereits im vorgelagerten Netz filtern kann.

Server und Betriebssystem

Der aktuelle Installer ist für Debian 12 vorgesehen; das ausgelieferte Filter-Plugin benötigt x86-64. Die an den Rechner gebundene Lizenzierung erfordert TPM 2.0. Der Installer legt VPP und seine Plugins auf 25.10-release fest. Tauschen Sie diese VPP-ABI bei einem Betriebssystem-Upgrade nicht ungeprüft aus.

• Unabhängigen Verwaltungszugang, funktionierendes DNS, korrekte Systemzeit und ausgehendes HTTPS für Registrierung, Lizenzprüfung und signierte Updates bereitstellen.
• CPU, Speicherbestückung, NUMA-Zuordnung, PCIe-Lane-Breite, genaue Bestellnummer der Netzwerkkarte, Firmware, Treiber und Optiken gemeinsam prüfen. Der Familienname ConnectX allein ist kein Kompatibilitätsnachweis.
• Die Serververwaltung von den Verkehrsschnittstellen trennen. Genügend CPU, RAM und Speicherplatz für Filter-Engine, Flow-Erfassung und Aufbewahrung der Messdaten reservieren.

Dimensionierung und Leistungsnachweise

Gbit/s und Mpps immer gemeinsam betrachten. Bei 100 Gbit/s und 64-Byte-Ethernet-Frames ergibt sich einschließlich Präambel und Inter-Frame Gap eine theoretische Rate von etwa 148,81 Mpps. Das ist eine Berechnung der Leitungskapazität, kein Filter-Benchmark. Zwei Ports garantieren keine Verdopplung der Ende-zu-Ende-Kapazität.

Die veröffentlichten Hardwarekonfigurationen sind Kandidaten für eine technische Qualifizierung. Für sie liegt kein veröffentlichter, reproduzierbarer Leistungstest vor. Testen Sie den konkreten Rechner mit der vorgesehenen Regelzahl, den relevanten Paketgrößen, gleichzeitigem regulärem Verkehr und aktivierter Abwehr. Erfassen Sie neben dem Durchsatz auch Verlust, Latenz und Wiederanlauf.

Lizenzen, Ports und Server

Die Basislizenz enthält einen 10G-Port. Gekaufte Ports bilden einen gemeinsamen Pool für die unter dieser Lizenz verwalteten Server. Ein zweiter Server verdoppelt diesen Pool nicht. Weisen Sie jedem Server vor dem kostenpflichtigen Betrieb die benötigte Portanzahl und Geschwindigkeit zu. Pro Lizenz lassen sich bis zu 128 Server verwalten.

Im 14-tägigen Test gibt es keine Softwarequote für die Portanzahl oder die angegebene Portgeschwindigkeit. Physische Grenzen, Hardwarequalifizierung und Voraussetzungen für die Netzaktivierung bleiben bestehen. Das Hinzufügen eines Servers startet den Testzeitraum nicht neu.

Lizenzgültigkeit, Serveridentität und Bereitschaft des Routings sind getrennt zu prüfen. Nach dem Test sind Zahlung und gültige Nutzungsrechte für den weiteren lizenzierten Betrieb erforderlich. Ablauf und Verlängerungsstatus stehen im Kundenbereich.

Installation und Registrierung

Öffnen Sie Defense Fabric in Ihrem Kundenkonto. Legen Sie das Abonnement an oder wählen Sie ein bestehendes aus, fügen Sie den Server hinzu und erzeugen Sie sein kurzlebiges, einmal verwendbares Registrierungstoken. Verwenden Sie die zu diesem Server gehörenden Installationsanweisungen. Halten Sie Identität und Token geheim.

Der Installer prüft Debian 12, die Verfügbarkeit des TPM und die benötigte VPP-Version. Eine bereits aktive, unabhängige Datenebene erfordert eine Migration: Planen Sie die Wartung, statt sie einfach zu überschreiben. Eine erfolgreich geprüfte Signatur und Registrierung belegen noch nicht, dass Kundenverkehr geschützt wird.

• Installierte Version festhalten und Installationsergebnis prüfen.
• Portalverbindung, Filter-Engine, zugewiesene Ports und Schnittstellenzähler einzeln kontrollieren.
• Den Server im Beobachtungsmodus lassen, bis Hin- und Rückweg des Verkehrs geprüft sind.

Schnittstellen und Rückführung des bereinigten Verkehrs

Ermitteln Sie den Eingang für den zu filternden Verkehr und die separate logische Schnittstelle für dessen bereinigte Rückführung. Prüfen Sie VLANs, Adressen, Gateways, MTU und Next-Hop-Erreichbarkeit sowohl am Router als auch am Filterserver. Zähler der Linux-Verwaltungsschnittstelle sind nicht mit Zählern der Filterports gleichzusetzen.

Umgeleiteter Verkehr darf nicht wieder in den ungefilterten Eingang gelangen. Adressen der Steuerungsebene und des Gateways für bereinigten Verkehr müssen außerhalb der geschützten Zielbereiche liegen. Prüfen Sie tatsächlichen Kundenverkehr in beiden Richtungen, bevor Sie den Pfad freigeben.

Inline, BGP-Umleitung oder hybrider Betrieb

Inline: Der Verkehr durchläuft ständig den lokalen Filterpfad. Prüfen Sie das Verhalten bei Server-, Schnittstellen- und Stromausfall. Eine Softwareinstallation stellt keinen physischen Bypass bereit.

BGP-Umleitung: Der Router leitet Verkehr zu ausgewählten angegriffenen Zielen an den Filter-Next-Hop. Definieren Sie ausdrücklich Import-/Exportfilter und Communities. Prüfen Sie anschließend Ankündigungen, FIB-Einträge, bereinigten Rückweg und Rücknahme. Exportverzögerungen und Konvergenz beeinflussen die Reaktionszeit.

Hybrid: Ergänzen Sie die lokale Filterung bei Bedarf um geschützten Peeryx-Transit im vorgelagerten Netz. Dieser Netzdienst erfordert eine eigene Aktivierung, autorisierte Präfixe und einen geprüften Übergabepfad. Der Lizenzkauf allein ändert Ihr Upstream-Routing nicht.

BGP, FlowSpec und RTBH

Konfigurieren Sie Router-ID, lokale und entfernte Peer-Adressen, ASNs, erreichbaren Filter-Next-Hop und vereinbarte Umleitungs-Community. Der Routing-Schalter im Portal erlaubt dem Agenten, Sitzungen und Ankündigungen zu verwalten. Ein gespeicherter Entwurf bestätigt nicht, dass der Router die gewünschte Route installiert hat.

FlowSpec exportiert gezielte Regeln ins vorgelagerte Netz nur bei aktivierter Funktion, ausgeschalteter Simulation und aufgebauter BGP-Sitzung für die entsprechende Adressfamilie. Beginnen Sie im Dry-Run, prüfen Sie die erzeugten Regeln sowie Fähigkeiten und Grenzen Ihres Routers. Das Portal begrenzt die Zahl gleichzeitig aktiver Regeln auf 50.

RTBH ist ein letztes Mittel: Es verwirft sämtlichen Verkehr zum betroffenen Ziel, einschließlich legitimer Pakete. Schwellenwert, erforderliche Dauer und Gültigkeitszeit bis zur Rücknahme sind getrennte Einstellungen. Testen Sie auch die Wiederherstellung.

sFlow, NetFlow und IPFIX

Aktivieren Sie den Empfänger auf einer für autorisierte Exporter erreichbaren Adresse, vorzugsweise in einem privaten Netz oder VPN. Standard ist UDP-Port 6343. Stimmen Sie den Port auf beiden Seiten ab und beschränken Sie die Exporter-Zulassungsliste. Stellen Sie keinen unbeschränkten Collector ins Internet.

Prüfen Sie Sampling und Exporter-Timeouts, bevor Sie Erkennungsschwellen wählen. sFlow liefert seine Sampling-Rate mit. Der konfigurierte Multiplikator gilt für NetFlow/IPFIX, wenn der Exporter keine Rate übermittelt. Das Erfassungsfenster ist von 5 bis 60 Sekunden einstellbar.

Vergleichen Sie geschätzte Raten mit Schnittstellenzählern und prüfen Sie die Aktualität. Fehlende Exporte belegen weder das Ende des Verkehrs noch das Ende eines Angriffs. Paketmitschnitte und Flow-Schätzungen zeigen unterschiedliche Ausschnitte.

Präfixe, Schwellenwerte und Rückkehr zum Normalbetrieb

Schutzrichtlinien verwenden registrierte IPv4-/24-Netze und darin liegende /32-Ausnahmen. Prüfen Sie das normale Verkehrsprofil vor der Übernahme eines Schutzprofils. Protokoll- und zielbezogene Erkennungsschwellen dieser Version werden in PPS angegeben. Gbit/s-Einstellungen in FlowSpec und RTBH dienen deren eigenen Kapazitätsentscheidungen.

Monitor beobachtet ohne angriffsbedingte Umleitung. Automatic leitet während erkannter Angriffe um. Permanent hält den geprüften Filterpfad aktiv. Legen Sie die Austrittsschwelle unter die Eintrittsschwelle und verwenden Sie eine Haltezeit, damit schwankende Angriffe nicht ständig Routenwechsel auslösen.

Ein Profil lädt Protokollschwellen. Es ist keine Anwendungsliste zulässiger Dienste. Ein strengeres Profil ist nicht automatisch für ein stärker ausgelastetes Netz geeignet.

Adaptive Regeln sowie TCP- und UDP-Schutz

Die adaptive Erkennung kann Signaturen im Beobachtungsmodus bewerten oder erzeugte Regeln im aktiven Modus anwenden. Prüfen Sie die aufgezeichnete Signatur und ihre Wirkung auf regulären Verkehr, bevor Sie sie ausschließen oder das Backend ändern. Das Backend muss zur installierten Version und qualifizierten Hardware passen.

SYN-Proxy prüft den Verbindungsaufbau und erfordert einen getesteten symmetrischen Pfad. SYN-Challenge ist für den unterstützten asymmetrischen Fall vorgesehen. Die Funktionen sind nicht austauschbar; das Portal verhindert unvereinbare Kombinationen. Auch die SYNACK-spezifische Validierung erfordert den dokumentierten symmetrischen Pfad.

Quellquoten begrenzen UDP- oder zusammengefasste SYN/SYNACK-Pakete pro Quell-IP auf den dafür aktivierten Präfixen. Nutzer hinter NAT, VPN oder Proxy können dieselbe Quelladresse verwenden. Berücksichtigen Sie ihren normalen Gesamtverkehr bei der Auswahl einer Quote.

Ausnahmen und Firewall nach der Filterung

Nutzen Sie /32-Ausnahmen für einzelne Hosts innerhalb eines registrierten /24. Halten Sie sie eng begrenzt und dokumentiert. Eine Accept-Regel wirkt erst in der nachgelagerten Firewall. Sie stellt zuvor verworfene Pakete nicht wieder her und bedeutet keine allgemeine Umgehung aller Schutzprüfungen.

Das Portal erlaubt bis zu 20 geordnete Firewall-Prioritäten pro Präfix. Prüfen Sie vor der Anwendung Protokoll, Quellbereich, Zielports und Rateneinheiten. TCP-/UDP-Portbedingungen sind nicht für jedes IP-Protokoll sinnvoll.

Portal, Berichte und API

Bewerten Sie Portalverbindung, Engine-Zustand, BGP-Status und tatsächliche Schutzbereitschaft einzeln. Ein verbundener Agent oder laufender Prozess ersetzt keinen Weiterleitungstest. Aktuelle Statistiken beruhen auf Stichproben. Veraltete Messwerte müssen untersucht werden und sind nicht als Nullverkehr zu behandeln.

Angriffshistorie, aufgezeichnete Abwehrregeln sowie verfügbare PCAP-, ZIP- oder PDF-Nachweise helfen bei der Analyse. Aufbewahrungsfristen und Paket-Sampling begrenzen die Rekonstruktion. Ein Export ist nicht zwingend ein vollständiger Angriffsmitschnitt.

Die öffentliche OpenAPI-Referenz beschreibt verfügbare Operationen und Berechtigungen. Zugriffe erfordern Authentifizierung; beschränken Sie Token auf die nötigen Konten und Rechte. Richtlinienänderungen verwenden Revisionen und werden zunächst als noch anzuwenden gemeldet. Prüfen Sie den Knotenstatus, bevor Sie eine Änderung als aktiv betrachten. Nutzen Sie keine privaten Portal-Interna als Automatisierungsschnittstelle.

Mehrere Server und ECMP

Eine gemeinsame Lizenz und ein zweiter Server erzeugen weder automatische Zustandsreplikation noch Hochverfügbarkeit. Definieren Sie Ausfallerkennung, Routenpräferenzen, Rücknahme und Wiederanlauf für die gesamte Netzarchitektur und testen Sie jeden Ausfall einzeln.

Die unterstützte zweite Verbindung verwendet direkt verbundenes iBGP mit derselben ASN und getrennten VLANs für ungefilterten und bereinigten Verkehr. Sie erfordert Fabric 2.8.0 oder neuer. Jede Sitzung verwendet ihren eigenen lokalen Next Hop. ECMP verteilt Flows; ein einzelner Flow kann auf einer Verbindung verbleiben.

SYN-Proxy und SYNACK-Challenge sind für diesen Zweipfadbetrieb nicht qualifiziert. Zwei 100G-Verbindungen begründen keine garantierte Filterleistung von 200 Gbit/s.

Updates und Wiederherstellung der Konfiguration

Verwenden Sie den signierten Updateablauf im Portal. Planen Sie ein Wartungsfenster, da das Update die Filter-Engine neu starten kann. Prüfen Sie vor Beginn die Zielversion und halten Sie einen unabhängigen Verwaltungszugang bereit.

Der Updater prüft die Version, bewahrt die Konfiguration auf und bereitet Wiederherstellungsdateien vor. Prüfen Sie bei einem Fehler Diagnose und wiederhergestellten Zustand. Ein Rollback bestätigt nicht automatisch, dass sämtliche Verkehrswege wieder funktionieren.

Sichern Sie vor Richtlinienänderungen die relevante Konfiguration und vergleichen Sie die geplanten Änderungen. Bewahren Sie Sicherungen und Zugangsdaten vertraulich auf. Prüfen Sie eine wiederhergestellte Richtlinie gegen die laufende Software, bevor Sie wieder produktiven Verkehr dorthin umleiten.

Abnahme vor dem Produktivbetrieb

Vereinbaren Sie Testablauf und Rückfallkriterien, bevor Sie aktive Dienste umleiten. Verwenden Sie ausschließlich autorisierten Testverkehr und ein kontrolliertes Testziel.

• Ausgangszustand: regulären Verkehr, Zähler, Paketverlust und Anwendungserreichbarkeit mit inaktivem und aktivem Schutz vergleichen.
• Erkennung: ein begrenztes Ereignis auslösen und prüfen, dass nur vorgesehenes Ziel, Regel und Route betroffen sind.
• Rückkehr: Ereignis beenden, konfigurierte Haltezeit abwarten und Regelrücknahme sowie normale Weiterleitung bestätigen.
• Ausfall: Verlust von Exporter, BGP und Filterknoten getrennt testen. Tatsächlichen Pfad und Fail-Open- oder Fail-Closed-Verhalten feststellen.
• Version, Server, NIC, Paketgrößen, Regelzahl, Sampling, Testdauer, Verlust und Latenz festhalten. Erfolgreichen Betrieb und Rückfall dokumentieren.

Fehlersuche nach Schicht

Kein Portalkontakt: Verwaltungsnetz, DNS, Systemzeit, HTTPS, Identität und Lizenzstatus prüfen. Ändern Sie produktives BGP nicht allein zur Wiederherstellung der Verwaltungsverbindung.

Engine läuft, aber kein geschützter Verkehr: Filterschnittstellen, VLANs, Next Hops und tatsächliche RX-/TX-Zähler prüfen. Router-FIB und bereinigten Rückweg unabhängig vom BGP-Sitzungsstatus kontrollieren.

Unerwartete Abwehr: normalen Messwert, Sampling, gewähltes Profil und aufgezeichnete Regel vergleichen. Einen Entwurf ändern, Änderung prüfen und bewusst anwenden. Vor Prozessneustarts oder dem Entfernen von Routen Diagnosedaten sichern.

Bekannte Grenzen

Dieser Leitfaden beschreibt die ausgelieferte Debian-12-/x86-64-Version und den IPv4-Schutzablauf. Er bescheinigt weder andere Betriebssysteme oder beliebige NICs noch Funktionsgleichheit für IPv6, verlustfreie Umschaltung oder eine bestimmte Mpps-Leistung.

Lokale Filterung kann bereits im Upstream gesättigte Bandbreite nicht zurückgewinnen. Peeryx-Transit bietet separat die Möglichkeit, früher im Netz zu filtern. Flow Collector kann ein eigens geprüftes On-Demand-Konzept unterstützen.

SYN-Funktionen, ECMP und automatisches Routing haben jeweils Kompatibilitätsvoraussetzungen. Eine ungetestete Kombination ist zu qualifizieren und gilt nicht als bereits betriebsbereiter Dienst.