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.

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, 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.

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. Administratoren mit dem Profil Administrator können CLI-Zugriff erhalten; 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.
• 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.

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.

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. 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 Central 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.
• SSL VPN verwendet standardmässig TCP oder UDP 8443.
• 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.

Enge Local Service ACL Exception Rule erstellen

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. Description: Zweck, Ticket und geplantes Ablaufdatum dokumentieren.
3. Rule position: Für eine spezifische WAN-Ausnahme Top wählen und die übrigen Regeln auf Überschneidungen prüfen.
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

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.

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.

Ä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.

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 Central.
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: Funktioniert die erlaubte Quelle nach dem Entfernen der breiten Freigabe nicht oder erreicht eine gesperrte Quelle den Dienst weiterhin, stellt man die breite Freigabe über den unabhängigen Adminweg sofort wieder her. Danach wird die neue oder eine widersprüchliche ACL-Regel korrigiert und der Ablauf 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.

Third-Party Threat Feeds können systembestimmten Traffic blockieren, wenn die Feed-Aktion Block ist und die Quelladresse als passender IPv4-IoC enthalten ist. Domain- oder URL-IoCs schützen einen Login-Endpunkt nicht vor einer bösartigen Quell-IP; auch IPv6-Quellen werden damit derzeit nicht abgedeckt. Threat Feeds sind deshalb Zusatzschutz und kein Ersatz für enge ACLs. Planung und Allowlisting erklärt Sophos Firewall Threat Feeds.

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.

Troubleshooting

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.

FAQ