Managed OPNsense: was wir abnehmen, und wo KI mitarbeitet

/01Was „Managed OPNsense" bei HostSpezial umfasst

„Wir haben eine OPNsense-Firewall" und „Wir betreiben eine OPNsense-Firewall" sind zwei verschiedene Aussagen. Die erste beschreibt ein Gerät im Rack. Die zweite beschreibt einen Prozess: Jemand prüft, ob Patches eingespielt werden müssen, pflegt Regeln nach, wenn sich Netz oder Anwendungen ändern, beobachtet die Hochverfügbarkeit und ist erreichbar, wenn etwas ausfällt. Managed OPNsense bei HostSpezial ist der zweite Fall — ein Managed Service, kein verkauftes Gerät mit Restverantwortung beim Kunden.

Konkret gehören vier Dinge dazu, die dieser Artikel der Reihe nach durchgeht: Patch-Fenster und Versionspflege, Regelpflege mit Dokumentation, Überwachung der Hochverfügbarkeit im Firewall-Paar und — seit kurzem als zusätzlicher Baustein im Support — eine KI-gestützte Vorfilterung der Logs und Alarme, die aus OPNsense und der integrierten Intrusion-Detection kommen. Der letzte Punkt ist der, über den am meisten missverstanden wird, deshalb bekommt er in diesem Artikel den größten Raum — inklusive der Grenze, die er nicht überschreitet.

Wichtig ist dabei die Reihenfolge: Die KI-gestützte Vorfilterung ist ein Zusatz zum bestehenden Betrieb, kein Ersatz dafür. Eine Firewall, deren Patch-Stand seit Monaten nicht geprüft wurde, wird nicht dadurch sicherer, dass ihre Alarme hübscher zusammengefasst werden. Deshalb beginnt dieser Artikel bei den drei Grundaufgaben, die jede Managed-OPNsense-Umgebung trägt, bevor er zur Vorfilterung kommt.

/02Patch-Fenster und Versionspflege

OPNsense veröffentlicht fortlaufend Punktversionen innerhalb einer Release-Serie. Die aktuelle Serie trägt die Bezeichnung 26.7 „Xenial Xenops", erschienen am 15.07.2026; der Stand zum Abruf dieses Artikels war Punktversion 26.7.5 vom 30.09.2026, mit Suricata 8.0.7 und FreeBSD 15.1 als Unterbau. Jede Punktversion kann Sicherheitskorrekturen enthalten, muss es aber nicht — und genau das ist der Grund, warum „automatisch updaten" keine Patch-Management-Strategie ist, sondern ein Risiko: Ein Update kann auch Verhalten ändern, das eine produktive Firewall betrifft.

Bei HostSpezial läuft das deshalb in einem festen Rhythmus mit Wartungsfenster: Wir prüfen den aktuellen Versionsstand gegen die laufende Release-Serie, lesen die Änderungsliste auf sicherheitsrelevante und verhaltensändernde Einträge durch, und erst dann wird das Update im angekündigten Fenster eingespielt — bei einem HA-Paar nacheinander, Knoten für Knoten, damit die CARP-Umschaltung während des Updates die Erreichbarkeit hält. Das ist Routine, aber Routine, die jemand tatsächlich ausführen muss, Woche für Woche, nicht nur beim Einrichten der Firewall.

Zur Versionspflege gehört auch das Gegenteil von Eile: Nicht jede neue Punktversion wird am Tag ihres Erscheinens eingespielt. Zwischen Veröffentlichung und Einspielen liegt bei uns ein kurzes Beobachtungsfenster, in dem wir die Rückmeldungen aus der Community und etwaige Hinweise auf Regressionen sichten — eine Firewall ist kein Testgerät, und ein Update, das an anderer Stelle Nebenwirkungen zeigt, soll nicht zuerst bei einem Kunden auffallen. Nur bei Sicherheitskorrekturen mit hoher Dringlichkeit verkürzt sich dieses Fenster deutlich, im Zweifel bis auf ein außerplanmäßiges Wartungsfenster noch am selben Tag.

/03Regelpflege: wer eine Firewall-Regel anfasst

Eine Firewall-Regel, die niemand mehr erklären kann, ist in der Praxis schlimmer als eine fehlende Regel — sie bleibt über Jahre stehen, weil niemand das Risiko eingeht, sie zu löschen. Regelpflege heißt deshalb nicht nur „neue Regel anlegen, wenn eine neue Anwendung ein Protokoll braucht", sondern auch: jede Regel trägt eine Begründung, ein Datum und — wo sinnvoll — ein Ablaufdatum im Kommentarfeld. Wer eine Regel sechs Monate später liest, muss verstehen, warum sie da ist, ohne eine E-Mail-Kette zu durchsuchen.

Bei HostSpezial fasst ausschließlich unser Team produktive Regeln an, nach einem Vier-Augen-Prinzip bei Änderungen, die den Zugriff erweitern. Eine Anfrage vom Kunden — „Port X für Anwendung Y freischalten" — wird gegen den tatsächlichen Bedarf geprüft, nicht blind umgesetzt; häufig ist die engere Regel (eine IP statt eines Subnetzes, ein Protokoll statt „jeglicher Datenverkehr") genauso funktional und deutlich kleiner im Risiko. Das kostet am Anfang eine Rückfrage mehr. Es spart später die Stunde, in der jemand herausfinden muss, wofür eine Freigabe aus dem Vorjahr eigentlich da war.

Einmal im Quartal läuft zusätzlich eine Bestandsprüfung über das komplette Regelwerk: Welche Regel hat in den letzten Monaten überhaupt Datenverkehr gesehen, welche Freigabe gehört zu einer Anwendung, die längst abgelöst wurde, welche Quelle ist ein Dienstleister, der den Zugriff gar nicht mehr braucht? Verwaiste Regeln werden nicht stillschweigend gelöscht, sondern dem Kunden zur Bestätigung vorgelegt — eine Regel kann selten genutzt und trotzdem wichtig sein, etwa für einen jährlichen Wartungszugriff. Die Entscheidung, eine Regel zu entfernen, bleibt deshalb immer eine gemeinsame.

/04HA-Überwachung: CARP, pfSync und XMLRPC im Blick

Ein HA-Paar aus zwei OPNsense-Firewalls stützt sich laut Hersteller-Dokumentation auf drei zusammenspielende Teilsysteme: CARP (Common Address Redundancy Protocol, IP-Protokoll 112) für die virtuelle IP und den Statusabgleich zwischen den Knoten, pfSync für die laufende Zustandstabelle der Firewall-Verbindungen, und XMLRPC für den Abgleich der Konfiguration vom aktiven zum passiven Knoten. Fällt eines dieser drei Teilsysteme lautlos aus — ein Kabel am Sync-Interface, ein vergessener Haken bei XMLRPC nach einer manuellen Änderung —, bleibt die Firewall äußerlich unauffällig, bis im Ernstfall die Übernahme nicht funktioniert.

Deshalb ist „HA eingerichtet" kein abgeschlossener Zustand, sondern ein Wert, der laufend beobachtet werden muss: Ist der passive Knoten tatsächlich erreichbar, ist die Konfiguration synchron, ist die Priorität (Skew) noch wie vorgesehen verteilt? HostSpezial überwacht genau diese drei Werte im laufenden Betrieb und meldet eine Abweichung, bevor sie zum Problem wird — nicht erst, wenn der Kunde merkt, dass die zweite Firewall im Ernstfall nicht übernommen hat.

Ein Fall aus der Praxis zeigt, warum das wichtig ist: Nach einer manuellen Änderung direkt am passiven Knoten — eigentlich nur eine Routenprüfung — bleibt XMLRPC ohne weiteres Zutun synchron, weil die Konfiguration regelmäßig vom aktiven Knoten überschrieben wird. Wurde dieselbe Änderung dagegen versehentlich am aktiven Knoten vorgenommen, repliziert sich der abweichende Zustand auf den passiven Knoten — und beide Firewalls weichen fortan gemeinsam vom dokumentierten Soll-Zustand ab, ohne dass eine Fehlermeldung erscheint. Genau solche stillen Abweichungen sind der Grund, warum HA-Überwachung mehr ist als ein grüner Haken im Dashboard.

/05Wie KI im Support eingesetzt wird

Eine OPNsense-Firewall mit aktivierter Suricata-Engine erzeugt laufend Ereignisse — Protokollerkennung, abgelehnte Pakete, Signatur-Treffer aus den eingespielten Regelsätzen. Pro Firewall sind das über den Tag gerechnet mehr Zeilen, als ein Mensch sinnvoll einzeln lesen kann, ohne dass die meisten davon je einen Vorfall bedeuten. Diese Ereignisse laufen bei HostSpezial als strukturiertes JSON-Protokoll in unser SIEM: Wazuh liest die Datei ein, ordnet jedes Ereignis nach Herstellerangabe auf einer Skala von 0 bis 16 ein, und reichert bereits dort nach Regelwerk an.

Genau an dieser Stelle setzt die KI-gestützte Vorfilterung an, die wir seit kurzem im Support einsetzen: Ein Sprachmodell fasst eine Reihe zusammengehöriger Alarme zu einer lesbaren Zeile fürs Ticket zusammen — „Portscan aus internem Subnetz X, 40 Minuten, keine Treffer auf kritischen Diensten" statt vierzig Einzelzeilen —, und markiert, wenn ein Muster von der gewohnten Baseline einer Umgebung abweicht. Das ist keine neue Erkennungstechnik; die Erkennung selbst leistet weiterhin die Regel-Engine. Die KI übernimmt die Verdichtung und die Priorisierung, damit ein Mensch zuerst das sieht, was wirklich eine Entscheidung braucht.

# vereinfachter Ausschnitt, wie OPNsense-Alarme ins SIEM gelangen
# (Wazuh-Agent, /var/ossec/etc/ossec.conf)
<ossec_config>
  <localfile>
    <log_format>json</log_format>
    <location>/var/log/suricata/eve.json</location>
  </localfile>
</ossec_config>

# Alarme danach im Dashboard filterbar, z. B.:
rule.groups:suricata AND rule.level:>=8

Die Standardfelder aus der eve.json werden laut Wazuh-Dokumentation ohne eigenen Decoder erkannt — die eigentliche Pflegearbeit liegt nicht im Parsen, sondern in den Regeln und Schwellwerten, die festlegen, was überhaupt bis zur Vorfilterung durchkommt.

Der Nutzen zeigt sich am deutlichsten an einem gewöhnlichen Tag, nicht am Tag eines echten Vorfalls: Ein interner Scan durch ein neues Monitoring-Werkzeug, ein Mitarbeiter, der versehentlich ein falsches Passwort dreimal hintereinander eingibt, ein Lieferant, dessen VPN-Verbindung kurz abbricht und neu aufbaut — jedes dieser Ereignisse erzeugt einen oder mehrere Alarme, von denen keiner einen Vorfall bedeutet. Ohne Vorfilterung liegen diese Alarme als einzelne Zeilen nebeneinander im Dashboard. Mit Vorfilterung stehen sie als eine zusammengefasste, erklärte Zeile im Ticket — und die Zeit, die vorher für das Einordnen dieser Routine draufging, bleibt für die Fälle, die tatsächlich eine Prüfung brauchen.

/06Was die KI nicht entscheidet

Hier liegt die Grenze, die wir bewusst nicht verschieben: Das Sprachmodell liest, verdichtet und markiert — es setzt keine Firewall-Regel, sperrt keine IP-Adresse und schließt kein Ticket. Jede Aktion, die eine Veränderung am System bedeutet, durchläuft dieselbe Freigabe durch einen Menschen, die auch ohne KI-Vorfilterung gilt: ein Mitglied unseres Teams bewertet den Befund, entscheidet, ob er eine Regeländerung, eine Sperrung oder gar nichts nach sich zieht, und trägt die Begründung im Ticket nach.

Das ist kein Lippenbekenntnis, sondern eine technische Grenze, die wir aktiv ziehen. Wazuh selbst bringt mit „Active Response" eine Funktion mit, die laut Hersteller-Dokumentation automatisch und ohne Rückfrage ausgelöst werden kann, sobald eine festgelegte Regel-ID, ein Schweregrad oder eine Regelgruppe zutrifft — technisch wäre eine automatische Sperrung also möglich. Wir nutzen diese Automatisierung bei Managed OPNsense bewusst eng begrenzt und nur für eindeutig definierte, getestete Fälle; die Entscheidung über eine Firewall-Regel bleibt beim Menschen, nicht bei einem Schwellwert.

Praktisch sieht die Trennung so aus: Eine zusammengefasste Meldung landet im Ticketsystem mit einem Vorschlag, keiner Ausführung — „Empfehlung: IP X temporär sperren, Begründung: wiederholte Anmeldeversuche außerhalb der üblichen Zeiten, betroffener Dienst: Y". Ein Mitarbeiter prüft diesen Vorschlag gegen den Kontext, den eine Maschine nicht hat — läuft gerade eine angekündigte Wartung, ist X eine bekannte Außenstelle, deren Mitarbeiter heute früher anfängt — und setzt die Regel erst dann, wenn die Prüfung das stützt. Der Vorschlag beschleunigt die Arbeit. Er ersetzt nicht den Blick, der weiß, was in dieser einen Umgebung normal ist.

Diese Zurückhaltung ist eine bewusste Entscheidung, keine technische Notwendigkeit. Wazuh selbst könnte, wie Abschnitt 07 zeigt, auch ohne jede Rückfrage handeln. Dass wir diesen Weg nicht gehen, liegt daran, dass eine Firewall-Regel, die falsch gesetzt wird, schneller einen Geschäftsprozess stört als ein ausbleibender Alarm — eine fälschlich gesperrte IP-Adresse eines Zahlungsdienstleisters mitten im Tagesgeschäft ist im Zweifel teurer als ein Vorfall, der eine Stunde später bearbeitet wird, weil er erst durch einen Menschen bestätigt werden musste.

/07Wo es hakt: Grenzen der Vorfilterung und Datenschutz der Logs

Zwei Punkte gehören zur ehrlichen Einordnung, nicht erst auf Nachfrage.

Die Vorfilterung ist keine Erkennung neuer Angriffsmuster

Ein Sprachmodell, das Alarme zusammenfasst, erkennt keinen Angriff, für den es keine zugrunde liegende Regel oder Signatur gibt — es ordnet und priorisiert, was die Erkennungsebene bereits gemeldet hat. Wer sich von „KI im Support" eine neue Erkennungsqualität erhofft, die über die vorhandenen Suricata-Regelsätze und Wazuh-Regeln hinausgeht, erwartet mehr, als die Technik heute hält. Die Verdichtung spart Zeit beim Lesen; sie ersetzt keine gepflegte Regelbasis.

Datenschutz der Logs ist kein Nebenschauplatz

Firewall- und IDS-Protokolle enthalten IP-Adressen, teils auch Nutzernamen aus Authentifizierungsereignissen — personenbezogene oder zumindest personenbeziehbare Daten im Sinn der DSGVO. Dass ein Sprachmodell diese Daten verarbeitet, ändert nichts an der Pflicht, die Verarbeitung vertraglich zu fassen und technisch-organisatorisch abzusichern. Bei HostSpezial läuft die gesamte Logpipeline — von der Firewall über Wazuh bis zur Vorfilterung — innerhalb der eigenen Infrastruktur im Rechenzentrum Coburg mit Ausweichstandort Neustadt, dokumentiert als technische und organisatorische Maßnahme im Rahmen der ISO/IEC 27001:2024-Zertifizierung (Zertifikat 202787, gültig bis 05.09.2029) — nicht als Aufruf an einen externen KI-Dienst, bei dem unklar bliebe, wo die Daten landen.

Eine dritte Grenze: Was die Baseline nicht kennt, fällt nicht auf

Die Vorfilterung markiert Abweichungen von einem gelernten Normalzustand einer Umgebung. Für eine neu angebundene Umgebung existiert dieser Normalzustand noch nicht — in den ersten Wochen nach dem Anschluss an die Vorfilterung ist die Trefferquote entsprechend niedriger, weil schlicht zu wenig Vergleichsdaten vorliegen. Das ist kein Defekt, sondern eine Einlaufzeit, die wir Kunden auch so benennen, statt eine Qualität zu versprechen, die am ersten Tag technisch nicht gegeben sein kann.

/08Rufbereitschaft und Eskalation

Die Vorfilterung ändert nichts daran, dass ein echter Befund jemanden erreichen muss, der handeln kann — auch außerhalb der Bürozeiten. Markiert die KI-Vorfilterung einen Alarm als abweichend von der Baseline und erreicht er die vereinbarte Schwelle, geht er als Vorfall an unsere Rufbereitschaft, mit der Zusammenfassung aus Abschnitt 05 als erstem Kontext — nicht mit vierzig Rohzeilen, durch die sich jemand um drei Uhr nachts erst durcharbeiten muss. Was danach passiert, folgt einem Runbook: welche Schritte geprüft werden, wer informiert wird, ab wann der Kunde selbst kontaktiert wird.

Der Unterschied zur Vorfilterung ist also nicht, dass weniger Menschen beteiligt sind — sondern dass die beteiligten Menschen schneller bei der richtigen Information ankommen. Das senkt im besten Fall die Zeit bis zur ersten Einschätzung; es ersetzt nicht die Zeit, die eine echte Prüfung und Entscheidung brauchen.

Die Eskalation selbst ist gestuft, nicht binär. Nicht jeder markierte Befund braucht sofort einen Anruf: Eine Abweichung mit niedrigem Schweregrad geht zunächst ins Ticket und wird zur nächsten Bürozeit bearbeitet, eine Abweichung mit hohem Schweregrad löst die Rufbereitschaft unmittelbar aus. Diese Abstufung ist bei der Einrichtung jeder Umgebung ein eigener Punkt, keine Voreinstellung von der Stange — ein Produktionsbetrieb mit Schichtarbeit braucht andere Schwellen als ein Dienstleister, der ausschließlich zur Bürozeit arbeitet.

/09Wann Managed OPNsense die richtige Wahl ist — und wann nicht

Managed OPNsense mit KI-gestützter Vorfilterung ist kein Ersatz für eine Entscheidung, die ein Betrieb ohnehin treffen muss: Wer kümmert sich um die Firewall, wenn der zuständige Administrator im Urlaub ist, kündigt oder krank wird?

Dafür spricht

• Keine durchgehend besetzte IT mit Firewall-Erfahrung im Haus: Patch-Fenster, Regelpflege und HA-Überwachung brauchen wiederkehrende Aufmerksamkeit, nicht nur Fachwissen beim Einrichten.
• Viele Alarme, wenig Zeit zum Lesen: Wo eine interne IT-Abteilung die IDS/IPS-Protokolle ohnehin nicht täglich durchsieht, macht die Vorfilterung den Unterschied zwischen „wird gelesen" und „läuft lautlos mit".
• Nachweispflichten gegenüber Kunden, Versicherern oder Audit: Dokumentierte Regelpflege und ein belastbares Eskalationsverfahren lassen sich vorzeigen, ein informelles „kümmert sich schon jemand" nicht.

Dagegen spricht

• Eine vorhandene, gut besetzte Netzwerk- und Security-Abteilung: Wer Regelpflege, Patch-Management und 24/7-Eskalation bereits intern trägt, braucht den Managed-Teil nicht zusätzlich eingekauft.
• Die Erwartung einer autonomen KI-Abwehr: Wer eine Firewall sucht, die selbstständig entscheidet und reagiert, bekommt bei uns bewusst nicht dieses Produkt — die Entscheidung bleibt beim Menschen, siehe Abschnitt 06.

Unsere Praxis-Linie: Managed OPNsense trägt den laufenden Betrieb, die KI-Vorfilterung trägt die Lesbarkeit der Alarme. Beides zusammen verkürzt den Weg zur richtigen Entscheidung — es nimmt sie niemandem ab.

/10Häufige Fragen