Sophos Firewall IPS einrichten und sicher testen

Intrusion Prevention System (IPS) prüft Traffic auf bekannte Angriffsmuster, Exploits und auffällige Protokollmerkmale. Damit IPS tatsächlich schützt, muss es global aktiv und der verarbeitenden Firewall-Regel eine passende IPS Policy zugewiesen sein.

IPS sollte nicht pauschal mit der strengsten Policy auf jede Regel gelegt werden. Eine zum Datenpfad passende Policy, ein Pilotbetrieb und saubere Logs verhindern unnötige Ausfälle, ohne die Schutzwirkung leichtfertig zu reduzieren.

IPS aktivieren und einer Firewall-Regel zuweisen

Voraussetzungen

Vor der Konfiguration müssen diese Punkte erfüllt sein:

• aktive Network Protection Subscription oder Trial-Lizenz
• verfügbare IPS-Signaturen und funktionierende Pattern-Updates
• bekannte Firewall-Regel, die den zu prüfenden Traffic tatsächlich verarbeitet
• aktiviertes Regel-Logging und ein Ablauf für False Positives

IPS Protection ist standardmässig ausgeschaltet. Bei einer Online-Firewall werden IPS-Signaturen nur mit gültiger Lizenz und eingeschaltetem IPS aktualisiert. Lizenzierte Air-Gap-Firewalls sind die dokumentierte Ausnahme: Sie können IPS-Signaturen auch bei ausgeschaltetem IPS über den vorgesehenen Updateprozess erhalten. Die Details stehen unter Air-Gap-Lizenzierung und Pattern-Updates.

Läuft Network Protection ab, kann der IPS-Schalter weiterhin aktiv aussehen, obwohl die Firewall keinen IPS-Schutz mehr erzwingt. Wird IPS manuell ausgeschaltet, werden keine Online-Signaturen mehr aktualisiert und Policies sowie eigene Signaturen lassen sich nicht mehr konfigurieren. Nach 30 Tagen löscht die Firewall die IPS-Signaturen und Regeln.

Nach Ablauf einer Trial-Lizenz schaltet sich IPS automatisch aus. Innerhalb der folgenden 30 Tage erzwingt es keinen Schutz, lädt keine Signaturen herunter und erlaubt keine Policy-Konfiguration; danach werden Signaturen und Regeln gelöscht. Wer die Konfiguration behalten will, muss sie vorher exportieren oder ein Backup erstellen.

IPS global aktivieren

1. Protect > Intrusion prevention > IPS policies öffnen. Je nach Ansicht lautet der Pfad verkürzt Intrusion prevention > IPS policies.
2. IPS Protection einschalten.
3. Lizenzstatus und Pattern-Updates prüfen.
4. Warten, bis die Signaturen verfügbar sind.
5. Vorhandene Standard-Policies prüfen.
6. Falls eine eigene Policy nötig ist, über Add eine passende Standard-Policy klonen.

Nach der Aktivierung sollte nicht nur der Schalter kontrolliert werden. Ein aktueller Pattern-Stand und ein erster Treffer im Log zeigen wesentlich besser, ob die Schutzkette wirklich arbeitet.

Das Ein- oder Ausschalten von Firewall Acceleration oder PKI Acceleration startet IPS beziehungsweise die DPI Engine neu. Solche Änderungen gehören in ein Wartungsfenster und nicht mitten in eine laufende Fehleranalyse.

IPS in der Firewall-Regel aktivieren

1. Rules and policies > Firewall rules öffnen.
2. Die tatsächlich passende Regel bearbeiten.
3. Unter Other security features die Option Detect and prevent exploits (IPS) aktivieren.
4. Eine zum Traffic passende IPS Policy auswählen.
5. Regel-Logging aktivieren, speichern und mit realem Traffic testen.

Die globale Aktivierung allein reicht nicht. Trifft der Traffic zuerst eine andere Regel ohne IPS Policy, schützt eine spätere Regel nicht. In diesem Fall hilft Sophos Firewall Regel greift nicht: Ursachen prüfen.

Für veröffentlichte Server bedeutet das: DNAT, eng begrenzte Firewall-Regel, IPS Policy, Logging und Patchmanagement müssen zusammenpassen. Bei internen Segmenten ist ebenso zu prüfen, ob der Verkehr überhaupt über die Firewall und die erwartete Regel läuft.

Passende IPS Policy wählen

Die Policy richtet sich nach Quelle, Ziel und Anwendung:

• Clients ins Internet: Client- oder LAN-to-WAN-Policy verwenden und mit Web Protection, Application Control und gegebenenfalls TLS Inspection abstimmen. Browser, Update-Dienste und Fachanwendungen gehören in den Pilot; für verdächtige Downloads ergänzt Zero-Day Protection die Signaturprüfung.
• Internet zu einem Server per DNAT: Server- oder Webserver-Policy eng auf Zielsystem und veröffentlichte Ports ausrichten. Der Schutz gilt für die tatsächlich angebotenen Dienste, nicht pauschal für jede Servertechnologie. NAT und Regelkontext erklärt Server per DNAT veröffentlichen; bekannte bösartige IPs, Domains oder URLs lassen sich ergänzend über Threat Feeds sperren.
• Site-to-Site- oder Remote-Access-VPN: Policy nach Quell- und Zielsystem wählen. Produktive Anwendungen, MTU/MSS, Latenz und Durchsatz müssen über die reale VPN-Strecke getestet werden.
• VoIP: SIP/RTP mit einer spezifischen Policy und Rückfallplan testen. Eine aggressive Client- oder Server-Policy kann Signalisierung oder Medienfluss stören.
• Management-, Backup- und Infrastruktur-Netze: restriktiv schützen, ohne notwendige Admin-, Monitoring- oder Backup-Verbindungen zu unterbrechen. Hier sind enge Regeln meist wertvoller als eine besonders breite Signaturauswahl.

Auch an Segmentgrenzen wie Client zu Server oder VPN zu Server erschwert IPS die laterale Bewegung nach einer Kompromittierung. Es ergänzt jedoch nur saubere Firewall-Regeln. Gegen einfache Spoofing- und Flooding-Muster sind die separaten Spoof- und DoS-Einstellungen zuständig.

Eigene Policy aus einer Vorlage erstellen

Über Add lässt sich eine Standard-Policy klonen und danach gezielt anpassen. Das ist nachvollziehbarer als eine freie Signatursammlung und erhält einen sinnvollen Grundschutz. Der Name sollte Zweck und Datenpfad erkennen lassen, zum Beispiel IPS-Pilot-LAN oder IPS-DNAT-Webserver.

Die Policy-Regeln werden von oben nach unten ausgewertet. Eine breite Regel für alle Server-Signaturen kann deshalb eine darunterliegende Sonderregel für eine einzelne SID überdecken. Spezifische Anpassungen gehören oberhalb der allgemeineren Regeln; danach muss ein passender Treffer im Log bestätigen, dass die erwartete Aktion greift.

Signaturen filtern und bewerten

Signaturen lassen sich nach Category, Severity, Platform und Target filtern. Eigene IPS-Signaturen sind ebenfalls möglich, sollten aber nur für einen klar beschriebenen Erkennungsfall eingesetzt und später wieder geprüft werden. Für Logs, Tickets und Ausnahmen sind diese Angaben entscheidend:

• SID: eindeutige Signatur-ID
• Category: technischer Bereich, zum Beispiel DNS, Browser oder Malware
• Severity: Schweregrad
• Platform: betroffene Plattform, zum Beispiel Windows oder Linux
• Target: Client- oder Server-Signatur
• Recommended action: von Sophos empfohlene Aktion

Sophos ordnet Critical CVSS 9 bis 10, Major 7 bis unter 9, Moderate 4 bis unter 7 und Minor 1 bis unter 4 oder Parent-Signaturen zu. Warning kennzeichnet auffälligen Traffic als Alarm. Severity allein entscheidet aber nicht: Eine Major-Signatur auf einem exponierten Server ist anders zu bewerten als ein Warning-Treffer in einem Testnetz. Zielsystem, Erreichbarkeit, Patchstand und tatsächliche Aktion gehören immer zur Bewertung.

IPS-Aktionen verstehen

Eine Policy-Regel kann die von Sophos empfohlene Aktion übersteuern:

• Recommended: sinnvoller Ausgangspunkt für produktive Regeln; die jeweilige Sophos-Empfehlung wird angewendet
• Allow packet: Treffer protokollieren, Paket aber zulassen; eignet sich für einen Pilot, verhindert den erkannten Angriff jedoch nicht
• Drop packet: nur das betroffene Paket verwerfen; die Anwendung kann weiterlaufen oder mit Fehlern reagieren
• Drop session: komplette Sitzung nach einem Treffer beenden; stärkerer Eingriff bei einem bestätigten Angriffsrisiko
• Reset: TCP-Sitzung aktiv zurücksetzen; Benutzer oder Anwendung sehen einen harten Abbruch
• Disable: Signatur ausschalten; der Schutz für genau diese Erkennung entfällt
• Bypass session: restliche Sitzung nicht mehr prüfen; Traffic kann dabei in FastPath oder Offload gelangen und damit weitergehend aus der Prüfung fallen als beabsichtigt

Paketaktionen gelten pro Paket. Sessionaktionen prüfen bis zum ersten Treffer und wirken danach auf die ganze Verbindung. Abweichungen von Recommended brauchen deshalb eine Notiz mit Signatur, Policy, Firewall-Regel, Grund, Owner und Review-Datum.

PQC-Patterns ab SFOS 22.0 MR2

SFOS 22.0 MR2 erkennt reine und hybride ML-KEM-Aushandlungen, darunter ML-KEM-512, -768, -1024 und X25519 mit ML-KEM-768. Die neuen PQC-Patterns stehen standardmässig auf Disabled, weil PQC nicht automatisch verdächtig ist. Wer sie auswerten will, sollte eine eigene Pilot-Policy zuerst mit Allow packet und Logging testen und erst nach der Analyse mit Drop session oder Reset arbeiten. Hintergründe erklärt Sophos Firewall v22 MR2: PQC-Kontrolle.

Kontrolliert ausrollen und testen

1. Pilotregel wählen: Mit einem bekannten Client-Testnetz oder einer einzelnen DNAT-Regel beginnen. Der erwartete Traffic und die verantwortliche Person müssen vor dem Test klar sein.
2. Reale Anwendungen testen: Anmeldung, Dateiübertragung, Updates, APIs und länger laufende Sitzungen prüfen. Ein kurzer Ping beweist nicht, dass die Anwendung unter IPS stabil arbeitet.
3. Treffer auswerten: Im Log viewer Quelle, Ziel, Dienst, Firewall-Regel, Signatur, SID, Severity, Aktion und Zeitpunkt prüfen. Die Werkzeuge darunter liefern den technischen Kontext.
4. Schrittweise erweitern: Erst nach stabilen Tests weitere Regeln aufnehmen. VoIP, ERP, industrielle Protokolle, VPN und ältere Anwendungen brauchen ein Testfenster und einen Rückfallplan.

Für die Analyse helfen Services und Logs, der gemeinsame Einsatz von Log Viewer und Packet Capture sowie die Auswertung verworfener Pakete.

Die Werkzeuge beantworten unterschiedliche Fragen:

• ips.log: tiefere Hinweise auf IPS-, DPI- und Application-Control-Entscheidungen
• Packet Capture: Paketfluss, Richtung, Firewall Rule ID, NAT ID und IPS Policy ID
• Regeltest: welche Firewall-Regel den Traffic tatsächlich verarbeitet
• Syslog oder Central Reporting: längere Aufbewahrung und Korrelation

Wenn mehrere Schutzmodule aktiv sind, muss der Zeitpunkt über Firewall-, IPS-, Web-, Application-Control- und SSL/TLS-Inspection-Logs hinweg verglichen werden. Eine Firewall-Regel kann Traffic erlauben, den ein nachgelagertes Modul anschliessend blockiert.

Performance vergleichen

IPS benötigt je nach Modell, Traffic, Signaturen, TLS Inspection, Application Control, VPN und Paketgrösse unterschiedlich viele Ressourcen. Vor und nach der Aktivierung sollten deshalb folgende Werte unter vergleichbarer Last erfasst werden:

• CPU- und Speicherlast
• Durchsatz auf den betroffenen Interfaces
• Latenz und Retransmits kritischer Anwendungen
• IPS-/DPI- sowie Syslog-Volumen
• Benutzer- und Applikationsmeldungen

IPS nur kurz auszuschalten beweist noch keine Ursache. Reproduzierbare Vergleiche gelingen mit sauber eingeordneten Firewall-Leistungsdaten und einem kontrollierten iPerf-Test.

False Positives und Ausnahmen behandeln

Wenn legitimer Traffic blockiert wird, darf IPS nicht reflexartig global ausgeschaltet werden. Ein Treffer kann ein False Positive, eine unerwartete Anwendung oder ein realer Exploit-Versuch sein. Zuerst sammeln:

• Signatur-ID und Signaturname
• Quelle, Ziel, Dienst und getroffene Firewall-Regel
• Zeitpunkt, Häufigkeit und betroffene Anwendung
• Patchstand des Zielsystems
• relevanter Logauszug oder Packet Capture

Dabei helfen konkrete Fragen: Tritt der Fehler nur bei einem Host oder Port auf? Ist er reproduzierbar? Verschwindet er nach einem Patch? Zeigt dieselbe SID wiederholt auf dasselbe Ziel? Erst diese Fakten rechtfertigen eine Änderung an der Policy.

Danach wird die Änderung möglichst eng begrenzt:

• einzelne Signatur statt ganzer Kategorie anpassen
• eigene IPS Policy nur an der betroffenen Firewall-Regel verwenden
• Reihenfolge der Policy-Regeln kontrollieren
• Quelle, Ziel und Dienst in der Firewall-Regel enger fassen
• Grund, Owner und Review-Datum dokumentieren
• nach der Änderung prüfen, ob nur der erwartete Traffic betroffen ist

Eine temporäre Ausnahme ist meist besser als eine dauerhafte Abschaltung. Nach einem Applikations-, Firmware- oder Systemupdate muss sie erneut geprüft werden. Stören viele Signaturen dieselbe Anwendung, ist eine eigene Policy oder bessere Segmentierung sauberer als eine grosse globale Ausnahme.

Troubleshooting und Betrieb

IPS wirkt nicht

In dieser Reihenfolge prüfen:

1. Ist Network Protection oder die Trial-Lizenz gültig?
2. Ist IPS Protection global eingeschaltet?
3. Sind IPS-Patterns aktuell? Im HA-Cluster wird auf dem Primary aktualisiert und automatisch zur Auxiliary synchronisiert.
4. Trifft der Traffic die erwartete Firewall-Regel mit IPS Policy und Logging?
5. Überdeckt eine breite Policy-Regel eine spezifische Regel?
6. Enthält die Policy unbegründete Aktionen wie Allow packet, Disable oder Bypass session?
7. Passt die Policy zu Client-, Server-, VPN- oder VoIP-Traffic?
8. Wurde mit realem Traffic geprüft, ob Log Viewer und ips.log passende Ereignisse zeigen?

Ausnahmen ohne Owner oder Review-Datum gelten als offen und gehören in die nächste Betriebsprüfung.

IPS-Service steht auf DEAD

Unter SFOS 22.0 GA und neuer können in seltenen Fällen benötigte Web-Policy-Konfigurationsdaten fehlen. Der Web-Policy-Dienst startet dann nicht, IPS kann seine Policy nicht initialisieren und bleibt auf DEAD; auch Pattern-Updates schlagen fehl. In einem HA-Cluster kann jeder Node unabhängig betroffen sein.

In der CLI führt 5 Device Management > 3 Advanced Shell zur benötigten Shell. Dort zeigt dieser read-only Befehl alle Servicezeilen mit ips im Namen:

service -S | grep -i ips

Relevant ist nur die Zeile, deren erster Dienstname exakt ips lautet; ipsec-monitor ist nicht gemeint. In einem HA-Cluster muss jeder betroffene Node separat geprüft werden.

Steht der Dienst auf DEAD, sollte man SFOS-Version, Zeitpunkt, Node, vollständige Statusausgabe sowie ips.log und sig_upgrade.log sichern und Sophos Support mit Verweis auf NC-181971 kontaktieren. Der Befehl allein beweist diesen Fehler nicht. Sophos veröffentlicht weiterhin keine behobene Version und stellt den Workaround nur über den Support bereit. Wiederholte Neustartversuche oder undokumentierte Reparaturbefehle sind keine saubere Lösung.

FAQ