Sophos Firewall TACACS+ für Administratoren einrichten

TACACS+ kann die Anmeldung benannter Administratoren an Sophos Firewall gegen einen zentralen Server prüfen. Das vereinfacht Passwortregeln und Offboarding, macht die Firewall aber nicht automatisch zum vollständig TACACS+-gesteuerten Netzwerkgerät: Die eigentliche Device access profile-Zuweisung bleibt unter SFOS lokal.

Der sichere Ablauf trennt deshalb drei Ebenen: Verbindung und Zugangsdaten zum TACACS+-Server, erfolgreiche Anmeldung am gewünschten SFOS-Dienst und die lokale Administratorrolle auf der Firewall. Test connection bestätigt nur Serververbindung und Benutzercredentials, nicht den späteren WebAdmin-Zugriff.

Wichtig: Vor der Umstellung müssen das lokale Super-Administrator-Konto admin, ein zweiter funktionierender Managementweg und eine geöffnete lokale Adminsitzung verfügbar sein. TACACS+ wird nicht als einzige Methode aktiviert, bevor Pilotlogin, Negativtest und Rückweg funktionieren.

TACACS+ in zehn Schritten

1. Lokalen admin, MFA- beziehungsweise Recoveryweg und Managementzugriff positiv testen.
2. TACACS+-Server, Firewall-Quelladresse, TCP-Port, Shared Secret und Pilotkonto dokumentieren.
3. Den TACACS+-Pfad nur über ein vertrauenswürdiges Managementnetz oder einen geschützten Tunnel zulassen.
4. Unter Authentication > Servers > Add einen TACACS+ server anlegen.
5. Mit Test connection Credentials und Erreichbarkeit prüfen, danach speichern.
6. Den Pilotbenutzer einmal über einen bereits freigegebenen Firewall-Dienst extern authentifizieren, damit sein Benutzerobjekt entsteht.
7. Unter Authentication > Users den Pilotbenutzer kontrolliert zum Administrator machen und ein minimales Device-Access-Profil zuweisen.
8. Unter Authentication > Services > Administrator authentication methods TACACS+ hinzufügen, die Reihenfolge festlegen und Local als bewussten Fallback behalten.
9. WebAdmin in einem privaten Browserfenster positiv und mit einem nicht berechtigten Benutzer negativ testen.
10. Erst danach weitere Administratoren aufnehmen, Logs prüfen und den Ausfall des TACACS+-Pfads kontrolliert testen.

Was SFOS mit TACACS+ steuert

Sophos Firewall verwendet den konfigurierten TACACS+-Server als Authentifizierungsmethode für ausgewählte Dienste. Die SFOS-22-Hilfe nennt PAP und CHAP für TACACS+ ausdrücklich in der Protokollmatrix von VPN (IPsec/dial-in/L2TP/PPTP) authentication methods. Daraus lässt sich keine wählbare PAP-/CHAP-Einstellung für WebAdmin ableiten; für Administratoren wird unter Administrator authentication methods der Server und seine Reihenfolge gewählt.

Die aktuelle SFOS-22-Hilfe dokumentiert keine automatische Übernahme eines TACACS+-Attributes in ein Sophos-Administratorprofil. Ein Benutzer von einem externen Server erscheint bei seiner ersten Anmeldung als Standardbenutzer und erhält erst nach einer lokalen Zuweisung Administratorrechte. Microsoft Entra ID SSO ist hier eine ausdrücklich dokumentierte Ausnahme mit Rollen- beziehungsweise Gruppenmapping.

Auch die allgemeine Fähigkeit des TACACS+-Protokolls zu Authorization und Accounting ist nicht gleichbedeutend mit einer dokumentierten SFOS-Command-Authorization. Für dieses Runbook gilt deshalb:

• TACACS+ prüft die externe Identität und das Passwort.
• SFOS legt Benutzerart und Device-Access-Profil lokal fest.
• configuration-audit.log bleibt der Nachweis für Konfigurationsänderungen auf der Firewall.
• Eine TACACS+-Freigabe allein berechtigt keinen Benutzer zum WebAdmin.

Für die lokale Rollenplanung passt Sophos Firewall Administratoren und Profile sicher einrichten.

Beispiel und Voraussetzungen

Der Beispielaufbau verwendet:

• Server name: TACACS-HQ
• Server IP: 10.20.30.15
• Port: 49
• Pilotbenutzer: fw-noc-pilot
• Device-Access-Profil: NOC-ReadOnly
• Managementnetz: 10.20.40.0/24

10.20.30.15 und 10.20.40.0/24 sind private Beispielwerte und werden durch die echte Serveradresse und das freigegebene Managementnetz ersetzt. TCP 49 ist der von IANA zugewiesene TACACS+-Serverport; der in SFOS eingetragene Port muss dennoch exakt zur Gegenstelle passen. Das Shared Secret wird nicht in Screenshots, Tickets oder diesem Beispiel dokumentiert.

Vor der Konfiguration müssen diese Punkte geklärt sein:

• Der TACACS+-Server kennt die tatsächliche Quelladresse der Firewall als Client beziehungsweise Network Access Server.
• Routing und Firewallpfad zwischen Firewall und Server funktionieren in beiden Richtungen.
• Das Pilotkonto ist am TACACS+-Server aktiv und für den vorgesehenen Authentifizierungstyp freigegeben.
• Ein eigenes Device-Access-Profil mit None, Read-only und nur benötigtem Read-write ist vorbereitet.
• WebAdmin ist nur aus dem vorgesehenen Managementnetz erreichbar.
• Das lokale admin-Konto funktioniert unabhängig von TACACS+.
• Backup, Wartungsfenster und Rückweg sind dokumentiert.

Das minimale Profil wird unter Profiles > Device access > Add erstellt. Für jeden Menübereich wird None, Read-only oder Read-write gesetzt; Expand öffnet die Untermenüs für feinere Rechte. Der Profilname NOC-ReadOnly ist nur ein Beispiel. Entscheidend ist die gespeicherte Berechtigungsmatrix, die später dem Benutzer mit User type: Administrator zugewiesen wird.

Die aktuelle SFOS-Maske dokumentiert für TACACS+ IP-Adresse, Port und Shared Secret, aber keinen TLS-Schalter. RFC 8907 bezeichnet den Schutz klassischer TACACS+-Pakete als Obfuscation ohne zeitgemässe Integrität, Vertraulichkeit oder Replay Protection. Der Serverpfad gehört deshalb in ein getrenntes, vertrauenswürdiges Managementnetz oder einen geschützten Tunnel und nicht ungeschützt ins Internet. Wenn nur ein unsicherer Transportweg verfügbar ist, wird die Produktivsetzung gestoppt.

TACACS+-Server auf der Firewall anlegen

Menüpfad:

Authentication > Servers > Add

Vorgehen:

1. Server type auf TACACS+ server setzen.
2. Einen eindeutigen Server name eintragen, zum Beispiel TACACS-HQ.
3. Die echte Server IP und den am Server konfigurierten Port eintragen.
4. Das identische Shared secret wie auf der TACACS+-Gegenstelle hinterlegen.
5. Für Test connection das freigegebene Pilotkonto verwenden.
6. Nur bei erfolgreichem Test speichern.

Der Verbindungstest prüft Benutzercredentials und die Verbindung zum Server. Er beweist weder das Shared Secret isoliert noch, dass der Benutzer bereits ein Administratorprofil besitzt, WebAdmin aus seinem Netz erreichbar ist oder eine echte Administratoranmeldung funktioniert.

Wenn der Test scheitert, werden zuerst Server-IP, Route, Port, Shared Secret, Clientdefinition und Serverlog geprüft. Die Authentifizierungsmethoden oder Administratorrollen werden nicht auf Verdacht geändert.

XML-API-Automation: Konfigurationsantworten nach SFOS-Version auswerten

Wer TACACS+-Server über die XML API anlegt oder ändert, muss die Antwortauswertung an die SFOS-Version binden. Die API-Dokumentation unterscheidet für Add TACACS+ server und Edit TACACS+ server folgende Status-/Identifier-Paare:

• SFOS 22 – Add: 200/TacacsAddSuccess, 500/TacacsAddFail, 502/TacacsRecordExists, 503/TacacsAddFailDetail.
• SFOS 22 – Edit: 200/TacacsUpdateSuccess, 500/TacacsUpdateFail, 502/TacacsUpdateFailDetail.
• SFOS 23 – Add: 200/CPSuccessConfig, 400/CPInvalidRequestBody, 401/CPUnauthorized, 403/CPForbidden, 409/CPResourceConflict, 500/CPInternalServerError.
• SFOS 23 – Edit: 200/CPSuccessConfig, 400/CPInvalidRequestBody, 401/CPUnauthorized, 403/CPForbidden, 404/CPRecordNotFound, 500/CPInternalServerError.

Die Zahlen sind dokumentierte Statuswerte der Konfigurationsoperation, keine Aussage über den HTTP-Transportstatus. Die Namen hinter / sind rohe JavaScript-Identifier unter Message, keine aufgelösten Meldungstexte. Für SFOS 23 darf die Automation die alten 502-/503-Zuordnungen nicht unverändert weiterverwenden. Aus 409/CPResourceConflict folgt auch keine verifizierte Aussage, dass ausschliesslich ein doppelter Servereintrag vorliegt.

Vor einer Entscheidung über einen erneuten Schreibversuch empfiehlt sich, das gespeicherte Serverobjekt wieder auszulesen und mit der beabsichtigten Konfiguration abzugleichen. Die Statusliste garantiert weder sichere Wiederholbarkeit noch bestimmte Retry-Regeln. Ein Konfigurationsergebnis ersetzt weder Test connection noch die echte WebAdmin-Abnahme mit lokal zugewiesenem Minimalprofil und verfügbarem Notfallkonto. Diese Unterscheidung beschreibt den dokumentierten API-Vertrag, keinen ausgeführten Produkttest.

Externen Benutzer sicher zum Administrator machen

Benutzer externer Server werden in Authentication > Users sichtbar, nachdem sie sich erstmals erfolgreich an einem Firewall-Dienst angemeldet haben. Für den Pilot wird ein bereits fachlich freigegebener Dienst verwendet, beispielsweise User Portal oder VPN Portal. Gibt es keinen solchen Pfad, wird nicht allein für die Benutzeranlage eine breite WAN-Freigabe erstellt.

Der Ablauf bleibt eng:

1. Den gewählten Portal- oder Authentifizierungsdienst nur aus dem Managementnetz freigeben.
2. TACACS+ für genau diese Authentifizierungsmethode ergänzen, ohne bestehende Fallbacks zu entfernen.
3. Den Pilotbenutzer einmal erfolgreich anmelden.
4. Unter Authentication > Users prüfen, ob das externe Benutzerobjekt erschienen ist.
5. Benutzer öffnen und User type auf Administrator setzen.
6. Das vorbereitete Profil, zum Beispiel NOC-ReadOnly, zuweisen.
7. Nicht mehr benötigte temporäre Portal- oder Methodenfreigaben wieder auf den dokumentierten Vorzustand setzen.

Ein externer Benutzer wird nicht vorsorglich mit dem vollständigen Profil Administrator ausgestattet. Zuerst wird eine lesende oder eng begrenzte Rolle getestet. Schreibrechte erhalten nur Konten, deren Aufgabe sie wirklich benötigt.

Administrator authentication methods umstellen

Menüpfad:

Authentication > Services > Administrator authentication methods

TACACS+ wird in die Liste der ausgewählten Server aufgenommen. Pro Authentifizierungsmethode lassen sich höchstens 20 Server auswählen. Bei mehreren Servern leitet SFOS die Anfrage in der angezeigten Reihenfolge weiter. Anzahl und Reihenfolge sind deshalb Teil des Sicherheitsdesigns und keine kosmetischen Werte.

Für den Pilot:

1. TACACS+ zur ausgewählten Liste hinzufügen.
2. Den Server an die geplante Position verschieben.
3. Local für benannte lokale Administratoren als bewussten Fallback behalten.
4. Apply verwenden.
5. Die bestehende admin-Sitzung geöffnet lassen.

Die Administrator authentication methods gelten ausdrücklich nicht für den lokalen Super-Administrator admin. Dieses Konto bleibt der unabhängige Notfallweg und wird separat mit starkem Passwort, MFA und eingeschränkter Netz-Erreichbarkeit geschützt.

Set authentication methods same as firewall koppelt die Administratoranmeldung an die Methoden für Firewall-Authentifizierung. Diese Option wird nur verwendet, wenn diese Kopplung wirklich beabsichtigt und dokumentiert ist. Für einen klaren Admin-Pilot ist eine explizite Liste leichter zu prüfen und zurückzusetzen.

WebAdmin und Rollenwirkung abnehmen

WebAdmin verwendet standardmässig HTTPS-Port 4444; ein abweichender Port steht unter Administration > Admin and user settings. Vor Negativtests wird dort auch Block login geprüft: Nach genügend Fehlversuchen sperrt SFOS die Quell-IP für alle Dienste, WebAdmin, CLI, VPN Portal und User Portal. Deshalb nur einen geplanten Fehlversuch ausführen und eine zweite Managementquelle oder die Konsole bereithalten. Ein fehlgeschlagenes CAPTCHA zählt laut Sophos nicht als fehlgeschlagener Loginversuch.

Eine erfolgreiche Abnahme prüft nicht nur den Passwortdialog:

1. Die lokale admin-Sitzung bleibt geöffnet.
2. Der Pilot meldet sich in einem privaten Browserfenster über den vorgesehenen WebAdmin-FQDN an.
3. Das zugewiesene Profil wird geprüft: erwartete Menüs sind sichtbar, nicht erlaubte Bereiche fehlen.
4. Bei Read-only darf eine kontrollierte Änderung nicht gespeichert werden.
5. Bei einer vorgesehenen Schreibrolle wird eine harmlose Teständerung mit dokumentiertem Rückbau verwendet.
6. Ein gültiger TACACS+-Benutzer ohne lokale Administratorrolle darf WebAdmin nicht öffnen.
7. Ein falsches Passwort muss abgelehnt werden.
8. Der lokale admin muss sich in einem zweiten privaten Fenster weiterhin anmelden können.
9. TACACS+-Serverlog, Log Viewer und configuration-audit.log werden zeitlich korreliert.

WebAdmin-Erreichbarkeit wird separat unter Administration > Device access beziehungsweise mit einer engen Local Service ACL Exception gesteuert. TACACS+ und MFA rechtfertigen keine breite WAN-Freigabe. Der sichere Netzwerkpfad steht in Device Access und Local Service ACL.

Logs und HA prüfen

Im Log viewer wird nach dem Pilotbenutzer, der Quell-IP und dem Testzeitpunkt gefiltert. Für die tiefere Analyse sind relevant:

• access_server.log für Authentifizierung, Autorisierung und Accounting auf SFOS
• configuration-audit.log für Änderungen, Administrator und Zeitpunkt
• syslog.log für System- und admin-ausgelöste Ereignisse
• das TACACS+-Serverlog für Clientadresse, Benutzer, Verfahren und Ergebnis

In einem HA-Cluster wird nicht vorausgesetzt, dass eine bestehende WebAdmin-Sitzung einen Failover unterbrechungsfrei überlebt. Nach einem geplanten Rollenwechsel wird eine frische Anmeldung ausgeführt und am TACACS+-Server geprüft, welche Firewall-Quelladresse tatsächlich erscheint. Wenn der Server Clients anhand der Quelladresse zulässt, müssen alle im realen HA-Pfad auftretenden Adressen bewusst freigegeben sein.

Logs liegen auf dem Node, der den Vorgang verarbeitet hat. Bei einem zeitlich unklaren HA-Fall werden deshalb beide Nodes oder eine konsolidierte Auswertung geprüft.

Fehler nach Symptom eingrenzen

Test connection schlägt fehl

Server-IP, Route, TCP-Port, Shared Secret, Clientdefinition und Serverstatus prüfen. Ein Paketmitschnitt kann zeigen, ob die Firewall den Server erreicht und von welcher Source-IP die Verbindung kommt. Ohne Antwort oder bei einer unerwarteten Source-IP wird nicht an Benutzerrollen weitergearbeitet.

Test connection klappt, WebAdmin lehnt den Benutzer ab

Das ist mit einem fehlenden lokalen Administratorprofil vereinbar. Unter Authentication > Users prüfen, ob der Benutzer existiert, User type: Administrator gesetzt ist und das richtige Device-Access-Profil trägt. Danach die Reihenfolge unter Administrator authentication methods und die WebAdmin-ACL kontrollieren.

Der Server akzeptiert das Passwort, aber das falsche Profil greift

TACACS+ weist in diesem SFOS-Ablauf nicht automatisch das lokale Sophos-Profil zu. Benutzerobjekt und Profil auf der Firewall prüfen. Keine Serverattribute erfinden und kein vollständiges Administratorprofil als schnellen Test vergeben.

Login funktioniert nur bis zum HA-Failover

Am TACACS+-Server die tatsächliche Source-IP der neuen Anmeldung kontrollieren. Danach Route, Port, Clientdefinition und Shared Secret für den aktiven Pfad prüfen. Eine alte Browsersitzung ist kein Erfolgsnachweis; es wird eine neue Sitzung verwendet.

Alle externen Adminlogins fallen aus

Mit dem lokalen admin anmelden, Serverstatus und Methodenreihenfolge prüfen und TACACS+ bei Bedarf kontrolliert aus der Adminliste entfernen. Keine Device-Access-Freigabe auf Any erweitern und den Authentifizierungsdienst nicht als ersten Schritt neu starten.

Für die methodenübergreifende Diagnose passt Sophos Firewall Authentifizierung systematisch prüfen.

Offboarding und Rollback

Beim Offboarding wird der Benutzer zuerst am TACACS+-Server gesperrt. Danach wird auf der Firewall geprüft, ob noch eine bestehende Sitzung aktiv ist und ob das lokale externe Benutzerobjekt weiterhin ein Administratorprofil trägt. Eine Sperre am Server wird nicht als Garantie behandelt, dass jede bereits bestehende WebAdmin-Sitzung sofort endet.

Nach dem Negativtest wird das lokale Administratorprofil entfernt oder der Benutzer deaktiviert. Audit- und Serverlogs werden mit Ticket und Zeitpunkt dokumentiert. Das Super-Administrator-Konto admin gehört nicht in diesen normalen Offboarding-Ablauf.

Rollback bei einem fehlgeschlagenen Pilot:

1. Mit der geöffneten lokalen Adminsitzung anmelden.
2. TACACS+ aus Administrator authentication methods entfernen oder auf die dokumentierte frühere Position zurücksetzen.
3. Temporäre Portal- und Device-Access-Freigaben auf den Vorzustand zurücksetzen.
4. Dem Pilotbenutzer die lokale Administratorrolle entziehen oder ihn deaktivieren.
5. Eine neue lokale Adminanmeldung und den normalen Authentifizierungspfad testen.
6. Erst danach den TACACS+-Servereintrag löschen, sofern keine andere Funktion ihn verwendet.

Checkliste

• lokaler admin, MFA und Recoveryweg getestet
• tatsächliche Firewall-Quelladresse am TACACS+-Server bekannt
• TCP-Port und Shared Secret stimmen überein
• Serverpfad liegt in einem vertrauenswürdigen oder geschützten Netz
• Test connection erfolgreich, aber nicht als WebAdmin-Beweis missverstanden
• Pilotbenutzer als externes Benutzerobjekt sichtbar
• User type: Administrator und minimales Profil lokal zugewiesen
• Local als bewusster Fallback erhalten
• positiver und negativer WebAdmin-Test bestanden
• WebAdmin nur aus vorgesehenem Managementnetz erreichbar
• access_server.log, Serverlog und Audit Trail korreliert
• HA beziehungsweise Failover mit frischer Anmeldung geprüft
• Offboarding und Rollback dokumentiert

Häufige Fragen