Sophos Firewall Advanced Firewall Settings sicher prüfen

Die Advanced Firewall Settings der Sophos Firewall sind keine Sammlung harmloser Komfortoptionen. Viele Werte wirken global auf Paketprüfung, Verbindungszustand oder Timeouts. Eine Änderung kann deshalb gleichzeitig mehrere Firewall-Regeln, VPNs, Anwendungen und Benutzerpfade beeinflussen.

Der sichere Einstieg ist immer lesend: show advanced-firewall zeigt den aktuellen Zustand. Erst wenn ein reproduzierbares Fehlerbild zu genau einem Parameter passt, wird eine einzelne Einstellung in einem Wartungsfenster geändert. Der alte Wert, ein Gegenvergleich und der Rückweg gehören bereits vor dem set-Befehl in die Dokumentation.

⚠️ Advanced Firewall Settings nicht nach einer Tuning-Liste übernehmen. Die dokumentierten Standardwerte passen für die meisten Umgebungen. Globale Schutzfunktionen wie strict-policy oder tcp-seq-checking werden nicht auf Verdacht deaktiviert, und Timeouts werden nicht ohne gemessenen Anwendungsbedarf erhöht.

Sicherer Kurzweg

1. In Log Viewer, Packet Capture und der betroffenen Anwendung das genaue Symptom mit Zeitstempel, Quelle, Ziel, Dienst und Richtung erfassen.
2. Über die Device Console den aktuellen Zustand mit show advanced-firewall sichern.
3. Prüfen, ob bereits ein spezieller Artikel für den Parameter existiert und ob Firewall-Regel, NAT, Routing, MTU oder Gegenstelle die wahrscheinlichere Ursache sind.
4. Nur einen globalen Wert ändern und den vorherigen Wert als fertigen Rollback-Befehl bereithalten.
5. Den betroffenen Flow und mindestens einen unbeteiligten Kontrollflow erneut testen.
6. Hilft die Änderung nicht eindeutig oder entstehen neue Symptome, sofort auf den dokumentierten Ausgangswert zurückstellen.

Eine grüne Verbindung oder ein einzelner erfolgreicher Ping reicht nicht als Abnahme. Je nach Änderung müssen zusätzlich Rule ID, NAT Rule ID, TCP- oder UDP-Verhalten, Paketfluss, Applikationsfunktion und Gegenrichtung stimmen. Der Ablauf für diese Prüfung steht in Sophos Firewall-Regel sauber testen.

Zustand lesen und Wirkung verstehen

Die Befehle werden in der Device Console ausgeführt, nicht in der Advanced Shell. Nach dem SSH-Login wird dafür im Konsolenmenü 4. Device Console gewählt. Zugriff, Host-Key-Prüfung und eine enge Managementfreigabe erklärt Sophos Firewall CLI Troubleshooting.

show advanced-firewall

Die Ausgabe ist eine Baseline, kein Gesundheitscheck. Ein Wert kann korrekt angezeigt werden und trotzdem unpassend zur Anwendung sein. Umgekehrt beweist ein vom Standard abweichender Wert noch keinen Fehler. Wichtig ist, wann und warum er gesetzt wurde und welches messbare Verhalten sich dadurch ändert.

Global statt pro Firewall-Regel

set advanced-firewall ändert keine einzelne Firewall-Regel. Die Parameter liegen unterhalb oder neben der normalen Policy-Auswertung. Ein global höherer UDP-Timeout gilt daher nicht nur für eine VoIP-Regel. Ebenso beschränkt tcp-seq-checking off die Lockerung nicht auf einen Server.

Vor jeder Änderung werden deshalb diese vier Punkte festgehalten: der aktuelle Wert, der konkrete Testflow, die erwartete Wirkung und der Befehl zum Wiederherstellen. Gibt es keinen engen Positiv- und Negativtest, ist die Änderung noch nicht bereit für den produktiven Einsatz.

Zugriff und Paketprüfung absichern

WebAdmin aus dem WAN global sperren

restrict-admin-console-wan-access ist ein grober globaler Schutzschalter. Mit enable wird WebAdmin aus allen WAN-Quellen abgeschaltet; Sophos dokumentiert enable als Standard. Das scheinbar umgekehrte Wording ist wichtig: enable aktiviert die Einschränkung, nicht den WAN-Zugriff.

set advanced-firewall restrict-admin-console-wan-access enable

Für eine einzelne feste Adminquelle wird dieser Schutz nicht einfach mit disable geöffnet. Zuerst wird geprüft, ob ein Management-VPN, Sophos Central oder eine enge Local Service ACL Exception genügt. Die sichere Planung steht in Device Access und Local Service ACL.

ICMP, Fragmente und IPv6-Erweiterungen

icmp-error-message steuert ICMP-Fehlermeldungen wie Network, Host oder Port Unreachable. Der dokumentierte Standard ist allow. Ein pauschales deny kann wichtige Fehler- und Path-MTU-Signale ausblenden und damit die Diagnose erschweren.

fragmented-traffic erlaubt oder verweigert fragmentierten IP-Traffic; Standard ist allow. Fragmentierung ist nicht automatisch ein Angriff. Vor einem globalen deny müssen MTU, PMTUD, VPN-Overhead, Protokoll und tatsächlicher Paketfluss geklärt sein.

ipv6-unknown-extension-header behandelt IPv6-Pakete mit unbekannten Extension Headers. Sophos dokumentiert deny als Standard. Eine Lockerung braucht einen nachgewiesenen legitimen Anwendungsfall und einen IPv6-Packet-Capture, nicht nur einen allgemeinen Erreichbarkeitsfehler.

ipv6-ready-logo-compliance ist standardmässig off. Mit on passt die Firewall ihr Verhalten für das formale IPv6 Ready Logo Testprogramm an. Das ist weder der Schalter zum Aktivieren von IPv6 noch ein allgemeiner IPv6-Workaround. Grundlagen und Abnahme eines produktiven IPv6-Pfads stehen in IPv6-Unterstützung auf Sophos Firewall.

strict-policy ist standardmässig on und verwirft bestimmte ungewöhnliche Pakete sowie IP-basierte Angriffe. Für das konkrete Fehlerbild Invalid TCP reserved bit gibt es den eng begrenzten Ablauf Accurate ECN und Strict Policy prüfen. Ohne diesen oder einen gleichwertigen Nachweis bleibt die Funktion aktiv.

ftpbounce-prevention schützt vor FTP-Bounce-Angriffen, bei denen ein PORT-Befehl eine fremde Drittadresse enthält. Der Parameter unterscheidet die Prüfung auf der Control- oder Data-Verbindung; Sophos dokumentiert control als Standard. Eine Änderung auf data wird nur mit einem klaren FTP-Kompatibilitätsfall, enger Regel und protokolliertem Dateiübertragungstest bewertet.

TCP-Verhalten gezielt prüfen

Sophos aktiviert Selective Acknowledgement mit tcp-selective-acknowledgement on standardmässig. SACK lässt den Empfänger konkrete fehlende Segmente melden, sodass nicht das gesamte TCP-Fenster erneut übertragen werden muss. tcp-window-scaling on ist ebenfalls Standard und erlaubt Fenster über 64 KB. Beide Funktionen helfen besonders auf Pfaden mit hoher Bandbreite oder Latenz; ein Abschalten ist kein allgemeiner Stabilitätsfix.

tcp-frto und tcp-timestamp stehen standardmässig auf off. F-RTO verbessert die senderseitige Erholung nach Retransmission Timeouts, insbesondere wenn Verlust eher durch Funkstörungen als durch Überlast entsteht. TCP Timestamps ermöglichen eine genauere Round-Trip-Messung. Beide Optionen werden nur mit einem reproduzierbaren TCP-Test und Gegenvergleich aktiviert, nicht gemeinsam als pauschales Performance-Tuning.

Sequenzprüfung und Midstream-Verbindungen

Mit tcp-seq-checking on kontrolliert die Firewall standardmässig, ob Sequence und Acknowledgement Numbers zum bekannten TCP-Zustand passen. Einzelne nicht RFC-konforme Anwendungen können ungültige Sequenznummern senden. off lockert diese Prüfung jedoch global. Vorher müssen Packet Capture, Drop-Grund und Gegenstelle den Verdacht stützen.

midstream-connection-pickup ist standardmässig off. Mit on kann die Firewall bereits laufende, noch nicht verfolgte TCP-Verbindungen übernehmen. Sophos nennt dafür etwa die Einführung einer Bridge in ein Live-Netz oder spezielle asymmetrische Designs. Die Option ersetzt weder symmetrisches Routing noch saubere Firewall-Regeln und wird nach einer Migration nicht unbegründet aktiv gelassen.

Idle Timeout für etablierte TCP-Verbindungen

tcp-est-idle-timeout bestimmt, wie lange eine etablierte, aber inaktive TCP-Verbindung im Zustand bleibt. Der zulässige Bereich liegt zwischen 2700 und 432000 Sekunden.

Eine längere Lebensdauer kann bei einer Anwendung mit langen echten Ruhephasen helfen, erhöht aber gleichzeitig die Zahl alter Zustände und löst keine Timeouts auf Server, Load Balancer, NAT-Gateway oder Client. Vor einer Anpassung werden deshalb beide Endpunkte, Keepalives und der Zeitpunkt des Abbruchs verglichen. Der vorherige Zahlenwert wird anschliessend explizit wieder gesetzt, falls der Test keinen klaren Nutzen zeigt.

UDP-Zustände passend zur Anwendung dimensionieren

UDP besitzt keinen TCP-Handshake. Sophos unterscheidet deshalb zwei globale Zeitwerte. udp-timeout gilt für UDP-Verbindungen, die noch nicht als Stream erkannt wurden. udp-timeout-stream gilt, sobald beide Endpunkte über denselben Port zwischen Netzwerksegmenten Traffic gesendet haben. Beide Werte unterstützen 30 bis 3600 Sekunden.

set advanced-firewall udp-timeout <30-3600>
set advanced-firewall udp-timeout-stream <30-3600>

Ein hoher Wert ist nicht automatisch besser. Er hält Zustände länger, kann aber veraltete Sessions und mehr Zustände erzeugen. Bei VoIP, SIP oder RTP werden deshalb Signalisierung, Medienports, beide Richtungen und der genaue Zeitpunkt des Audioabbruchs gemeinsam geprüft. Der spezialisierte Ablauf steht in VoIP auf Sophos Firewall optimieren und prüfen.

Bypass und System-Traffic-NAT nicht verwechseln

Stateful Firewall nur im belegten Sonderfall umgehen

bypass-stateful-firewall-config nimmt Hosts oder Netze aus dem normalen Stateful-Firewall-Pfad. Für einen vollständigen ausgehenden Verbindungsweg verlangt Sophos Einträge für beide Richtungen. Die Anzahl möglicher Einträge ist nicht begrenzt, doch genau dadurch kann eine alte Bypass-Liste schnell unübersichtlich und sicherheitskritisch werden.

Eine Bypass-Regel ist keine schnelle Allow-Regel und kein normaler Performance-Schalter. Sie kann Policy-Auswertung, Logging und Security-Funktionen umgehen. Syntax, bidirektionaler Test und Rückbau erklärt Sophos Firewall Bypass-Regel sicher verwenden.

NAT für von der Firewall erzeugten Traffic

sys-traffic-nat ändert die Source-Adresse von Traffic, den die Firewall selbst erzeugt, für ein bestimmtes Ziel. destination und snatip sind Pflichtangaben; interface und netmask grenzen den Eintrag bei Bedarf weiter ein.

Das ist kein Ersatz für eine normale SNAT- oder MASQ-Regel für weitergeleiteten Clienttraffic. Es erstellt auch keine Route. Typische Spezialfälle und sichere Rücknahme sind in Interface Alias für System-Traffic, SD-WAN Routing für Reply Packets und System-Traffic und IPsec Route und System-Traffic getrennt beschrieben.

Änderung abnehmen und zurückrollen

Vorher und nachher wird show advanced-firewall gespeichert. Danach folgt genau derselbe kontrollierte Test mit gleicher Quelle, gleichem Ziel, Dienst, Richtung und möglichst vergleichbarer Last. Nur wenn das erwartete Symptom verschwindet und ein unbeteiligter Kontrollflow unverändert bleibt, stützt das Ergebnis die Änderung.

Der Rollback verwendet denselben Parameter mit dem zuvor dokumentierten Wert. Bei einem Zahlenwert wird nicht ein vermuteter Standard, sondern der tatsächlich gesicherte Ausgangswert gesetzt. Bei on, off, allow, deny, enable oder disable wird ebenfalls der abgelesene Zustand wiederhergestellt.

Wenn die Änderung nicht hilft

• Kein Unterschied im betroffenen Flow: Ausgangswert wiederherstellen und Regel, NAT, Route, Gegenstelle oder Applikation prüfen.
• Nur neue Sessions reagieren anders: Alte Verbindungen kontrolliert beenden oder einen frischen Testflow verwenden; bestehende States können die Bewertung verfälschen.
• Andere Anwendungen werden instabil: Sofort zurückrollen. Das ist ein Hinweis auf die globale Wirkung, nicht auf Bedarf für weitere Advanced-Firewall-Änderungen.
• HA-Cluster: Zustand und Test auf dem verarbeitenden Node dokumentieren und nach geplantem Failover mit einer neuen Verbindung erneut prüfen. Keine unterbrechungsfreie Übernahme eines geänderten Verbindungszustands voraussetzen.

Betriebscheckliste

• Ausgangsausgabe von show advanced-firewall, Zeit, Build und verantwortliche Person dokumentiert.
• Ein einzelner Parameter mit konkretem Fehlerbild und erwarteter Wirkung ausgewählt.
• Globaler Sicherheits- und Performance-Effekt bewertet.
• Rückweg mit dem tatsächlich vorhandenen Vorher-Wert vorbereitet.
• Betroffener Flow, Gegenrichtung und unbeteiligter Kontrollflow getestet.
• Bypass- und sys-traffic-nat-Einträge separat inventarisiert.
• Nach dem Test erneut show advanced-firewall gesichert und unnötige Änderung zurückgenommen.

FAQ