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

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 ? geprüft. 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.

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. Danach folgen erneut system system_modules show und derselbe Testflow. 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.

FAQ