Sophos Firewall Administratoren und Profile sicher einrichten

Für die tägliche Administration sollte jede Person ein eigenes Konto erhalten. Dazu wird zuerst ein passendes Device-Access-Profil erstellt und danach unter Authentication > Users ein lokaler Benutzer mit User type: Administrator angelegt. Das Profil bestimmt, was der Administrator sehen oder ändern darf. MFA, Login-Quellen und Device Access schützen zusätzlich die Anmeldung und die Erreichbarkeit des WebAdmin.

Der Default-Administrator admin bleibt als getesteter Notfallzugang erhalten und wird nicht als gemeinsames Alltagskonto verwendet. So bleiben Änderungen einer Person zuordenbar und ein Fehler in einem eingeschränkten Profil sperrt nicht den letzten Recovery-Weg.

Lokalen Administrator in acht Schritten einrichten

1. Backup, Default-Administrator und Recovery-Zugang prüfen. Eine bestehende Admin-Sitzung bleibt bis zum erfolgreichen Test geöffnet.
2. Aufgabe und benötigte Rechte schriftlich festlegen, beispielsweise nur Diagnose oder zusätzlich Änderungen an Netzwerkobjekten.
3. Unter Profiles > Device access > Add ein eigenes Profil erstellen und nicht benötigte Bereiche auf None lassen.
4. Unter Authentication > Users > Add einen persönlichen Benutzernamen eintragen und User type auf Administrator setzen.
5. Das neue Profil, ein starkes eigenes Passwort und die geschäftliche E-Mail-Adresse zuweisen.
6. Unter Administrator advanced settings bei Bedarf Schedule for device access und Login restriction for device access begrenzen.
7. Prüfen, dass Local unter Authentication > Services > Administrator authentication methods weiterhin verfügbar ist. Danach MFA und den WebAdmin-Zugriff aus dem Managementnetz konfigurieren.
8. Das Konto in einem privaten Browserfenster positiv und negativ testen. Erst danach weitere Konten umstellen oder alte Zugänge deaktivieren.

⚠️ Ein neues Profil wird erst produktiv verwendet, wenn ein zweiter funktionierender Administrator und ein dokumentierter Recovery-Weg vorhanden sind. Das integrierte Profil Administrator gibt Vollzugriff und gehört nur zum kleinsten notwendigen Personenkreis.

Die fünf Schutzebenen auseinanderhalten

Bei Admin-Zugängen greifen mehrere Einstellungen zusammen. Sie lösen unterschiedliche Aufgaben und ersetzen einander nicht:

• Benutzerkonto: Identifiziert die Person. Persönliche Konten machen Änderungen nachvollziehbar; Teamkonten wie firewalladmin verwischen diese Zuordnung.
• Device-Access-Profil: Legt mit None, Read-only und Read-write fest, welche Menüs und Funktionen sichtbar oder änderbar sind. Die Rechte gelten auch für die API.
• Schedule und Login Restriction: Begrenzen, wann und von welchen IPv4-Adressen dieses konkrete Administratorkonto den WebAdmin verwenden darf.
• Device Access und Local Service ACL: Legen fest, aus welchen Zonen und Quellen der WebAdmin überhaupt erreichbar ist. Die Umsetzung beschreibt Device Access und Local Service ACL sicher konfigurieren.
• MFA und Audit Trail: MFA schützt das Konto zusätzlich zum Passwort. Der Audit Trail hilft, unterstützte Änderungen einer Identität, Quelle und Konsole zuzuordnen. Für Data Anonymization in Logs und Reports werden zusätzlich mindestens zwei persönliche Authorizer mit getrennten Konten vorbereitet.

Ein Read-only-Profil schützt beispielsweise nicht vor Passwortdiebstahl. MFA wiederum verhindert nicht, dass eine unnötig öffentlich erreichbare Loginseite angegriffen wird. Erst das Zusammenspiel reduziert sowohl Rechte als auch Angriffsfläche.

Ein Login-Disclaimer und angepasste Messages ergänzen diese Ebenen nur um sichtbare Hinweise. Die Zustimmung erweitert weder das Device-Access-Profil noch die Netzwerkfreigabe und ersetzt keine der fünf Kontrollen.

Default-Admin, lokale Konten und zentrale Identitäten

Der Default-Benutzer admin besitzt die Rechte des integrierten Profils Administrator. Er eignet sich als lokaler Notfallzugang, aber nicht als gemeinsam genutztes Tageskonto. Passwort, MFA, Konsolenzugang und Recovery-Ablauf müssen unabhängig von den persönlichen Konten dokumentiert und getestet sein.

Persönliche lokale Administratoren passen zu kleinen Teams, isolierten Firewalls und als bewusster Fallback. Grössere Teams können Admin-Rollen über Microsoft Entra ID SSO für WebAdmin, TACACS+ mit lokaler Profilzuweisung oder über Sophos Central Administrationsrollen verwalten. Ein unter Authentication > Users mit Managed by Central gekennzeichneter Benutzer wird in Central verwaltet und lässt sich nicht lokal bearbeiten.

Automationen erhalten kein persönliches Tageskonto. Für die XML API wird ein separates Servicekonto mit eigenem Owner, begrenzten Rechten und fester Quellfreigabe verwendet. Den vollständigen Schutzpfad zeigt Sophos Firewall XML API Zugriff absichern.

Device-Access-Profil planen

Unter Profiles > Device access stellt Sophos einige nicht editierbare Standardprofile bereit:

• Administrator: Vollzugriff auf WebAdmin und API. Sophos beschreibt das Profil auch mit CLI-Vollzugriff; der direkte SSH-Login ist in SFOS trotzdem nur mit dem Default-Benutzernamen admin möglich.
• Audit admin: Lese- und Schreibzugriff auf Logs und Reports.
• Crypto admin: Lese- und Schreibzugriff für Sicherheitszertifikate.
• HAProfile: Read-only-Zugriff auf die Auxiliary Appliance eines HA-Clusters.
• Security admin: Schreibzugriff auf die Funktionen ausser Profilen, Logs und Reports.

Diese Profile sind praktische Ausgangspunkte, aber nicht automatisch die passende Rolle für den eigenen Betrieb. Ein eigenes Profil ist besser, wenn eine Person nur einen klar begrenzten Aufgabenbereich benötigt.

Rechte aus der Aufgabe ableiten

Die Profilbezeichnung allein hat keine technische Wirkung. Ein Profil namens ReadOnly kann weiterhin Schreibrechte enthalten. Entscheidend ist die vollständige Berechtigungsmatrix einschliesslich der aufgeklappten Untermenüs.

Für ein Helpdesk-Konto kann man beispielsweise so planen:

• Diagnose, Logs und die für den Support benötigten Konfigurationsbereiche auf Read-only setzen.
• Read-write nur vergeben, wenn das Team eine konkret benannte Änderung selbst durchführen muss.
• Administratorprofile, Zertifikate und alle nicht benötigten Produktbereiche auf None lassen.
• Für jede Schreibberechtigung ein Beispiel definieren, was erlaubt sein soll, und ein Beispiel, was ausdrücklich nicht erlaubt sein darf.

Ein Network-Operations-Profil darf breiter lesen und beispielsweise ausgewählte Netzwerkbereiche ändern. Es braucht deshalb trotzdem keinen Vollzugriff auf Administratoren, Zertifikate oder andere unabhängige Sicherheitsfunktionen. Least Privilege bedeutet nicht möglichst wenig sichtbare Menüs, sondern genau die Rechte, die für die verantwortete Aufgabe nötig sind.

Eigenes Profil erstellen

1. Profiles > Device access öffnen.
2. Add auswählen.
3. Einen eindeutigen Namen eintragen, beispielsweise SFOS-NOC-Limited.
4. Für jedes sichtbare Menü None, Read-only oder Read-write wählen.
5. Mit Expand die Untermenüs öffnen und abweichende Rechte enger festlegen.
6. Mit Save speichern.
7. Das Profil nochmals gegen die dokumentierten Aufgaben und Negativtests prüfen.

SFOS-NOC-Limited ist nur ein Beispielname. Er wird an Team und Aufgabe angepasst. Die tatsächlich vergebenen Rechte müssen zusätzlich dokumentiert werden, weil der Name die Berechtigungsmatrix nicht erklärt.

Persönlichen lokalen Administrator anlegen

Benutzer erfassen

1. Authentication > Users öffnen.
2. Add auswählen.
3. Unter Username einen dauerhaften persönlichen Namen eintragen, beispielsweise m.mueller. Der Benutzername kann später nicht geändert werden.
4. Einen verständlichen Anzeigenamen und die geschäftliche E-Mail-Adresse erfassen.
5. User type auf Administrator setzen.
6. Unter Profile das zuvor geprüfte Profil SFOS-NOC-Limited auswählen.
7. Ein langes, eindeutiges und sicher übergebenes Passwort setzen. Wird ein häufig verwendetes Passwort oder Wörterbuchwort erkannt, verlangt die Firewall ein stärkeres Passwort.

m.mueller ist ein Muster und wird durch die eindeutige Identität der verantwortlichen Person ersetzt. Funktionsnamen wie noc-admin sollten nur verwendet werden, wenn dahinter wirklich eine einzelne technische Identität mit eigenem Owner steht. Mehrere Personen teilen kein Passwort.

Zeit und Login-Quelle begrenzen

Unter Administrator advanced settings stehen zwei zusätzliche Kontrollen zur Verfügung:

• Schedule for device access: Erlaubt WebAdmin-Anmeldungen nur während des gewählten Zeitplans. Das passt zu temporärem Support oder klaren Betriebszeiten. Für einen Bereitschaftsdienst darf der Zeitplan notwendige Notfalleinsätze nicht unbeabsichtigt blockieren.
• Login restriction for device access: Erlaubt die WebAdmin-Anmeldung nur von ausgewählten IPv4-Adressen oder einem IPv4-Bereich. Für einen Admin-Jump-Host kann beispielsweise 10.20.30.25 als Selected node verwendet werden.

Die Adresse 10.20.30.25 ist ein Beispiel aus einem privaten Netz. Sie wird durch die feste Adresse des eigenen Jump-Hosts oder Management-Arbeitsplatzes ersetzt. Bei wechselnden Clientadressen ist ein Admin-VPN oder ein dediziertes Managementnetz meist sauberer als eine grosse IP-Range.

Access time im normalen Benutzerbereich und Schedule for device access sind nicht dasselbe. Access Time für normale Benutzer und Gruppen steuert den Internetzugriff; für WebAdmin ist die Einstellung unter Administrator advanced settings relevant.

Lokale Authentifizierung erhalten

Unter Authentication > Services > Administrator authentication methods muss die lokale Datenbank für persönliche lokale Administratoren ausgewählt sein. Der Default-Super-Administrator admin ist von dieser Methodenliste ausgenommen, die neu angelegten lokalen Administratoren jedoch nicht.

Die lokale Methode wird nicht entfernt, bevor das neue Konto in einem separaten Browser erfolgreich getestet wurde. Bei externen Authentifizierungsservern bestimmt die Reihenfolge, wohin ein Loginversuch zuerst gesendet wird. Änderungen an dieser Reihenfolge gehören deshalb in denselben Abnahme- und Rollback-Plan wie das Konto selbst.

MFA und Erreichbarkeit absichern

Für interaktive Administratoren sollte MFA aktiviert werden. Persönliche Administratoren werden unter Authentication > Multi-factor authentication für Web admin console aufgenommen. Für den Default-Benutzer admin gilt ein eigener Schalter unter Administration > Device access > MFA for default admin. MFA für Sophos Firewall WebAdmin aktivieren erklärt Pilotgruppe, Token-Registrierung, Login Security und Recovery. MFA wird zuerst mit einem einzelnen neuen Administrator getestet, nicht gleichzeitig mit allen Konten.

Der WebAdmin bleibt zusätzlich auf Managementnetze, VPN oder eng definierte Quellen beschränkt. Eine aktive Login restriction for device access macht eine breite WAN-Freigabe nicht sicher. Umgekehrt ersetzt eine Local Service ACL nicht das persönliche Konto und dessen Rechteprofil.

Auch SSH wird nicht durch einen erfolgreichen WebAdmin-Test freigegeben. SFOS akzeptiert für den direkten SSH-Login nur den Benutzernamen admin; ein persönlicher lokaler WebAdmin wird deshalb nicht als SSH-Konto getestet. SSH braucht zusätzlich eine eigene Device-Access-Entscheidung. Die Public-Key-Verwaltung des Default-Admins und der sichere SSH-Zugang werden in Sophos Firewall per SSH verbinden getrennt behandelt.

Unter Administration > Admin and user settings ergänzen Administrator password complexity, Session-Timeout und Block login die Kontoeinstellungen. Diese Werte gelten systemweit und werden deshalb nicht für ein einzelnes Konto aggressiv verschärft. Besonders Block login kann nach Fehlversuchen die Quell-IP für alle Anmeldedienste sperren; vor dem Test braucht es eine zweite Managementquelle oder den Konsolenzugang.

Rechte und Login sicher testen

Vor dem Test bleiben das bisherige Admin-Fenster und ein unabhängiger Recovery-Weg verfügbar. Mehrere absichtliche Fehlanmeldungen sind ungeeignet, weil Block login die gemeinsame Quell-IP vorübergehend für weitere Anmeldedienste sperren kann.

1. Ein privates Browserfenster öffnen und den WebAdmin über den vorgesehenen FQDN aus dem erlaubten Managementnetz aufrufen.
2. Mit dem neuen Konto und MFA anmelden.
3. Prüfen, ob alle benötigten Menüs sichtbar sind und die vorgesehenen Informationen gelesen werden können.
4. Falls das Profil Schreibrechte enthält, eine ungefährliche, vorab genehmigte Teständerung mit direktem Rollback durchführen.
5. Einen Bereich öffnen, der auf None oder Read-only steht. Das Konto darf dort keine verbotene Änderung speichern können.
6. Einen kontrollierten Login von einer nicht erlaubten Quelle höchstens einmal prüfen. Bei unklarem Ergebnis zuerst Einstellungen und Logs auswerten, nicht weitere Fehlversuche erzeugen.
7. Die Teständerung und den verwendeten Administrator im Configuration Audit Trail prüfen. Nicht jedes Objekt erzeugt dort denselben Detailumfang; die technische Wirkung wird zusätzlich in der betroffenen Funktion kontrolliert.
8. Abmelden, erneut anmelden und erst danach das nächste Konto migrieren.

In einem HA-Cluster wird nach einem geplanten Failover zusätzlich eine frische Anmeldung am jetzt aktiven Node geprüft. Eine bestehende WebAdmin-Sitzung oder deren nahtlose Fortsetzung ist kein verlässliches Erfolgskriterium.

Ein sichtbares Menü beweist noch keine funktionierende Schreibberechtigung. Ein ausgeblendetes Menü beweist nicht, dass andere zugewiesene Funktionen korrekt sind. Positivtest, Negativtest und Audit-Zuordnung gehören deshalb zusammen.

Konten prüfen und sicher entfernen

Admin-Zugänge werden regelmässig gegen Owner, Aufgabe, Profil, MFA, Login-Quelle und letzte Nutzung geprüft. Temporäre Supportkonten erhalten zusätzlich ein dokumentiertes Enddatum. Für einen zeitlich begrenzten Avanet-Fall bleibt der eigene Ablauf Avanet Support-Zugang auf Sophos Firewall einrichten massgebend.

Beim Offboarding ist ein kontrollierter Ablauf sicherer als sofortiges Löschen:

1. Prüfen, ob das Konto in API-Skripten, Passworttresoren, Dokumentationen oder Supportprozessen verwendet wird.
2. Unter Authentication > Users den Status auf inaktiv setzen.
3. In einem privaten Browser prüfen, dass keine neue Anmeldung mehr möglich ist.
4. Aktive WebAdmin-Sitzungen und aktuelle Änderungen separat prüfen. Das Deaktivieren darf nicht ungeprüft als Beweis gelten, dass jede bestehende Sitzung sofort beendet wurde.
5. MFA-Token, Secrets und externe Zuweisungen passend zum Konto entfernen oder rotieren.
6. Nach der vereinbarten Beobachtungszeit den Benutzer löschen, wenn keine Abhängigkeit mehr besteht.
7. Ein nicht mehr benötigtes Custom-Profil erst löschen, wenn es keinem Administrator mehr zugewiesen ist.

Der Default-Administrator bleibt ausserhalb dieses normalen Offboardings. Wird dessen Passwort oder MFA-Zugang verloren, hilft Sophos Firewall Admin-Passwort wiederherstellen bei der Vorbereitung des Recovery-Wegs.

Typische Probleme eingrenzen

Konto existiert, WebAdmin-Anmeldung schlägt aber fehl

Diese Punkte in Reihenfolge prüfen:

• User type ist wirklich Administrator.
• Benutzerstatus ist aktiv und das Passwort stimmt.
• Local ist unter Administrator authentication methods ausgewählt.
• Schedule for device access erlaubt den aktuellen Zeitpunkt.
• Login restriction for device access enthält die tatsächliche IPv4-Quelladresse.
• MFA-Token, Systemzeit und Registrierung sind korrekt.
• Block login hat die Quell-IP nach Fehlversuchen nicht gesperrt.
• Device Access oder eine Local Service ACL erlaubt HTTPS aus dieser Quelle.

Ist die Loginseite gar nicht erreichbar, beginnt die Analyse bei Device Access, Routing und Quelladresse. Ist sie erreichbar, lehnt aber nur dieses Konto ab, sind Benutzer, Profil, Authentifizierungsmethode, Schedule, Login Restriction und MFA die näheren Spuren.

Für die zeitliche Korrelation helfen der Authentication-Bereich im Log Viewer sowie access_server.log für Authentifizierung und Autorisierung. syslog.log ergänzt System- und admin-ausgelöste Ereignisse. Änderungen an unterstützten Objekten werden separat in configuration-audit.log geprüft.

Konto sieht zu viel oder zu wenig

Das zugewiesene Profil und dessen aufgeklappte Untermenüs prüfen. Read-only und Read-write können innerhalb eines Hauptmenüs unterschiedlich gesetzt sein. Danach mit einer neuen Anmeldung erneut testen und nicht nur auf den Profilnamen vertrauen.

Bei Managed by Central kommt die Rolle aus Sophos Central und wird nicht am lokalen Benutzer geändert. Bei Entra SSO entscheidet das Rollen- oder Gruppenmapping des Entra-Servers über das lokale Device-Access-Profil.

WebAdmin funktioniert, API oder SSH aber nicht

Das Device-Access-Profil gilt auch für API-Rechte, aber die API braucht zusätzlich aktivierten API-Zugriff und eine erlaubte Quelle. SSH ist ein eigener lokaler Dienst und kein geeigneter Erfolgstest für ein eingeschränktes WebAdmin-Profil. Ein Konto erhält nicht allein deshalb SSH-Zugriff, weil die WebAdmin-Anmeldung funktioniert.

Betriebscheckliste

• Default-Administrator und Recovery-Weg sind getestet und werden nicht geteilt.
• Jede Person verwendet ein eigenes Konto.
• Profile sind aus Aufgaben abgeleitet und Untermenüs wurden aufgeklappt geprüft.
• Vollzugriff ist auf den kleinsten notwendigen Personenkreis begrenzt.
• MFA, Schedule und Login-Quelle passen zum Einsatzzweck.
• WebAdmin ist nur aus vorgesehenen Managementquellen erreichbar.
• Positive und negative Rechteprüfungen wurden durchgeführt.
• Änderungen sind mit einem persönlichen Admin-Konto im Audit Trail, soweit unterstützt, nachvollziehbar.
• API- und Supportkonten haben eigene Owner und Lebenszyklen.
• Offboarding umfasst Status, Sitzungen, MFA, Secrets und Abhängigkeiten.

FAQ