Sophos Firewall Zugriff absichern: Device Access richtig konfigurieren

Unter Administration > Device access wird festgelegt, aus welchen Zonen lokale Dienste der Sophos Firewall erreichbar sind. Dazu gehören zum Beispiel HTTPS für die WebAdmin Console, SSH für die CLI, Ping, DNS, User Portal, VPN Portal und weitere Dienste.

Dieser Bereich ist sicherheitskritisch. Normale Firewall-Regeln steuern Traffic durch die Firewall. Device access steuert Traffic zur Firewall selbst. Wenn WebAdmin oder SSH aus einer unsicheren Zone erreichbar sind, entsteht ein direkter Management-Zugriff auf das Sicherheitsgerät.

⚠️ WebAdmin, SSH und Portale sollten nur aus vertrauenswürdigen Netzen erreichbar sein. Für produktive Umgebungen ist es besser, den Zugriff auf ein Management-Netz, eine feste Admin-IP, VPN oder Sophos Central Firewall Management zu beschränken.

Warum Device Access nicht wie eine Firewall-Regel funktioniert

Eine typische Firewall-Regel erlaubt oder blockiert Verbindungen zwischen Zonen, zum Beispiel LAN nach WAN oder VPN nach Server. Device Access ist anders: Hier geht es um Dienste, die direkt auf der Sophos Firewall laufen.

Beispiele:

• Ein Admin öffnet https://172.16.16.16:4444.
• Ein Client verwendet die Firewall als DNS-Server.
• Ein Monitoring-System pingt die Firewall.
• Ein Benutzer öffnet das User Portal oder VPN Portal.
• Ein Admin verbindet sich per SSH mit der Firewall.

Solcher Traffic hat als Ziel nicht einen Server hinter der Firewall, sondern die Firewall selbst. Darum wird er über die lokale Service ACL gesteuert.

Das ist auch der Grund, warum Device Access zur Grundhärtung jeder Sophos Firewall gehört. Ein sauberer Regelsatz für LAN-zu-WAN schützt nicht automatisch die Management- und Portal-Dienste der Firewall selbst. Diese Dienste müssen separat geprüft und bewusst eingeschränkt werden.

Zonenfreigaben verstehen

Im oberen Bereich von Administration > Device access sieht man eine Tabelle mit Zonen und Diensten. Wenn bei einer Zone ein Dienst aktiviert ist, darf aus dieser Zone grundsätzlich auf diesen lokalen Dienst zugegriffen werden.

Die Zonentabelle ist praktisch, aber grob und passt für klare interne Zonen, zum Beispiel LAN, Management oder VPN. Sobald ein Dienst nur für einzelne Admin-IP-Adressen, Standorte, Länder oder Support-Ziele erreichbar sein soll, sind Local service ACL exception rules die bessere Wahl.

Typische Beispiele:

Bei Custom Zones kann die Erreichbarkeit lokaler Dienste auch über die Zoneneinstellungen beeinflusst werden. Trotzdem sollte man Device Access immer bewusst prüfen, weil hier die zentrale Übersicht für lokale Firewall-Dienste liegt.

Welche Dienste lassen sich über ACL Rules einschränken?

Über Local Service ACL und ACL Exception Rules kann man lokale Firewall-Dienste sehr fein steuern. Besonders relevant sind diese Dienste:

Je mehr dieser Dienste aus WAN, Gastnetzen, IoT-Netzen oder unscharf definierten Zonen erreichbar sind, desto grösser wird die Angriffsfläche. Ziel ist nicht, alles zu deaktivieren, sondern jeden Dienst nur dort erreichbar zu machen, wo er wirklich gebraucht wird.

Quellen möglichst eng definieren

Eine ACL Rule muss nicht einfach Any erlauben. Als Quelle kann man sehr fein arbeiten, zum Beispiel mit:

• einzelnen Admin-IP-Adressen
• Management-Netzen
• IP ranges
• IP lists
• FQDN hosts
• FQDN host groups
• DNS hosts oder DNS groups
• Country objects oder Ländergruppen
• dedizierten VPN- oder Support-Netzen

Damit lässt sich ein Zugriff deutlich besser begrenzen. Ein Beispiel: Wenn ein externer Support-Dienst nur von einer festen FQDN oder einem definierten IP-Bereich kommt, sollte nicht die ganze WAN-Zone Zugriff auf HTTPS oder SSH erhalten. Wenn ein Monitoring-System SNMP benötigt, sollte nicht ein komplettes Servernetz SNMP auf die Firewall abfragen dürfen.

Bei globalen Remote-Access-Szenarien ist die Abgrenzung schwieriger. Manche Firmen können SSL VPN oder VPN Portal nicht einfach nur für die Schweiz, Deutschland oder ein einzelnes Land freigeben, weil Mitarbeitende weltweit unterwegs sind. In solchen Fällen sollte man zusätzlich mit MFA, Logging, restriktiven Portal-Einstellungen und Threat Feeds arbeiten.

Local Service ACL Exception Rule

Wenn ein Dienst nicht für eine ganze Zone freigegeben werden soll, verwendet man eine Local service ACL exception rule. Damit kann man sehr genau definieren, wer auf welchen lokalen Dienst zugreifen darf.

Pfad:

1. Administration öffnen.
2. Device access auswählen.
3. Zu Local service ACL exception rule scrollen.
4. Add anklicken.

Eine ACL Exception Rule besteht im Wesentlichen aus diesen Feldern:

Für WebAdmin-Zugriff aus dem Internet sollte man niemals Any als Quelle verwenden. Sophos verhindert WebAdmin-Zugriff aus der WAN-Zone für alle Quellen bewusst, weil dies ein hohes Risiko wäre. Wenn WAN-Zugriff wirklich nötig ist, sollte er nur über spezifische Quell-IP-Adressen, definierte Netze, FQDN-Objekte oder andere enge Quellen erlaubt werden.

Wichtig ist auch die Reihenfolge. ACL Exception Rules werden von oben nach unten ausgewertet. Eine höhere Drop-Regel kann eine spätere Accept-Regel unwirksam machen. Umgekehrt kann eine zu breit formulierte Accept-Regel später geplante Einschränkungen aushebeln. Die Regelreihenfolge sollte deshalb genauso bewusst geprüft werden wie bei Firewall-Regeln.

Empfohlene Grundkonfiguration

Für viele produktive Umgebungen ist folgende Logik sinnvoll:

• HTTPS/WebAdmin nur aus Management, Admin-VPN oder einer festen Admin-IP erlauben.
• SSH standardmässig deaktivieren und nur bei Bedarf gezielt per ACL erlauben.
• DNS nur in Zonen aktivieren, in denen Clients die Firewall wirklich als DNS-Server verwenden.
• Ping für interne Monitoring-Systeme erlauben, aber nicht pauschal aus WAN.
• User Portal, VPN Portal und SSL VPN nur aktivieren, wenn sie gebraucht werden.
• RED nur für Standorte oder Quellbereiche erlauben, an denen tatsächlich RED Appliances stehen.
• SNMP nur für das Monitoring-System erlauben.
• SMTP Relay nur für definierte interne Systeme erlauben.
• Dynamic Routing nur in Routing-Segmenten aktivieren, in denen dynamische Routing-Protokolle wirklich eingesetzt werden.
• MFA für WebAdmin, VPN Portal und Remote Access prüfen.
• Sophos Central Firewall Management verwenden, wenn ein sicherer externer Management-Zugriff benötigt wird.

SSH besonders vorsichtig behandeln

SSH ist für Troubleshooting und Support sehr nützlich, sollte aber nicht dauerhaft breit offen sein. Für SSH gilt:

• Nur der Benutzer admin kann sich per SSH anmelden.
• Public-Key-Authentifizierung ist der bevorzugte Weg.
• Zugriff aus WAN sollte nur über feste Quell-IP-Adressen oder VPN erfolgen.
• Nach Abschluss einer Analyse sollte geprüft werden, ob SSH weiterhin benötigt wird.

Mehr dazu steht in der Anleitung Sophos Firewall per SSH verbinden.

Bots, Brute Force und Threat Feeds

In der Praxis sieht man sehr häufig, dass zu offene Dienste sofort von Bots gefunden werden. Besonders betroffen sind WebAdmin, User Portal, VPN Portal und SSL VPN. Auch wenn ein Dienst durch Passwort und MFA geschützt ist, erzeugen öffentliche Logins Angriffsversuche, Brute-Force-Traffic, Lograuschen und unnötige Last auf der Firewall.

Das bedeutet nicht automatisch, dass ein erfolgreicher Angriff stattfindet. Es zeigt aber, dass der Dienst Teil der öffentlichen Angriffsfläche ist. Je weniger Quellen überhaupt bis zum Login kommen, desto besser.

Wenn ein Portal weltweit erreichbar sein muss, reichen Länderfilter oder einzelne Quell-IP-Adressen oft nicht aus. In solchen Umgebungen empfehlen wir zusätzlich Third-Party Threat Feeds. Threat Feeds liefern der Firewall laufend aktuelle Indicators of Compromise, zum Beispiel bösartige IP-Adressen, Domains oder URLs. Bekannte Scanner, Botnetze und Angreifer können dadurch blockiert werden, bevor sie WebAdmin, VPN Portal, SSL VPN oder andere veröffentlichte Dienste erreichen.

Mehr dazu: Sophos Firewall Threat Feeds

Häufige Fehler

Firewall-Regel statt Device Access geprüft

Wenn WebAdmin, SSH, DNS oder Ping zur Firewall nicht erreichbar sind, hilft eine normale Firewall-Regel nicht. Der Traffic geht nicht durch die Firewall hindurch, sondern endet auf der Firewall selbst. Darum muss Administration > Device access geprüft werden.

WebAdmin aus zu vielen Zonen erlaubt

WebAdmin sollte nicht aus jeder internen Zone erreichbar sein. Ein Gastnetz, IoT-Netz oder VoIP-Netz braucht normalerweise keinen Zugriff auf die Firewall-Verwaltung. Auch intern sollte man davon ausgehen, dass kompromittierte Clients existieren können. Ein separates Management-Netz oder ein Admin-VPN reduziert dieses Risiko deutlich.

DNS nicht für Client-Zone aktiviert

Wenn Clients die Firewall als DNS-Server verwenden sollen, muss DNS für die passende Zone erlaubt sein. Sonst erreichen die Clients zwar die Firewall-IP, bekommen aber keine DNS-Antwort. Umgekehrt sollte DNS nicht aus Zonen erlaubt sein, in denen die Firewall gar nicht als DNS-Resolver verwendet werden soll.

User Portal und VPN Portal verwechselt

Das User Portal und das VPN Portal sind unterschiedliche Dienste. Je nach Remote-Access-Konzept muss geprüft werden, welches Portal wirklich benötigt wird. Oft wird ein Portal aktiviert, weil ein Benutzer einmal eine Konfiguration herunterladen musste, danach bleibt es aber jahrelang offen. Solche Altlasten sollte man regelmässig entfernen.

Web Proxy Sonderfall übersehen

Wenn der Web Proxy verwendet wird, können HTTP- und HTTPS-Anfragen aus Proxy-Sicht intern wirken. Das kann Auswirkungen darauf haben, wie Zugriffe auf WebAdmin, Captive Portal, VPN Portal oder User Portal kontrolliert werden. In Umgebungen mit Proxy sollte man deshalb besonders genau testen, welche Zugriffe wirklich möglich sind.

ACL-Regel zu breit formuliert

Eine ACL Exception Rule mit Source zone: Any, Source Network / Host: Any und Services: HTTPS, SSH ist fast nie eine gute Idee. Solche Regeln umgehen den eigentlichen Sicherheitsgewinn der ACL-Ausnahme. Besser ist eine kleine, klare Regel mit einer eindeutigen Quelle und genau den benötigten Diensten.

Drop-Regel an falscher Position

Wenn eine Drop-Regel oberhalb einer Accept-Regel liegt, kann der erlaubte Zugriff trotzdem blockiert werden. Bei ACL Exception Rules ist die Reihenfolge deshalb genauso wichtig wie bei Firewall-Regeln.

SSL VPN und VPN Portal zu offen gelassen

Remote Access muss oft von aussen erreichbar sein. Trotzdem sollte man prüfen, ob alle Länder, Netze und Benutzergruppen wirklich Zugriff benötigen. Wenn keine enge Quellbegrenzung möglich ist, sollten MFA, Logging und Threat Feeds umso konsequenter eingesetzt werden.

Troubleshooting

Wenn ein lokaler Dienst nicht erreichbar ist, hilft diese Reihenfolge:

1. Stimmt die Ziel-IP der Firewall?
2. Kommt der Client aus der erwarteten Zone?
3. Ist der Dienst in Administration > Device access für diese Zone erlaubt?
4. Gibt es eine passende Local service ACL exception rule?
5. Greift eventuell eine höhere ACL-Regel mit Drop?
6. Ist der Dienst auf einem anderen Port konfiguriert?
7. Wird der Zugriff über VPN, Proxy oder NAT anders gesehen als erwartet?
8. Zeigt der Log Viewer einen Hinweis?
9. Kann Packet Capture den Verbindungsversuch auf dem Interface sehen?

Für Support-Zugriffe kann es sinnvoll sein, eine gezielte ACL Exception Rule zu erstellen und diese nach Abschluss wieder zu entfernen oder zu deaktivieren.

Weitere Informationen

• Sophos Firewall - Device access
• Sophos Firewall - Device access best practices
• Sophos Firewall per SSH verbinden
• MFA für Sophos Firewall WebAdmin, VPN Portal und Remote Access aktivieren