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. Wurde SIP früher mit einem Custom Port geladen, muss dessen exakter Wert zusätzlich aus der vorhandenen Konfigurationsdokumentation gesichert werden. Ist er nicht zuverlässig feststellbar, wird SIP nicht verändert, weil sonst kein zustandserhaltender Rückweg vorbereitet ist.

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.

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 standardmässig geladen, wird es mit dem passenden ... load-Befehl wieder geladen.
• War es zuvor entladen, wird es mit dem passenden ... unload-Befehl wieder entladen.
• 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.

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. 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