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 Fusion (ehemals 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.

⚠️ Kontrollierter Avanet-Arbeitsstand: Die folgende Übersicht ist der interne Snapshot vom 4. September 2026 für SFOS 22. Er ist die Ausgangsbasis für Planung und Abnahme; Zielnamen können sich später ändern. Feste IP-Adressen aus einem einzelnen DNS-Lookup sind kein dauerhafter Ersatz für FQDNs und Wildcards. Der verantwortliche Firewall-Owner führt den unten beschriebenen Abgleich durch, bevor er den Snapshot ändert.

Schnell prüfen, wenn ein Sophos-Dienst nicht funktioniert

1. Betroffene Funktion, Fehlerzeitpunkt und aktuellen SFOS-Build festhalten.
2. Prüfen, ob die Firewall den Zielnamen aus dem Snapshot per DNS auflöst und die Systemzeit sowie NTP-Synchronisation stimmen.
3. 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.
4. Nur die fehlende Funktionsgruppe freigeben, nicht pauschal *.sophos.com, Any und alle Ports.
5. 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 ist der freigegebene Snapshot für die erste Planung. Ausgewählt werden nur Funktionsgruppen, die auf der konkreten Firewall aktiviert oder für einen terminierten Rollout vorgesehen sind. Bei regionalen Sophos-Fusion-Diensten wird nur die tatsächlich verwendete Region freigegeben. Ein Unternehmen in der Region Frankfurt benötigt beispielsweise nicht automatisch S3-Ziele aus Oregon, Mumbai, Sydney und Tokio.

utm.cloud.sophos.com/api/utm ist eine URL mit Pfad, kein FQDN. Akzeptiert das Upstream-Produkt als Ziel nur einen FQDN, wird daher nur der Host utm.cloud.sophos.com eingetragen; /api/utm gehört nicht in ein FQDN-Objekt. Der Snapshot enthält für Heartbeat und Sophos Fusion konkrete upe.p.hmr.sophos.com-Hosts, keine Freigabe für die gesamte Wildcard-Domain. Diese Namen können sich durch den Plattformbetrieb ändern und werden nur über den kontrollierten Abgleich aktualisiert. Auch pool.ntp.org gilt nur bei Verwendung des Standard-NTP-Ziels; bei einem selbst konfigurierten NTP-Server wird stattdessen dessen Ziel freigegeben.

Regionale Ziele für Reporting und Backups auswählen

Zuerst wird die tatsächlich verwendete Region des jeweiligen Dienstes in der eigenen Sophos-Fusion-Umgebung geprüft. Der Standort des Unternehmens allein legt sie nicht fest. Ist die Zuordnung unklar, wird das Ziel eines Report-Uploads beziehungsweise Backups mit Packet Capture und Upstream-Log ermittelt und vor der Freigabe geklärt. Die folgende Liste ist ein Katalog, keine gemeinsame Allowlist: Nur die benötigten Ziele der verwendeten Region und Funktion werden übernommen. CFR sendet Reports und Logs; Backup dient dem Sichern und Wiederherstellen der Firewall-Konfiguration.

• USA (Oregon) — us-west-2
  • CFR: tf-presigned-url-us-west-2-prod-firewall-bucket.s3.us-west-2.amazonaws.com
  • Backup: us-west-2-firewall-backup.s3.us-west-2.amazonaws.com
• Europa (Frankfurt) — eu-central-1
  • CFR: tf-presigned-url-eu-central-1-prod-firewall-bucket.s3.eu-central-1.amazonaws.com
  • Backup: eu-central-1-firewall-backup.s3.eu-central-1.amazonaws.com
• Europa (Irland) — eu-west-1
  • CFR: tf-presigned-url-eu-west-1-prod-firewall-bucket.s3.eu-west-1.amazonaws.com
  • Backup: eu-west-1-firewall-backup.s3.eu-west-1.amazonaws.com
• USA Ost (Ohio) — us-east-2
  • CFR: tf-presigned-url-us-east-2-prod-firewall-bucket.s3.us-east-2.amazonaws.com
  • Backup: us-east-2-firewall-backup.s3.us-east-2.amazonaws.com
• Asien-Pazifik (Mumbai) — ap-south-1
  • CFR: tf-presigned-url-ap-south-1-prod-firewall-bucket.s3.ap-south-1.amazonaws.com
  • Backup: ap-south-1-firewall-backup.s3.ap-south-1.amazonaws.com
• Asien-Pazifik (Tokio) — ap-northeast-1
  • CFR: tf-presigned-url-ap-northeast-1-prod-firewall-bucket.s3.ap-northeast-1.amazonaws.com
  • Backup: ap-northeast-1-firewall-backup.s3.ap-northeast-1.amazonaws.com
• Kanada (Zentral) — ca-central-1
  • CFR: tf-presigned-url-ca-central-1-prod-firewall-bucket.s3.ca-central-1.amazonaws.com
  • Backup: ca-central-1-firewall-backup.s3.ca-central-1.amazonaws.com
• Asien-Pazifik (Sydney) — ap-southeast-2
  • CFR: tf-presigned-url-ap-southeast-2-prod-firewall-bucket.s3.ap-southeast-2.amazonaws.com
  • Backup: ap-southeast-2-firewall-backup.s3.ap-southeast-2.amazonaws.com
• Vereinigte Arabische Emirate (Dubai) — me-central-1
  • CFR: tf-presigned-url-me-central-1-prod-firewall-bucket.s3.me-central-1.amazonaws.com
  • Backup: *.s3.me-central-1.amazonaws.com — die dokumentierte Ausnahme, kein daraus erfundener einzelner Backup-Host.

Für die ersten acht Regionen ist TCP 443 der Port dieser Dienstgruppen. Quellenbegrenzung für Dubai: Beide eingefrorenen Diensttabellen enthalten neun Regionszeilen, aber die gemeinsamen Port- und Zweckzellen überspannen nur acht Zeilen (rowspan=8); die Dubai-Zellen sind leer. Die Übersicht oben ordnet TCP 443 auf Dienstgruppenebene ein, nicht als ausdrücklich befüllten UAE-Portwert. Die Dubai-Zielnamen sind dokumentiert, der regionale Portwert bleibt in diesen Tabellen jedoch uneindeutig. Vor einer UAE-Freigabe wird er im kontrollierten Abgleich geklärt; hier wird weder ein fehlender Zellenwert ergänzt noch ein getestetes Produktverhalten behauptet.

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. Als Quelle wird dort nur die WAN-Adresse der Sophos Firewall verwendet, so wie das filternde Gerät sie vor oder nach einer allfälligen Übersetzung tatsächlich sieht. 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 dort die Namen aus dem freigegebenen Snapshot 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: Im Snapshot gehört dieser breite Wildcard nur zu Central Firewall Management. Er wird nicht auf andere Funktionen oder zusätzliche Ports übertragen. 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

Unter Diagnostics > Tools > Name lookup kann ein Zielname aus dem Snapshot zunächst ohne Konfigurationsänderung aufgelöst werden. Mit Lookup using all configured servers lässt sich erkennen, ob die konfigurierten Resolver unterschiedlich antworten oder auffällig lange brauchen. Alternativ kann die bekannte Device-Console-Abfrage verwendet werden:

dnslookup host xg-up2date-firmwares.sophosupd.com

Danach zeigt Diagnostics > Packet capture, ob die Firewall eine Verbindung zur aufgelösten Adresse startet, über welches WAN-Interface sie geht und ob Antworten zurückkommen. Der Display Filter wird auf die konkrete Ziel-IP und den Port begrenzt. Der Status Generated kennzeichnet Pakete, welche die Firewall selbst erzeugt hat. Parallel wird im Upstream-System nach demselben Zeitfenster, derselben Source und Destination gesucht. Nach dem Test wird der Capture wieder ausgeschaltet; sein Puffer ist begrenzt und ersetzt kein dauerhaftes Logging.

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 Fusion 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, Sophos Fusion erhält die Aufgabe, ein Report erscheint oder Support Access zeigt eine aktive Sitzung.

Danach bleibt die Upstream-Regel geloggt und wird nach einigen Tagen geprüft. Nicht verwendete Regionen und temporär breite Testfreigaben werden entfernt.

Der Firewall-Owner prüft den Snapshot mindestens quartalsweise sowie vor Firmware-Upgrades, beim Aktivieren einer neuen Sophos-Funktion, nach einem Regionswechsel, nach einer passenden Herstellerankündigung und bei ungeklärten Verbindungsfehlern. Er öffnet dazu in diesem konkreten Reconciliation-Schritt die laufend veränderte Seite Default services und protokolliert Prüfdatum, SFOS-Build, Prüfer und den Diff zum internen Snapshot.

Jeder neue, geänderte oder entfernte Eintrag wird einer aktiv verwendeten Funktion, Region und einem Port zugeordnet. Ergänzungen werden pro Funktionsgruppe zuerst in einem Wartungsfenster angewendet und mit DNS, Packet Capture, Upstream-Log und Funktionstest abgenommen. Ein entfernter Zielname wird nicht allein aufgrund des Diffs sofort gelöscht: Zuerst wird seine Nutzung im Regel-Log geprüft, dann wird das alte Objekt deaktiviert und während einer festgelegten Beobachtungszeit überwacht. Scheitert die Validierung, wird die Änderung zurückgenommen und der vorherige Snapshot bleibt freigegeben. Erst ein erfolgreicher Test führt zu einem neuen datierten Snapshot.

Rückweg bei unerwarteten Nebenwirkungen

Vor der Änderung wird die bestehende Upstream-Regelbasis exportiert oder anderweitig gesichert. Treten nach der Freigabe unerwartete Verbindungen oder andere Nebenwirkungen auf, wird ausschliesslich die neu erstellte Regel deaktiviert beziehungsweise auf den letzten dokumentierten Ziel- und Portumfang zurückgesetzt. Danach werden die ursprünglich betroffene Funktion und ein unabhängiger normaler Internetzugriff erneut geprüft. So ist erkennbar, ob die Nebenwirkung wirklich mit der Allowlist zusammenhing, ohne gleichzeitig andere Regeln zu verändern.

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.

Häufige Fragen