Sophos Firewall IPS einrichten und sicher testen

Intrusion Prevention System (IPS) ist eine der wichtigsten Schutzfunktionen auf der Sophos Firewall. IPS prüft Traffic auf bekannte Angriffsmuster, Exploits und auffällige Protokollmuster. Richtig eingesetzt schützt es Clients, Server, veröffentlichte Dienste und VPN-Strecken zusätzlich zu Firewall-Regeln, Web Protection, Application Control und TLS Inspection.

In der Praxis ist IPS aber kein Schalter, den man überall maximal aktiviert. Eine falsche oder zu breite IPS Policy kann legitimen Traffic brechen, VoIP stören, Performance verbrauchen oder Fehlalarme erzeugen. Deshalb sollte man IPS geplant aktivieren, pro Regel passend auswählen und danach mit Logs und Tests kontrollieren.

Welcher Security-Inspection-Artikel passt?

IPS ist nur ein Baustein der Security Inspection. Je nach Problem oder Rollout-Ziel passt ein anderer Artikel besser:

• IPS aktivieren, Policy auswählen und False Positives prüfen: Dieser Artikel.
• Web-Kategorien, Web Policies und Benutzer-Webtraffic steuern: Sophos Firewall Web Protection mit Web Policies einrichten.
• Verschlüsselten Webtraffic entschlüsseln und prüfen: Sophos Firewall TLS Inspection richtig einführen.
• Dateien und Downloads per Sandbox oder ML prüfen: Sophos Firewall Zero-Day Protection verstehen und betreiben.
• Bekannte bösartige IPs, Domains oder URLs blockieren: Sophos Firewall Threat Feeds einrichten und sicher betreiben.
• Einfache Spoofing- oder Flooding-Muster reduzieren: Sophos Firewall Spoof Protection und DoS Settings prüfen.
• Öffentlich erreichbare Server mit NAT und IPS absichern: Server per DNAT auf Sophos Firewall veröffentlichen.
• Unerwartete Drops, Rule ID oder IPS policy ID analysieren: Sophos Firewall verworfene Pakete analysieren.

So bleibt die Schutzlogik nachvollziehbar: Firewall-Regeln begrenzen den erlaubten Traffic, IPS prüft diesen Traffic auf Angriffsmuster, Web Protection steuert Webinhalte, TLS Inspection schafft bei HTTPS mehr Sichtbarkeit, und Zero-Day Protection ergänzt Datei- und Download-Prüfungen.

Wann IPS sinnvoll ist

IPS lohnt sich besonders dort, wo Traffic ein höheres Risiko hat oder wo bekannte Exploits früh blockiert werden sollen.

Typische Einsatzbereiche:

• Client-Netze mit Internetzugriff
• Servernetze und DMZs
• DNAT-Regeln zu internen Servern
• Site-to-Site-VPN-Traffic zwischen Standorten
• Remote-Access-Traffic, wenn nach der VPN-Einwahl auf interne Systeme zugegriffen wird
• VoIP, nur mit vorsichtiger Policy-Auswahl und Tests
• besonders kritische Segmente wie Management-, Backup- oder Infrastruktur-Netze

Für veröffentlichte Server sollte IPS immer zusammen mit sauberem NAT, engen Firewall-Regeln, Logging und Patchmanagement betrachtet werden. Der Artikel Server per DNAT auf Sophos Firewall veröffentlichen erklärt den passenden Kontext für NAT und Firewall-Regeln. Für die grundsätzliche Regelstruktur passt Sophos Firewall-Regeln verstehen und richtig konfigurieren.

Voraussetzungen

IPS funktioniert nur, wenn die notwendigen Voraussetzungen erfüllt sind.

Vor dem Rollout prüfen:

• Eine aktive Network Protection Subscription oder eine Trial-Lizenz ist vorhanden.
• IPS Protection ist unter Intrusion prevention > IPS policies eingeschaltet.
• Pattern-Updates funktionieren und die Firewall kann Sophos-Update-Dienste erreichen.
• Firewall-Regeln enthalten passende IPS Policies unter Detect and prevent exploits (IPS).
• Logging ist für die betroffenen Regeln und Logtypen aktiv.
• Es gibt einen Ablauf für False Positives, Ausnahmen und Policy-Anpassungen.
• Für veröffentlichte Dienste und Segmentgrenzen ist klar, welche Firewall-Regel den Traffic wirklich trifft.

Wenn die Network-Protection-Subscription abläuft, kann der IPS-Schalter weiterhin aktiv aussehen, obwohl IPS nicht mehr erzwungen wird. Wenn IPS manuell oder nach Trial-Ablauf deaktiviert wird, können Signaturen, Updates und Konfigurationsmöglichkeiten je nach Zustand eingeschränkt sein. Vor dem Abschalten sollte man deshalb ein Backup oder einen Export der IPS-Konfiguration einplanen.

Achtung: IPS ist lizenz- und updateabhängig. Eine Firewall-Regel mit ausgewählter IPS Policy bedeutet nicht automatisch, dass IPS tatsächlich schützt. Lizenzstatus, globale IPS-Aktivierung, Signaturen und Logs müssen geprüft werden.

IPS global aktivieren

Die globale Aktivierung erfolgt in aktuellen SFOS-Versionen im Bereich Protect > Intrusion prevention > IPS policies. In manchen Ansichten erscheint der Menüpfad verkürzt als Intrusion prevention > IPS policies.

1. Protect > Intrusion prevention > IPS policies öffnen.
2. IPS Protection einschalten.
3. Lizenzhinweise prüfen.
4. Warten, bis Signaturen verfügbar sind.
5. Bestehende Standard-Policies prüfen.
6. Falls nötig, eigene Policy aus einer bestehenden Policy klonen.

Eine eigene Policy erstellt man über Add, vergibt einen Namen und klont eine bestehende Policy als Ausgangspunkt. Danach werden nur die wirklich nötigen Regeln angepasst. Das ist nachvollziehbarer als eine komplett freie Sammlung einzelner Signaturen, bei der später niemand mehr weiss, warum sie so gebaut wurde.

Änderungen an bestimmten Beschleunigungsfunktionen können IPS neu starten. Solche Änderungen sollten deshalb nicht während einer produktiven Fehleranalyse oder in einem engen Wartungsfenster ohne Plan erfolgen.

Die richtige IPS Policy auswählen

IPS Policies sollten zum Traffic passen. Die härteste Policy ist nicht automatisch die beste Policy.

• Clients nach Internet: Meist passt eine Client- oder LAN-to-WAN-Policy. Web, Application Control und TLS Inspection sollten dabei mitgedacht werden.
• Internet nach internem Server per DNAT: Server- oder Webserver-Policy wählen und Zielsystem, Ports sowie False Positives genau beobachten.
• Standort-VPN: Policy abhängig von Quell- und Zielsystemen auswählen. Performance, MTU/MSS und Anwendungen testen.
• VoIP: Sehr vorsichtig und spezifisch arbeiten. SIP/RTP darf nicht durch zu aggressive Signaturen brechen.
• Management-Netze: Gezielt und restriktiv absichern. Admin-Zugriffe, Monitoring und Backup-Traffic müssen getestet werden.

Bei Segmentgrenzen lohnt IPS ebenfalls: Client zu Server, VPN zu Server, Management zu Infrastruktur. Dadurch wird laterale Bewegung nach einem ersten kompromittierten System schwieriger. Wichtig bleibt aber die Reihenfolge der Firewall-Regeln. IPS schützt nur den Traffic, der wirklich durch eine Regel mit ausgewählter IPS Policy läuft.

Eine eigene IPS Policy ist sinnvoll, wenn eine Standard-Policy zu breit ist oder wenn nur bestimmte Signaturen mit angepasster Aktion benötigt werden. Man sollte aber nicht planlos Signaturen deaktivieren. Zuerst muss klar sein, welcher Traffic betroffen ist, welche Signatur ausgelöst hat und ob es sich wirklich um einen False Positive handelt.

Eigene IPS Policies sauber bauen

Eigene IPS Policies sollten aus einer bestehenden Policy geklont und dann gezielt angepasst werden. IPS-Policy-Regeln enthalten Signaturen und eine Aktion. Die Firewall wertet diese Regeln von oben nach unten aus. Dadurch kann eine zu breite Regel oberhalb einer spezifischen Regel das gewünschte Verhalten überdecken.

Beim Hinzufügen einer IPS-Policy-Regel wählt man Signaturen aus. Diese können nach Category, Severity, Platform und Target gefiltert werden. Für Sonderfälle können eigene IPS-Signaturen eingebunden werden. Das sollte aber nur passieren, wenn der Erkennungsfall sauber beschrieben ist und die Policy später wieder geprüft wird.

Bei Signaturen sind vor allem diese Felder wichtig:

• SID: eindeutige Signatur-ID für Logs, Tickets und Ausnahmen.
• Kategorie: technischer Bereich, zum Beispiel Browser, Betriebssystem, DNS, RPC oder Malware.
• Severity: Schweregrad der Bedrohung.
• Platform: Zielplattform, zum Beispiel Windows, Linux oder browserbezogene Komponenten.
• Target: client- oder serverbezogene Signatur.
• Recommended action: von Sophos empfohlene Standardaktion.

Severity sollte nicht nach Bauchgefühl gelesen werden. Sophos ordnet Critical grob CVSS 9 bis 10 zu, Major 7 bis unter 9, Moderate 4 bis unter 7 und Minor 1 bis unter 4 oder weniger kritischen Signaturen. Warning steht für auffälligen Traffic und wird als Alert behandelt. Für die Policy heisst das: Eine Major-Signatur auf einem exponierten Server ist anders zu bewerten als ein Warning-Treffer in einem Testnetz.

Die Aktion in einer Policy-Regel kann die empfohlene Signaturaktion übersteuern. Das ist nützlich, aber riskant. Ein pauschales Allow packet, Disable oder Bypass session kann Schutzwirkung entfernen, ohne dass man es später im Alltag sofort merkt.

Paketbasierte Aktionen prüfen jedes Paket. Sessionbasierte Aktionen prüfen bis zum ersten Treffer und wirken dann auf die Sitzung. Deshalb sind Drop session, Reset und Bypass session stärkere Eingriffe als ein einzelnes Paket zu erlauben oder zu verwerfen.

Praktischer Umgang mit Aktionen:

• Recommended: Standard für die meisten produktiven Regeln. Das Verhalten hängt von der Signatur ab.
• Allow packet: Beobachtung ohne Block, etwa im Pilot. Ein echter Angriff würde damit nicht verhindert.
• Drop packet: Einzelne Pakete verwerfen. Das kann Anwendungen stören.
• Drop session: Sitzung beenden, wenn ein Angriff verhindert werden soll. Das ist ein stärkerer Eingriff in produktiven Traffic.
• Reset: TCP-Session aktiv zurücksetzen. Benutzer oder Applikation sehen harte Abbrüche.
• Disable: Signatur deaktivieren. Der Schutz entfällt für diese Signatur.
• Bypass session: Rest der Session nicht mehr scannen. Solcher Traffic kann je nach Architektur in FastPath oder Offload laufen. Das kann mehr Traffic aus der Prüfung nehmen als erwartet.

Für produktive Policies ist deshalb eine kurze Änderungsnotiz sinnvoll: Welche Signatur wurde geändert, warum, in welcher Policy, für welche Firewall-Regel und bis wann wird die Anpassung erneut geprüft?

IPS in Firewall-Regeln verwenden

IPS wird nicht nur global eingeschaltet. Die Policy muss auch in der passenden Firewall-Regel verwendet werden.

1. Rules and policies > Firewall rules öffnen.
2. Relevante Regel bearbeiten oder erstellen.
3. Unter Other security features die Option Detect and prevent exploits (IPS) aktivieren.
4. Passende IPS Policy auswählen.
5. Regel-Logging aktivieren.
6. Änderung speichern.
7. Traffic kontrolliert testen.

Wenn die Firewall-Regel keine IPS Policy enthält, hat die globale IPS-Aktivierung für diesen Traffic keinen Effekt. Bei mehreren überlappenden Regeln ist die Reihenfolge entscheidend. Wenn Traffic von einer Regel ohne IPS getroffen wird, hilft die IPS Policy in einer späteren Regel nicht. Für solche Fälle ist Sophos Firewall Regel greift nicht: Ursachen prüfen der bessere Anschlussartikel.

Rollout in produktiven Umgebungen

IPS sollte schrittweise eingeführt werden.

1. Start mit Pilotregeln

Zuerst eine kleine, gut bekannte Regel wählen, zum Beispiel ein Client-Testnetz oder eine einzelne DNAT-Regel. Danach Logs prüfen und mit realen Anwendungen testen.

2. Treffer auswerten

Im Log viewer nach IPS-Ereignissen filtern. Wichtig sind Quelle, Ziel, Dienst, Regel, Signatur, SID, Severity, Aktion und Zeitpunkt. Wenn mehrere Schutzmodule beteiligt sind, muss man Web, Application Control, SSL/TLS Inspection und Firewall-Logs zusammen betrachten.

3. False Positives eingrenzen

Wenn legitimer Traffic blockiert wird, sollte man nicht sofort IPS global deaktivieren. Besser ist eine enge Analyse:

• Welche Signatur hat ausgelöst?
• Welche Anwendung oder welcher Dienst war betroffen?
• Betrifft es einen Host, ein Netz oder nur einen Port?
• Ist das Zielsystem aktuell gepatcht?
• Ist eine engere Firewall-Regel möglich?
• Reicht eine angepasste IPS Policy statt einer globalen Ausnahme?

4. Schrittweise ausweiten

Erst wenn die Pilotregel stabil läuft, sollte IPS auf weitere Regeln ausgerollt werden. Besonders bei VoIP, ERP-Systemen, industriellen Protokollen, VPN-Strecken und älteren Anwendungen braucht es Testfenster und Rückfallplan.

Ausnahmen und Signaturänderungen kontrollieren

IPS-Ausnahmen sind Sicherheitsentscheidungen. Wenn eine Signatur legitimen Traffic stört, kann eine Anpassung nötig sein. Trotzdem sollte man nicht reflexartig die ganze IPS Policy entschärfen oder IPS auf der Regel deaktivieren. Zuerst muss klar sein, ob wirklich ein False Positive vorliegt oder ob die Signatur ein reales Risiko sichtbar macht.

Vor einer Ausnahme sollte man mindestens sammeln:

• Signatur-ID und Signaturname: zeigt, welche Erkennung ausgelöst hat.
• Quelle, Ziel, Dienst und Firewall-Regel: grenzt den betroffenen Traffic ein.
• Zeitpunkt und Häufigkeit: trennt Einzelereignis von wiederkehrendem Muster.
• Anwendung oder Protokoll: hilft bei der Bewertung, ob der Traffic legitim ist.
• Patchstand des Zielsystems: reduziert das Risiko, einen echten Exploit zu erlauben.
• Packet Capture oder Logauszug: liefert Nachweis vor der Policy-Änderung.

Wenn eine Ausnahme nötig ist, sollte sie möglichst eng gesetzt werden:

• einzelne Signatur statt komplette Kategorie deaktivieren
• eigene IPS Policy für genau die betroffene Firewall-Regel verwenden
• Policy-Regel-Reihenfolge prüfen, damit spezifische Regeln nicht von breiten Regeln überdeckt werden
• Quelle, Ziel und Dienst in der Firewall-Regel enger fassen
• Ausnahme mit Grund, Owner und Review-Datum dokumentieren
• nach der Änderung prüfen, ob nur der erwartete Traffic betroffen ist

Eine temporäre Ausnahme ist oft besser als eine dauerhafte Abschaltung. Nach einem Applikationsupdate, Firmwareupdate oder Patch des Zielsystems sollte die Ausnahme erneut geprüft werden. Wenn viele Signaturen für dieselbe Anwendung stören, ist meistens eine eigene Policy oder eine saubere Segmentierung besser als eine grosse globale Ausnahme.

Logging und Troubleshooting

Für IPS-Analyse braucht man mehrere Blickwinkel.

• Log viewer: IPS-Treffer, Signatur, Aktion, Quelle, Ziel und Regel.
• ips.log: tiefere Hinweise auf IPS, DPI und Application-Control-Entscheidungen.
• Packet Capture: Paketfluss, Regel-ID, NAT-ID, IPS policy ID und Richtung.
• Regeltest: Prüfung, welche Firewall-Regel überhaupt passt.
• Syslog oder Central Reporting: längere Aufbewahrung und Korrelation.

Der Artikel Sophos Firewall Troubleshooting: Services und Logs ordnet ips.log und verwandte Logdateien ein. Für die Kombination aus Log Viewer und Packet Capture passt Sophos Firewall Regel testen mit Log Viewer und Packet Capture. Wenn Pakete unerwartet verworfen werden, hilft Sophos Firewall verworfene Pakete analysieren.

Performance beachten

IPS kostet Ressourcen. Wie stark die Last steigt, hängt von Modell, Traffic, aktivierten Signaturen, TLS Inspection, Application Control, VPN, Paketgrösse und Durchsatz ab.

Vor und nach der Aktivierung sollte man prüfen:

• CPU- und Speicherlast
• IPS- und DPI-bezogene Last
• Durchsatz auf betroffenen Interfaces
• Latenz und Retransmits bei kritischen Anwendungen
• Logvolumen und Syslog-Last
• Benutzer- oder Applikationsmeldungen nach der Änderung

Wenn ein Durchsatzproblem vermutet wird, sollte man nicht nur IPS deaktivieren und den Fall abschliessen. Besser ist ein Vergleich mit klarer Testmethode, zum Beispiel über Sophos Firewall Leistungsdaten richtig interpretieren und Sophos Firewall Performance mit iPerf testen.

Typische Fehler

• IPS Protection ist global ausgeschaltet.
• Network Protection ist abgelaufen oder nicht aktiv.
• In der Firewall-Regel ist keine IPS Policy ausgewählt.
• Traffic trifft eine andere Regel als erwartet.
• Eine breite IPS-Policy-Regel steht oberhalb einer spezifischen Regel und überdeckt sie.
• Logging ist auf der betroffenen Regel deaktiviert.
• Eine Server-Policy wird auf Clienttraffic angewendet oder umgekehrt.
• VoIP oder Spezialprotokolle werden ohne Pilotphase mit aggressiver Policy geprüft.
• False Positives werden mit globaler Deaktivierung statt enger Anpassung gelöst.
• Signaturen werden ohne Nachweis, Owner oder Review-Datum deaktiviert.
• Nach Trial-Ablauf wird nicht geprüft, ob Signaturen oder Policies noch verfügbar sind.
• Performance-Probleme werden nicht mit Messwerten vor und nach der Änderung verglichen.

Betriebscheckliste

• Network Protection oder Trial-Lizenz geprüft.
• IPS Protection unter Protect > Intrusion prevention > IPS policies aktiviert.
• Signaturen und Pattern-Updates geprüft.
• Passende IPS Policy pro Firewall-Regel gewählt.
• Regel-Logging aktiviert.
• Pilotregel mit realem Traffic getestet.
• Log viewer und ips.log geprüft.
• False-Positive-Prozess definiert.
• IPS-Ausnahmen eng dokumentiert und später erneut geprüft.
• Eigene IPS Policies enthalten keine unbegründeten Allow, Disable oder Bypass session Regeln.
• Performance vor und nach Aktivierung verglichen.
• Kritische Ausnahmen dokumentiert und mit Review-Datum versehen.

FAQ