Sophos Firewall IPS einrichten und sicher testen

Intrusion Prevention System (IPS) prüft Netzwerkverkehr auf bekannte Angriffsmuster, Exploits und auffällige Protokollmerkmale. Damit IPS tatsächlich schützt, muss es global aktiv sein. Ausserdem muss die Firewall-Regel, die den Datenstrom verarbeitet, eine passende IPS Policy verwenden.

Der sichere Kurzweg lautet: Lizenz und Patterns prüfen, IPS einschalten, eine Policy nach dem zu schützenden System auswählen, diese der richtigen Firewall-Regel zuweisen und den Datenpfad mit einer kleinen Pilotgruppe abnehmen. Die strengste Policy auf jeder Regel bietet nicht automatisch den besten Schutz. Eine unpassende Auswahl erzeugt unnötige Treffer, Last oder Störungen und erschwert die eigentliche Auswertung.

Voraussetzungen und Lizenzzustand prüfen

Vor der Konfiguration braucht man:

• eine aktive Network Protection Subscription oder Trial-Lizenz;
• verfügbare IPS-Signaturen und funktionierende Pattern-Updates;
• die Firewall Rule ID der Regel, die den vorgesehenen Traffic tatsächlich verarbeitet;
• Regel-Logging für die Korrelation von Sitzung, Firewall-Regel und IPS-Ereignis;
• eine verantwortliche Person, definierte Tests und einen Rückweg 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 Unterschiede erklärt Air-Gap-Lizenzierung und Pattern-Updates.

Nach Ablauf einer Network-Protection-Subscription kann der IPS-Schalter weiterhin aktiv aussehen, obwohl die Firewall keinen IPS-Schutz mehr erzwingt. Die Trial-Lizenz verhält sich anders: Nach ihrem Ablauf schaltet sich IPS automatisch aus. Mit ausgeschaltetem IPS werden keine Online-Signaturen mehr heruntergeladen und Policies sowie eigene Signaturen lassen sich nicht mehr konfigurieren. Nach 30 Tagen in diesem ausgeschalteten Zustand löscht SFOS die IPS-Signaturen und Regeln. Wer die Konfiguration erhalten muss, erstellt vorher einen Export oder ein Backup.

Auch bei ausgeschaltetem IPS können vorhandene IPS Policies weiterhin Firewall-Regeln zugewiesen werden. Diese Zuweisung ist kein Nachweis für aktive Prüfung oder Schutzwirkung. Ist die bezahlte Subscription abgelaufen und IPS ausgeschaltet, oder hat eine abgelaufene Trial-Lizenz IPS automatisch ausgeschaltet, muss zuerst eine Network Protection Subscription aktiviert werden, bevor sich IPS wieder einschalten lässt. Nach der Aktivierung den IPS-Schalter und die Signaturen erneut prüfen.

Auch eine gültige Subscription schützt nicht unbegrenzt ohne Lizenzkontakt. Online-Firewalls synchronisieren ihre Lizenzen normalerweise alle 24 Stunden. Bleibt die Synchronisierung 90 aufeinanderfolgende Tage aus, deaktiviert SFOS die Security Subscriptions; bei einer Air-Gap-Lizenz beträgt diese Frist 180 Tage. Anmeldungen und Traffic können dann weiter funktionieren, jedoch ohne den Schutz der deaktivierten Subscriptions. Der Lizenzstatus gehört deshalb zur Fehleranalyse, wenn IPS scheinbar konfiguriert ist, aber nicht wirkt.

Unter Backup & firmware > Pattern updates zeigt SFOS unter anderem die Zustände Ready to install, Downloading, Success und Failed. Update pattern now startet eine Aktualisierung der normalen Pattern-Definitionen. Ein erfolgreicher Eintrag für Application Signatures beweist nicht, dass auch IPS-Signaturen geladen wurden: Bei Online-Systemen benötigen diese weiterhin Lizenz und eingeschaltetes IPS.

IPS aktivieren und den Datenpfad festlegen

1. Intrusion prevention > IPS policies öffnen.
2. IPS Protection einschalten.
3. Unter Backup & firmware > Pattern updates den IPS-Pattern-Zeitpunkt und Status kontrollieren.
4. Den bisherigen Zustand von IPS Protection, die Firewall Rule ID des Pilot-Datenstroms, die bisherige IPS Policy, Log firewall traffic und vorhandene Ausnahmen dokumentieren.

Das Ein- oder Ausschalten von Firewall Acceleration oder PKI Acceleration startet IPS beziehungsweise die DPI Engine neu. Solche Änderungen gehören nicht in diesen Aktivierungsablauf. Wenn ein reproduzierbares Problem eine globale Engine-Einstellung betrifft, beschreibt Globale IPS-Einstellungen sicher prüfen, welche Änderungen sofort gelten, welche einen Apply-Schritt oder Neustart benötigen und wie der Ausgangswert erhalten bleibt.

Das zu schützende System bestimmt die Policy

Target bezeichnet die Seite, deren verwundbare Software eine Signatur schützt. Es ist nicht einfach mit Source Zone oder Destination Zone gleichzusetzen. Für einen Browser, der eine präparierte Antwort empfängt, kann das Target beispielsweise Client sein; bei einem veröffentlichten Webserver, der einen schädlichen Request erhält, Server.

Die Auswahl gelingt in drei Fragen:

1. Welches System ist im betrachteten Flow das zu schützende Ziel: Client oder Server?
2. Welche Plattformen, Protokolle und Dienste laufen dort tatsächlich?
3. Deckt eine vorhandene Policy diesen Umfang ohne fachfremde Signaturgruppen ab?

Für einen normalen Client-Internetpfad ist eine passende Client- oder LAN-to-WAN-Policy der Ausgangspunkt. Bei einer DNAT-Veröffentlichung wählt man eine Server- oder Webserver-Policy, die zu Betriebssystem und tatsächlich veröffentlichten Ports passt. In einem VPN- oder Segmentierungsdatenstrom entscheidet ebenfalls die geschützte Anwendung, nicht allein der Name der Quellzone. MTU, MSS, Latenz und Durchsatz werden dabei über die reale VPN-Strecke geprüft.

VoIP benötigt einen eigenen Funktionstest für SIP-Signalisierung und RTP-Medien samt vorbereiteter Rückkehr zur früheren Policy. Für Management-, Backup- und Infrastrukturnetze sind enge Regeln meist wertvoller als eine besonders breite Signaturauswahl. Auch an internen Segmentgrenzen kann IPS laterale Angriffe erschweren; Spoofing- und Flooding-Grenzwerte bleiben jedoch eine separate Aufgabe der Spoof- und DoS-Einstellungen.

Eine eigene Policy ist sinnvoll, wenn der Datenpfad enger abgegrenzt werden soll, eine einzelne SID eine dokumentierte Ausnahme benötigt oder eine Aktion bewusst von Recommended abweicht. Dafür wird unter Intrusion prevention > IPS policies > Add ein eindeutiger Name wie IPS-Pilot-LAN oder IPS-DNAT-Webserver vergeben und eine geeignete bestehende Policy als Ausgangsbasis geklont. Mit Save zuerst die neue beziehungsweise geklonte Policy speichern; damit ist noch keine neue Policy-Regel angelegt. Danach werden die Regeln in der Kopie angepasst; die mitgelieferten Signaturen selbst lassen sich nicht bearbeiten.

Signaturen filtern und Policy-Regeln anordnen

Beim Hinzufügen einer Regel kann man einzelne Signaturen, eigene Signaturen oder Select all wählen. Der Smart Filter nimmt Suchbegriffe und Kriterien wie Category, Severity, Platform und Target auf; nach der Eingabe wird der Filter mit Enter angewendet.

Der Regeleditor wird getrennt von der Policy-Erstellung geöffnet: Unter Intrusion prevention > IPS policies bei der gewünschten, bereits gespeicherten Policy Edit wählen, dann Add und einen eindeutigen Regelnamen eingeben. Anschliessend die benötigten Signaturen auswählen: Select individual signature für einzelne Signaturen oder Custom signature für eigene Signaturen. Für eine Suche über Smart filter zuerst Select all wählen, den Suchbegriff eingeben und mit Enter anwenden.

Die Kategorien helfen bei der fachlichen Eingrenzung. Die folgende vollständige Zuordnung erklärt die in SFOS sichtbaren Bezeichnungen. Category bleibt eine Nachschlagehilfe, kein Risikourteil; zusammen mit Platform und Target hilft sie im Smart Filter, nur Signaturen für das geschützte System auszuwählen.

Breite Indikatorkategorien gehören zuerst in einen beobachtenden Pilotbetrieb. Insbesondere indicator-compromise kann False Positives erzeugen; die Kategorie allein rechtfertigt daher keine Sperre oder Ausnahme.

Nach der Signaturauswahl die Action bewusst festlegen; die Unterschiede werden im Abschnitt zu Severity und Aktion erklärt. Mit Save im Regeleditor die Regel speichern. Das ist ein anderer Schritt als das erste Speichern der Policy. Beim DDoS-Ablauf wird danach zusätzlich die umschliessende Policy mit Save gespeichert.

Nach dem Speichern wird eine neue Testsitzung gestartet: ips_policy_id oder idp_policy_id und fw_rule_id müssen stimmen; bei einem Treffer werden zusätzlich signature_id, classification und log_subtype mit der vorgesehenen Regel und Aktion verglichen. Das Ausbleiben eines Treffers allein beweist nicht, dass Filter oder Policy angewendet wurden.

Policy-Regeln werden von oben nach unten ausgewertet. Eine breite Regel für alle Server-Signaturen kann daher eine darunterliegende Sonderregel für eine einzelne SID überdecken. Spezifische Ausnahmen oder abweichende Aktionen stehen oberhalb der allgemeineren Regel. Ein anschliessender Treffer muss die erwartete Policy, Rule ID und Aktion zeigen.

Eigene IPS-Signaturen sind für einen klar beschriebenen Erkennungsfall gedacht, nicht als Ersatz für eine unpassende Standardauswahl. Der Ablauf mit Syntax, enger Pilot-Policy sowie Positiv- und Negativtest steht unter Eigene IPS-Signaturen erstellen und testen.

Severity und Aktion getrennt bewerten

Für Logs, Tickets und Ausnahmen sind SID, Category, Severity, Platform, Target und Recommended action wichtig. 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 eine bestimmte Traffic-Art und alarmiert. Severity allein entscheidet nicht über das Risiko: Erreichbarkeit, Zielsystem, Patchstand und effektive Aktion gehören zur Bewertung.

Diese CVSS-Zuordnung ist nicht ausnahmslos: Sophos beschreibt Fälle, deren Severity-Einstufung nicht in die genannten Formeln passt. Daraus lässt sich weder eine dokumentierte WebAdmin-Funktion zum Übersteuern der Severity noch ein Verfahren zur Neueinstufung ableiten; die tatsächlich angezeigte Signatur-Severity prüfen.

Eine Policy-Regel kann die empfohlene Aktion übersteuern:

• Recommended wendet die von Sophos für die jeweilige Signatur empfohlene Aktion an und ist der übliche Ausgangspunkt für produktive Regeln.
• Allow packet protokolliert den Treffer, lässt das Paket aber zu. Das eignet sich für einen Pilot, verhindert den erkannten Angriff jedoch nicht.
• Drop packet verwirft nur das betroffene Paket. Die Anwendung kann weiterlaufen oder mit einem Fehler reagieren.
• Drop session beendet nach einem Treffer die komplette Sitzung.
• Reset beendet eine TCP-Sitzung aktiv mit einem Reset an den Initiator.
• Disable schaltet genau diese Signatur aus; die zugehörige Erkennung entfällt.
• Bypass session prüft die restliche Sitzung nicht mehr. Der Traffic kann dadurch in FastPath oder Offload gelangen und 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. Jede Abweichung von Recommended erhält deshalb eine Begründung mit Signatur, Policy, Firewall-Regel, verantwortlicher Person und Review-Datum.

IPS Policy in der Firewall-Regel auswählen

1. Rules and policies > Firewall rules öffnen.
2. Die Regel bearbeiten, deren Rule ID im Pilotflow nachgewiesen wurde.
3. Unter Other security features bei Detect and prevent exploits (IPS) die ausgewählte IPS Policy setzen.
4. Log firewall traffic aktivieren, speichern und für den Test eine neue Sitzung erzeugen.

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

Firewall-Regeln begrenzen, welcher Traffic überhaupt erlaubt ist. IPS erkennt Angriffsmuster im sichtbaren Datenstrom. Web Protection steuert Webinhalte und Kategorien, Application Control klassifiziert Anwendungen, TLS Inspection macht bei Bedarf verschlüsselte Inhalte sichtbar und Zero-Day Protection untersucht verdächtige Dateien. Threat Feeds, etwa gepflegte Feeds von Cybora, blockieren ergänzend bekannte bösartige IP-Adressen, Domains oder URLs. Diese Module ergänzen einander; keines ersetzt eine enge Firewall-Regel, Patchmanagement oder die korrekte Policy-Auswahl.

Einen kontrollierten Pilotbetrieb abnehmen

Vor dem Start werden Testdauer, verantwortliche Person, Vergleichsbasis und Abbruchkriterien festgelegt. Zur Baseline gehören Pattern-Zeitpunkt, Firewall Rule ID, bisherige und neue IPS Policy, bekannte Ausnahmen, CPU und Speicher sowie mindestens eine unveränderte Kontrollverbindung. Bei VoIP, ERP, industriellen Protokollen, VPN und älteren Anwendungen braucht der Test ein Wartungsfenster.

1. Policy-Zuweisung nachweisen: Eine neue Sitzung erzeugen und in Packet Capture oder Firewalllog die erwartete Firewall Rule ID und IPS Policy ID prüfen. Das beweist die Zuweisung, noch keinen Signaturtreffer. Den gemeinsamen Ablauf für Log Viewer und Packet Capture kann man dafür direkt auf die Testverbindung anwenden.
2. Reale Arbeitsabläufe testen: Anmeldung, Dateiübertragung, Updates, APIs und länger laufende Sitzungen ausführen. Ein Ping ist dafür kein Ersatz.
3. Ereignisse auswerten: Bei einem Treffer Signatur-ID, Signaturname, Policy, Firewall-Regel, Quelle, Ziel, Ports und effektive Aktion sichern. Ein echter Angriff wird nicht eigens zur Funktionsprüfung erzeugt. Für einen deterministischen harmlosen Treffer verwendet man den kontrollierten Custom-Signature-Pilot.
4. Kontrollverbindung vergleichen: Eine erlaubte Verbindung aus demselben Geltungsbereich muss weiterhin die erwartete Regel und Anwendung zeigen. Falls Pakete verschwinden, hilft die separate Auswertung verworfener Pakete bei der Abgrenzung.
5. Erst danach erweitern: Weitere Hosts oder Regeln nur aufnehmen, wenn keine ungeklärten Blocks bestehen und die vorher festgelegten Last-, Latenz- und Anwendungsgrenzen eingehalten werden.

Erfolg bedeutet nicht, dass zwingend eine Angriffssignatur ausgelöst wurde. Entscheidend sind die nachgewiesene Policy-Zuweisung, funktionierende Test- und Kontrollabläufe, keine ungeklärten Sperren und akzeptable Ressourcenwerte. Sobald ein kritischer Geschäftsprozess ausfällt, eine ungeklärte Blockierung auftritt oder eine vereinbarte Performance-Grenze überschritten wird, werden die dokumentierten Ausgangswerte für Policy-Zuweisung und Regel-Logging wiederhergestellt. Eine eigens angelegte Pilot-Policy wird erst gelöscht, wenn sie keiner Regel mehr zugewiesen ist und ihre Ausnahmen dokumentiert wurden. War IPS vor dem Pilot global ausgeschaltet, wird auch dieser Ausgangszustand erst dann wiederhergestellt, nachdem geprüft wurde, welche anderen Firewall-Regeln dadurch ihren IPS-Schutz verlieren.

Logs, Packet Capture und Reports richtig lesen

Die Werkzeuge beantworten unterschiedliche Fragen:

• Firewalllog: ips_policy_id zeigt, welche Policy am Flow hing. Das ist auch ohne Signaturtreffer nützlich.
• IPS-Ereignis: log_type=IDP, signature_id, signature_msg, idp_policy_id, fw_rule_id, classification und log_subtype verbinden Signatur, Policy, Regel und Ergebnis. detection_severity im Log ist nicht automatisch dieselbe Darstellung wie die kategorische Policy-Severity.
• Packet Capture: zeigt unter anderem Firewall Rule ID, NAT ID und IPS Policy ID am Paketfluss.
• ips.log: liefert tiefere Hinweise auf IPS-, DPI-, Application-Control- und Active-Threat-Response-Entscheidungen.
• sig_upgrade.log und sigmigration.log: zeigen Signaturupdate beziehungsweise -migration.
• Reports > Network & threats > Intrusion attacks: eignet sich für die rückblickende Auswertung; Log Viewer bleibt besser für einzelne aktuelle Ereignisse.

Die Zuordnung weiterer Logdateien und Dienste erklärt Sophos Firewall Services und Logs. Wenn mehrere Schutzmodule aktiv sind, wird derselbe Zeitpunkt über Firewall-, IPS-, Web-, Application-Control- und SSL/TLS-Inspection-Logs verglichen. Eine Firewall-Regel kann Traffic erlauben, den ein nachgelagertes Modul anschliessend blockiert.

Performance unter vergleichbarer Last prüfen

IPS benötigt je nach Modell, Traffic, Signaturen, TLS Inspection, Application Control, VPN und Paketgrösse unterschiedlich viele Ressourcen. Vor und nach der Aktivierung werden unter vergleichbarer Last CPU, Speicher, Durchsatz, Latenz, Retransmits kritischer Anwendungen sowie IPS-/DPI- und Syslog-Volumen erfasst.

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

False Positives entscheiden statt nur freischalten

Ein IPS-Treffer kann ein False Positive, eine unerwartete Anwendung oder ein echter Exploit-Versuch sein. Zuerst werden Signatur-ID und -name, Quelle, Ziel, Dienst, Firewall-Regel, Zeitpunkt, Häufigkeit, betroffene Anwendung und Patchstand gesichert. Danach folgt die Entscheidung:

1. Den legitimen Ablauf reproduzieren und bestätigen, dass genau diese SID ihn trifft.
2. Patchstand, Herstellerhinweise und Erreichbarkeit des geschützten Systems prüfen.
3. Das Risiko bewerten, falls der Treffer zugelassen wird. Bei unklarem oder nicht reproduzierbarem Befund entsteht keine dauerhafte Ausnahme.
4. Die engste reversible Massnahme wählen: bevorzugt patchen oder den Datenpfad enger fassen; andernfalls eine einzelne SID in einer nur dort verwendeten Policy zeitlich begrenzt auf Allow packet setzen. Disable oder Bypass session entfernen mehr Schutz und benötigen eine stärkere Begründung.
5. Den legitimen Positivflow und einen Negativ- beziehungsweise Kontrollflow erneut testen.
6. Ausnahme, verantwortliche Person und Review-Datum dokumentieren und nach Applikations-, Pattern-, Firmware- oder Systemupdate neu bewerten.

Stören viele Signaturen dieselbe Anwendung, ist eine eigene enge Policy oder bessere Segmentierung sauberer als eine Sammlung dauerhafter globaler Ausnahmen. IPS global auszuschalten ist kein angemessener Rollback für eine einzelne SID.

Troubleshooting nach Symptom

Keine IPS-Ereignisse sichtbar

Zuerst eine neue Sitzung erzeugen und Firewall Rule ID sowie ips_policy_id im Firewalllog oder Packet Capture prüfen. Fehlt die Policy ID, trifft der Flow eine andere Regel oder der ausgewählten Regel ist keine IPS Policy zugewiesen. Ist die Policy nachweisbar, aber es gibt keinen Signaturtreffer, kann das für harmlosen Traffic korrekt sein. Für einen reproduzierbaren Nachweis dient eine enge Custom Signature in einem isolierten Pilot, kein echter Exploit.

Ereignis vorhanden, aber Traffic wird nicht blockiert

Im IPS-Ereignis signature_id, Policy und log_subtype prüfen. Danach die erste passende Policy-Regel und deren effektive Aktion kontrollieren. Allow packet, Disable oder Bypass session können eine erwartete Sperre verhindern; eine breite obere Regel kann die spezifische Regel überdecken. Nach jeder Änderung wird eine neue Sitzung getestet.

IPS-Signaturen fehlen oder Pattern-Update schlägt fehl

Lizenzstatus, globalen IPS-Schalter und Backup & firmware > Pattern updates gemeinsam prüfen. Failed oder ein frischer Application-Signature-Stand beweisen kein erfolgreiches IPS-Update. sig_upgrade.log zeigt den Updatepfad; bei Lizenzproblemen ergänzt licensing.log den Kontext. In einem HA-Cluster aktualisiert der Primary die IPS-Patterns und synchronisiert sie automatisch zum Auxiliary.

IPS-Service steht auf DEAD

Unter System services > Services den Status des Dienstes IPS prüfen und dokumentieren. Wenn Sophos Support zusätzlich eine node-spezifische Shell-Ausgabe verlangt, führt 5 Device Management > 3 Advanced Shell zu diesem nur lesenden Check:

service -S | grep -i ips

Massgeblich ist die Zeile, deren erster Dienstname exakt ips lautet; ipsec-monitor ist nicht gemeint. Dieser Advanced-Shell-Befehl ist nicht Teil des veröffentlichten Known-Issue-Verfahrens und wird nur für eine abgestimmte Supportdiagnose verwendet. In einem HA-Cluster muss der angeforderte Status auf jedem betroffenen Node separat gesichert werden.

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.

SFOS-Version, Zeitpunkt, Node, Service-Status, ips.log und sig_upgrade.log sichern und Sophos Support mit Verweis auf NC-181971 kontaktieren. Der Status allein beweist diese Ursache nicht. Sophos veröffentlicht in der aktuellen Known-Issues-Liste weiterhin keine behobene Version und stellt den Workaround über den Support bereit. Wiederholte Neustarts oder undokumentierte Reparaturbefehle sind kein sauberer Diagnoseweg.

Vollständiges Signaturpaket nur für belegte Sonderfälle

SFOS kann während eines Pattern-Updates statt eines Teilpakets das vollständige IPS-Signaturpaket herunterladen. Diese Option gilt nur für Appliances mit mindestens 32 GB RAM und kann laut Sophos die Performance beeinflussen. Sie aktiviert IPS nicht und weist keiner Firewall-Regel eine Policy zu.

Ein sinnvoller Anlass ist eine ausdrücklich von Sophos Support benannte Signatur, die im Teilpaket fehlt. Die Option wird nicht vorsorglich aktiviert, nur weil mehr Signaturen besser klingen. Zuerst wird in der Device Console der aktuelle Zustand gelesen:

system ips full-signature-pack show

Die Device-Console-Hilfe nennt keinen Default. Sind RAM-Grenze und konkreter Bedarf bestätigt, lässt sich der vollständige Download aktivieren:

system ips full-signature-pack enable

Nach dem nächsten Pattern-Update werden Pattern-Zeitpunkt, sig_upgrade.log, erwartete Signatur, IPS-Status, CPU, RAM und betroffener Traffic geprüft. Fehlt der erwartete Nutzen oder verschlechtert sich der Betrieb, wird der zuvor gelesene Zustand wiederhergestellt. War er vor dem Test disable, lautet der Rückweg:

system ips full-signature-pack disable

PQC-Erkennung ab SFOS 22.0 MR2

SFOS 22.0 MR2 kann reine und hybride Post-Quantum-Schlüsselaustauschverfahren auf Basis von ML-KEM erkennen und kontrollieren. Die neuen IPS-Patterns sind standardmässig deaktiviert, weil PQC nicht automatisch verdächtig ist. Wer diese Verbindungen auswerten muss, verwendet zuerst eine eigene Pilot-Policy mit Allow packet und Logging. Erst ein definierter Anwendungsfall und ein stabiler Positiv- und Kontrolltest rechtfertigen Drop session oder Reset. Hintergründe erklärt Sophos Firewall v22 MR2: PQC-Kontrolle.

FAQ