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.

Für den übergeordneten Hardening-Kontext passt der Hub Sophos Firewall Hardening: Best Practices für eine sichere Konfiguration.

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.

Wichtig ist auch die API: Die Device-Access-Freigabe für HTTPS/WebAdmin wirkt auch auf API-Zugriffe. Seit SFOS 22 werden API-Zugriffsquellen zusätzlich unter Administration > API access gepflegt, aber ein erlaubter API-Host hilft nicht, wenn Device Access den lokalen HTTPS-Zugriff aus dieser Zone blockiert.

⚠️ 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.

Für die Praxis hilft diese Trennung:

• Device Access Zonentabelle: Dienst grundsätzlich pro Zone erlauben oder sperren, zum Beispiel DNS für LAN, Ping für eine Monitoring-Zone oder SSL VPN für eine benötigte Remote-Access-Zone.
• Local Service ACL Exception Rule: Zugriff enger nach Quelle, Ziel und Dienst steuern, zum Beispiel WebAdmin nur aus dem Management-Netz, SSH nur von einer Support-IP oder SNMP nur vom Monitoring-System.
• Normale Firewall-Regel: Traffic durch die Firewall erlauben oder blockieren, zum Beispiel wenn ein Client aus LAN auf einen Server in DMZ oder auf einen Internetdienst zugreift.

Damit wird klar: Eine Firewall-Regel ersetzt keine Device-Access-Härtung. Wenn HTTPS oder SSH über Device Access zu breit erreichbar ist, erreicht ein Client den lokalen Dienst der Firewall, bevor eine klassische Durchgangsregel überhaupt die richtige Prüfstelle wäre.

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.

Für Custom Zones sollte man zusätzlich die Zoneneinstellungen prüfen. Lokale Dienste können dort ebenfalls beeinflusst werden. Trotzdem bleibt Administration > Device access der zentrale Ort, an dem man lokale Firewall-Dienste bewusst freigibt oder einschränkt.

Typische Beispiele:

• HTTPS: WebAdmin-Zugriff aus dem Management-Netz. Nicht breit aus WAN erlauben.
• SSH: CLI-Zugriff für Admins oder Support. Nur gezielt erlauben, bevorzugt mit Public Key.
• Ping/Ping6: Monitoring und einfache Erreichbarkeitstests. Nicht unnötig aus unsicheren Zonen aktivieren.
• DNS: Clients verwenden die Firewall als DNS-Resolver. Nur für interne Client-Zonen aktivieren.
• SSL VPN: SSL-VPN-Benutzer bauen eine Verbindung zur Firewall auf. Extern nur so offen wie nötig und mit MFA absichern; Port separat im Remote-Access-Bereich prüfen.
• User Portal: Benutzer laden VPN-Konfigurationen oder Tokens. Extern möglichst über VPN/ZTNA oder eng begrenzt.
• VPN Portal: Remote-Access-VPN-Benutzer. Nur wenn wirklich benötigt und mit MFA absichern.
• RED: RED Appliances verbinden sich mit der Firewall. Nur für echte RED-Standorte oder definierte Quellen erlauben.
• SMTP Relay: Interne Systeme nutzen die Firewall als SMTP Relay. Nicht als offenes Relay aus unsicheren Zonen freigeben.
• SNMP: Monitoring fragt Firewall-Werte ab. Nur vom Monitoring-System erlauben; Details stehen in SNMP Hardware Monitoring.
• Dynamic Routing: Routing-Protokolle zwischen Routern und Firewall. Nur in dafür vorgesehenen Netzwerksegmenten aktivieren.

In SFOS 22 unterstützen WebAdmin, VPN Portal und User Portal TLS 1.3. Das ist gut für die Verschlüsselung, ändert aber nichts am Grundprinzip: Ein Dienst, der aus zu vielen Quellen erreichbar ist, bleibt eine unnötige Angriffsfläche. Transportverschlüsselung ersetzt keine saubere ACL.

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:

• DNS: Die Firewall beantwortet DNS-Anfragen aus Netzen, die sie nicht bedienen soll.
• Dynamic Routing: Routing-Protokolle sind aus falschen Segmenten erreichbar.
• HTTPS: Die WebAdmin Console ist für zu viele Quellen erreichbar.
• Ping/Ping6: Die Firewall ist unnötig leicht sichtbar und scanbar.
• RED: RED-Dienste sind aus zu breiten Quellbereichen erreichbar.
• SMTP Relay: Fehlkonfigurationen können Relay-Missbrauch begünstigen.
• SNMP: Monitoring-Daten sind aus falschen Netzen abfragbar.
• SSH: Direkter CLI-Zugriff auf die Firewall ist zu offen.
• SSL VPN: VPN-Anmeldepunkte sind weltweit erreichbar und werden gescannt.
• User Portal: Portal-Login und VPN-Downloads sind unnötig exponiert.
• VPN Portal: Remote-Access-Portal ist Ziel von Bots und Brute-Force-Versuchen.

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.

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

Entscheidungsmodell für lokale Dienste

Für jeden lokalen Dienst sollte man bewusst entscheiden, welches Zugriffsniveau passend ist. Es ist selten sinnvoll, WebAdmin, SSH, User Portal, VPN Portal, DNS und SNMP gleich zu behandeln.

• Deaktiviert: Passend, wenn der Dienst in der Umgebung nicht benötigt wird. Beispiel: SSH dauerhaft aus, wenn kein CLI-Zugriff vorgesehen ist.
• Nur interne Zone: Passend, wenn der Dienst von vielen internen Clients gebraucht wird. Beispiel: DNS aus LAN, wenn Clients die Firewall als DNS-Resolver verwenden.
• Management-Netz: Passend für administrative oder monitoringbezogene Dienste. Beispiel: HTTPS, SSH und SNMP nur aus Management.
• Admin-VPN: Passend, wenn Admins extern arbeiten sollen, aber nicht direkt aus dem Internet. Beispiel: WebAdmin nur über VPN erreichbar.
• ACL Exception Rule: Passend, wenn Zugriff aus einer sehr konkreten Quelle kommen soll. Beispiel: Eine Support-IP darf temporär auf HTTPS oder SSH zugreifen.
• WAN breit erreichbar: Nur für echte Remote-Access-Dienste und mit Zusatzschutz. Beispiel: SSL VPN für mobile Benutzer mit MFA, Logging und Threat Feeds.

Diese Entscheidung sollte dokumentiert werden. Besonders bei Ausnahmen aus WAN muss später nachvollziehbar sein, warum der Dienst erreichbar ist, wer ihn braucht und wann die Ausnahme erneut geprüft wird.

WAN-Zugriff ist eine Ausnahme

WAN ist nicht einfach eine weitere Zone. Alles, was aus WAN erreichbar ist, wird von Scannern, Bots und Brute-Force-Werkzeugen gefunden. Darum sollte WebAdmin aus WAN nicht als normale Betriebsvariante geplant werden.

Wenn externer Managementzugriff gebraucht wird, sind diese Varianten meist sicherer:

• Sophos Central Firewall Management für administrative Aufgaben.
• Admin-VPN mit MFA und klarer Benutzergruppe.
• Eine temporäre ACL Exception Rule für eine feste Quell-IP.
• Ein dediziertes Management-Netz über Site-to-Site VPN.

Für das allgemeine Härtungsbild passt zusätzlich Sophos Firewall Health Check richtig nutzen, weil dort Managementzugriffe, MFA, Backups und Regelhygiene zusammen bewertet werden.

Sophos schützt WebAdmin zusätzlich davor, für alle WAN-Quellen freigegeben zu werden. Wenn WAN-Zugriff wirklich nötig ist, muss er über spezifische Quellen wie einzelne IPs, Netze oder FQDN-Objekte begrenzt werden. Bestehende Altfreigaben aus älteren Konfigurationen sollten regelmässig geprüft werden: Sophos kann bestimmte breite WAN-Freigaben für WebAdmin oder User Portal nach längerer Inaktivität automatisch deaktivieren, während gezielte ACL-Ausnahmen für konkrete WAN-Quellen weiter gelten können.

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.

Typischer Ablauf für eine enge Admin-Ausnahme aus dem WAN:

1. Rule name setzen, zum Beispiel admin-https-from-support-ip.
2. Rule position auf Top setzen, wenn eine bestehende Drop- oder Allow-Regel sonst vorher greifen könnte.
3. IP version passend zur Quelle auswählen, meistens IPv4.
4. Source zone auf WAN setzen.
5. Source Network / Host auf die konkrete Admin-IP, ein kleines Admin-Netz oder ein gepflegtes FQDN-/IP-Objekt setzen.
6. Destination host auf die betroffene Firewall-Adresse oder das Interface begrenzen, wenn nicht bewusst alle lokalen Ziele gemeint sind.
7. Services auf den benötigten lokalen Dienst setzen, zum Beispiel HTTPS für WebAdmin oder API, nicht gleichzeitig HTTPS und SSH aus Bequemlichkeit.
8. Action auf Accept setzen.
9. Speichern und sofort aus erlaubter und nicht erlaubter Quelle testen.

Eine ACL Exception Rule besteht im Wesentlichen aus diesen Feldern:

• Rule name: Eindeutiger Name, zum Beispiel admin-https-from-mgmt.
• Rule position: Reihenfolge der ACL-Regeln.
• Source zone: Zone, aus der der Zugriff kommt, zum Beispiel WAN, LAN oder VPN.
• Source Network / Host: Erlaubte Admin-IP, Management-Netz, FQDN Host oder IP-Liste.
• Destination host: Firewall-IP oder Interface, auf das zugegriffen wird.
• Services: Lokaler Dienst, zum Beispiel HTTPS, SSH, Ping oder DNS.
• Action: Accept oder Drop.

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.

Für API-Automation gilt dieselbe Logik. Ein Host kann unter Administration > API access erlaubt sein und trotzdem scheitern, wenn die HTTPS-Freigabe unter Device Access fehlt. Umgekehrt sollte eine HTTPS-Freigabe nicht breiter werden, nur weil ein API-Tool angebunden wird. Für API-Details passt Sophos Firewall API Zugriff sicher begrenzen.

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.

Der Destination host ist besonders wichtig, wenn die Firewall mehrere Interfaces, Alias-Adressen, VPN-Adressen oder separate Portal-/Admin-Ziele hat. Eine Regel sollte möglichst genau auf die Firewall-Adresse zeigen, die wirklich administriert oder genutzt werden soll. Sonst wirkt eine eigentlich enge Quellfreigabe plötzlich auf mehr lokale Dienste oder Interfaces als geplant.

Vor der Änderung Lockout vermeiden

Device-Access-Änderungen wirken direkt auf Management- und Portalzugriffe. Deshalb sollte vor jeder Einschränkung klar sein, wie man wieder auf die Firewall kommt, wenn eine Regel falsch greift.

Vor dem Speichern einer riskanten Änderung sollte man prüfen:

• Ist ein zweiter Admin mit passendem Rechteprofil verfügbar?
• Gibt es Zugriff über ein anderes Netz, zum Beispiel Management-LAN, Admin-VPN oder Sophos Central?
• Ist lokale Konsolen- oder Out-of-Band-Erreichbarkeit vorhanden, falls WebAdmin nicht mehr erreichbar ist?
• Wird gerade an einem HA-Cluster gearbeitet, bei dem ein Rollenwechsel den Zugriffspfad ändern kann?
• Sind aktuelle Backup-Datei, Secure Storage Master Key und Notfallzugriff dokumentiert?
• Gibt es ein kurzes Wartungsfenster, in dem Fehlzugriffe sofort bemerkt werden?

Gerade bei Remote-Standorten sollte man nicht zuerst die breite Freigabe entfernen und danach testen. Sicherer ist der umgekehrte Ablauf: neue enge ACL Exception Rule erstellen, erlaubten Zugriff testen, zweiten Admin-Weg bestätigen und erst dann die alte breite Zonenfreigabe reduzieren.

Änderungen sicher ausrollen

Device-Access-Änderungen können Admins aussperren. Deshalb sollte man sie nicht nebenbei ändern, sondern wie eine Management-Änderung behandeln.

Bewährter Ablauf:

1. Aktuellen Zugriff dokumentieren: WebAdmin, SSH, User Portal, VPN Portal, SSL VPN, DNS, SNMP und Ping.
2. Sicherstellen, dass ein zweiter Admin-Weg vorhanden ist, zum Beispiel lokale Konsole, Admin-VPN oder Sophos Central.
3. Backup erstellen, bevor grössere ACL-Änderungen umgesetzt werden.
4. Neue ACL Exception Rule möglichst spezifisch erstellen.
5. Zugriff aus der erlaubten Quelle testen.
6. Zugriff aus einer nicht erlaubten Quelle testen.
7. Log Viewer prüfen, ob die erwarteten Events sichtbar sind.
8. Alte breite Zonenfreigabe erst entfernen, wenn der neue Zugriff bestätigt ist.
9. Änderung mit Datum, Quelle, Dienst und Verantwortlichem dokumentieren.

Wenn mehrere Firewalls oder HA-Cluster betroffen sind, sollte die Änderung zuerst an einem System mit guter Rückfallmöglichkeit getestet werden. Für HA-Umgebungen passt zusätzlich Sophos Firewall High Availability einrichten, weil Managementzugriffe, Rollenwechsel und Wartungsfenster dort zusammen betrachtet werden müssen.

Nachkontrolle nach Device-Access-Änderungen

Nach einer Anpassung reicht es nicht, nur den eigenen WebAdmin-Zugriff zu prüfen. Man sollte sowohl erlaubte als auch nicht erlaubte Quellen testen, sonst bleibt unklar, ob die Härtung wirklich wirkt.

• WebAdmin aus Management-Netz: Zugriff funktioniert wie geplant.
• WebAdmin aus normalem Clientnetz: Zugriff ist blockiert, wenn nicht ausdrücklich erlaubt.
• SSH aus Admin-Netz: Zugriff funktioniert nur, wenn SSH bewusst freigegeben ist.
• SSH aus WAN oder Gastnetz: Zugriff ist blockiert.
• DNS aus Clientnetz: DNS funktioniert nur in Netzen, die die Firewall als Resolver nutzen sollen.
• User Portal oder VPN Portal: Nur benötigte Portale sind erreichbar.
• SNMP vom Monitoring-System: Monitoring funktioniert, andere Quellen sind blockiert.

Wenn ein Zugriff unerwartet funktioniert, sollte nicht nur die ACL Exception Rule geprüft werden. Auch die Zonentabelle im oberen Device-Access-Bereich, Custom-Zone-Einstellungen, VPN-Zone, Proxy-Verhalten und vorhandene breite Accept-Regeln können die Ursache sein.

Für die Dokumentation reicht oft eine kurze Liste pro Dienst:

• HTTPS: erlaubte Quelle mgmt-net, Grund Adminzugriff WebAdmin, Review quartalsweise.
• SSH: erlaubte Quelle support-ip-temporary, Grund Supportfall, Review nach Ticketabschluss.
• SNMP: erlaubte Quelle monitoring-server, Grund Hardware- und Interface-Monitoring, Review halbjährlich.
• SSL VPN: erlaubte Quelle WAN, Grund Remote Access, Review mit monatlicher Logprüfung.

Bei jeder Nachkontrolle sollte zusätzlich geprüft werden, ob erfolgreiche und blockierte Zugriffe überhaupt sichtbar sind. Für kurze Tests reicht oft der Log viewer. Für längere Aufbewahrung oder Audit-Fragen sind Central Reporting oder Syslog besser geeignet, weil lokale Logs rotiert oder in Störfällen verloren gehen können.

Empfohlene Grundkonfiguration

Für viele produktive Umgebungen ist folgende Logik sinnvoll:

• HTTPS/WebAdmin nur aus Management, Admin-VPN oder einer festen Admin-IP erlauben.
• API nur aus definierten Automations- oder Monitoring-Hosts erlauben und zusätzlich HTTPS über Device Access passend begrenzen.
• 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; die Einrichtung steht in MFA für Sophos Firewall WebAdmin, VPN Portal und Remote Access aktivieren.
• Sophos Central Firewall Management verwenden, wenn ein sicherer externer Management-Zugriff benötigt wird.

Für längere Nachvollziehbarkeit sollte man auch die Logstrategie prüfen. Lokale Logs reichen für akute Fehlersuche, aber nicht für jede Audit- oder Incident-Response-Frage. Wenn Portal- oder Managementzugriffe langfristig nachvollziehbar sein müssen, sind Central Firewall Reporting oder Sophos Firewall Syslog an SIEM senden die passenderen Bausteine.

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.

Der eigene Artikel Sophos Firewall Threat Feeds erklärt Planung, Allowlisting und Betrieb.

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.

Wenn Portale aus dem Internet erreichbar bleiben müssen, sollte man nicht nur die Checkbox prüfen. Wichtig sind MFA, Benutzergruppen, Token-/Provisioning-Prozess, Ablauf von temporären Benutzern, Logging und die Frage, ob das Portal nach dem Rollout noch dauerhaft benötigt wird.

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.

Umgekehrt kann eine breite Accept-Regel oben in der Liste spätere Drop-Regeln praktisch wertlos machen. Nach jeder Regeländerung sollte deshalb nicht nur die neue Regel, sondern auch die Trefferlogik der Regeln darüber geprüft werden.

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.

Betriebscheckliste

• WebAdmin nicht breit aus WAN erreichbar.
• SSH nur temporär oder aus Management-/Admin-Netzen erlaubt.
• DNS nur für Client-Zonen aktiv, die die Firewall wirklich als Resolver verwenden.
• SNMP nur vom Monitoring-System oder Monitoring-Netz erlaubt.
• User Portal, VPN Portal und SSL VPN nur aktiv, wenn sie im Remote-Access-Konzept gebraucht werden.
• MFA für WebAdmin, VPN Portal und Remote Access geprüft.
• API-Zugriff nur aus definierten Hosts erlaubt und mit Device Access abgeglichen.
• ACL Exception Rules mit klarer Quelle, Dienst und Zweck benannt.
• Temporäre Support-Regeln mit Ablaufdatum dokumentiert.
• Zugriff aus erlaubten und nicht erlaubten Quellen getestet.
• Logging, Central Reporting oder Syslog für relevante Portal- und Managementzugriffe geprüft.
• Quartalsweiser Review für WebAdmin, SSH, SNMP, User Portal, VPN Portal und SSL VPN geplant.

FAQ