Sophos Firewall Inspection auf nicht standardmässigen Ports

Sophos Firewall prüft HTTP, HTTPS, FTP, SMTP/S, POP und IMAP auf ihren Standardports. Verwendet eine Anwendung für eines dieser Protokolle einen abweichenden Port, kann service-param die Protokollprüfung auf diesen Port erweitern.

Der Befehl ist kein allgemeiner Port-Öffner. Er erstellt weder ein Service-Objekt noch eine Firewallregel und aktiviert auch keine Web-, TLS- oder Mail-Policy. Damit Traffic tatsächlich geprüft wird, müssen Regelmatch, erlaubter Zielport und der zuständige Inspection-Pfad zusammenpassen. Für neue Webregeln bleibt ausserdem zuerst zu klären, ob die DPI Engine oder der Web Proxy den Flow verarbeitet.

⚠️ service-param ist eine globale Zuordnung. Ein zusätzlich eingetragener Port betrifft nicht nur einen einzelnen Host oder eine einzelne Firewallregel. Vor der Änderung werden deshalb bestehende Verwendungen des Ports, betroffene Policies und ein ausführbarer Rückweg dokumentiert.

Zuerst den Prüfpfad wählen

Ein zusätzlicher Zielport und die Prüfung dieser Verbindung sind zwei getrennte Entscheidungen. Unter Hosts and services > Services definiert ein TCP-Service-Objekt, welchen Zielport eine Firewallregel erfasst. Beim Anlegen unter Hosts and services > Services > Add bleibt Source port normalerweise auf 1:65535, weil Anwendungen ihren Quellport dynamisch wählen. Das Objekt allein aktiviert aber keine Inhaltsprüfung.

Für Webverkehr ist service-param in SFOS 22 meist nicht der erste Schritt:

• Die DPI Engine erkennt HTTP und SSL/TLS auf allen Ports. Für ein HTTPS-Portal auf TCP 8443 braucht die Firewallregel daher einen passenden Service sowie die gewünschte Web policy und die passenden Scanning-Einstellungen. Soll entschlüsselt werden, muss zusätzlich eine passende Regel unter Rules and policies > SSL/TLS inspection rules matchen. Diese Regeln erkennen TLS auf jedem TCP-Port und prüfen Quelle, Ziel, Benutzer, Service und Website-Kriterien gemeinsam.
• Der Transparent Web Proxy verarbeitet bei aktiviertem Use web proxy instead of DPI engine nur HTTP auf Port 80 und HTTPS auf Port 443. HTTP- und TLS-Traffic auf anderen Ports bleibt bei der DPI Engine. service-param ist deshalb kein Weg, den transparenten Proxy pauschal auf weitere Ports auszudehnen.
• Beim Direct Web Proxy verbindet sich der Client mit dem unter Web > General settings > Web proxy configuration konfigurierten Listener. Dieser explizite Proxy-Pfad funktioniert unabhängig davon, ob Use web proxy instead of DPI engine in einer Firewallregel gewählt ist.

Auch IPS ist ein eigener Pfad. IPS muss unter Intrusion prevention > IPS policies global eingeschaltet sein, ein aktives Network-Protection-Abonnement oder eine Testlizenz muss vorliegen und die gewünschte IPS-Policy muss in der passenden Firewallregel stehen. service-param aktiviert IPS nicht und sagt nichts darüber aus, ob eine Signatur die Verbindung erkannt hat. Dafür werden Firewall Rule ID und IPS-Ereignis im Log Viewer einander zugeordnet.

Damit bleibt service-param vor allem dann ein Kandidat, wenn der von Sophos dokumentierte protokollspezifische Service einen zusätzlichen Port verarbeiten soll, etwa FTP oder ein Mailprotokoll. Für reine Web- oder TLS-Prüfung mit DPI wird stattdessen der Regelpfad korrekt konfiguriert.

Wann service-param passt

Der Befehl passt, wenn eine bekannte Anwendung tatsächlich HTTP, HTTPS, FTP, SMTP, SMTPS, POP oder IMAP auf einem nicht standardmässigen TCP-Port verwendet, nicht bereits die DPI Engine für die Prüfung zuständig ist und genau der zugehörige protokollspezifische Dienst den Traffic verarbeiten soll. Typische Beispiele sind FTP auf TCP 2121 oder eine abgestimmte SMTP-Konfiguration auf TCP 2525.

Ein offener TCP-Port ist noch kein Nachweis für das erwartete Protokoll. Läuft auf 8443 proprietärer Binärtraffic, kann die Zuordnung zu HTTPS Verbindungen stören, statt Schutz hinzuzufügen. Bei Webtraffic wird ausserdem geprüft, ob die DPI Engine das Protokoll bereits erkennt oder ob wirklich ein Proxy-Service-Port ergänzt werden muss. Bei Mailtraffic muss klar sein, ob SMTP mit STARTTLS oder SMTPS mit TLS ab Verbindungsbeginn gemeint ist. Wird Mail Protection im MTA-Modus eingesetzt, folgt der Traffic einem anderen, durch den MTA gerouteten Pfad.

Nicht passend ist service-param, wenn nur eine Firewallregel einen zusätzlichen Zielport erlauben soll. Dafür wird unter Hosts and services > Services ein passendes TCP-Service-Objekt erstellt und in der Firewallregel verwendet. Die Inspection-Zuordnung wird erst ergänzt, wenn der zuständige Proxy- oder Maildienst den abweichenden Port auch verarbeiten muss.

Ausgangszustand in der Device Console sichern

Der Zugriff erfolgt über 4. Device Console. Vor jeder Änderung zeigt der folgende Befehl die vorhandenen Service-Ports und weitere globale Werte:

show service-param

Die vollständige Ausgabe wird mit SFOS-Build, Zeitpunkt und Change-Referenz gesichert. Wichtig ist insbesondere, ob der gewünschte Port bereits einem anderen Dienst zugeordnet ist. Derselbe Port wird nicht auf Verdacht gleichzeitig als HTTP, HTTPS, SMTP oder SMTPS eingetragen.

Sophos dokumentiert für SFOS 22 diese Service-Namen:

FTP
HTTP
HTTPS
IMAP
POP
SMTP
SMTPS
IM_MSN
IM_YAHOO

IM_MSN und IM_YAHOO sind Legacy-Bezeichnungen in der CLI. Sie sind kein Ausgangspunkt für ein neues Instant-Messaging-Design. Neue Anwendungen werden über Firewallregeln, Application Control, TLS Inspection und die tatsächlich unterstützte Protokollerkennung abgesichert.

Einen zusätzlichen Port eintragen

Die dokumentierte Grundsyntax für die unterstützten Dienste lautet:

set service-param <service> add port <portID>
set service-param <service> delete port <portID>

Für eine bestätigte SMTP-Verbindung auf TCP 2525 sieht ein kontrollierter Pilot beispielsweise so aus:

show service-param
set service-param SMTP add port 2525
show service-param

Dieses Beispiel gilt für die transparente Mail-Proxy-Prüfung im Legacy Mode. Zusätzlich braucht die Firewallregel einen Service, der TCP 2525 als Zielport erlaubt; unter Scan email content muss SMTP ausgewählt und eine passende Mail-Policy konfiguriert sein. Vor dem Change muss feststehen, dass auf diesem Port SMTP gesprochen wird und ob STARTTLS verwendet wird. Eine erfolgreiche TCP-Verbindung oder Mailzustellung allein beweist noch keine Inhaltsprüfung. Im MTA Mode wird die automatisch angelegte MTA-Firewallregel nicht für diesen Pilot verändert.

Der Platzhalter portID in der Sophos-Syntax wird in der Device Console mit dem konkreten Portwert verwendet. Ein Port wird erst eingetragen, nachdem ein Packet Capture oder die Anwendungsdokumentation das Protokoll und den Zielport bestätigt hat.

Globale Sonderoptionen nicht mit einem Porttest vermischen

Für HTTPS führt Sophos zusätzlich deny_unknown_proto on|off und invalid-certificate allow|block auf. Für SMTPS ist ebenfalls invalid-certificate allow|block vorhanden. SMTP besitzt weitere globale Optionen für Failure Notifications, Fast ISP Mode, Notification Port und Strict Protocol Check.

Diese Werte lösen eine andere Aufgabe als add port. Sie werden bei einem Portpilot nicht gleichzeitig geändert. Besonders invalid-certificate allow kann Zertifikatsfehler global tolerieren, während deny_unknown_proto und strict-protocol-check die Behandlung nicht erwartungskonformer Verbindungen verändern. Eine erfolgreiche Verbindung nach mehreren gleichzeitigen Änderungen wäre technisch kaum zuzuordnen und könnte die Schutzwirkung unbemerkt reduzieren.

Die offizielle Syntax enthält auch:

set service-param HTTPS deny_unknown_proto <on|off>
set service-param HTTPS invalid-certificate <allow|block>
set service-param SMTPS invalid-certificate <allow|block>
set service-param SMTP failure_notification <on|off>
set service-param SMTP fast-isp-mode <on|off>
set service-param SMTP notification-port add port <portID>
set service-param SMTP strict-protocol-check <on|off>

Vor einer solchen globalen Änderung werden die exakte vorhandene Ausgabe, betroffene Sender oder Webanwendungen, Sicherheitswirkung und Supportvorgabe separat bewertet. Der Artikel verwendet diese Befehle deshalb nicht als empfohlene Standardwerte.

Wirkung mit einem echten Flow prüfen

Der Test beginnt mit genau einer Pilotquelle und einer geloggten Firewallregel. Vor und nach der Änderung werden dieselbe Zieladresse, derselbe Zielport und eine neue Verbindung verwendet. Im Log Viewer müssen Firewall Rule ID, Web- oder Mailaktion und Zeitpunkt zum Pilot passen.

Bei HTTPS werden zusätzlich Zertifikatsaussteller, TLS-Handshake und erwartete Block- beziehungsweise Allow-Aktion geprüft. Wenn Malware-Scanning Teil des Designs ist, folgt ein kontrollierter EICAR-Test über genau diesen Port. EICAR bestätigt dabei nur den normalen Antiviruspfad, nicht jede TLS-, Policy- oder ML-Funktion. Bei SMTP, SMTPS, POP und IMAP wird eine eindeutig erkennbare Testnachricht verwendet und in Mail Logs, Quarantäne und gegebenenfalls Mail Spool verfolgt.

Ein Packet Capture bestätigt, dass der Client wirklich den vorgesehenen Zielport nutzt. Zeigt nur das Firewall-Log Allow, fehlt weiterhin der Beleg, dass der nachgelagerte Proxy oder Maildienst den Inhalt inspiziert hat. Für die gemeinsame Auswertung von Regel, Log Viewer und Capture hilft Sophos Firewall-Regeln kontrolliert testen.

Portzuordnung zurückrollen

Der Rückweg entfernt nur den im Change ergänzten Port vom richtigen Dienst:

set service-param SMTP delete port 2525
show service-param

Danach wird derselbe Testflow neu aufgebaut. Die vorherige Konnektivität muss wieder dem dokumentierten Ausgangszustand entsprechen. Temporäre Firewall-Servicefreigaben, Pilotregeln und Ausnahmen werden separat entfernt; delete port löscht diese Objekte nicht.

Schlägt bereits das Hinzufügen fehl, werden die Fehlermeldung und show service-param gesichert. Daraus wird geklärt, ob der Port bereits als Standardport behandelt oder einem anderen Service zugeordnet ist. Ein vorhandener Eintrag wird nicht blind gelöscht, weil dadurch ein anderer Inspection-Pfad ausfallen kann.

Betriebscheckliste

• Anwendung, Protokoll und echter Zielport sind bestätigt.
• show service-param und der SFOS-Build sind vor der Änderung gesichert.
• Firewall-Service, Regelmatch und Inspection-Zuordnung werden getrennt betrachtet.
• Der Port ist nicht bereits einem widersprüchlichen Dienst zugeordnet.
• Im Pilot wird nur add port geändert, keine globale Zertifikats- oder Protokolloption.
• Positivtest, Negativtest, Inspection-Log und Packet Capture sind vorbereitet.
• Der passende delete port-Befehl und der unveränderte Rückweg stehen bereit.

FAQ