Sophos Firewall: Device Access und Local Service ACL

Unter Administration > Device access wird festgelegt, aus welchen Zonen lokale Dienste der Sophos Firewall erreichbar sind. Dazu gehören HTTPS für WebAdmin und API, SSH, Ping, DNS, SNMP, SSL VPN, User Portal und VPN Portal.

Diese Dienste enden direkt auf der Firewall und bilden ihre Management- und Serviceoberfläche. Ist eine Freigabe zu breit, können Bots, kompromittierte interne Clients oder externe Angreifer Loginseiten, API und SSH unmittelbar erreichen und Zugangsdaten, bekannte Schwachstellen oder Fehlkonfigurationen testen. MFA und sichere Kennwörter bleiben wichtig, begrenzen aber nicht die Erreichbarkeit: Device Access reduziert die Angriffsfläche vor der Anmeldung und gehört deshalb zu den ersten Hardening-Massnahmen.

Die Identitätsquelle bleibt davon getrennt. Soll WebAdmin zentrale TACACS+-Credentials verwenden, erklärt TACACS+ für Sophos Firewall Administratoren Serveranbindung, lokale Profilzuweisung, Pilotlogin und Fallback; die HTTPS-Erreichbarkeit wird weiterhin hier begrenzt.

Entscheidend ist das Ziel der Verbindung:

• Device Access Zonentabelle: Erlaubt einen lokalen Firewall-Dienst grundsätzlich aus einer Zone.
• Local service ACL exception rule: Erlaubt oder blockiert einen lokalen Dienst für konkrete Quellen, Ziele und Dienste.
• Firewall-Regel: Steuert Traffic durch die Firewall, beispielsweise von LAN zu einem Server in DMZ.

Öffnet man beispielsweise https://172.16.16.16:4444, endet die Verbindung auf der Firewall. Eine normale Firewall-Regel ersetzt deshalb keine Device-Access-Freigabe.

⚠️ WebAdmin, SSH und Portale sollten nur aus den Netzen erreichbar sein, die sie wirklich benötigen. Für externe Administration sind ein Admin-VPN, Sophos Central Firewall Management in Sophos Fusion (Anmeldung unter fusion.sophos.com), ein Management-Netz oder eine enge ACL-Ausnahme sicherer als eine breite WAN-Freigabe.

Zwei Sonderfälle können die Zonentabelle bei HTTP- und HTTPS-Diensten aushebeln:

• Web Proxy: Anfragen über den Web Proxy gelten als intern und lassen sich nicht nach Quellzone über Device Access steuern. Wer den Proxy verwenden darf, kann dadurch WebAdmin, Captive Portal, VPN Portal und User Portal erreichen, obwohl der Dienst für die eigene Zone deaktiviert ist.
• Port Sharing: Verwenden VPN Portal und SSL VPN denselben Port und dasselbe Protokoll, wird das VPN Portal aus allen SSL-VPN-Zugriffszonen erreichbar. Zudem greifen dann die Einstellungen unter Login security nicht.

Diese beiden Pfade müssen bei der Abnahme separat getestet werden. Der übergeordnete Artikel Sophos Firewall Hardening ordnet Device Access in die gesamte Systemhärtung ein.

Zonen und lokale Dienste planen

Die Zonentabelle eignet sich für klare Grundfreigaben, etwa DNS aus LAN, Ping aus einer Monitoring-Zone oder HTTPS aus einem Management-Netz. Braucht nur eine einzelne IP-Adresse oder ein kleines Netz Zugriff, ist eine ACL Exception Rule genauer.

Eine Zone fasst Interfaces zusammen. Bei einer benutzerdefinierten Zone lässt sich der lokale Dienstzugriff zusätzlich unter Network > Zones erlauben oder blockieren. Vor einer Änderung müssen deshalb das tatsächliche Eingangsinterface und seine Zone feststehen. Ausserdem werden das enge Quellobjekt, der benötigte Interface Host als Ziel sowie der echte Dienstport vorbereitet. Vorhandene IP Hosts findet man unter Hosts and services > IP host; Interface Hosts werden über Network > Interfaces gepflegt.

Standardmatrix als Ausgangszustand lesen

Eine neue SFOS-22-Konfiguration erlaubt lokale Dienste standardmässig aus den folgenden Zonen. Die Matrix ist kein Hardening-Ziel: Restore, Migration, Wizard und spätere Änderungen können abweichen, und nicht benötigte Dienste werden nach einem Positiv- und Negativtest entfernt.

Typische Entscheidungen sind:

• HTTPS: WebAdmin und API nur aus Management-Netzen oder eng definierten Adminquellen.
• SSH: Nur für Administration oder Support und möglichst mit Public Key. Für Netzwerk-SSH ist der dokumentierte Anmeldeweg in SFOS 22/23 das integrierte Konto admin; eine CLI-Profilberechtigung bestätigt keinen SSH-Anmeldeweg für ein benanntes Administratorkonto. Nur der Default-Admin verwaltet die Public-Key-Einstellungen und Schlüssel.
• DNS: Nur für interne Clientzonen, welche die Firewall als DNS-Resolver verwenden. DNS aus WAN ist kein normaler Clientfall.
• Ping/Ping6: Für benötigtes Monitoring, nicht pauschal aus unsicheren Zonen.
• SNMP: Nur vom Monitoring-System oder -Netz; die Einrichtung beschreibt SNMP Hardware Monitoring.
• RADIUS SSO: Nur vom festen Accounting-Absender. Die Zuordnung von Client-IP und Benutzer erklärt RADIUS SSO mit Accounting.
• SSL VPN: Extern so offen wie nötig und mit MFA, Logging sowie bewusst gewähltem Port und Protokoll.
• VPN Portal: Stellt seit SFOS 20 Sophos Connect sowie IPsec- und SSL-VPN-Konfigurationen bereit.
• User Portal: Dient unter anderem persönlichen Daten, OTP-Token, Quarantäne, Ausnahmen und Policy Overrides, nicht dem Download der VPN-Konfiguration.
• RED, SMTP Relay und Dynamic Routing: Nur in den dafür vorgesehenen Netzen oder für definierte Gegenstellen. Wie diese Grenze bei Multicast-Nachbarn geprüft wird, zeigt PIM-SM auf Sophos Firewall konfigurieren; für kleine IPv4-Routing-Domains erklärt RIPv2 auf Sophos Firewall konfigurieren die getrennte Freigabe von Peer-Zone und Nutzdatenverkehr.

Im Service-Dialog stehen zusätzlich AD SSO, Captive portal, Chromebook SSO, Clients, IPsec, Web proxy und Wireless Protection zur Wahl. Dass ein Dienst auswählbar ist, ist keine Empfehlung für eine breite Zonenfreigabe; jede Auswahl braucht einen konkreten Client-, Peer- oder Administrationspfad. Die Suchfelder für Source Network / Host, Destination host und Services durchsuchen auch Attribute. Mit 53 lässt sich beispielsweise der DNS-Dienst finden.

WebAdmin, VPN Portal und User Portal unterstützen seit SFOS 22 TLS 1.3. Gute Verschlüsselung reduziert jedoch nicht die Angriffsfläche eines unnötig erreichbaren Dienstes.

Device Access beantwortet nur, aus welchem Netz die WebAdmin-Konsole erreichbar ist. Soll die Anmeldung über Microsoft Entra ID erfolgen, erklärt Entra ID SSO für Sophos Firewall WebAdmin die separate Zuordnung von Entra-Rollen und -Gruppen zu lokalen Administratorprofilen.

Zusätzlich kann restrict-admin-console-wan-access den WebAdmin-Zugriff aus allen WAN-Quellen global sperren. Die bewusst umgekehrte Enable-/Disable-Logik und die Abgrenzung zur Local Service ACL erklärt Advanced Firewall Settings sicher prüfen.

Quellen eng begrenzen

Eine ACL Exception Rule unterstützt als Quelle Country, Country group, FQDN host/group, Host group, IP address/list/range, MAC address/list und Network. Wildcard-FQDNs werden nicht unterstützt.

Für WebAdmin aus WAN darf keine Freigabe für alle Quellen verwendet werden. SFOS lässt die ACL-Ausnahme gar nicht erst erstellen, wenn Source Network / Host auf Any oder die Quell-IP auf 0.0.0.0 gesetzt ist. Diese Produktsperre macht andere grosse Netze jedoch nicht automatisch sicher. Eine feste Admin-IP, ein kleines Management-Netz oder ein gepflegtes FQDN-Objekt ist wesentlich sicherer. Bei mobilen Benutzern, deren Quelladressen wechseln, sollte der administrative Zugriff über VPN oder Sophos Fusion erfolgen.

Breite WAN-Freigaben für WebAdmin und User Portal werden seit SFOS 19.5 MR2 nach 90 aufeinanderfolgenden Tagen ohne erfolgreiche Anmeldung automatisch deaktiviert. Spezifische WAN-Quellen in ACL Exception Rules bleiben davon unberührt und müssen weiterhin regelmässig geprüft werden. Der Sophos Firewall Health Check hilft beim wiederkehrenden Review von Managementzugriffen, MFA und Konfiguration.

Web Proxy und Port Sharing vorab prüfen

Vor einer Härtung sollte man unter Administration > Admin and user settings sowie in den SSL VPN global settings die verwendeten Ports und Protokolle notieren.

• WebAdmin verwendet standardmässig TCP 4444, das User Portal TCP 4443 und das VPN Portal TCP 443.
• Für WAF ist in SFOS 22/23 TCP 443 als Standard dokumentiert; vor der Kollisionsprüfung erfasst man jedoch die tatsächlich konfigurierten WAF-Listener.
• SSL VPN verwendet standardmässig TCP 8443; als Protokoll kann auch UDP gewählt werden.
• WebAdmin und User Portal dürfen ihren Port nicht mit anderen Diensten teilen.
• VPN Portal und SSL VPN sollten nicht denselben Port und dasselbe Protokoll verwenden, weil sonst Zonensperren und Login Security nicht wie erwartet wirken.

Wenn der Web Proxy aktiv ist, genügt ein Test ohne Proxy nicht. Der gleiche Portal- oder WebAdmin-Aufruf muss zusätzlich über den expliziten Proxy aus einer eigentlich gesperrten Zone geprüft werden.

Wie man den Proxylistener auf einen Pilotclient begrenzt und diese Exposition kontrolliert abnimmt, zeigt Direct Web Proxy mit PAC-Datei einrichten.

Enge Local Service ACL Exception Rule erstellen

Vor direktem WAN-WebAdmin-Zugriff: In der Device Console zuerst mit dem lesenden Befehl show advanced-firewall den tatsächlichen Wert von restrict-admin-console-wan-access und den installierten Build dokumentieren. Sophos beschreibt enable in SFOS 22/23 als WebAdmin-Sperre aus allen WAN-Quellen und als Standardwert; dieser Default ersetzt nicht den erfassten Vorher-Wert. Die ACL-Anleitung beschreibt enge WAN-Ausnahmen, klärt aber deren Vorrang gegenüber dieser globalen Sperre nicht. Deshalb nicht annehmen, dass die folgende ACL-Ausnahme allein WebAdmin aus WAN erreichbar macht. Bei enable die Einschränkung beibehalten und den bereits getesteten, autorisierten Admin-VPN-, Management- oder Fusion-Zugang verwenden. Ist direkter WAN-Zugriff unvermeidbar und das Zusammenspiel für den installierten Build nicht eindeutig geklärt, den direkten WAN-Change stoppen und mit Sophos Support klären. Auch bei einem fehlgeschlagenen Positivtest zuerst diese Voraussetzung prüfen, nicht die ACL verbreitern.

Dieses ACL-Beispiel ist keine Anweisung, den globalen Schalter auf disable zu setzen. Eine Änderung der globalen Einschränkung ist ein gesondert freizugebender Change mit funktionierendem unabhängigem Adminweg, dokumentiertem tatsächlichem Vorher-Wert, eigenen Tests aus erlaubter und gesperrter WAN-Quelle sowie exakter Wiederherstellung dieses Vorher-Werts bei Abbruch und nach Ende eines temporären Zugriffs. Lassen sich Ausgangswert oder Rückweg nicht verlässlich feststellen, wird nicht geändert. Das folgende enge WAN-Beispiel wird nur umgesetzt, wenn diese Voraussetzungen geklärt sind.

Eine typische Ausnahme erlaubt WebAdmin aus WAN nur für eine feste Support-IP. Der Menüpfad lautet Administration > Device access > Local service ACL exception rule > Add.

1. Rule name: admin-https-from-support-ip
2. Rule position: Für eine spezifische WAN-Ausnahme Top wählen und die übrigen Regeln auf Überschneidungen prüfen.
3. Description: Zweck, Ticket und geplantes Ablaufdatum dokumentieren.
4. IP version: Passend zur Quelle auswählen, meistens IPv4.
5. Source zone: WAN
6. Source Network / Host: Eine konkrete Admin-IP oder ein enges, gepflegtes Objekt auswählen.
7. Destination host: Auf die benötigte Firewall-Adresse oder das Interface begrenzen. Any erweitert die erreichbaren Zieladressen oder Interfaces, nicht die unter Services ausgewählten Dienste.
8. Services: Nur HTTPS auswählen, nicht zusätzlich SSH aus Bequemlichkeit.
9. Action: Accept

Die Beispielwerte werden nicht unverändert übernommen. Für ein internes Management-Netz kann dasselbe Muster etwa Source zone: LAN oder eine benutzerdefinierte Management-Zone, Source Network / Host: mgmt-net, den Interface Host der Management-IP als Destination host, HTTPS und Accept verwenden. Soll dagegen innerhalb einer grundsätzlich freigegebenen Zone eine bekannte Quelle gezielt ausgeschlossen werden, verwendet eine separate, passend positionierte Regel das enge Quellobjekt, nur die betroffenen Dienste und Drop. Eine Ländergruppe ist höchstens eine grobe Netzgrenze und kein Ersatz für die feste Adminquelle oder ein VPN.

Anschliessend wird gespeichert und aus einer erlaubten sowie einer nicht erlaubten Quelle getestet. Die Position der Regel ist wichtig: Höhere Regeln können das Ergebnis beeinflussen. Bei überlappenden Regeln sollte die tatsächliche Wirkung deshalb auf der Firewall geprüft und nicht allein aus der Liste abgeleitet werden.

API-Zugriff

Für die API müssen drei Bedingungen zusammenpassen:

1. Die API ist unter Administration > API access aktiviert.
2. Die Quelladresse befindet sich in Allowed IP hosts.
3. Device Access erlaubt HTTPS aus der betreffenden Zone oder über eine passende ACL-Ausnahme.

Seit SFOS 22 liegt die API-Konfiguration unter Administration und unterstützt IP-Host-Objekte für Adressen, Bereiche und Netze. Bis zu 64 Objekte sind möglich. Eine breite HTTPS-Freigabe ist dafür nicht nötig. Die vollständige Konfiguration steht in Sophos Firewall API Zugriff sicher begrenzen.

XML-Automation: Zoneneinstellung statt ACL-Ausnahme

Die XML-Zonendokumentation für SFOS 22/23 ordnet HTTPS und SSH unter Zone/ApplianceAccess/AdminServices/HTTPS beziehungsweise Zone/ApplianceAccess/AdminServices/SSH ein. Das ist der lokale Dienstzugriff auf Zonenebene: weder eine Firewall-Regel für Durchgangsverkehr noch eine quellenspezifische Local service ACL exception rule. Eine Änderung an diesem Zweig betrifft die Management-Erreichbarkeit aus der Zone; sie begrenzt den Zugriff nicht auf eine einzelne Admin-IP. Für eine enge Quellfreigabe bleibt die oben beschriebene ACL-Ausnahme die passende Grenze.

Die Dokumentation ist bei den Werten widersprüchlich: Das XML-Beispiel zeigt Enable/Disable, während die gemeinsame Parametertabelle Enable mehrfach sowie 12 und 40 aufführt. Daraus lässt sich keine verlässliche boolesche oder numerische Codierung ableiten. Vor einem automatisierten Schreibzugriff muss die Syntax für die installierte Firmware geklärt sein; diese Hierarchieerklärung ist keine ausführbare Freigabevorlage.

Auch Zone/MemberPorts ist keine Schreibanweisung: Der Kommentar im XML-Beispiel bezeichnet die Mitgliedsports ausdrücklich als nur lesbar. Die optionale CSV-Zeile der Tabelle beschreibt ihre Anzeige, nicht eine belegte Änderungsmöglichkeit. Vor jeder automatisierten Zonenänderung einen unabhängigen, angemeldeten Wiederherstellungsweg testen und danach erlaubte sowie gesperrte Quellen wie im Rollout unten prüfen.

Eine benutzerdefinierte Zone sicher entfernen

Das Löschen einer Local service ACL exception rule entfernt nur diese Ausnahme, nicht die benannte Zone. Auch das Abschalten eines lokalen Dienstes ist keine Zonenlöschung. Die Zuordnung erklärt Zonen und Interfaces.

1. Unter Network > Zones den exakten Namen der nicht mehr produktiv benötigten benutzerdefinierten Zone feststellen und ihren bisherigen Zustand dokumentieren. Retired_Test ist nur ein Beispiel, kein Löschziel zum Übernehmen. Vorher den unabhängigen Adminweg wie im Rollout unten anmelden und testen; er darf weder von dieser Zone noch von den zu ändernden Interfaces oder Regeln abhängen.
2. Unter Network > Interfaces alle Zuordnungen zu dieser Zone und unter Rules and policies > Firewall rules alle Verweise als Source zone oder Destination zone prüfen. Benötigte Interfaces und Regeln nicht löschen: Nur im freigegebenen Change auf die vorgesehene verbleibende Zone umstellen und die Wirkung prüfen. Müssen Verweise bestehen bleiben oder ist ihre Nutzung unklar, Zone und Abhängigkeiten behalten und die Löschung stoppen. Keine produktiven Abhängigkeiten kaskadierend entfernen, um die Löschung zu erzwingen.
3. Erst nach geklärten Abhängigkeiten ausschliesslich diese benannte Zone entfernen. Die XML-Dokumentation für SFOS 22/23 verlangt Name mit höchstens 60 Zeichen: zuerst A-Za-z1-9 (nicht 0), danach A-Za-z0-9_. Das belegt weder Wildcards noch automatisches Kaskadenlöschen; hier wird kein XML-Request oder unbelegter Löschdialog vorgegeben.
4. Danach prüfen, dass nur die beabsichtigte Zone fehlt, die verbleibenden Interface-Zuordnungen und Firewall-Regeln stimmen und benötigter Durchgangsverkehr weiterhin funktioniert. Lokale Dienste aus erlaubten und gesperrten Quellen sowie den unabhängigen Adminweg erneut testen. Bei Abweichungen stoppen und über diesen Weg die dokumentierten Änderungen gezielt zurücknehmen, nicht Freigaben verbreitern.

Die dokumentierten XML-Statuswerte sind 200 (ZoneDeleteSuccess), 500 (ZoneDeleteFailed), 503 (ZoneInterfaceExists) und 504 (ZoneFirewallRuleExists). Bei 503 oder 504 die betreffenden Interface- beziehungsweise Regelverweise erneut prüfen, nicht abhängige Objekte pauschal löschen. 500 ist kein Erfolg; auch 200 ersetzt die Nachkontrolle nicht.

DNS aus dem WAN

Eine DNS-ACL-Ausnahme aus WAN allein führt nicht dazu, dass die Firewall dort DNS-Anfragen beantwortet. Dafür müsste unter Network > DNS zusätzlich ein statischer DNS Host mit Publish on WAN eingerichtet werden. Das sollte nur für einen konkreten autoritativen Anwendungsfall erfolgen; die Firewall darf dadurch nicht zum öffentlich rekursiven Resolver werden. Delegation, DNS Host Entry und Positiv- sowie Negativtests erklärt DNS Host Entries auf Sophos Firewall einrichten.

Betriebsdetails vor der Änderung

Nach einem Upgrade oder Restore von vor SFOS 20 übernimmt das VPN Portal den bisherigen User-Portal-Port, auch einen benutzerdefinierten Port. Das User Portal wechselt auf 4443, bei belegtem Port auf 65040. Deshalb prüft man den tatsächlich konfigurierten Port und nicht nur den Default, bevor eine scheinbar fehlende ACL-Freigabe untersucht wird. Für den VPN-Portal-Zugang müssen ausserdem die Benutzer oder Gruppen in einer passenden Remote-Access-Policy enthalten sein; Erreichbarkeit allein erteilt keine Benutzerberechtigung.

Bei WAF muss sich der Listener vom VPN Portal in WAN-IP oder Port unterscheiden. Gegenüber SSL VPN genügt auch ein anderes Protokoll: WAF und VPN Portal verwenden TCP, SSL VPN kann TCP oder UDP verwenden. Diese Listener-Trennung ist nicht dasselbe wie eine ACL-Freigabe; nach jeder Portänderung werden die betroffenen Dienste erneut geprüft.

Dynamic Routing erlaubt Routing-Updates zur Firewall, nicht den Nutzdatenverkehr durch sie. Die Freigabe gehört zur tatsächlichen Peer-Zone, nicht automatisch zu WAN. Im WAN-Beispiel mit zwei RIP-Firewalls empfängt nur die Seite mit aktivierter Freigabe die Updates; die andere verwirft sie und lernt die angekündigten Netze nicht. Bei einseitig fehlenden Routen prüft man deshalb die Peer-Zone auf beiden Seiten und danach die protokollspezifische Konfiguration im verlinkten Routing-Artikel.

Das Widget Messages im Control center kann auf WAN-Erreichbarkeit von HTTPS und SSH hinweisen. Man prüft dann Zonenfreigaben und ACL-Ausnahmen und begrenzt den Zugang auf VPN oder konkrete Hosts und Netze. Meldungen lassen sich nicht manuell löschen; manche verschwinden nach Erfüllung der Anforderung. Eine verschwundene Meldung ersetzt keinen Positiv- und Negativtest. Meldungen zum Secure Storage Master Key, zu Registrierung, Lizenzen, Reports und Firmware gehören in die jeweiligen Betriebsabläufe, nicht in eine zusätzliche ACL-Regel.

Änderungen ohne Lockout ausrollen

Device-Access-Änderungen wirken sofort. Bei Remote-Arbeiten muss der zweite Adminweg vor der Änderung tatsächlich angemeldet und getestet sein.

Der Rückfallweg muss auch nach der geplanten Zonen- oder Portänderung funktionieren. Ein zweiter Browser-Tab über denselben gesperrten Zugang ist kein unabhängiger Weg. Vor Beginn werden die konkreten bisherigen Einstellungen und die zuständige Person mit Konsolenzugang festgehalten; ohne funktionierenden Rückweg wird remote nicht umgestellt.

1. Aktuelle Zonenfreigaben, ACL-Ausnahmen, Ports und benötigte Dienste dokumentieren.
2. Einen unabhängigen Zugang öffnen, beispielsweise lokale Konsole, Management-LAN, Admin-VPN oder Sophos Fusion.
3. Bei grösseren Änderungen ein aktuelles Backup und den Secure Storage Master Key verfügbar halten.
4. Die neue, enge Accept-Ausnahme erstellen, ohne die bestehende breite Freigabe bereits zu entfernen.
5. Den erlaubten Zugriff als Baseline prüfen. Solange die breite Zonenfreigabe aktiv ist, beweist dieser Test noch nicht, dass die neue Ausnahme greift.
6. Unter Diagnostics > Packet capture einen engen Filter für Quelle, Ziel und Port setzen und Trace On aktivieren.
7. Über den unabhängigen Adminweg die alte breite Zonenfreigabe entfernen.
8. Unmittelbar danach den Dienst aus der erlaubten Quelle funktional testen. Ein erfolgreicher TCP-/TLS- beziehungsweise Dienstzugriff und typischerweise Status: Consumed bestätigen den Positivfall; Reason: LOCAL_ACL muss dabei nicht erscheinen.
9. Den gleichen Dienst aus einer nicht erlaubten Quelle testen. Für den blockierten Versuch sind typischerweise Status: Violation und Reason: LOCAL_ACL zu erwarten.
10. Bei HTTP/HTTPS zusätzlich den Web-Proxy-Pfad und bei Portalen die SSL-VPN-Zugriffszonen prüfen.
11. Packet Capture stoppen und im Log viewer ergänzende Dienst- oder Anmeldeereignisse prüfen. Die im Packet Capture angezeigte Rule-ID ist die Firewall-Regel-ID, nicht die ID der ACL Exception Rule, und kann bei lokalem Traffic 0 sein.
12. Regel, Zweck, Verantwortlichen, Ticket, Quelle, Dienst und Review- oder Ablaufdatum dokumentieren.

Abbruch und Rückfall: Fällt die erlaubte Quelle aus, stellt man über den unabhängigen Adminweg gezielt die zuletzt geänderte Einstellung auf den dokumentierten Ausgangswert zurück und prüft den Zugang erneut. Erreicht dagegen eine gesperrte Quelle den Dienst weiterhin, erweitert man die Freigabe nicht: Man untersucht Proxy, Port Sharing und überlappende ACL-Regeln und begrenzt den unerwünschten Pfad, ohne den Rückfallweg zu verlieren. Erst nach Korrektur werden beide Tests wiederholt.

Kompakte Dokumentationsbeispiele helfen beim späteren Review:

• HTTPS: Regel admin-https-from-mgmt, Quelle mgmt-net, Zweck WebAdmin, quartalsweise prüfen.
• SSH: Quelle support-ip-temporary, Zweck Supportfall, nach Ticketabschluss löschen.
• SNMP: Quelle monitoring-server, Zweck Hardware- und Interface-Monitoring, halbjährlich prüfen.
• SSL VPN: Quelle WAN, Zweck Remote Access, Logs monatlich prüfen.

Bei mehreren Firewalls oder einem HA-Cluster sollte man zuerst ein System mit guter Rückfallmöglichkeit ändern. Rollenwechsel und Wartungszugriff behandelt die Anleitung Sophos Firewall High Availability einrichten.

Sonderfälle und zusätzlicher Schutz

User Portal, VPN Portal und SSL VPN

Zuerst ist zu klären, welches Portal wirklich benötigt wird. VPN-Clients und -Konfigurationen gehören ins VPN Portal; das User Portal erfüllt andere Benutzerfunktionen. Eine Übersicht bietet Sophos Firewall Portale im Vergleich.

Muss ein Remote-Access-Dienst weltweit erreichbar sein, sind MFA, restriktive Benutzergruppen und Logging wichtiger als eine ungeeignete Länderbegrenzung. Die Einrichtung zeigt MFA für WebAdmin, VPN Portal und Remote Access. Port-Sharing bleibt trotzdem zu vermeiden: Authentisierung ersetzt keine korrekte Erreichbarkeitssteuerung.

Öffentlich erreichbare WebAdmin-, User-Portal-, VPN-Portal- und SSL-VPN-Logins werden schnell von Scannern und Bots gefunden. Auch mit MFA entstehen dadurch Brute-Force-Traffic, Lograuschen und zusätzliche Last.

Wenn bereits viele fehlgeschlagene VPN-Portal-Anmeldungen oder Kontosperren auftreten, verbindet Sophos Firewall VPN Portal gegen Brute Force absichern Logprüfung, Identitätskontrolle, ACL-Eindämmung und Nachkontrolle zu einem Incident-Ablauf.

Bleibt ein Portal dennoch weltweit erreichbar, können Sophos Firewall Threat Feeds mit der Aktion Block bekannte bösartige IPv4-Quellen aus Third-Party Feeds wie Cybora zusätzlich sperren, auch bei Traffic zur Firewall selbst. Domain- oder URL-IoCs schützen einen Login nicht vor einer bösartigen Quell-IP; IPv6-Quellen werden derzeit nicht unterstützt. Threat Feeds sind deshalb Zusatzschutz und kein Ersatz für enge ACLs. Der verlinkte Artikel erklärt Einrichtung, Tests und Allowlisting.

SSH und temporäre Supportregeln

SSH sollte nur bei Bedarf aus einem Management-Netz, über VPN oder für eine feste Support-IP erreichbar sein. Public-Key-Authentifizierung ist zu bevorzugen. Nach einem Supportfall wird die temporäre ACL-Ausnahme gelöscht; ein in der aktuellen Oberfläche nicht bestätigter Deaktivierungsstatus sollte nicht vorausgesetzt werden. Weitere Schritte stehen in Sophos Firewall per SSH verbinden.

CLI-Berechtigung ist nicht gleich SSH-Anmeldung: Das Profil Administrator gewährt laut Profilbeschreibung für SFOS 22/23 vollen CLI-Zugriff, ohne den Transport festzulegen. Die PuTTY-Anleitung derselben Versionen verlangt dagegen für Netzwerk-SSH den Benutzernamen admin und schliesst andere Benutzernamen aus; das betrifft auch die Anmeldung mit Kennwort. Daraus wird hier weder eine SSH-Fähigkeit benannter Administratorkonten noch eine allgemeine Aussage über jeden CLI-Zugang abgeleitet. Die WebAdmin-Funktion Console öffnet eine Konsole im Browser über den WebAdmin-Zugang und ist kein Nachweis einer Netzwerk-SSH-Anmeldung. Ob ein bestimmtes benanntes Konto diesen Browserzugang nutzen kann, muss separat anhand seiner Berechtigungen und der installierten Firmware geprüft werden. Auch die nur dem Default-Admin erlaubte Schlüsselverwaltung ist eine eigene Berechtigung und beantwortet nicht, welche Konten sich per Kennwort über SSH anmelden können.

Vor einer ACL-Änderung den tatsächlichen Rückfallweg prüfen: Für den dokumentierten Netzwerk-SSH-Weg das integrierte Konto admin mit seinen aktuellen Zugangsdaten beziehungsweise einem dafür eingerichteten Schlüssel verwenden. Den gewählten Zugang in einer neuen Sitzung anmelden, die benötigte Konsole öffnen und Konto, Transport sowie Firmwarestand im Change festhalten; ein erreichbarer TCP-Port allein genügt nicht. Ein funktionierender Browser-Console-Zugang hängt weiter vom WebAdmin-Pfad ab und ist bei dessen Sperrung kein unabhängiger Rückweg. Wird ein benanntes Konto als SSH-Rückfallweg benötigt oder widerspricht das beobachtete Verhalten der Anleitung, die Änderung stoppen, einen bereits getesteten autorisierten Zugang behalten und den genauen Konto-/Transportumfang mit Sophos Support klären. Weder die ACL verbreitern noch wiederholte Anmeldeversuche als Ersatz für diese Klärung verwenden.

Eine abgelaufene Ausnahme entfernt man unter Administration > Device access > Local service ACL exception rule mit Delete bei der betreffenden Regel und bestätigt mit OK. Vorher wird der weiterhin benötigte Adminweg getestet; danach prüft man, dass die frühere Supportquelle keinen Zugang mehr hat. Ein eingetragenes Ablaufdatum ist hier eine Review-Vorgabe, kein nachgewiesener automatischer Löschmechanismus.

Troubleshooting

Bei einem plötzlich nicht erreichbaren Login prüft man zusätzlich Administration > Admin and user settings > Login security > Block login. Die Sperre hängt von fehlgeschlagenen Anmeldungen und der Quell-IP ab und kann WebAdmin, CLI, VPN Portal und User Portal betreffen. Sie ist keine ACL-Regel. Fehlgeschlagene CAPTCHA-Versuche zählen nicht zu diesen Anmeldeversuchen. Man prüft die konfigurierte Sperrdauer und die Ereignisse, statt HTTPS für eine ganze Zone freizugeben oder die Schutzfunktion pauschal abzuschalten.

Wenn ein lokaler Dienst nicht wie erwartet erreichbar oder gesperrt ist, prüft man in dieser Reihenfolge:

1. Ziel und Port: Stimmt die Firewall-IP, und verwendet der Dienst den erwarteten Port?
2. Quellzone: Kommt der Client direkt aus der erwarteten Zone, über VPN oder über den Web Proxy?
3. Zonentabelle: Ist der Dienst unter Administration > Device access für diese Zone erlaubt?
4. ACL-Ausnahmen: Stimmen IP-Version, Quellzone, Quellobjekt, Destination host, Service, Action und Position?
5. Port Sharing: Teilen VPN Portal und SSL VPN Port und Protokoll?
6. API: Stimmen API-Aktivierung, Allowed IP hosts und HTTPS Device Access gleichzeitig?
7. DNS: Ist DNS für interne Clients erlaubt? Bei WAN-Veröffentlichung ist zusätzlich Publish on WAN nötig.
8. Logs: Zeigt der Log Viewer ergänzende Dienst- oder Anmeldeereignisse?
9. Packet Capture: Trace vor dem erneuten Test starten. Der erlaubte Zugriff muss funktional gelingen und zeigt typischerweise Status: Consumed; der blockierte Versuch zeigt typischerweise Status: Violation und Reason: LOCAL_ACL. Die Rule-ID ist keine ID der ACL-Ausnahme. Die Bedienung erklärt Sophos Firewall Packet Capture.

Bleibt WebAdmin oder ein Portal trotz deaktivierter Quellzone erreichbar, testet man als Erstes den Web Proxy und Port Sharing. Eine zusätzliche Firewall-Regel löst dieses Problem nicht.

Für die längerfristige Nachvollziehbarkeit eignen sich Central Firewall Reporting oder Sophos Firewall Syslog an SIEM senden.

Betriebscheckliste

• WebAdmin ist nicht breit aus WAN, Gast-, IoT- oder VoIP-Zonen erreichbar.
• HTTPS, SSH und SNMP sind auf konkrete Management- oder Monitoring-Quellen begrenzt.
• User Portal, VPN Portal und SSL VPN sind nur aktiv, wenn das Betriebskonzept sie benötigt.
• VPN Portal und SSL VPN teilen nicht denselben Port und dasselbe Protokoll.
• Der Web-Proxy-Zugriff auf lokale HTTP/HTTPS-Dienste wurde separat getestet.
• API access, Allowed IP hosts und HTTPS Device Access sind aufeinander abgestimmt.
• Temporäre ACL-Ausnahmen enthalten Zweck und Ablaufdatum und werden nach Abschluss gelöscht.
• Erlaubte und gesperrte Quellen wurden getestet; Logs bestätigen das Ergebnis.
• Die Regeln werden regelmässig auf veraltete Quellen, unnötige Dienste und breite Accept-Ausnahmen geprüft.

Quellenqualifikationen

STAS dient der Benutzerauthentifizierung; es ist weder ein VPN noch ein verschlüsselter Administrationskanal. Seine Freigabe als Authentifizierungsdienst ersetzt keinen geschützten Managementzugang.

Die aufbewahrten SSH-Schlüsselanweisungen für SFOS 22/23 sind mehrdeutig: Sie nennen RSA/DSA mit mindestens 2048 Bit und ECDSA unter Ausschluss von ED25519. Daraus darf weder ED25519-Unterstützung noch eine DSA-Empfehlung abgeleitet werden. Vor der Registrierung den unterstützten Algorithmus der tatsächlichen Firmware bestätigen; nur den öffentlichen Schlüssel hochladen und einen separaten Wiederherstellungsweg behalten. Eine Device-Access-Freigabe bestätigt keinen Schlüsselalgorithmus.

Adaptive Learning umfasst auch URLs erkannter Viren, Bedrohungsnamen/-URLs/-IP-Adressen, Quell-IP-Adressen und verwendete Anwendungen. Das standardmässige HTTPS-Reporting umfasst Geräte-, Firmware- und Lizenzdaten (ohne Eigentümerinformationen), Feature-/HA-/Cloud-Management-Status, Objektanzahlen, Fehler sowie CPU-/Speicher-/Datenträgernutzung in Prozent. Dies ist eine Entscheidung über die Datenweitergabe, keine ACL-Steuerung. Sophos Assistant ist standardmässig aktiviert; zum Abschalten unter Administration > Admin and user settings das Kontrollkästchen Turn on Sophos Assistant deaktivieren, Apply wählen und anschliessend ab- und wieder anmelden. Dies schaltet die Telemetrie nicht ab.

FAQ