Suricata inline vor dem Apache CloudStack Virtual Router

Kategorie: Public Cloud · Für wen: Betreiber von Apache CloudStack, KVM und virtuellen Netzwerken · Lesezeit: 9 Min.

Auf einen Blick

• Wir haben Suricata in den Datenpfad der KVM-Bridge eingefügt, bevor die Pakete den Apache CloudStack Virtual Router erreichen.
• Der Mechanismus erfasst den gesamten Verkehr über die geschützte Bridge; die Regeln arbeiten derzeit im Alarmierungsmodus.
• Warteschlangenzustand, Verkehr, Telemetrie und Alarme sind im Monitoring sichtbar. Das Verhalten bei einem Ausfall ist ausdrücklich festgelegt.

Apache CloudStack trennt die Orchestrierungsebene klar von den Netzwerken der Mandanten. Das ist eine seiner größten Stärken, verlangt vom Betreiber aber auch eine bewusste Entscheidung für den Kontrollpunkt im Datenpfad. Eine zu hoch angesetzte Schutzschicht sieht nur einen Teil der Kommunikation. Eine zu tief angesetzte Schutzschicht erschwert den Betrieb der Hosts und kann die Fehlerdiagnose behindern.

Bei WebDisk haben wir einen Punkt zwischen dem physischen Uplink und dem Virtual Router gewählt: die KVM-Bridge für das öffentliche Netzwerk. Suricata arbeitet dort inline. Jedes Paket durchläuft also die Analyse-Engine, bevor es die virtuelle CloudStack-Infrastruktur erreicht. Damit bleibt die Lösung nahe am Hypervisor, umfasst einen klar bestimmten Datenpfad und erfordert keine Änderungen an den Kundenmaschinen.

Wo haben wir die Verkehrskontrolle platziert?

In einer typischen CloudStack-Zone stellt der Virtual Router Netzwerkdienste wie NAT, Routing und Firewall-Regeln bereit. Der Verkehr zu diesem Router läuft über eine Linux-Bridge auf dem KVM-Host. Genau dort lässt sich eine zusätzliche Kontrolle einführen, ohne das Standardmodell von CloudStack zu verändern.

In der Praxis leitet eine Regel auf der Bridge-Ebene Pakete in eine NFQUEUE-Warteschlange. Der Suricata-Prozess empfängt und analysiert sie und gibt seine Entscheidung an den Netzwerkstack zurück. CloudStack verwaltet weiterhin den Virtual Router und die Mandantennetzwerke. Die Schutzschicht liegt dagegen in der Verantwortung des Hypervisor-Betreibers.

Dieser Kontrollpunkt ist aus drei Gründen attraktiv. Erstens erfasst er den Verkehr, bevor die Dienste des Virtual Routers ihn verarbeiten. Zweitens benötigt er keinen Agenten in den Gastsystemen. Drittens lässt sich der Geltungsbereich an eine bestimmte Bridge binden, statt den gesamten Verkehr des Hosts abzufangen.

Wie unterscheidet sich Inline-Betrieb von passiver Beobachtung?

Ein passiver Sensor erhält eine Kopie des Verkehrs. Er kann Ereignisse erkennen und melden, befindet sich aber nicht im Paketpfad. Er ist ein nützliches Analysewerkzeug, doch seine Verfügbarkeit bestimmt nicht die Verfügbarkeit des Netzwerks.

Eine Inline-Unit ist Teil des Datenpfads. Ein Paket gelangt in die Warteschlange und kehrt erst nach der Verarbeitung durch den Prozess zur Bridge zurück. Damit lassen sich Entscheidungen durchsetzen. Zugleich verlangt dies einen wesentlich sorgfältigeren Umgang mit dem Lebenszyklus, mit Überlastung und mit Prozessausfällen. Suricata lediglich zu starten reicht nicht aus: Erforderlich sind Ressourcengrenzen, die Kontrolle über den Eigentümer der Warteschlange, ein Watchdog, eine eindeutige Bereinigung und Telemetrie, die den funktionierenden Datenpfad bestätigt.

In unserer Installation wurde der passive Dienst deaktiviert, damit auf demselben Host nicht zwei konkurrierende Beobachtungsmodelle laufen. Maßgeblich sind die Inline-Unit und ihr Zustandsmonitor.

Wie sieht der Lebenszyklus der Lösung aus?

Der größte Aufwand lag nicht in der Regel, die den Verkehr an NFQUEUE weiterleitet. Entscheidend war ein vorhersehbarer Lebenszyklus für die Engine: von der Konfigurationsprüfung über die Übernahme der Warteschlange bis zum sicheren Entfernen der Regel beim Stoppen.

Die systemd-Unit hat ein begrenztes Budget für CPU, Speicher und Prozesse. Der Monitor prüft, ob der Listener der Warteschlange vorhanden ist, die Verkehrszähler steigen, die Telemetrie aktuell ist und ob Kernel oder Prozess Pakete verworfen haben. Ein beeinträchtigter Zustand wird festgehalten. Ein kurzes Ereignis verschwindet dadurch nicht einfach, nur weil die nächste Messung wieder gesund aussieht.

Ebenso wichtig ist das Stoppen. Die Regel zur Weiterleitung in die Warteschlange muss entfernt werden, wenn der Prozess sie nicht mehr bedienen kann. Andernfalls sieht der Betreiber möglicherweise einen scheinbar gesunden Systemdienst bei gleichzeitig unterbrochenem Paketpfad. Die Bereinigung gehört deshalb zur selben Verantwortung wie der Start.

Was bedeutet Alarmierungsmodus?

Die Engine hat ein Profil mit Erkennungsregeln geladen, der aktive Regelsatz enthält jedoch keine DROP-Regeln. Jeder Treffer erzeugt ein Ereignis; das Paket wird nicht aufgrund der Signatur blockiert. Das ist eine bewusste Betriebskonfiguration: Zunächst ermitteln wir ein Bild des realen Verkehrs und der Signalqualität, bevor wir eine Blockierungsrichtlinie durchsetzen.

Der Alarmierungsmodus ändert nichts daran, dass Suricata inline arbeitet. Das Paket durchläuft weiterhin die Warteschlange und die Engine. Der Unterschied liegt in der Entscheidung nach der Analyse: Derzeit beobachten und beschreiben die Regeln den Verkehr, statt ihn zu verwerfen.

So lassen sich Fehlalarme, Last und Protokollabdeckung anhand realen Verkehrs beurteilen. Eine blockierende Regel kann später als separate, messbare Änderung eingeführt werden, mit einer verantwortlichen Person, einem Kriterium für das Zurückrollen und einer Überprüfung ihrer Wirkung.

Was sehen wir im Monitoring?

Der Prozesszustand active allein wäre ein zu schwacher Nachweis. Das Monitoring kombiniert mehrere unabhängige Signale:

• Zustand der Unit und Anzahl der Neustarts — ob der Prozess stabil läuft;
• vorhandener NFQUEUE-Listener — ob die Warteschlange einen Empfänger hat;
• Zähler der nftables-Regel — ob der Verkehr den Kontrollpunkt tatsächlich erreicht;
• pending sowie kernel/user drops — ob die Warteschlange Pakete verliert;
• Aktualität der Telemetrie — ob der Monitor den gegenwärtigen Zustand meldet;
• alert- und DROP-Regeln — welcher Durchsetzungsmodus tatsächlich aktiv ist;
• CPU und Speicher — ob der Schutz innerhalb des vorgesehenen Budgets bleibt.

Vier Alarme gruppieren Verfügbarkeitsprobleme, Datenverlust in der Warteschlange, Zustandsverschlechterungen und fehlende Telemetrie. Der Betreiber erkennt damit sowohl einen Prozessausfall als auch die Situation, in der ein Prozess zwar existiert, seine Aufgabe aber nicht mehr erfüllt.

Was ist für CloudStack-Betreiber am wichtigsten?

Die erste Erkenntnis lautet: Schützen Sie einen konkreten Datenpfad statt eines abstrakten „Hosts“. Die öffentliche Bridge ist eine Grenze, die sich beschreiben und messen lässt und deren Schutz zurückgenommen werden kann, ohne die Mandantenmaschinen anzufassen. Die Topologie jedes Hosts muss dennoch überprüft werden. Gerätenamen und die Anbindung der Virtual Router sollten nicht ungeprüft vorausgesetzt werden.

Die zweite Erkenntnis betrifft die Zuständigkeit. Eine einzige Unit sollte für die nftables-Regel, den NFQUEUE-Listener, den Suricata-Prozess und die Bereinigung verantwortlich sein. Eine Aufteilung dieser Elemente ohne gemeinsame Überwachung erhöht das Risiko, dass ein Teil des Datenpfads nach dem Ausfall eines anderen Teils aktiv bleibt.

Die dritte Erkenntnis: Beobachtbarkeit ist Bestandteil der Sicherheitsfunktion. Ein steigender Verkehrszähler, keine Paketverluste, aktuelle Telemetrie und die erwartete Anzahl von Regeln vermitteln ein wesentlich besseres Bild als ein einzelner systemd-Status.

Die vierte Erkenntnis: Grenzen müssen klar benannt werden. Die Analyse verschlüsselten Verkehrs gibt ohne TLS-Terminierung keinen Einblick in Anwendungsinhalte. Der Schutz der öffentlichen Bridge erfasst nicht automatisch East-West-Verkehr in anderen Netzwerken. Das Verhalten der Warteschlange bei Ausfällen ist eine Architekturentscheidung und sollte nicht dem Zufall überlassen werden.

Wie beginnen Sie eine ähnliche Installation?

1. Zeichnen Sie den tatsächlichen Paketpfad von der Host-Schnittstelle zum Virtual Router.
2. Wählen Sie eine Bridge aus und bestätigen Sie ihre Rolle anhand der Konfiguration und der Zähler.
3. Starten Sie Suricata mit einem separaten Profil und einer klar definierten Warteschlange.
4. Verbinden Sie nftables-Regel, Listener, Monitor und Bereinigung zu einem Lebenszyklus.
5. Beginnen Sie mit alarmierenden Regeln und vollständiger Beobachtbarkeit.
6. Erwägen Sie erst auf Grundlage der Daten blockierende Regeln und Kriterien für deren Zurückrollen.

Das öffentliche Repository cs-public0 unter der Lizenz Apache-2.0 enthält einen Lebenszyklus-Controller, eine Ansible-Rolle, Suricata-Konfigurationsvorlagen, beispielhaftes Monitoring und Tests. Es kann als Ausgangspunkt für Ihr eigenes Labor dienen.

Die Referenzvariante umfasst weitergeleiteten IPv4-Verkehr auf einer ausgewählten Bridge und Regeln im Modus alert-only. Sie enthält eine Demonstrationssignatur; den vollständigen Regelsatz stellt der Betreiber bereit. Vor der Installation müssen die Topologie, der systemd-Lebenszyklus und das Ausfallverhalten auf dem Ziel-KVM-Host gemäß der Repository-Dokumentation überprüft werden.

Die Apache-CloudStack-Dokumentation beschreibt Netzwerke und Verkehr in der Cloud sowie die Anforderungen an KVM-Hosts. Die offizielle Suricata-Dokumentation erklärt den Inline-IPS-Modus mit NFQUEUE, das nftables-Projekt die Filterung auf der Bridge-Ebene. Dies sind Standardkomponenten. Der Wert der Lösung entsteht durch ihre stimmige Kombination und die vollständige Ausarbeitung des Betriebs.

FAQ

Ersetzt Suricata den Apache CloudStack Virtual Router?

Nein. Der Virtual Router stellt weiterhin die Netzwerkfunktionen von CloudStack bereit. Suricata ist ein zusätzlicher Analysepunkt im Datenpfad der KVM-Bridge.

Muss auf Kundenmaschinen ein Agent installiert werden?

Nein. Die Kontrolle erfolgt auf dem KVM-Host vor dem Virtual Router. Die Gastmaschinen benötigen daher keine Änderungen.

Blockiert die Lösung erkannte Bedrohungen?

Die aktuelle Konfiguration verwendet alarmierende Regeln. Die Inline-Architektur kann Entscheidungen durchsetzen, doch das aktive Profil enthält keine DROP-Regeln.

Was geschieht, wenn der Suricata-Prozess stoppt?

Zum Lebenszyklus gehört das Entfernen der Regel, die Verkehr an eine nicht bediente Warteschlange weiterleitet. Die genaue Verfügbarkeitsrichtlinie sollte der Betreiber bewusst festlegen und zusammen mit dem Verfahren zum Stoppen testen.

Sieht die Lösung verschlüsselten Verkehr?

Sichtbar sind Verbindungsmetadaten und Protokolleigenschaften, die ohne Entschlüsselung zugänglich sind. HTTPS-Inhalte bleiben verschlüsselt, sofern TLS nicht vor dem Analysepunkt terminiert wird.

Lässt sich dieses Muster auf anderen KVM-Hosts einsetzen?

Ja, sofern der Betreiber zunächst die lokale Topologie, die Gerätenamen, das Ressourcenbudget und das Ausfallverhalten überprüft. Die Vorlage sollte nicht davon ausgehen, dass alle Hosts identisch sind.

Wie geht es weiter?

Wenn Sie Apache CloudStack auf KVM betreiben, beginnen Sie mit einem Diagramm des tatsächlichen Paketpfads und einer Reihe von Signalen, die den funktionierenden Schutz bestätigen. Wir tauschen uns gerne über Erfahrungen mit NFQUEUE, Suricata und Beobachtbarkeit auf CloudStack-Bridges aus — sprechen Sie das WebDisk-Team an. Mehr über unsere Infrastruktur erfahren Sie auf der Seite WebDisk Cloud.