Sophos Firewall – XML Export von OTP Token unvollständig

Der XML Export von OTP Tokens in der Sophos Firewall ist nur für lokale Benutzer möglich. Tokens von Benutzern aus externen Authentifizierungsquellen wie ActiveDirectory oder LDAP sind bei dem Export nicht enthalten. In dieser Anleitung wird ein Weg gezeigt, wie es trotzdem geht.

getestet mit SFOS 19.5.x bis 21.0.x

Einleitung

Wenn man Konfigurationen von einer Sophos Firewall auf eine andere manuell transferieren muss, wird man kleine Einschränkungen diesbezüglich feststellen. Zum Beispiel sind im XML Export nur die OTP Tokens von lokal in der Firewall angelegten Benutzern enthalten. Warum genau dies von Sophos hier ausgeschlossen wird, ist mir nicht ganz klar. Zumal die Tokens bei einer Wiederherstellung eines vollständigen Backups enthalten sind.

Bei dem Wechsel der Firewall werden die meisten Admins den Backup-Weg nehmen und sind hiervon nicht betroffen. Wer aber lieber ausgewählte Konfigurationen übertragen will, oder von einem 1U/2U Modell auf ein kleines Desktop Modell wechselt, wird auf dieses Problem treffen. Letzteres ist weiterhin von Sophos nicht in jeder Konstellation unterstützt zum jetzigen Stand und SFOS 21. Ich will aber nicht unerwähnt lassen, dass seit spätestens SFOS 20.0.2 ein Umweg laut der Kompatibilitäts-Matrix gehen sollte: 1US/1UL/2U --> virtuelle Appliance --> XGS 88.

Der hier aufgezeigte Weg ist also nicht in allen Fällen notwendig! Beim manuellen Weg aber immer.

Der im folgenden aufgezeigte Weg funktioniert in meinen Tests und in reellen Umgebungen bisher ohne Probleme. Trotzdem möchte ich die Warnung aussprechen, dass Veränderungen an der Datenbank, auch wenn sie wieder rückgängig gemacht werden, nicht von Sophos in der Form vorgesehen sind unerwünschte Nebenwirkungen erzeugen können.
Macht also immer ein Backup und geht bei der Verwendung der Shell mit Vorsicht um - insbesondere dann, wenn die Datenbank editiert wird.

Für mögliche Schäden können wir nicht haftbare gemacht werden und übernehmen keine Garantie! Im Zweifelsfall geht auf euren Sophos Partner zwecks Unterstützung zu.

Was wird benötigt?

Für den Vorgang benötigt ihr:

  • Shell Zugang zur alten Firewall
  • Den Storage Master Key der alten Firewall für den Import
  • Ein wenig Shell Erfahrung

Wie funktioniert der Lösungsansatz?

Der Ansatz, den ich erarbeitet habe, basiert auf temporäre Veränderungen an den Benutzern in der Datenbank. Diese Änderungen werden im Nachgang wieder komplett rückgängig gemacht.

Generell wird in der Datenbank bei den Benutzern im Feld "authserverid" der Benutzer der zuletzt verwendete Authentifizierungsserver hinterlegt. Der Wert "1" bedeutet "lokale Datenbank" der Firewall. Andere IDs entsprechen den IDs aus den zusätzlich konfigurierten Authentifizierungsservern.

Diese ID wird durch einen Befehl angepasst auf "1". Der Firewall wird also vorgetäuscht, dass es sich um einen lokalen Benutzer handelt. Und genau dann funktioniert auch der XML-Export aller OTP-Token.

Nach erfolgreichem Export wird die ID wieder auf die vorher gesetzte ID zurückgesetzt und die Tokens können auf einer neuen Firewall eingespielt werden. 😀

Lest bitte alle Anweisungen und Anmerkungen bis zum Ende, um Probleme oder Fragen zu vermeiden.

Umsetzung

Auslesen der nötigen Authentifizierungsserver IDs

Meldet euch in der advanced Shell an und gebt den folgenden Befehl ein, um die IDs der Authentifizierungsserver angezeigt zu bekommen.

Advanced Shell - Auslesen der Authentifizierungsserver IDs
psql -U pgroot -d corporate -c "select authservername,authserverid from tbladsauthserver;" -x

Die Ausgabe sieht wie im folgenden Screenshot dargestellt aus. Je nach Menge der Server, ist die Liste länger, oder enthält wie im Screenshot nur einen Eintrag. Notiert euch die ID(s) für welche der Export gemacht werden soll. In den meisten Fällen sollten das alle aufgelisteten sein.

Laufzeitvariable setzen

Die ID(s) speichert ihr jetzt in einer Laufzeitvariable. Dies wird für die weiteren Befehle benötigt.

Die Variable ist nur gesetzt, solange die Shell Sitzung offen ist! Wenn die Sitzung geschlossen wird, wird die Variable gelöscht. Solltet ihr also in einer zweiten Sitzung noch mal weiter machen wollen, muss die Variable erneut gesetzt werden!

Passt die ID(s) in dem folgenden Codefenster entsprechend eurer ID(s) an. Ein erneutes Abschicken mit anderen Werten, überschreibt den Wert der Variable - falls ihr die ID(s) noch mal ändern wollt.

Advanced Shell - Laufzeitvariable für IDs setzen
# Eine ID
# single ID
authserverids="3"

# Mehrere IDs
# Multiple IDs
authserverids="3,4,5"

Auflisten der jetzt exportierbaren Token (optional)

Wenn ihr euch die Token auflisten lassen wollte welche im Nachgang exportierbar sind müsst ihr diesen Befehl in die Shell eingeben. Seht es als Kontrolle der IDs in der "authserverids" Variable.

Advanced Shell - Auflisten der exportierbaren Tokens
if echo "$authserverids" | grep -q ','; then operator="IN (${authserverids})"; else operator="= $authserverids"; fi; psql -U pgroot -d corporate -c "SELECT o.tokenid, o.active, o.userid, u.username, o.comment FROM tblotp o INNER JOIN tbluser u ON o.userid = u.userid WHERE u.authserverid $operator;"

Die Ausgabe sieht dann wie folgt aus. Dabei wird die "tokenid" nur als eindeutiger Identifier mit angezeigt. Die anderen Werte sind selbstredend.

Auflistung der exportierbaren Tokens

Ist die Anzeige für euch passend, kann mit der nötigen Anpassung fortgefahren werden.

ID auf lokalen Server setzen

Ab hier finden Veränderungen an der Datenbank statt. Diese werden zwar wieder rückgängig gemacht, aber denkt daran ab spätestens hier für alle Fälle ein volles Backup anzulegen und auch herunterzuladen.

Ab hier sollten sich die Benutzer am besten nicht an der Firewall anmelden und auch nicht aktiv sein. Ist ein Benutzer dennoch aktiv, wird in der Regel die ID in der Datenbank wieder zurückgesetzt, sobald sich der Benutzer authentifiziert. Dies war zumindest in meinen Tests so. Evtl. ist auch eine Inkonsistenz der Datenbank möglich.

Übergangsweise sollte daher VPN, Benutzerportal und VPN Portal im "Appliance Zugriff" deaktiviert werden. Auch der Heartbeat kann einen Einfluss haben und sollte kurzfristig abgeschaltet werden.

Im Folgenden wird die Authentifizierungsquelle der Benutzer auf "lokal" umgestellt. Dabei wird in der Beschreibung der Benutzer auch ein "(-=ID=-)" angefügt, um die Einträge auch in der GUI prüfen zu können. Zusätzlich dient dieser Wert dazu die Änderungen wieder Rückgängig machen zu können. "ID" wird dabei entsprechend der zuletzt gesetzten Server ID angepasst.

Advanced Shell - Authentifizierungsserver auf lokal setzen
IFS=','; for id in $authserverids; do echo "Processing authserverid: $id"; psql -U pgroot -d corporate -c "UPDATE tbluser SET authserverid = 1, description = CONCAT(COALESCE(description, ''), ' (-=$id=-)') WHERE authserverid = $id;"; done

In der Ausgabe kann man sehen wie viele Einträge pro ID angepasst wurden - sprich ob auch was passiert ist.

Ergebnis der Änderung - XML Export von OTP Token

Ab hier keine Änderungen an den Benutzern im WebAdmin vornehmen, um eine mögliche Inkonsistenz in der Datenbank zu vermeiden!

Anschauen ja, aber bitte keine Änderungen vornehmen oder einfach nur auf "Speichern" klicken!

Im WebAdmin kann geprüft werden, welcher Authentifizierungsserver vorher bei dem Benutzer gesetzt war. Dazu einfach den Benutzer öffnen. Der Wert steht in der Beschreibung: (-=ID=-)

Alten ID Wert bei den einzelnen Benutzern ansehen

Export der Token

Jetzt kann ein Export der OTP-Token auf gewohnte Weise vorgenommen werden .

XML Export der OTP Token

Änderungen an der Datenbank rückgängig machen

Jetzt können die Änderungen an der Datenbank wieder rückgängig gemacht werden. Das temporär angefügte "(-=ID=-)" wird auch wieder entfernt.

Advanced Shell - ID bei den Benutzern zurücksetzen
IFS=','; for id in $authserverids; do echo "Processing ID: $id"; psql -U pgroot -d corporate -c "UPDATE tbluser SET authserverid = $id, description = TRIM(REPLACE(description, ' (-=$id=-)', '')) WHERE description LIKE '%(-=$id=-)%';"; done

Falls VPN, Benutzerportal, VPN Portal oder Heartbeat deaktiviert wurden, können sie jetzt auch wieder aktiviert werden.

Jetzt kann mit dem Import der Token weiter gemacht werden.

Lest dazu bitte noch weiter, da ich hier auch noch interessante und wichtige Hinweise gebe.

Import der Token

Die vorher exportierte XML Datei kann in eine neue Firewall importiert werden. Bitte beachtet dabei aber noch die folgenden Hinweise:

Auch Token der lokalen Datenbank sind enthalten

Der Export enthält unter Umständen mehr Token als euch lieb ist. Es wurden nämlich nicht nur die Token passend zu den externen Authentifizierungsservern exportiert, sondern auch die der lokalen Datenbank. Ist das nicht gewünscht, kann die in der TAR-Datei enthaltene XML-Datei bearbeitet werden. Dazu einfach alle nicht gewünschten <OTPTokens>...</OTPTokens> Blöcke entfernen. Zum Packen in die TAR-Datei bitte den Punkt "Bearbeitete XML wieder in TAR Datei packen" beachten. Denn nur die TAR-Datei kann importiert werden!

Import der Token zu (noch) nichtexistierenden Benutzern

Die Token sind in der XML einem Benutzernamen zugewiesen. Existiert der Benutzername nicht vor dem Import wird der Token nicht importiert. Dazu gibt es zwei Lösungsansätze:

  1. Benutzerzuweiseung entfernen
    In der XML den Wert <user>Benutzername</user> auf einen leeren Wert <user></user> setzen und nach dem Import den Token später im WebAdmin zuweisen in der MFA-Konfiguration. Zum Packen in die TAR-Datei bitte den Punkt "Bearbeitete XML wieder in TAR Datei packen" beachten. Denn nur die TAR-Datei kann importiert werden!
  2. Den Benutzer vorher anlegen
    Hier gibt es auch einen Workaround der gut funktioniert ohne das sich der Benutzer tatsächlich anmelden muss. Legt einfach einen Benutzer in der Firewall lokal an. Achtet dabei auf den korrekten Benutzernamen. Mail und Anzeigename werden später automatisch korrigiert. Setzt ein kryptisches Passwort für den Benutzer. Dieses ist später nicht mehr gültig. Der Token kann zu dem Zeitpunkt importiert werden und wird korrekt zugeordnet.
    Wenn sich der Benutzer nachher über den externen Authentifizierungsserver anmeldet, wird der Benutzer in einen externen konvertiert. Mail und Anzeigename wird dabei entsprechend der Quelle angepasst. Das vorhin definierte Passwort ist ab hier nicht mehr gültig.

Bearbeitete XML wieder in TAR Datei packen

Beim erneuten Packen der Daten in das TAR-Archiv, müssen alle Dateien, die vorher mit drin waren, auch wieder unbedingt mit rein. Ansonsten schlägt der Import fehl. In das Archiv muss also:

  • Entities.xml
  • propertyfile
  • hashFile.json

Import in neue Firewall

Zum Import sei noch erwähnt, dass ihr den Storage Master Key der alten Firewall eingeben müsst. Ansonsten schlägt der Import fehl.

2 Kommentare

Schreibe einen Kommentar

Kommentare werden nicht direkt angezeigt, da sie moderiert freigegeben werden.


WordPress Cookie Plugin von Real Cookie Banner