Sophos Firewall System Modules sicher verwalten

Sophos Firewall verwendet System Modules als Protocol Helper für Traffic, bei dem die Firewall zusätzliche Protokollinformationen verfolgen oder dynamische Verbindungen berücksichtigen soll. SFOS 22 führt dafür dns, h323, irc, pptp, sip und tftp. Die Module sind standardmässig geladen.

Ein geladenes Modul ist weder eine Firewall-Regel noch eine Empfehlung, das jeweilige Protokoll einzusetzen. Es ersetzt keine passende NAT-Regel, Route oder Security-Policy. Umgekehrt ist das pauschale Entladen aller vermeintlich unbenutzten Helper kein sinnvoller Hardening-Schritt: Die Einstellung wirkt global und kann bestehende Anwendungen unerwartet verändern.

⚠️ Betriebsregel: Zuerst Status und konkreten Fehlerflow dokumentieren. Danach höchstens ein Modul ändern, denselben Flow erneut testen und bei ausbleibender Verbesserung den ursprünglichen Zustand wiederherstellen.

Die sechs Module richtig einordnen

Gerade bei sip und h323 wird der Helper oft vorschnell als Ursache oder Lösung genannt. Der vollständige Ablauf mit NAT, RTP, Timeouts, Custom SIP Port, Packet Capture und echten Testanrufen steht unter VoIP-Probleme mit SIP und RTP beheben.

Ausgangszustand in der Device Console sichern

Die Befehle gehören in 4. Device Console, nicht in die Advanced Shell. Der Zugriff erfolgt per SSH oder im WebAdmin oben rechts über admin > Console. Für SSH muss unter Administration > Device access > Local service ACL der SSH-Zugriff für die benötigte Zone erlaubt sein; für die Web-Konsole muss dort HTTPS erlaubt sein. Den Zugriff nicht breiter freigeben als für die Administrationsquelle nötig.

Vor einer Änderung wird der globale Zustand gelesen:

system system_modules show

Die Ausgabe wird vollständig gesichert, auch wenn nur ein Modul untersucht wird. Damit bleibt sichtbar, ob ein migriertes oder früher angepasstes System vom Default abweicht. Ein angezeigtes loaded beweist nur den Modulzustand, nicht dass der Helper einen bestimmten Flow verarbeitet oder dessen Fehler verursacht. Es beweist auch nicht, dass IRC, SIP oder TFTP ohne eigene Ports oder weitere angepasste Argumente konfiguriert sind. Vor jeder Änderung wird für das betroffene Modul ausdrücklich geklärt und dokumentiert, ob eine bestätigte Default-Konfiguration ohne eigene Ports oder weitere angepasste Argumente vorliegt.

Bei IRC, SIP oder TFTP mit angepassten Argumenten werden vor dem Test die vollständige tatsächlich konfigurierte Baseline und ein auf dem installierten Build bestätigtes, unterstütztes Verfahren zur exakten Wiederherstellung gesichert. Dazu gehört bei SIP der exakte Custom Signalling Port aus der vorhandenen zuverlässigen Konfigurationsdokumentation; bei IRC und TFTP gehören alle tatsächlich konfigurierten Port- und sonstigen Argumentwerte dazu. Syntaxhilfe allein weist die aktuelle Konfiguration nicht nach. Ist die Baseline unklar, fehlen Werte oder ist der zustandserhaltende Rückweg nicht bestätigt, bleibt der betreffende Helper unverändert. Weder Defaultwerte noch Wiederherstellungsbefehle werden geraten.

Zusätzlich werden Source und Destination IP, Port, Protokoll, Rule ID, NAT ID, Uhrzeit und der konkrete Anwendungstest notiert. Ohne reproduzierbaren Flow lässt sich nach einer globalen Änderung nicht unterscheiden, ob sie geholfen oder nur zufällig zeitgleich gewirkt hat. Für die technische Abnahme eignen sich Log Viewer, Policy Test und Packet Capture.

Genau ein Modul laden oder entladen

Die Basisbefehle folgen demselben Muster. Die Tabelle ist eine Referenz, kein Befehlsblock zum vollständigen Ausführen. Der einfache Wechsel mit diesen Befehlen und der inverse Rückweg sind nur für eine vorab bestätigte Default-Baseline ohne eigene Ports oder weitere angepasste Argumente vorgesehen. Für angepasstes IRC, SIP oder TFTP gilt stattdessen ausschliesslich das vor dem Test gesicherte und für den installierten Build bestätigte Änderungs- und Wiederherstellungsverfahren; ohne dieses wird kein Test begonnen.

Vor der Ausführung wird die Syntax auf dem installierten Build mit der eingebauten Hilfe geprüft: Den vorgesehenen Befehl eingeben und mit ? die unterstützten Argumente anzeigen lassen. Keine unvollständigen Varianten auf Verdacht absenden; Sophos warnt, dass ein unvollständiger Device-Console-Befehl den access_server-Daemon blockieren kann. Nach genau einer Änderung folgt erneut system system_modules show. Danach wird derselbe zuvor dokumentierte Anwendungspfad getestet. Paralleländerungen an NAT, Firewall-Regeln, Routing, Timeouts oder PBX erschweren die Zuordnung und werden deshalb vermieden.

Sophos dokumentiert für SIP ausdrücklich, dass load und unload einen Neustart überstehen. Für die anderen Module macht die SFOS-22-Seite keine gleich genaue Persistenzaussage. Nach einem geplanten Neustart wird ihr Zustand deshalb erneut gelesen, statt die Persistenz anzunehmen.

Custom Ports nicht aus unvollständiger Kurzsyntax ableiten

Die System-Modules-Seite nennt für IRC, SIP und TFTP zusätzliche Angaben wie port, portname, default oder show, erklärt deren genaue Eingabeform aber nicht vollständig. Solche Werte werden nicht geraten. Die Device Console zeigt mit ? die Syntax des installierten Builds.

Für SIP veröffentlicht Sophos separat den genauen Custom-Port-Befehl system system_modules sip load ports <custom_port>. Die Entscheidung dafür gehört in die VoIP-Analyse und nicht in einen allgemeinen Helper-Test. Der Platzhalter wird durch genau den Signalisierungsport ersetzt, den Provider oder PBX tatsächlich verwenden.

SIP-Grenzen vor dem Test kennen

Der SIP-Helper verwendet standardmässig UDP-Port 5060. Er übersetzt lokale IP-Adressen im SIP-Header in öffentliche Adressen und legt eine erwartete dynamische Sprachverbindung in der Firewall an. Das erklärt, warum seine Wirkung über das reine Erkennen von Signalisierung hinausgeht.

Zwei Grenzen sind bei der Fehleranalyse entscheidend:

• Der Helper unterstützt SIP-Medienports nur im Bereich 1024–65535. Liegt ein konfigurierter Medienport ausserhalb dieses Bereichs, verwirft die Firewall die Pakete; im Event Log erscheint Invalid Traffic.
• Der Helper unterstützt keine SIP- oder SDP-Nachricht, die sich über mehr als ein Paket erstreckt. Das kann bei SIP über TCP auftreten. Sophos nennt eine SIP-UDP-Control-Connection als Workaround; sie kommt nur infrage, wenn Provider, PBX oder SBC sie unterstützen.

Ein Custom Signalling Port und der RTP-Medienbereich sind verschiedene Werte. <custom_port> im Ladebefehl ist der tatsächlich verwendete SIP-Signalisierungsport; daraus wird kein RTP-Bereich abgeleitet.

Wirkung und Rückweg prüfen

Ein sinnvoller Test prüft mehr als die CLI-Ausgabe. Nach dem Laden oder Entladen werden der konkrete Verbindungsaufbau, Datenfluss in beide Richtungen, Rule und NAT ID, Drops sowie die betroffene Anwendung kontrolliert. Bei SIP oder H.323 gehören Registrierung, ein- und ausgehende Verbindung und Medienfluss in beide Richtungen dazu. Bei DNS werden Abfrage und Antwort samt erwartetem Namen geprüft; bei TFTP nicht nur der Start, sondern auch die Dateiübertragung.

Bleibt das Fehlerbild unverändert oder entstehen neue Störungen, wird nur das geänderte Modul auf den vorher dokumentierten Zustand zurückgesetzt:

• War es zuvor geladen und ist die Default-Baseline ohne eigene Ports oder weitere angepasste Argumente bestätigt, wird es mit dem passenden ... load-Befehl wieder geladen.
• War es zuvor entladen und ist die Default-Baseline ohne eigene Ports oder weitere angepasste Argumente bestätigt, wird es mit dem passenden ... unload-Befehl wieder entladen. Der Status allein genügt auch hier nicht als Nachweis für fehlende angepasste Argumente.
• War SIP zuvor auf einem eigenen Signalisierungsport geladen, wird exakt dieser gesicherte Wert mit system system_modules sip load ports <previous_custom_port> wiederhergestellt. <previous_custom_port> wird durch den Wert aus der Baseline ersetzt, nicht durch einen neuen Beispielwert. Auch dieser Rückweg muss vor dem Test auf dem installierten Build bestätigt sein und die vollständige gesicherte Konfiguration wiederherstellen.
• Bei IRC oder TFTP mit eigenen Ports oder weiteren angepassten Argumenten wird die vollständige gesicherte Baseline ausschliesslich mit dem zuvor für den installierten Build bestätigten, unterstützten Wiederherstellungsverfahren zurückgesetzt, nicht durch einen einfachen inversen Lade- oder Entladebefehl. Fehlt dieses Verfahren, bleibt der Helper von Anfang an unverändert.

Danach folgen erneut system system_modules show und derselbe Testflow. Die CLI-Ausgabe muss wieder dem gesicherten Ausgangszustand entsprechen, und der ursprüngliche Anwendungspfad darf durch den Test nicht zusätzlich gestört sein. Bei angepasstem IRC, SIP oder TFTP wird ausserdem die vollständige konfigurierte Baseline einschliesslich aller gesicherten Argumentwerte mit dem vorab bestätigten Prüfverfahren verglichen; ein passender Modulstatus allein beweist deren Wiederherstellung nicht. Ein Neustart ist kein Ersatz für diesen Rollback.

Wenn sich das Verhalten zwar ändert, die Ursache aber unklar bleibt, werden Status vor und nach der Änderung, Firmwarebuild, Logs und Packet Capture gesichert. Ein global entladener Helper sollte nicht als dauerhafte Lösung stehen bleiben, nur weil ein einzelner kurzer Test besser aussieht.

Bei SIP grenzt das Fehlerbild den nächsten Check ein: Invalid Traffic bei fehlenden Medien führt zuerst zum konfigurierten Medienport und zum Bereich 1024–65535. Bleibt die Registrierung über TCP oder brechen lange SIP-/SDP-Nachrichten ab, wird die Mehrpaket-Grenze geprüft. Ändert sich trotz korrekt angezeigtem Modulstatus nichts, werden zuerst der tatsächlich verwendete Signalisierungsport und der betroffene Rule-/NAT-Pfad bestätigt.

FAQ