Sophos Intercept X for Mobile: Netzwerkzugriff bei ausbleibenden Updates prüfen

Kurzweg: Wenn Updates oder Web-Lookups in Sophos Intercept X for Mobile (IXM) hinter einem Egress-Filter nicht funktionieren, zuerst Plattform, App-Version, Verwaltungsart und den fehlgeschlagenen Vorgang erfassen. Danach lesend DNS-, Proxy- und Egress-Logs des tatsächlichen Gerätenetzes mit den unten genannten Clientzielen und dem Zeitpunkt vergleichen. Erst bei einem nachgewiesenen Block und nach Abgleich der für die konkrete Installation geltenden Herstellerangaben einen eng begrenzten, genehmigten Pilot mit dokumentiertem Rückweg planen. Ein DNS-Treffer oder ein Browser-Test von einem anderen Rechner beweist keine funktionierende App-Verbindung.

Hier bedeutet Netzwerkzugriff die ausgehenden Verbindungen der Schutz-App auf Android beziehungsweise iPhone/iPad. Das ist weder eine ZTNA-Zugriffsregel für interne Anwendungen noch die Network configuration einer Mobile-Threat-Defense-Richtlinie für die WLAN-Sicherheitsprüfung und auch keine fertige Sophos-Firewall-Regel. Eine mit Sophos Mobile verwaltete App kann zusätzlich Verbindungen für Verwaltung und Synchronisierung benötigen. Wer nur die App-Ziele prüft, kann daher einen Managementfehler übersehen.

Lizenz und Funktion trennen: Sophos Mobile Device Management (MDM, früher Central Mobile Standard) ermöglicht die Geräteverwaltung für Android, iPhone/iPad, Mac und Windows. Sophos Mobile Threat Defense (MTD, früher Intercept X for Mobile) ermöglicht die Verwaltung von IXM für Android und iPhone/iPad sowie Sophos Chrome Security für ChromeOS. Die kombinierte Lizenz Sophos Mobile (früher Central Mobile Advanced) enthält beide Funktionsbereiche. Im betroffenen Konto über das Profile-Symbol > Licensing die tatsächlich aktive Lizenz prüfen; zusätzlich Enrollment und wirksame Richtlinie erfassen. Eine Client-URL belegt weder einen Tenant-Anspruch noch einen Enrollment- oder Policy-Zustand.

Verwaltung/Synchronisierung: In Sophos Fusion My Products > Mobile öffnen und die Region in der Browser-Adresse direkt nach smc-user-if-cloudstation- ablesen. Nicht aus dem S3-Host auf die Kontoregion schliessen. Für die ermittelte Region gilt folgendes separates Serverziel, jeweils HTTPS/443 (Technikleitfaden vom 9. September 2026):

eu-central-1: smc-device-if-cloudstation-eu-central-1.prod.hydra.sophos.com
eu-west-1: smc-device-if-cloudstation-eu-west-1.prod.hydra.sophos.com
us-west-2: smc-device-if-cloudstation-us-west-2.prod.hydra.sophos.com
us-east-2: smc-device-if-cloudstation-us-east-2.prod.hydra.sophos.com

Ist die Region nicht eindeutig ermittelbar oder nicht aufgeführt, zuerst mit Kontoverantwortlichen und Sophos Support klären, statt alle vier Ziele freizugeben. Diese Zuordnung ergänzt die Clientdiagnose; sie ist keine vollständige Liste aller Management-, Push- und Enrollment-Verbindungen.

Client-Egress: Android und iOS getrennt prüfen

Die Android-App-Hilfe (2. Juni 2023) und die iOS-App-Hilfe (22. Juni 2023) nennen jeweils dieselben sieben URLs für den IXM-Client. Laut diesen beiden Seiten kann das Blockieren eines dieser Ziele die Funktion einschränken; sie erklären aber weder einzelne Dienstzuordnungen noch Ports und belegen nicht die Gültigkeit für jede spätere App-Version oder Verwaltungsart. Der Sophos-Mobile-Technikleitfaden (9. September 2026) ordnet diese Clientziele unter Android und iPhones/iPads innerhalb seiner Sophos-Mobile-Netzwerkverbindungen zusätzlich Diensten und Ports zu:

Intercept X for Mobile: https://sdds3.sophosupd.com und https://sdds3.sophosupd.net (im Technikleitfaden: HTTPS/443); http://secureservices.s3.eu-central-1.amazonaws.com (HTTP/80).
Web Filtering: https://4.sophosxl.net/lookup (HTTPS/443); nur für die tatsächlich genutzte, auf dem Gerät anwendbare Funktion untersuchen. Den dokumentierten Pfad /lookup nicht stillschweigend als ganze Domain-Freigabe auslegen.
Wi-Fi Security: https://sslintt.sophos.com, https://sslintt.sophosupd.com und https://sslintt.sophosupd.net (HTTPS/443); nur bei entsprechendem Fehlersymptom untersuchen.

Geltungsgrenze: Die beiden App-Hilfen sind plattformspezifische Clientlisten vom Juni 2023; der September-2026-Technikleitfaden beschreibt den Sophos-Mobile-Kontext mit gesonderten Management- und Plattformverbindungen. Die Übereinstimmung der sieben Ziele ist kein Nachweis für jede Edition, jede installierte IXM-Version, ein selbstständig betriebenes oder anders verwaltetes Gerät und jede Netzarchitektur. Vor einer Änderung installierte App-Version, gebuchte/aktive Edition, Managementzustand und tatsächlich betroffene Funktion mit den hier genannten Grenzen abgleichen; falls die anwendbare Ziel- oder Portliste für diese Umgebung unklar bleibt, keine Freigabe aus diesem Artikel ableiten, sondern mit Sophos Support und dem Netzwerkteam klären. Die Aufzählung ist auch keine Vollständigkeitsgarantie für sämtliche Mobile-Server-, Push- oder Enrollment-Verbindungen.

Die Dienst-/Portzuordnung stammt aus dem Technikleitfaden, nicht aus den beiden App-Hilfen, und ist kein vorgefertigter Firewall-Regelsatz: Quellgerät und -netz, Proxy, TLS-Prüfung und tatsächlich anwendbare App-Funktionen müssen vor Ort geprüft werden. Insbesondere steht das S3-Ziel in beiden App-Hilfen ausdrücklich mit http://; es weder still zu HTTPS umschreiben noch daraus eine pauschale HTTP-Freigabe ableiten. Der Hostname eu-central-1 beweist keine für jedes Gerät gültige Sophos-Mobile-Tenant-Region. Nicht jeder Gateway kann den Pfad /lookup prüfen: Ist nur eine Host-Freigabe möglich, das grössere Risiko gesondert bewerten statt eine Pfadbegrenzung zu behaupten. Keine pauschale TLS-Inspektionsausnahme oder Proxy-Umgehung aus der Liste herleiten.

Einen vermuteten Netzblock sicher eingrenzen

Zuerst plattformspezifische Ursachen ohne Egress-Sperre prüfen

Die folgenden Unterschiede stammen aus dem am 7. Oktober 2026 geprüften Known-Issues-Quellenstand (Liste erstellt am 6. Oktober 2026). Sie sind keine universellen Fehler oder Fixes für alle App-Versionen und begründen keine zusätzlichen Host-Freigaben. Zuerst Browser, Dienststatus und Symptom lesend prüfen; den aktuellen Versions-/Fix-Stand bei passendem Issue im Selector unten kontrollieren.

Android – SMSECAND-4563: Web Filtering unterstützt Chrome, Firefox, Edge und den auf älteren Android-Geräten vorinstallierten nativen Browser. Ein anderer Browser kann den fehlenden Filtereffekt erklären; diese Android-Liste nicht auf iOS übertragen.
Android – SMSECAND-4568 / SMSECAND-4567: Auf manchen Geräten, etwa Asus Zenpad 10, kann Android den für Web Filtering erforderlichen Sophos Accessibility Service bei einem IXM-Update deaktivieren (4568). Auch unabhängig vom Update kann der Dienst deaktiviert werden; IXM fordert dann zum erneuten Aktivieren auf (4567). Bei bestätigtem deaktiviertem Dienst nennt 4568 das Aktivieren in den Android-Einstellungen oder einen Geräteneustart als Wiederherstellung. Das sind Änderungen, keine lesenden Prüfungen: vorher Status und betroffene Funktion dokumentieren, mit Geräteverantwortlichen abstimmen und anschliessend Dienst und Web Filtering erneut prüfen. Ein Neustart unterbricht die Gerätenutzung; nicht als harmlosen Verbindungstest ausführen. Bleibt der Dienst nicht aktiv, Support einbeziehen, statt Schutzfunktionen zu umgehen.
ChromeOS – SMSECAND-4571: IXM Web Filtering wirkt nur in Android-Browser-Apps. Der integrierte Chrome-Browser nutzt dafür Sophos Chrome Security, nicht IXM Web Filtering. Link Checker benötigt eine installierte Android-Browser-App. Ein fehlender Filtereffekt im integrierten Chrome ist daher nicht automatisch ein Egress-Fehler.
iOS – SMSECIOS-1983: Push-Mitteilungen öffnen gelegentlich die App, ohne dass dort eine Nachricht vorhanden ist. Der Eintrag führt dies auf Maximum interval between Intercept X for Mobile synchronizations zurück, das eine Synchronisierung auslösen soll. Das ist kein Nachweis für blockierte Updates oder Lookups.
iOS – SMSECIOS-2042: Gelegentliche Abstürze beim Navigieren in der Oberfläche von 9.7.13 betreffen laut Quellenstand nicht die App-Funktionalität. In diesem datierten Stand war ein Fix für eine spätere Version geplant; den aktuellen Fix-Stand live prüfen. Den UI-Absturz nicht als Nachweis für eine Update- oder Lookup-Sperre behandeln.
Android – SMSECAND-4561, bei Eskalation: Bei manchen Android-Versionen und Geräten hängt Gmail Log-/Trace-Dateien nicht an die Support-Mail an. Eine andere E-Mail-App verwenden und die Anhänge vor dem Versand kontrollieren; fehlende Anhänge sind kein Beleg für einen Netzblock. Nur freigegebene Diagnosedaten an den zuständigen Support senden.

Danach Netzbefunde, Pilot und Rückweg

Ausgangslage festhalten: Android oder iOS/iPadOS, installierte App-Version, mit Sophos Mobile verwaltet oder anders/nicht verwaltet, Edition/Lizenz, wirksame Funktion und Richtlinie, Uhrzeit und tatsächlicher Gerätepfad (WLAN, Mobilfunk, VPN/Proxy). Ist Web Filtering auf dem Gerät gar nicht aktiv oder wegen Modus/Berechtigung nicht anwendbar, ist ein fehlender Web-Filter-Effekt kein Beleg für eine Egress-Sperre. Betrifft der Fehler stattdessen Verwaltung oder Synchronisierung, das oben für die tatsächlich ermittelte Kontoregion zugeordnete Sophos-Mobile-Serverziel separat prüfen. Nicht das S3-Ziel als Tenant-Server interpretieren.
Nur beobachten: Bereits vorhandene DNS-, Proxy- und Egress-Ereignisse am betroffenen Netz für das Gerät und Zeitfenster lesen. Zielname, URL-Schema, Port, Ablehnungsgrund und den konkreten App-Vorgang getrennt notieren. Ein blockierter Request ist ein Anhaltspunkt, noch kein Beweis, dass genau diese Sperre den beobachteten Fehler verursacht; ein erfolgreicher DNS-Test prüft weder HTTP(S)-Verbindung noch App-Funktion.
Genehmigten Pilot planen: Nur wenn Beobachtung, aktive Funktion und für diese Umgebung anwendbare Herstellerangaben zusammenpassen, mit Netzwerk- und Sicherheitsverantwortlichen eine befristete, möglichst auf betroffene Geräte, benötigte Dienste und dokumentierte Ziele begrenzte Änderung vereinbaren. Vorherige Policy, Testzeit, Erfolgskriterium und Rückweg festhalten. Keine globalen Wildcards, kein generelles Öffnen von HTTP, keine pauschale TLS-Inspektionsausnahme und keine Proxy-Umgehung. Ist der Zweck des HTTP-Ziels im eigenen Setup unklar, zuerst Sophos beziehungsweise das Sicherheitsteam einbeziehen.
Ergebnis und Rückweg: Den zuvor fehlgeschlagenen Vorgang auf demselben Testgerät und Netz erneut ausführen und gleichzeitig die zugehörigen Ablehnungen beziehungsweise erfolgreichen Verbindungen beobachten. Nur ein funktionierender Vorgang zusammen mit passenden Netzbefunden stützt die Hypothese für diesen Pilot, nicht die Behauptung, dass alle Funktionen oder Versionen nun funktionieren. Bleibt der Fehler oder erscheinen unerwartete Verbindungen, Pilotänderung anhand der protokollierten Vor-Konfiguration zurücknehmen, erneut prüfen und Befunde an den zuständigen Support geben. Auch einen erfolgreichen Piloten vor einer produktiven Ausweitung unabhängig freigeben lassen.

Known-Issues-Selector: nur versionsbezogene Zusatzprüfung

Die Sophos-Liste bekannter Probleme mit product=smx dient nur dazu, bei einem passenden Android- oder iOS-App-Symptom die betroffene Version und den aktuellen Issue-/Fix-Status nachzuschlagen. Sie ist keine allgemeine Netzwerkvoraussetzung, keine zusätzliche Egress-Zielliste und kein Ersatz für die Clientlisten oder Geräte-Logs. Auf der abgerufenen Listenansicht vom 28. September 2026 waren beim nicht interaktiven Abruf die HTML-Inhalte mit und ohne ?product=smx gleich; eine wirksame clientseitige Filterung wurde nicht geprüft. Deshalb den exakten Selector beibehalten, auf der Seite Produkt, Issue, betroffene Version und Fix-Stand kontrollieren und aus dem ungefilterten HTML weder einen exklusiven Serverfilter noch eine allgemeine IXM-Anforderung ableiten.

Nicht am Kunden-Setup getestet: Die dokumentierten Quelllisten wurden verglichen. Ob sie für die Edition und App-Version auf einem konkreten Gerät gelten, welche Tenant-Berechtigungen bestehen und welche Gateway-Regeln tatsächlich greifen, wurde nicht in einer Kundenumgebung geprüft. Auch Pilotwirkung und Rückweg wurden dort nicht getestet. Diese Punkte müssen in der eigenen Umgebung geprüft werden; der Quellenvergleich ersetzt keinen Gerätetest.