Probleme mit Let’s Encrypt Webseiten

Am 30.09.2021 ist die Let’s Encrypt Root CA abgelaufen. Bei vielen Geräten, die nicht automatisch die neue Root CA über Updates erhalten, werden dann entsprechende Zertifikate nicht mehr als vertrauenswürdig eingestuft.

Wenn das SSL-Scanning und die Überprüfung der Zertifikate im Sophos UTM Webproxy konfiguriert wurde, kann bei bei dieses Webseiten auch hier eine Fehlermeldung erscheinen. In diesem Falle fehlt die entsprechende Root CA und sollte nachinstalliert werden.

Wenn im Sophos Webadmin unter Web Protection / Filtering Options / HTTPS CAs der folgende Eintrag fehlt:

  • Internet Security Research Group ISRG Root X1 (Fingerprint: CA:BD:2A:79:A1:07:6A:31:F2:1D:25:36:35:CB:03:9D:43:29:A5:E8)

dann kann diese Root CA bei Let’s Encrypt (https://letsencrypt.org/certificates/) heruntergeladen und zur Liste der CAs hinzugefügt werden. Dazu wird das öffentliche Zertifikat im PEM Format benötigt (https://letsencrypt.org/certs/isrg-root-x1-cross-signed.pem) und über den Punkt „Upload local CA“ hochgeladen und installiert.

Schwachstellen in Sophos UTM Mail Protection (Exim) manuell schließen

Die als 21Nails bekannten Schwachstellen im populären Mailserver Exim, welcher auch in den Sophos Firewallsystemen zum Einsatz kommt, sollten in der Sophos UTM durch ein manuelles Update geschlossen werden.

Notwendig ist ein Update der Exim Version auf v4.94.2. (Siehe auch https://community.sophos.com/b/security-blog/posts/advisory-multiple-vulnerabilities-aka-21nails-in-exim )

Sophos XG (SFOS 18.0 oder 17.5):

  • Automatische Upgrade via Hotfix („Allow automatic installation of hotfixes“ unter System / Backup & Firmware / Firmware sollte eingeschaltet sein)
  • Meldung via Alert: „Exim version upgraded to v4.94.2“

Sophos UTM (v9.705-3 oder 9.706-8):

  • Manuelles Download von https://download.astaro.com/UTM/v9/up2date/
  • u2d-sys-9.705003-705007.tgz.gpg bzw. u2d-sys-9.706008-706009.tgz.gpg (Auf genaue Quell- und Zielversion der UTM achten!)
  • Upload im Webadmin / Management / Up2Date, 5 Minuten warten
  • Installation starten (anschließend erfolgt ein Reboot

Siehe: https://community.sophos.com/utm-firewall/b/blog/posts/utm-up2date-9-705-7-released bzw. https://community.sophos.com/utm-firewall/b/blog/posts/utm-up2date-9-706-9-released

Backup-Server aus AD-Domäne entfernen

Spätestens seit den letzten Cyberangriff-Attacken ist es keine gute Idee mehr, den Backup-Server in der Domäne zu haben. Sollte die Ad-Domäne kompromittiert sein, so haben Angreifer damit auch Zugriff auf den Backup-Server und diesen werden sie auch nutzen.

Nachdem ich einen verschlüsselten UDP Datenspeicher und eine komplett gelöschte Tape Library gesehen hatte, empfehle ich dringend, den Backup-Server aus der AD-Domäne zu entfernen.

Und so geht es:

Vorbereitungen

DNS

Die Namensauflösung ist essentiell für die Funktion von Arcserve UDP und Backup. Deswegen sollte sichergestellt werden, dass trotz Entfernen aus der Domäne, die Einträge im DNS-Server beibehalten werden.

Weiterhin geht der primäre Suffix verloren, wenn ich ich den Backup-Server aus der AD entferne. Dieser sollte auf jeden Fall manuell eingetragen werden, wenn im Arcserve UDP die FQDN Syntax verwendet wird. Ansonsten kann es dazu führen, dass nicht mehr auf die RPS-Freigabe via FQDN zugegriffen werden kann.

Firewall

Beim Verlassen der Domäne wird auch das Netzwerkprofil „Domain“ obsolet. Der Server landet dann entweder im Profil „Private“ oder „Public“. So kann es passieren, dass eventuell Firewallausnahmen neu in diesen Profilen konfiguriert werden müssen:

  • Arcserve UDP (Eingehende Ports auf Konsole, RPS, Agent) Quelle: hier
    • TCP 445 (Anmeldung und Zugriff RPS)
    • TCP 4090 (Virtual Standby)
    • TCP 6052, 6054 (Arcserve Backup Datenabgleich)
    • TCP 8014, 8015 (Agent, Konsole)
  • Arcserve Backup (Eingehende Ports auf Server, Agent) Quelle: hier
    • UPD + TCP 6050 (Arcserve Agent)
    • TCP 111, 6502-6504 (RPC)
    • TCP 41523, UDP 41524 (Discovery)
    • TCP 10000 (NDMP)

Das Zuweisen von Netzwerkprofilen zu Netzwerkadaptern kann via Powershell und diesen Befehlen erfolgen:

  • get-netconnectionprofile
  • set-netconnectionprofile -interfaceindex (Nummer der NIC) -networkcategory private

Benutzer caroot

Wenn das „caroot“ Passwort nicht mehr bekannt ist, sollte man es spätestens jetzt zurücksetzen und neu zuweisen. Das ist einfacher, wenn man es mit einem Nutzer macht, der im Arcserve Backup die „Admin“-Rolle zugewiesen hat. Anleitung hier

Da beim Entfernen aus der AD-Domäne das Benutzerprofil entfernt wird, muss beim Start von Arcserve Backup das „caroot“ Passwort neu eingegeben werden.

Benutzer vorbereiten

Windows

Ich empfehle die Nutzung des lokalen Admistrators als Arcserve Systemaccount. Da Windows bei eingeschaltetem UAC zwischen „dem“ Administrator und Mitgliedern der Gruppe „Administratoren“ unterscheidet, geht man hier einigen Problemen aus dem Wege. Da Passwort dieses Administrators sollte sich von allen anderen Passwörten im Netz unterscheiden.

Gegebenenfalls können zusätzlich personalisierte Konten lokal, ebenfalls mit anderen Kennwörtern, angelegt werden. Diese sollten aber nur für die Administration, aber nicht als Systemaccount genutzt werden.

Arcserve UDP

Um später das System administrieren zu können, muss der oder die lokalen Benutzerkonten in Arcserve UDP berechtigt werden.

Aufruf der Benutzerverwaltung

Zuweisung Admin-Rolle

Arcserve Backup

Ähnlich hier.

Benutzerprofil zuweisen

Admin Rolle zuweisen

Zuweisung der Systemkonten

Arcserve UDP

Das Konto sollte an zwei Stellen angepasst werden. Einmal als Administratorkonto in der Konsole und einmal als Kennwort für den RPS-Server.

Systemkonto in Arcserve UDP

Anpassung des RPS-Kontos

Bei der zweiten Änderung werden alle Pläne mti dem aktualisierten Passwort neu verteilt. Wird der zweite Schritt vergessen, schlägt die Sicherung der Agenten fehl, weil der Zugriff auf die RPS-Share nicht möglich ist.

Arcserve Backup

Auch beim Arcserve Backup muss an zwei Stellen das Passwort angepasst werden. Einmal als Systemkonto und einmal in den Sicherungsjobs, die den entsprechenden Server sichern bzw. auf den RPS-Dienst zugreifen.

Arcserve Systemkonto

Als Domäne sollte hier der Servername angegeben werden.

Anschließend kann der Server aus der Domäne entfernt werden. Das Primäre Domänensuffix sollte allerdings manuell gesetzt werden.

Nach dem Neustart sollte alles wie vorher funktionieren.

Arcserve UDP – Sicherung von Office365 Daten via TLS1.2

Microsoft wird am 15. Oktober 2020 in den Office365 Produkten die Unterstützung von TLS1.0 und 1.1 deaktivieren (Siehe hier).

Dieses hat zur Folge, dass das Protokoll der Sicherung mit Arcserve auch auf TLS1.2 umgestellt werden muss, damit es weiterhin funktioniert.

Voraussetzung dafür ist die Arcserve UDP Version 7 Update 2. In einem Artikel in der Arcserve Knowledgebase ist diese notwendige Anpassung beschrieben: https://support.arcserve.com/s/article/Arcserve-UDP-TLS

Sophos UTM – SSL Scan Problem: „Certificate has expired“ bei einigen Webservern

Seit Ende Mai gibt es Probleme mit Zertifikaten von einigen Webseiten, welche von Sectigo (ehemals Comodo) ausgestellt wurden. Grund ist der Kreuzverweis auf Zertifikate, welche am 30.05.2020 ausliefen. (Siehe Sectigo Knowledgebase oder Sophos NakedSecurity)

Bei der Überprüfung der Zertifikate durch den Proxy der UTM wird folgender Fehler angezeigt:

Um diesen Fehler zu beheben, müssen die veralteten Zertifikate in der UTM deaktiviert werden und manuell die entsprechenden Ersatz-Zertifikate hochgeladen werden:

Die aktualisierten Root-CA’s kann man hier herunterladen:

Über der Link „Certificate“ kann das jeweilige Zertifikat heruntergeladen werden (*.crt).

Das Deaktivieren der alten Zertifikate und das Hinzufügen der neuen Zertifikate erfolgt über den Webadmin / Web Protection / Filtering Options / HTTPS CAs

Neue Zertifikate unter „Local verification CAs hinzufügen:

Damit die Einstellungen wirksam werden, muss der Proxy-Dienst neu gestartet werden. Am schnellsten, in dem man den Web Filtering Status (Webadmin / Web Protection / Web Filtering / Global) kurz deaktiviert und wieder aktiviert.

( Quelle: The Tech Journal, 04.06.2020)

 

Sophos RED20 und RED60 jetzt verfügbar

Nach Lieferengpässen bei RED15(w) und RED50 ist die Markteinführung der Nachfolgemodelle vorgezogen worden. Sowohl die RED20 als auch die RED60 sind nun bestell- und lieferbar. Offiziell sind die „alten“ RED Modelle aber nach wie vor bestellbar. Ein End-of-Sales Termin wurde noch nicht veröffentlicht, jedoch ein Migrationspfad schon angegeben (siehe Sophos Retirement Calendar).

Über die neuen Modelle ist auf der Webseite von Sophos noch wenig zu erfahren. Das kann daran liegen, das zum heutigen Tag noch kein Firmware-Release die neuen Geräte unterstützt. Eine entsprechende Firmware für die XG Firewall (v18 MR1) wurde kurzfristig aufgrund von Problemen zurückgezogen. Ebenfall zurückgezogen wurde eine neue Version für die UTM Firewall (v9.703). Hier ist aber der Support für die RED20 und RED60 nicht explizit erwähnt.

Was allerdings schon verfügbar ist, sind Informationen im Support Bereich von Sophos. So können die Installations und Erweiterungsanleitungen bereits hier heruntergeladen werden. Aus diesen sind auch die folgenden Informationen entnommen:

Unterschiede zur RED15 bzw. RED50:

  • zweites Netzteil anschließbar
  • Rackmount Kit möglich (das von der SG/XG 105 bzw. 115 Rev.3)
  • Erweiterungsmodul steckbar (Wifi oder 3G/4G Module der SG/XG135 Rev.3)
  • SFP WAN Port (shared mit WAN1), Unterstützung für Sophos VDSL Modul angekündigt
  • 5 Jahre Garantie (wahrscheinlich ausgenommen das Netzteil)
  • Nenndurchsatz ist angegeben mit 250 MB/s (RED20) bzw. 850 MB/s (RED60)

Nur die RED60:

  • zweiter WAN Port
  • PoE+ an zwei LAN Ports (2x 15W oder 1x 30W)

Interessant wird werden, ob auch die flexible VLAN-Konfiguration, ähnlich der RED50, bei beiden neuen REDs unterstützt wird. Das wird sich zeigen, sobald eine entsprechende Firmware verfügbar ist, um diese Geräte auch zu betreiben. Vorrätig sind sie bereits.

Sophos Connect Client – Verbindungsabbruch durch Rekeying verhindern

Bei Einsatz des Sophos Connect IPSec Clients mit den Standardwerten kommt es nach Ablauf der IKE SA Lifetime zu einer erneuten Authorisierungsaufforderung (Verbindung ist weg, Neuanmeldung erforderlich). Dieses Verhalten kann dient der Sicherheit, kann allerdings auch stören.

In diesem Falle kann man die IKE SA Lifetime höher setzen, um die Verbindungsunterbrechung herauszuschieben. Die Änderungen sind nur wirksam, wenn sie an beiden Enden des VPN Tunnels (UTM und Client) vorgenommen werden. Einseitige Veränderungen führen nicht zum gewünschten Erfolg, aber verhindern auch keinen Verbindungsaufbau. Es gilt dann immer der kleinere Wert von beiden Seiten.

Anpassungen an UTM-Seite

Die Anpassung erfolgt durch die Änderung der IPSec Policy.

Achtung! Die Policy könnte auch in anderen Verbindungen verwendet werden. Am besten die Policy klonen und unter neuem Namen speichern.

Nur die Lifetime, nichts anderes ändern! Ansonsten muss das Client-Profil komplett angepasst werden.

Nach dem Erstellen der Policy kann diese in der IPSec-Verbindung ausgewählt werden.

Achtung! Beim Speichern erfolgt ein Verbindungsabbruch bei allen verbundenen IPSec Clients.

Anpassungen an der Client-Seite

Das hiermit erstellte Client-Profil *.scx muss jetzt noch angepasst und neu in den Sophos Connect Client importiert werden.

Der gewählte Wert sollte etwas geringer als der Wert an der Firewall sein, damit der Client das Rekeying initiert und Zeit für die Re-Authentifizierung bleibt.

Die verwendeten Werte (86400 Sec. = 24h) haben sich für das HomeOffice bewährt.

Homeoffice – VPN sicher mit Zwei-Faktor-Authentifizierung

Momentan steht Homeoffice hoch im Kurs und wird oft hastig angeordnet. Damit die Sicherheit nicht auf der Strecke bleibt, ist hier ein einfaches Kochrezept, um mit kostenfreien Mitteln einen sicheren Zugang zur Sophos UTM einzurichten:

Zutaten

Vorbereitungen

Lokale Nutzer an der UTM sind schnell eingerichtet, aber bei einer Backend Authentifizierung an der ADS erhöht sich die Nutzerakzeptanz. Der einfache Nutzer muss sich kein zusätzliches Passwort merken und Passwortänderungen wie Nutzersperrungen sind auch einfacher umzusetzen.

Dazu wird einfach eine Sicherheitsgruppe in der ADS (hier „AD_SophosConnect“) angelegt und mit den entsprechenden Nutzern befüllt. Wenn in der UTM die „Authentication Server“ schon eingerichtet sind, kann eine dynamische Gruppe schnell erzeugt werden:

Schön ist auch das automatische Anlegen eine Nutzerkontos bei Anmeldung am UTM Userportal:

Weiterhin sollte die 2-Faktor Authentisierung mittels One-Time-Passwort (OTP) vorbereitet werden:

Das „User Portal“ und „IPSec Remote Access“ muss markiert sein. Achtung: Abhängig von der geplanten Authenticator-App (namentlich beim Google Authenticator) muss eventuell beim Hash SHA-1 statt SHA-256 gewählt werden.

Und so sollte es dann aussehen, wenn sich ein Benutzer (hier Otto, Mitglied der Gruppe AD_SophosConnect, und noch nicht als lokaler Benutzer an der UTM erstellt) am User Portal anmeldet:

Benutzername = ADS Konto / Passwort = ADS Kennwort

  • Nutzer wird automatisch an der UTM erstellt und mit dem Backend verknüpft
  • OTP Hash wird automatisch erstellt, dem Nutzer präsentiert und nach erfolgreichem ersten Login abgespeichert

Den QR-Code sollte der Nutzer mit seinem Smartphone und der Authenticator-App einscannen. Es sollte dann etwa so aussehen:

(Der QR-Code kann unter Definitions & User / Authentication Services / One-Time Password  mit Klick auf das „i“ in der Tokenliste erneut angezeigt werden.)

Login erfolgt nun mit Benutzername = ADS Konto / Passwort = ADS Kennwort + Token

So haben wir einen „self-Service“ eingerichtet, um Nutzer automatisiert zu erstellen und mit einer 2FA auszustatten.

IPSec Remote Access einrichten

Jetzt erfolgt die eigentliche Konfiguration des IPSec Remote Access:

  • Interface: Externes Interface der UTM (feste IP empfohlen, DynDNS sollte auch funktionieren)
  • Local Networks: Netzwerke oder Hosts, auf die zugegriffen werden soll (Gruppen sind hier nicht möglich). Ruhig großzügig sein, die Einschränkung erfolgt dann über Firewall Regeln.
  • Virtual IP Pool: Vordefinierter Pool, aus dem der Remote Client eine IP zugewiesen bekommt (kann angepasst werden)
  • Policy: AES-256 empfohlen (Sicher und schnell)
  • Authentication Type: Preshared Key (mit allen anderen Methoden habe ich keine Verbindung herstellen können)
  • Preshared Key: schön lang und zusammenhanglos (im Zweifel mit Keypass generieren)
  • Enable XAUTH: Hier wird die zusätzliche Abfrage nach Benutzer + Passwort (+ Token) erzwungen

Folgende Einstellungen sollten auch überprüft bzw. angepasst werden:

Firewall Regeln für Remote Access erstellen

Jetzt werden noch entsprechende Firewall Regeln benötigt. Man kann die Einstellungen großzügig oder granular vornehmen, da eine Festlegung auf Basis des VPN-Pools, der Gruppe oder des einzelnen Nutzers möglich ist.

 

IPSec Konfiguration herunterladen

Nun kann das IPSec Profil heruntergeladen werden, entweder im User Portal durch den Nutzer oder im Webadmin:

 

Bis hierher war es eigentlich nichts Neues. In den meisten Fällen wurde die Konfiguration in einen (kostenpflichtigen) IPSec Client importiert. Nun kommt der Sophos Connect Client ins Spiel.

Sophos Connect IPSec Client

Der Sophos Connect Client ist der kostenfreie IPSec Client für die Sophos XG Firewall. Seit Ende 2019 ist dieser Client auch im Zusammenspiel mit der Sophos UTM oder Sophos SG supportet.

Folgende Vorteile hat die Verwendugn dieses Clients:

  • kostenfrei
  • In obiger Konfiguration (PSK + XAUTH) kann eine einheitliche Konfiguration an viele Clients verteilt werden.
  • Separate Eingabe des zusätzlichen Tokens für 2FA sorgt für weniger Verwirrung beim Nutzer.
  • Benutzername / Passwort kann gespeichert werden. Es erfolgt dann nur noch die Abfrage des Einmalpassworts (Token).
  • Spätere Migration zur Sophos XG kann ohne neues Rollout des IPSec Clients erfolgen.

Zur Migration der UTM IPSec Konfiguration (kompatibel mit UTM/NCP IPSec Client, *.ini) in das Sophos Connect Format (*.scx) wird der Sophos Connect Admin benötigt. Leider ist diese Software nur in der Sophos XG enthalten und es existiert kein Download-Link auf der Sophos Webseite (soweit mir bekannt, Stand 12.03.2020). Allerdings kann man trotzdem an die Software gelangen:

Öffnen der Sophos XG Demo im Web (https://secure2.sophos.com/de-de/products/next-gen-firewall/free-trial/xg-firewall-demo.aspx, vorher muss natürlich der Vertrieb mit Daten gefüttert werden) und Download des Sophos Connect Client Installers. Hier sind beide Clients (Windows und MacOS), sowie das Admin Tool enthalten.

Mit dem Sophos Connetc Admin kann nun die Konfiguration angepasst und im Sophos Connect Format exportiert werden:

  • Connection Name: Name der Verbindung, wie sie am Client angezeigt wird (sollte geändert werden)
  • Target Host: nicht verändern (muss zur VPN-ID der UTM im Webadmin passen, Änderungen dort wirken sich ggf. auf Site-2-Site Tunnel aus!)
  • Prompt for 2FA: Eigenes Feld für Einmal-Passwort (sollte eingeschaltet werden)
  • Networks: nicht verändern (muss zur IPSec SA der Verbindung im Webadmin passen)

Abspeichern und in den installierten Sophos Connect Client importieren (für alle remote Benutzer mit dem gleichen IPSec-Profil kann diese *.scx Datei genutzt werden):

Bei der Einwahl dann kann der Benutzername und das Kennwort gespeichert werden. Es wird dann nur noch das Einmal-Passwort angefragt.

 

Einmal so vorbereitet, können die Benutzer für das Homeoffice einfach bei der IT-Abteilung antreten:

  1. Benutzer in Active Directory zur Gruppe AD_SophosConnect hinzufügen.
  2. Kompatible Authenticator App auf Smartphone installieren.
  3. Benutzer meldet sich am User Portal an, scannt den QR-Code und loggt sich einmal damit ein (Benutzername = ADS Konto / Passwort = ADS Kennwort + Token).
  4. Vorbereitetes Notebook mit Sophos Connect Client und importierter Konfiguration aushändigen.

Viel Spaß in der Quarantäne und gute Besserung allen Betroffenen!

Sophos Knowledgebase Eintrag zum Nachlesen (bleibt ein wenig unkonkret an den entscheidenden Stellen) : https://community.sophos.com/kb/en-us/134050

Über diese Website

Christian Sievers IT Beratung
Brückenstr. 6a
04651 Bad Lausick

Über diese Website

Christian Sievers IT Beratung
Brückenstr. 6a
04651 Bad Lausick