Sophos Firewall ausgehende Dienste und Ports prüfen
Sophos Firewall baut selbst Verbindungen zu Sophos und einigen externen Plattformdiensten auf. Darüber lädt sie Firmware und Patterns, synchronisiert Lizenzen, verbindet RED-Geräte, sendet Reports an Sophos Central oder öffnet einen Supportzugang. Steht vor der Firewall ein weiterer Router, Proxy oder Egress-Filter, können einzelne Funktionen ausfallen, obwohl normaler Client-Traffic weiterhin funktioniert.
Die wichtigste Abgrenzung lautet: Hier geht es um von der Firewall selbst erzeugten Systemtraffic. Eine zusätzliche breite LAN-to-WAN-Regel auf der Sophos Firewall behebt keinen vorgeschalteten Filter. Benötigt wird eine gezielte ausgehende Freigabe im tatsächlich blockierenden Upstream-System.
⚠️ Die Zielnamen sind eine veränderliche Herstellerliste. Die folgende Übersicht entspricht der öffentlichen SFOS-22-Dokumentation vom 21. August 2026. Vor einer produktiven Allowlist muss die aktuelle Sophos-Seite Default services erneut geprüft werden. Feste IP-Adressen aus einem einzelnen DNS-Lookup sind kein dauerhafter Ersatz für die dokumentierten FQDNs und Wildcards.
Schnell prüfen, wenn ein Sophos-Dienst nicht funktioniert
- Betroffene Funktion, Fehlerzeitpunkt und aktuellen SFOS-Build festhalten.
- Prüfen, ob die Firewall den dokumentierten Zielnamen per DNS auflöst und die Systemzeit sowie NTP-Synchronisation stimmen.
- Auf dem vorgeschalteten Router oder Egress-Filter nach einem Block für die Firewall-WAN-Adresse, den Ziel-FQDN und den benötigten Port suchen.
- Nur die fehlende Funktionsgruppe freigeben, nicht pauschal
*.sophos.com,Anyund alle Ports. - Genau einen neuen Test auslösen und Packet Capture, Upstream-Log und passenden SFOS-Service-Log zeitlich vergleichen.
Eine erfolgreiche DNS-Auflösung beweist nur, dass ein Zielname aufgelöst werden kann. Ein erfolgreiches TCP-Handshake beweist noch nicht, dass Lizenzierung, Update, Upload oder RED-Provisionierung vollständig funktioniert. Die jeweilige Funktion muss nach der Netzfreigabe nochmals positiv geprüft werden.
Welche Ziele und Ports SFOS 22 benötigt
Die Tabelle fasst die wichtigsten Gruppen zusammen. Bei regionalen Sophos-Central-Diensten wird nur die tatsächlich verwendete Region freigegeben. Ein Unternehmen in der Region Frankfurt benötigt beispielsweise nicht automatisch alle S3-Ziele aus Oregon, Mumbai, Sydney und Tokio.
| Funktion | Dokumentierte Ziele | Ports | Typisches Fehlerbild |
|---|---|---|---|
| Web-Kategorisierung und IP-Reputation | 4.sophosxl.net | TCP 443 | Kategorien oder Reputation werden nicht aktuell bewertet. |
| Firmware-, Pattern- und Client-Updates | *.u2d.sophos.com, *.sophosupd.com, xg-up2date-patterns.sophosupd.com, xg-up2date-firmwares.sophosupd.com | TCP 443 | Firmware oder Patterns bleiben bei Prüfung oder Download stehen. |
| Zusätzlicher Antivirus-Scanner kleiner Appliances | oem.avdl.ctmail.com | TCP 80 | Zusätzliche AV-Updates schlagen fehl. |
| Lizenzierung | *.soa.sophos.com | TCP 443 | Aktivierung oder Lizenzsynchronisation schlägt fehl. |
| RED-Provisionierung | *.astaro.com | TCP 3400, UDP 3410 | RED-Gerät registriert sich nicht oder baut keinen Tunnel auf. |
| Security Heartbeat und Sophos Central | utm.cloud.sophos.com, utm.cloud.sophos.com/api/utm, die von Sophos dokumentierten regionalen *.upe.p.hmr.sophos.com-Hosts und für Central Firewall Management *.sophos.com | TCP 80, 443, für Firewall Management zusätzlich TCP 22 | Registrierung, Heartbeat, Synchronized Application Control oder Central-Verwaltung bleibt offline. |
| Central Firewall Reporting | regionaler tf-presigned-url-...-prod-firewall-bucket.s3.<region>.amazonaws.com-Host | TCP 443 | Logs und Reports erscheinen nicht in Central. |
| Central Firewall Backup | regionaler <region>-firewall-backup.s3.<region>.amazonaws.com-Host; für UAE dokumentiert Sophos *.s3.me-central-1.amazonaws.com | TCP 443 | Central-Backup oder Restore erreicht den Speicher nicht. |
| Zero-Day Protection | *.sandbox.sophos.com | TCP 443 | Dateien werden nicht an die Sandbox übertragen oder Ergebnisse fehlen. |
| Support Access | *.apu.sophos.com | TCP 22 | Der ausgehende Supporttunnel lässt sich nicht aufbauen. |
| NTP | pool.ntp.org | UDP 123 | Zeit driftet; Zertifikate, MFA, Kerberos oder Logs wirken inkonsistent. |
| SAR, Telemetrie und DDNS-Prüfung | sarreport.sophos.com, sftelemetry.sophos.com, checkip.cyberoam.com | TCP 443; DDNS-Prüfung TCP 80 | Security Audit Report, Telemetrie oder Ermittlung der öffentlichen IP funktioniert nicht. |
| ZTNA | *.prod.ztna.access.sophos.com, *.prod.hydra.sophos.com, *.dev.hydra.sophos.com | TCP 443 | ZTNA-Datenpfad oder Verbindung zu Sophos Central fällt aus. |
Sophos führt zusätzlich einzelne konkrete Heartbeat- und Central-Hosts auf. Diese Werte können sich durch Region, Plattformbetrieb oder Herstelleränderungen verschieben. Deshalb wird die Tabelle nicht in eine statische IP-Liste übersetzt.
Egress-Allowlist sicher bauen
Die Freigabe wird am Gerät erstellt, das den ausgehenden Systemtraffic tatsächlich filtert. Das kann eine vorgelagerte Firewall, ein Provider-Router oder eine Cloud-Network-Firewall sein. Auf diesem System sollte als Quelle nur die öffentliche beziehungsweise übersetzte Adresse der Sophos Firewall gelten. Als Ziele dienen die benötigten FQDNs und als Dienste nur die dokumentierten TCP- oder UDP-Ports.
Wildcards und dynamische IP-Adressen richtig behandeln
Viele Sophos-Dienste verwenden CDNs, Cloud-Plattformen oder regional verteilte Hosts. Die IP-Adressen hinter einem FQDN können wechseln. Ein einmaliger nslookup, anschliessend fest eingetragene IPs und eine jahrelang unveränderte Allowlist sind deshalb nicht belastbar.
Unterstützt der vorgeschaltete Filter FQDN- oder URL-basierte Regeln, werden die von Sophos dokumentierten Namen dort gepflegt. Kann das Gerät nur IP-Adressen filtern, braucht es einen dokumentierten Prozess zur regelmässigen Auflösung und Aktualisierung. Eine pauschale Freigabe sämtlicher AWS- oder Sophos-Netze ist kein gleichwertiger Ersatz und vergrössert die erlaubte Angriffsfläche unnötig.
Bei *.sophos.com ist besonders sorgfältig zu arbeiten: Sophos nennt diesen breiten Wildcard ausdrücklich für Central Firewall Management. Er sollte nicht automatisch auf andere Funktionen oder zusätzliche Ports übertragen werden. Für RED, Updates, Sandbox, Lizenzierung und Supportzugang stehen engere Zielmuster zur Verfügung.
Keine eingehende WAN-Regel erstellen
Die beschriebenen Verbindungen beginnen auf der Firewall und gehen nach aussen. Dafür wird keine eingehende DNAT- oder WAN-to-Local-Regel angelegt. Auch eine breite Ausnahme von TLS Inspection, IPS oder Web Filtering sollte nicht auf Verdacht entstehen. Zuerst werden DNS, Route, Upstream-Block und der konkrete Dienst geprüft.
Beim Supportzugang ist die Richtung besonders leicht misszuverstehen: Die Firewall verbindet sich ausgehend über TCP 22 zu *.apu.sophos.com. Der sichere Ablauf zum Aktivieren und zeitlichen Begrenzen steht unter Sophos Firewall Support Access einrichten.
Fehler systematisch eingrenzen
DNS, Route und Port getrennt prüfen
In der Device Console kann ein dokumentierter Zielname zunächst lesend geprüft werden:
dnslookup host xg-up2date-firmwares.sophosupd.com
Danach zeigt ein enger Packet Capture, ob die Firewall eine Verbindung zur aufgelösten Adresse startet, über welches WAN-Interface sie geht und ob Antworten zurückkommen. Der Capture wird auf die konkrete Ziel-IP und den Port begrenzt. Parallel wird im Upstream-System nach demselben Zeitfenster, derselben Source und Destination gesucht.
Die Interpretation bleibt schichtweise:
- Keine DNS-Antwort: DNS-Server, Route zum Resolver und Systemzeit prüfen.
- SYN verlässt die Firewall, keine Antwort kommt zurück: Upstream-Freigabe, Providerpfad, NAT und Rückweg prüfen.
- TCP oder UDP funktioniert, die Funktion bleibt fehlerhaft: passenden Service-Log und Produktstatus prüfen; die Netzverbindung allein ist nicht der vollständige Funktionsnachweis.
- Nur ein HA-Node zeigt den Fehler: Logs und Capture auf dem Node prüfen, der die Verbindung zum Fehlerzeitpunkt verarbeitet hat.
Passenden SFOS-Service-Log verwenden
Für Updates sind u2d.log und up2date_av.log gute Einstiege, für Lizenzierung licensing.log, für RED red.log, für Sandbox sandboxd.log und für Sophos Central unter anderem centralmanagement.log, sophos-central.log sowie die fwcm-*.log-Dateien. Bei NTP passt ntpclient.log. Die vollständige Zuordnung und der sichere Export stehen unter Sophos Firewall Service-Logs finden und einordnen.
Bei HA liegen Service-Logs auf dem Node, der die betreffende Verbindung verarbeitet hat. Ein erfolgreicher Test auf dem aktuellen Primary beweist nicht rückwirkend, dass der andere Node zum Fehlerzeitpunkt dieselbe Verbindung hatte. Zeit, Node, Zielname, aufgelöste IP und Port gehören deshalb gemeinsam in die Fehlernotiz.
Änderung abnehmen und betreiben
Nach einer neuen Egress-Freigabe wird nicht nur der Porttest wiederholt. Die eigentliche Funktion muss einen sichtbaren Erfolg liefern: ein Pattern zeigt einen neuen Status, die Lizenz synchronisiert, RED verbindet sich, Central erhält die Aufgabe, ein Report erscheint oder Support Access zeigt eine aktive Sitzung.
Danach sollte die Upstream-Regel geloggt und nach einigen Tagen geprüft werden. Nicht verwendete Regionen, alte Zielnamen und temporär breite Testfreigaben werden entfernt. Bei Firmware-Upgrades oder neuen Sophos-Funktionen wird die aktuelle Default-services-Liste erneut verglichen, bevor ein Fehler erst im Wartungsfenster auffällt.
Erfolgskriterium: DNS-Auflösung, ausgehender Verbindungsaufbau, passende Upstream-Allowlist und der fachliche Funktionstest sind gemeinsam erfolgreich. Fehlt eine dieser Ebenen, ist die Störung noch nicht sauber behoben.