20
Sicherheit MFA VPN vs Wireguard wg. Cyberversicherung
Hallo zusammen,
wir sind gerade im Austausch mit der zukünftigen Cyberversicherung unseres Kunden bezüglich der IT-Sicherheitsanforderungen. Grundsätzlich erfüllt die durch uns betreute IT-Infrastruktur bereits alle Versicherungsanforderungen vollumfänglich, allerdings bereitet uns nun das Thema MFA bei VPN Zugängen Probleme:
Der Versicherer fordert zwingend durch MFA abgesicherter VPN Zugänge zum Firmennetz und begründet dies damit, dass ansonsten Anmeldedaten zum VPN abgegriffen werden könnten und dadurch u.U. Weltweiter Zugriff auf Unternehmensdaten durch Dritte möglich sei. Daher wird neben einem Benutzerpasswort ein weiteres Merkmal (OTP, Fido Token etc.) gefordert.
Wir setzen dort allerdings flächendeckend WireGuard als VPN ein, welches keine MFA unterstützt. Aus unserer Sicht kann es das auch schon aus rein technischen Gründen gar nicht, schließlich arbeitet es mit asymmetrischen Schlüsselpaaren, die je Endgerät ausgestellt werden. Das schließt aus unserer Sicht sämtliche Angriffswege, die durch MFA verhindert werden sollen (bspw. Phishing) bereits aus. Ich persönlich würde eine Gerätegebundene Authentifizierung und Verschlüsselung basierend auf Private- / Publickeys sowie WireGuard an sich in diesem Zusammenhang als modernster Stand der Technik bezeichnen. Sämtliche Clients sind natürlich zusätzlich mit Bitlocker verschlüsselt, sodass auch der Verlust des Geräts nicht zu einem Verlust des Privatekeys führen kann. Im Grunde handelt es sich bei unserer Umsetzung mehr oder weniger um eine Art „AlwaysOn“ VPN bis hin zu einer Art SD-WAN Lösung, da der WireGuard Dienst auf den Clients eigentlich ununterbrochen aktiv bleibt.
Der Versicherer lässt sich hiervon aber aktuell nicht überzeugen und fordert weiterhin eine MFA Absicherung der VPN Zugänge.
Wie seht ihr das? Haben wir hier auf das falsche Pferd gesetzt, oder würdet ihr das grundsätzlich so unterschreiben? Gibt es irgendwelche „offiziellen“ Handreichungen oder Empfehlungen, die die Sicherheit der aktuellen Lösung mit MFA VPNs vergleichen? Habt ihr irgendwelche Alternativvorschläge?
Viele Grüße
Joshua
wir sind gerade im Austausch mit der zukünftigen Cyberversicherung unseres Kunden bezüglich der IT-Sicherheitsanforderungen. Grundsätzlich erfüllt die durch uns betreute IT-Infrastruktur bereits alle Versicherungsanforderungen vollumfänglich, allerdings bereitet uns nun das Thema MFA bei VPN Zugängen Probleme:
Der Versicherer fordert zwingend durch MFA abgesicherter VPN Zugänge zum Firmennetz und begründet dies damit, dass ansonsten Anmeldedaten zum VPN abgegriffen werden könnten und dadurch u.U. Weltweiter Zugriff auf Unternehmensdaten durch Dritte möglich sei. Daher wird neben einem Benutzerpasswort ein weiteres Merkmal (OTP, Fido Token etc.) gefordert.
Wir setzen dort allerdings flächendeckend WireGuard als VPN ein, welches keine MFA unterstützt. Aus unserer Sicht kann es das auch schon aus rein technischen Gründen gar nicht, schließlich arbeitet es mit asymmetrischen Schlüsselpaaren, die je Endgerät ausgestellt werden. Das schließt aus unserer Sicht sämtliche Angriffswege, die durch MFA verhindert werden sollen (bspw. Phishing) bereits aus. Ich persönlich würde eine Gerätegebundene Authentifizierung und Verschlüsselung basierend auf Private- / Publickeys sowie WireGuard an sich in diesem Zusammenhang als modernster Stand der Technik bezeichnen. Sämtliche Clients sind natürlich zusätzlich mit Bitlocker verschlüsselt, sodass auch der Verlust des Geräts nicht zu einem Verlust des Privatekeys führen kann. Im Grunde handelt es sich bei unserer Umsetzung mehr oder weniger um eine Art „AlwaysOn“ VPN bis hin zu einer Art SD-WAN Lösung, da der WireGuard Dienst auf den Clients eigentlich ununterbrochen aktiv bleibt.
Der Versicherer lässt sich hiervon aber aktuell nicht überzeugen und fordert weiterhin eine MFA Absicherung der VPN Zugänge.
Wie seht ihr das? Haben wir hier auf das falsche Pferd gesetzt, oder würdet ihr das grundsätzlich so unterschreiben? Gibt es irgendwelche „offiziellen“ Handreichungen oder Empfehlungen, die die Sicherheit der aktuellen Lösung mit MFA VPNs vergleichen? Habt ihr irgendwelche Alternativvorschläge?
Viele Grüße
Joshua
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 81994951884
Url: https://administrator.de/contentid/81994951884
Ausgedruckt am: 24.11.2024 um 15:11 Uhr
20 Kommentare
Neuester Kommentar
Moin,
Bei Client2Site VPNs, welche Auf Basis von Zertifikaten funktionieren, gibt es kein MFA. Setzt natürlich voraus, dass der private Schlüssel für einen normalen Benutzer nicht exportierbar ist. Macht natürlich nur Sinn bei einer funktionalen und gepflegten PKI im Unternehmen.
Unabhängig davon gibt es wirklich noch Versicherungen die wirklich zahlen? Wir haben unsere vor Jahre wieder gekündigt, weil das Kleingedruckte so viele "wenn, dann" und Ausnahmen hatte, dass eigentlich kein Sinn mehr gemacht hat.
Gruß,
Dani
Wie seht ihr das?
Bei Client2Site VPNs, welche mit Benutzernamen und Passwort funktionieren, haben wir bereits vor 6 Jahren MFA eingeführt. Da gibt es auch keine Ausnahmen. Wird über AD FS + WAF + Vasco (Hardware Token) realisiert.Bei Client2Site VPNs, welche Auf Basis von Zertifikaten funktionieren, gibt es kein MFA. Setzt natürlich voraus, dass der private Schlüssel für einen normalen Benutzer nicht exportierbar ist. Macht natürlich nur Sinn bei einer funktionalen und gepflegten PKI im Unternehmen.
Unabhängig davon gibt es wirklich noch Versicherungen die wirklich zahlen? Wir haben unsere vor Jahre wieder gekündigt, weil das Kleingedruckte so viele "wenn, dann" und Ausnahmen hatte, dass eigentlich kein Sinn mehr gemacht hat.
...oder würdet ihr das grundsätzlich so unterschreiben?
Ist aus meiner Sicht eine einfache Rechnung. Kann es dich im Worst Case den Job kosten?Sämtliche Clients sind natürlich zusätzlich mit Bitlocker verschlüsselt, sodass auch der Verlust des Geräts nicht zu einem Verlust des Privatekeys führen kann.
In wie weit schützt Bitlocker vor einem Brut Force auf die Windows Konten?Im Grunde handelt es sich bei unserer Umsetzung mehr oder weniger um eine Art „AlwaysOn“ VPN bis hin zu einer Art SD-WAN Lösung, da der WireGuard Dienst auf den Clients eigentlich ununterbrochen aktiv bleibt.
WireGuard Dienst gestartet heißt nicht automatisch dass der Tunnel auch aktiv ist. Vor was möchtest du die User mit dem Konstrukt schützen? Gibt es irgendwelche „offiziellen“ Handreichungen oder Empfehlungen
Im öffentlichen Dienst ist je nach Behörde das BSI das Maß aller Dinge. In der Industrie kann viel durch Zertifizierungen vorgeschrieben werden. Aber da ist alles bis bis nichts möglich. Klar, im Militärbereich sieht es nochmals ganz anders aus.Gruß,
Dani
2
Moun.
Das wird wohl auf 2-stufige Anmeldung auslaufen ...
1. Wireguard-VPN zumbGateway-Server
2. Login mit MFA ins Unternehmensnetz.
Das wird wohl auf 2-stufige Anmeldung auslaufen ...
1. Wireguard-VPN zumbGateway-Server
2. Login mit MFA ins Unternehmensnetz.
Ungewöhnlich ist, dass der Koch die Speisekarte verhandelt.
Überhaupt außerhalb des Unternehmens oder des Homeoffices seine Login-Daten, auch in das eigene Gerät einzugeben ist als Kritisch anzusehen. An vielen Stellen ist das verboten.
Microsoft Always-On-VPN ist keine Möglichkeit?
Wireguard ist toll, aber nicht nur an dieser Stelle unausgereift.
VPN mit PIN+RSA-Token. wäre noch eine Idee. Finde ich persönlich aber nur bedingt dem MS AoVPN gleichwertig.
Überhaupt außerhalb des Unternehmens oder des Homeoffices seine Login-Daten, auch in das eigene Gerät einzugeben ist als Kritisch anzusehen. An vielen Stellen ist das verboten.
Microsoft Always-On-VPN ist keine Möglichkeit?
Wireguard ist toll, aber nicht nur an dieser Stelle unausgereift.
VPN mit PIN+RSA-Token. wäre noch eine Idee. Finde ich persönlich aber nur bedingt dem MS AoVPN gleichwertig.
Moin,
könnt ihr überhaupt alle Anforderungen erfüllen die im Kleingedruckten stehen? Beispiele können in so eine Richtung gehen:
Wenn niemand jeden zweiten Dienstag ab 22 Uhr die Windows-Systeme bis zum Sonnenaufgang patcht, dann ist man nicht sicher und in Verzug, was eine evtl. Auszahlung ausschließt.
Meist steht da so viele Unklarheiten dessen Interpretation nur der jeweilige Richter im Ernstfall auslegen kann, wie er eben mag. Aber wenn es euch ruhiger schlafen lässt, auch ein Grund für eine Versicherung (mit der Hoffnung das nie der Ernstfall eintritt).
könnt ihr überhaupt alle Anforderungen erfüllen die im Kleingedruckten stehen? Beispiele können in so eine Richtung gehen:
Wenn niemand jeden zweiten Dienstag ab 22 Uhr die Windows-Systeme bis zum Sonnenaufgang patcht, dann ist man nicht sicher und in Verzug, was eine evtl. Auszahlung ausschließt.
Meist steht da so viele Unklarheiten dessen Interpretation nur der jeweilige Richter im Ernstfall auslegen kann, wie er eben mag. Aber wenn es euch ruhiger schlafen lässt, auch ein Grund für eine Versicherung (mit der Hoffnung das nie der Ernstfall eintritt).
Wir haben in unserer GPO konfiguriert, dass nach zehn fehlerhaften Login-Versuchen das System neu startet und der Bitlocker Key eingegeben werden muss.
Moin @JoRu1407,
Ich kann dir an dieser Stelle nur den Tipp geben, dass die Bedingungen der Versicherung nicht nur "grundsätzlich" sondern exakt erfüllt werden müssen, ansonsten kann sich dein Kunde die Versicherung auch gleich wieder sparen.
Ja, diese Bedingung hat mittlerweile so gut wie jede Cyberversicherung und ich persönlich finde das auch gut und auch absolut gerechtfertigt so.
Ähm, bei mir stellen sich bei der Beschreibung schon jetzt die Nackenhaare. 😬
Ist den wenigstens die Anmeldung an den Geräten wo der WireGuard läuft, mit MFA gesichert?
Und auch selbst wenn das so währe, sehe ich dennoch an dem Konstrukt mehrere Punkte, die einen Angriff auf das System dahinter, eher begünstigen, vor allem das "AlwaysOn". 😔
Und das fordert die meiner Ansicht nach auch zurecht, da sobald der entsprechende Rechner infiziert ist, dem Angreifer die Tür in das interne Netz, wahrscheinlich sehr weit offen steht.
Eher genau so kritisch wie die Versicherung.
Nein, ich würde auch keinen Fall etwas unterschreiben was nicht gegeben ist.
Sprich, bei der Frage nach VPN und 2FA, darfst du auf keinen Fall den Hacken bei "JA" setzen!
https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/Kompendi ...
Siehe insbesondere 2.3.
SSL-VPN, am Besten nicht mit AD gekoppelt, sprich, eigener Benutzerkreis + 2FA.
Damit rennst du bei der Versicherung ganz sicher die Tür ein. 😉
Deine User werden dich dafür aber wahrscheinlich eher lynchen. 🙃
Aber ja, so ist das mit der Sicherheit, sprich, einen Tod muss man dabei mindestens Sterben. 🤪
Beste Grüsse aus BaWü
Alex
wir sind gerade im Austausch mit der zukünftigen Cyberversicherung unseres Kunden bezüglich der IT-Sicherheitsanforderungen. Grundsätzlich erfüllt die durch uns betreute IT-Infrastruktur bereits alle Versicherungsanforderungen vollumfänglich, allerdings bereitet uns nun das Thema MFA bei VPN Zugängen Probleme:
Ich kann dir an dieser Stelle nur den Tipp geben, dass die Bedingungen der Versicherung nicht nur "grundsätzlich" sondern exakt erfüllt werden müssen, ansonsten kann sich dein Kunde die Versicherung auch gleich wieder sparen.
Der Versicherer fordert zwingend durch MFA abgesicherter VPN Zugänge zum Firmennetz und begründet dies damit, dass ansonsten Anmeldedaten zum VPN abgegriffen werden könnten und dadurch u.U. Weltweiter Zugriff auf Unternehmensdaten durch Dritte möglich sei. Daher wird neben einem Benutzerpasswort ein weiteres Merkmal (OTP, Fido Token etc.) gefordert.
Ja, diese Bedingung hat mittlerweile so gut wie jede Cyberversicherung und ich persönlich finde das auch gut und auch absolut gerechtfertigt so.
Wir setzen dort allerdings flächendeckend WireGuard als VPN ein, welches keine MFA unterstützt. Aus unserer Sicht kann es das auch schon aus rein technischen Gründen gar nicht, schließlich arbeitet es mit asymmetrischen Schlüsselpaaren, die je Endgerät ausgestellt werden. Das schließt aus unserer Sicht sämtliche Angriffswege, die durch MFA verhindert werden sollen (bspw. Phishing) bereits aus. Ich persönlich würde eine Gerätegebundene Authentifizierung und Verschlüsselung basierend auf Private- / Publickeys sowie WireGuard an sich in diesem Zusammenhang als modernster Stand der Technik bezeichnen. Sämtliche Clients sind natürlich zusätzlich mit Bitlocker verschlüsselt, sodass auch der Verlust des Geräts nicht zu einem Verlust des Privatekeys führen kann. Im Grunde handelt es sich bei unserer Umsetzung mehr oder weniger um eine Art „AlwaysOn“ VPN bis hin zu einer Art SD-WAN Lösung, da der WireGuard Dienst auf den Clients eigentlich ununterbrochen aktiv bleibt.
Ähm, bei mir stellen sich bei der Beschreibung schon jetzt die Nackenhaare. 😬
Ist den wenigstens die Anmeldung an den Geräten wo der WireGuard läuft, mit MFA gesichert?
Und auch selbst wenn das so währe, sehe ich dennoch an dem Konstrukt mehrere Punkte, die einen Angriff auf das System dahinter, eher begünstigen, vor allem das "AlwaysOn". 😔
Der Versicherer lässt sich hiervon aber aktuell nicht überzeugen und fordert weiterhin eine MFA Absicherung der VPN Zugänge.
Und das fordert die meiner Ansicht nach auch zurecht, da sobald der entsprechende Rechner infiziert ist, dem Angreifer die Tür in das interne Netz, wahrscheinlich sehr weit offen steht.
Wie seht ihr das?
Eher genau so kritisch wie die Versicherung.
Haben wir hier auf das falsche Pferd gesetzt, oder würdet ihr das grundsätzlich so unterschreiben?
Nein, ich würde auch keinen Fall etwas unterschreiben was nicht gegeben ist.
Sprich, bei der Frage nach VPN und 2FA, darfst du auf keinen Fall den Hacken bei "JA" setzen!
Gibt es irgendwelche „offiziellen“ Handreichungen oder Empfehlungen, die die Sicherheit der aktuellen Lösung mit MFA VPNs vergleichen?
https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/Kompendi ...
Siehe insbesondere 2.3.
Habt ihr irgendwelche Alternativvorschläge?
SSL-VPN, am Besten nicht mit AD gekoppelt, sprich, eigener Benutzerkreis + 2FA.
Damit rennst du bei der Versicherung ganz sicher die Tür ein. 😉
Deine User werden dich dafür aber wahrscheinlich eher lynchen. 🙃
Aber ja, so ist das mit der Sicherheit, sprich, einen Tod muss man dabei mindestens Sterben. 🤪
Beste Grüsse aus BaWü
Alex
1
Moin @JoeDevlin,
Wir haben in unserer GPO konfiguriert, dass nach zehn fehlerhaften Login-Versuchen das System neu startet und der Bitlocker Key eingegeben werden muss.
und inwieweit hilft das, wenn sich ein Schädling bereits unbemerkt auf dem entsprechenden Client einnisten konnte?
Bei einer VPN Einwahl die per 2FA abgesichert ist, würde er zumindest nichts anrichten können, solange der User nicht bewusst den VPN aufbaut. 😉
Gruss Alex
Wir haben in unserer GPO konfiguriert, dass nach zehn fehlerhaften Login-Versuchen das System neu startet und der Bitlocker Key eingegeben werden muss.
und inwieweit hilft das, wenn sich ein Schädling bereits unbemerkt auf dem entsprechenden Client einnisten konnte?
Bei einer VPN Einwahl die per 2FA abgesichert ist, würde er zumindest nichts anrichten können, solange der User nicht bewusst den VPN aufbaut. 😉
Gruss Alex
1
Moin @nachgefragt,
nein, ganz so schlimm sin die Bedingungen jetzt auch nicht.
Siehe Beispiel von der HISCOX ...
https://www.hiscox.de/geschaeftskunden/cyber-versicherung/
Ja, bei grobem Unfug kann sich eine Versicherung schon auf die Hinterbeine stellen, vor allem wenn man die wenigen Fragen aus dem Antrag, bereits schon nicht wahrheitsgemäss beantwortet oder sich im Nachgang nicht daran gehalten hat.
Gruss Alex
könnt ihr überhaupt alle Anforderungen erfüllen die im Kleingedruckten stehen? Beispiele können in so eine Richtung gehen:
Wenn niemand jeden zweiten Dienstag ab 22 Uhr die Windows-Systeme bis zum Sonnenaufgang patcht, dann ist man nicht sicher und in Verzug, was eine evtl. Auszahlung ausschließt.
Wenn niemand jeden zweiten Dienstag ab 22 Uhr die Windows-Systeme bis zum Sonnenaufgang patcht, dann ist man nicht sicher und in Verzug, was eine evtl. Auszahlung ausschließt.
nein, ganz so schlimm sin die Bedingungen jetzt auch nicht.
Siehe Beispiel von der HISCOX ...
Meist steht da so viele Unklarheiten dessen Interpretation nur der jeweilige Richter im Ernstfall auslegen kann, wie er eben mag. Aber wenn es euch ruhiger schlafen lässt, auch ein Grund für eine Versicherung (mit der Hoffnung das nie der Ernstfall eintritt).
Ja, bei grobem Unfug kann sich eine Versicherung schon auf die Hinterbeine stellen, vor allem wenn man die wenigen Fragen aus dem Antrag, bereits schon nicht wahrheitsgemäss beantwortet oder sich im Nachgang nicht daran gehalten hat.
Gruss Alex
1
Vielen Dank erst mal für die zahlreichen Rückmeldungen! Grundsätzlich sind wir beim betreffenden Kunden nur externer IT-Dienstleister, daher haben nicht wir, sondern unser Kunde die Entscheidung pro Cyberversicherung getroffen. Ich persönlich bin auch noch unschlüssig, wie sinnvoll das im Schadensfall wirklich ist. Am Ende entscheidet und beauftragt der Kunde, was gemacht wird. Da wir aber gefragt wurden, haben mich eure Meinungen sehr interessiert.
Wireguard richtet für jede konfigurierte Verbindung einen separaten Windows-Dienst ein. Sobald dieser läuft, steht auch die Connection. Wir möchten mit diesem Konstrukt erreichen, dass der User im Grunde gar nicht mit der VPN in Berührung kommt. Wir installieren die mobilen Geräte, stellen ein Gerätezertifikat für's VPN aus und sichern den Client ab. Was der User nicht kennt, kann auch nicht von ihm gestohlen werden (bspw. Phishing).
Genau so ist das bei uns auch umgesetzt. Ich sehe also die mobilen Clients bei Verlust oder Diebstahl schon recht gut gegen Angriffe geschützt. Zusätzlich ließe sich ja auch jederzeit das Wireguard Zertifikat des Geräts sperren.
Könntest du das näher ausführen? Ich sehe insbesondere diesen Punkt nämlich grundsätzlich anders:
Der privaten Wireguard Schlüssel des Clients kann ausschließlich mit administrativen Rechten (die Benutzer sind selbstverständlich keine lokalen Admins) ausgelesen werden. Und dies wäre nur möglich, wenn der Client bereits mit entsprechender Schadsoftware infiziert ist. In einem solchen Fall nützt bei mobilen Clients, die 99% der Zeit sowieso immer im VPN eingebucht wären (auch bei einer MFA Lösung), aber auch die 2FA nichts, da Angreifer über die Schadsoftware dann genau so gut die aktive VPN missbrauchen könnten. 2FA ist doch im Grunde der Goldstandard, Benutzerpasswörter vor Phishing oder MITM zu schützen. Sind asymmetrische Zertifikate nicht mindestens gleichwertig?
Ich möchte an der Stelle mal auf folgende Beispiele hinaus, um meinen Gedankengang zu erläutern:
Angenommen ich authentifiziere mich als Nutzer bei M365 oder einem anderen Onlinedienst via 2FA, mein Zugang ist also grundsätzlich durch MFA geschützt. Am Ende speichert der Browser dann aber auch nur einen JWT oder ein anderweitiges Cookie, welches fortan Zugriff gewährt. Stiehlt ein Angreifer dieses Token, hat er ebenfalls Zugriff auf alle Dienste, ohne dass die MFA das verhindern könnte. Nichts anderes als dieser Token ist am Ende der Wireguard Schlüssel, mit der zusätzlichen Sicherheit, dass er nur mit administrativen Rechten ausgelesen werden könnte.
Angenommen, wir würden auf z.B. Tailscale als SD-WAN Lösung setzen: Die werben u.a. mit MFA. Aber was passiert am Ende? Ich muss mich mittels MFA bei Tailscale einloggen, danach wird auf dem betreffenden Client ein Zertifikat gespeichert und dieses ermöglicht 180 Tage Zugriff ohne erneut nach einem zweiten Faktor zu fragen. Bietet das irgendeine Verbesserung im Vergleich zu Wireguard?
Was unterscheidet ein administriertes Gerät innerhalb des Unternehmensnetzwerks physisch vor Ort von einem mobilen Gerät mit einer Wireguard "AlwaysOn" VPN? Beide Geräte hängen sofort nach dem Einschalten im internen Firmennetz. Auf beiden Geräten muss und wird nicht nach eine MFA für Netzwerkzugriff gefragt. Inwiefern unterscheidet sich ein administrierter mobiler Client mit Wireguard von einem Client an einem zweiten Standort des Kunden, der via Site-2-Site angebunden ist? Hier wird auch keine MFA für den Netzwerkzugriff gefordert. Ist eben auch (im Regelfall, ausgenommen 802.1.X Auth etc.) nicht erforderlich, da eben auf technischer Ebene bereits Zugriff gewährt wird, ohne dass der Benutzer tätig werden muss. Bei herkömmlichen VPN Lösungen musste eben der Benutzer tätig werden, das ermöglichte Angriffsszenarien ala Phishing oder Social-Engineering. MFA wird hier gebraucht, um ein dadurch entstehendes Problem zu entschärfen. Bei unserer Wireguard Lösung haben wir dieses Risiko / Problem aber schon von Grund auf nicht.
Viele Grüße
Joshua
Zitat von @Dani:
WireGuard Dienst gestartet heißt nicht automatisch dass der Tunnel auch aktiv ist. Vor was möchtest du die User mit dem Konstrukt schützen?
WireGuard Dienst gestartet heißt nicht automatisch dass der Tunnel auch aktiv ist. Vor was möchtest du die User mit dem Konstrukt schützen?
Wireguard richtet für jede konfigurierte Verbindung einen separaten Windows-Dienst ein. Sobald dieser läuft, steht auch die Connection. Wir möchten mit diesem Konstrukt erreichen, dass der User im Grunde gar nicht mit der VPN in Berührung kommt. Wir installieren die mobilen Geräte, stellen ein Gerätezertifikat für's VPN aus und sichern den Client ab. Was der User nicht kennt, kann auch nicht von ihm gestohlen werden (bspw. Phishing).
Zitat von @JoeDevlin:
Wir haben in unserer GPO konfiguriert, dass nach zehn fehlerhaften Login-Versuchen das System neu startet und der Bitlocker Key eingegeben werden muss.
Wir haben in unserer GPO konfiguriert, dass nach zehn fehlerhaften Login-Versuchen das System neu startet und der Bitlocker Key eingegeben werden muss.
Genau so ist das bei uns auch umgesetzt. Ich sehe also die mobilen Clients bei Verlust oder Diebstahl schon recht gut gegen Angriffe geschützt. Zusätzlich ließe sich ja auch jederzeit das Wireguard Zertifikat des Geräts sperren.
Zitat von @MysticFoxDE:
Ähm, bei mir stellen sich bei der Beschreibung schon jetzt die Nackenhaare. 😬
Ist den wenigstens die Anmeldung an den Geräten wo der WireGuard läuft, mit MFA gesichert?
Und auch selbst wenn das so währe, sehe ich dennoch an dem Konstrukt mehrere Punkte, die einen Angriff auf das System dahinter, eher begünstigen, vor allem das "AlwaysOn". 😔
Und das fordert die meiner Ansicht nach auch zurecht, da sobald der entsprechende Rechner infiziert ist, dem Angreifer die Tür in das interne Netz, wahrscheinlich sehr weit offen steht.
Ähm, bei mir stellen sich bei der Beschreibung schon jetzt die Nackenhaare. 😬
Ist den wenigstens die Anmeldung an den Geräten wo der WireGuard läuft, mit MFA gesichert?
Und auch selbst wenn das so währe, sehe ich dennoch an dem Konstrukt mehrere Punkte, die einen Angriff auf das System dahinter, eher begünstigen, vor allem das "AlwaysOn". 😔
Der Versicherer lässt sich hiervon aber aktuell nicht überzeugen und fordert weiterhin eine MFA Absicherung der VPN Zugänge.
Und das fordert die meiner Ansicht nach auch zurecht, da sobald der entsprechende Rechner infiziert ist, dem Angreifer die Tür in das interne Netz, wahrscheinlich sehr weit offen steht.
Könntest du das näher ausführen? Ich sehe insbesondere diesen Punkt nämlich grundsätzlich anders:
Der privaten Wireguard Schlüssel des Clients kann ausschließlich mit administrativen Rechten (die Benutzer sind selbstverständlich keine lokalen Admins) ausgelesen werden. Und dies wäre nur möglich, wenn der Client bereits mit entsprechender Schadsoftware infiziert ist. In einem solchen Fall nützt bei mobilen Clients, die 99% der Zeit sowieso immer im VPN eingebucht wären (auch bei einer MFA Lösung), aber auch die 2FA nichts, da Angreifer über die Schadsoftware dann genau so gut die aktive VPN missbrauchen könnten. 2FA ist doch im Grunde der Goldstandard, Benutzerpasswörter vor Phishing oder MITM zu schützen. Sind asymmetrische Zertifikate nicht mindestens gleichwertig?
Ich möchte an der Stelle mal auf folgende Beispiele hinaus, um meinen Gedankengang zu erläutern:
Angenommen ich authentifiziere mich als Nutzer bei M365 oder einem anderen Onlinedienst via 2FA, mein Zugang ist also grundsätzlich durch MFA geschützt. Am Ende speichert der Browser dann aber auch nur einen JWT oder ein anderweitiges Cookie, welches fortan Zugriff gewährt. Stiehlt ein Angreifer dieses Token, hat er ebenfalls Zugriff auf alle Dienste, ohne dass die MFA das verhindern könnte. Nichts anderes als dieser Token ist am Ende der Wireguard Schlüssel, mit der zusätzlichen Sicherheit, dass er nur mit administrativen Rechten ausgelesen werden könnte.
Angenommen, wir würden auf z.B. Tailscale als SD-WAN Lösung setzen: Die werben u.a. mit MFA. Aber was passiert am Ende? Ich muss mich mittels MFA bei Tailscale einloggen, danach wird auf dem betreffenden Client ein Zertifikat gespeichert und dieses ermöglicht 180 Tage Zugriff ohne erneut nach einem zweiten Faktor zu fragen. Bietet das irgendeine Verbesserung im Vergleich zu Wireguard?
Was unterscheidet ein administriertes Gerät innerhalb des Unternehmensnetzwerks physisch vor Ort von einem mobilen Gerät mit einer Wireguard "AlwaysOn" VPN? Beide Geräte hängen sofort nach dem Einschalten im internen Firmennetz. Auf beiden Geräten muss und wird nicht nach eine MFA für Netzwerkzugriff gefragt. Inwiefern unterscheidet sich ein administrierter mobiler Client mit Wireguard von einem Client an einem zweiten Standort des Kunden, der via Site-2-Site angebunden ist? Hier wird auch keine MFA für den Netzwerkzugriff gefordert. Ist eben auch (im Regelfall, ausgenommen 802.1.X Auth etc.) nicht erforderlich, da eben auf technischer Ebene bereits Zugriff gewährt wird, ohne dass der Benutzer tätig werden muss. Bei herkömmlichen VPN Lösungen musste eben der Benutzer tätig werden, das ermöglichte Angriffsszenarien ala Phishing oder Social-Engineering. MFA wird hier gebraucht, um ein dadurch entstehendes Problem zu entschärfen. Bei unserer Wireguard Lösung haben wir dieses Risiko / Problem aber schon von Grund auf nicht.
Viele Grüße
Joshua
Danke für das Beispiel 
So mancher Vertragsabschluss mit einer Cyber-Versicherung ist mit einer Checkliste einer Zertifizierung gleichzusetzen, beides ein Beleg für Vorkehrungen und Maßnahmen welche...
So mancher Vertragsabschluss mit einer Cyber-Versicherung ist mit einer Checkliste einer Zertifizierung gleichzusetzen, beides ein Beleg für Vorkehrungen und Maßnahmen welche...
kann sich eine Versicherung schon auf die Hinterbeine stellen
... es nicht selten zu beweisen gilt.
Moin @JoRu1407,
und mit welchem Konto läuft dieser "Wireguard-Dienst" und welche Berechtigungen hat dieses?
Bring dir aber nicht viel, wenn der Angreifer die Zugangsdaten bereits kennt. 😔
Jain, den sobald der Angreifer den Windows Login kennt, bringt dir der Rest nicht wirklich viel.
Klar.
Das ist in der IT ganz Normal. 😁
Wenn du 10 ITler nach deren Meinung befragst, dann kann es nicht selten passieren,
dass du darauf dann mindestens 10 unterschiedliche Antworten bekommst, die dann je nach Tageszeit auch noch variieren können . 🤪
Jup und genau der Punkt, dass wenn der Client infiziert ist, der Angreifer dank "AlwaysOn" VPN und ohne weitere Hürden auf dein Hauptsystem durchspazieren kann, bereitet der Versicherung auch die Sorgen.
Ja, aber bei weitem nicht ganz so nach Lust und Laune, wie bei deiner Lösung.
Die SSL-VPN's die wir bei unseren Kunden konfigurieren, werden nach Ablauf einer gewissen Frist immer zwangsläufig getrennt und danach muss sich der User erneut mit 2FA einwählen.
Das soll verhindern, dass wenn ein Angreifer schon ein externes Gerät wie auch immer gekapert hat, er dieses auf jeden Fall z.B. nicht über das ganze Wochenende benutzen kann, um das Hauptsystem zu infiltrieren. 😉
Ähm, fast. 2FA schützt nicht wirklich davor, dass ein Angreifer dein Benutzernahmen und das Passwort nicht klauen kann, sondern eher dann, wenn der Angreifer diese bereits erbeutet hat. Denn ohne den Quasi dritten Faktor, z.B. einem Token, kommt er bei mit MFA Abgesicherten Diensten mit einem geklauten Benutzernahmen und Passwort auch nicht weiter.
Und solange eure Benutzer für die interne Authentifizierung, einen Benutzernamen und vor allem auch ein Passwort eingeben müssen, besteht immer die Gefahr, dass sie, vor allem das gleiche Passwort, auch bei vielen anderen externen Zugängen, wie z.B. 0815 Online-Shops benutzen.
Die asymmetrische Zertifikate sichern meiner Ansicht nach, bei dir lediglich die "Integrität" des VPN's ab, sprich, dass man von Aussen nicht so einfach an die durch den VPN fliessenden Daten herankommen kann.
Sobald jedoch einer der EndPoint's selbst übernommen wird, bietet dir dieses Konstrukt überhaupt keinen Schutz, im Gegenteil, durch das "AlwaysOn" hast du meiner Ansicht nach, dann ein riesiges Loch in deinem primären Schutzwall klaffen.
Natürlich kann man diesen Problem mit dem Aufstellen von weiteren Schutzwällen wie IPS, ATP & Co ein Stückweit entgegen wirken, jedoch kostet jeder Schutzwall auch immer extra und zwar sowohl bei der Anschaffung als auch bei der Pflege.
M365 ... OK ... wie sage ich das jetzt am Besten, ohne dass mir danach diese Cloud-Jünger wieder mein ganzes Fell abfackeln wollen. 🤔
Ähm, ja, des M365 isch a ganz jefährliche Rakettawissenschaft, vor allem mit AD-Sync und so. 🤪
Gruss Alex
Wireguard richtet für jede konfigurierte Verbindung einen separaten Windows-Dienst ein.
und mit welchem Konto läuft dieser "Wireguard-Dienst" und welche Berechtigungen hat dieses?
Wir haben in unserer GPO konfiguriert, dass nach zehn fehlerhaften Login-Versuchen das System neu startet und der Bitlocker Key eingegeben werden muss.
Bring dir aber nicht viel, wenn der Angreifer die Zugangsdaten bereits kennt. 😔
Genau so ist das bei uns auch umgesetzt. Ich sehe also die mobilen Clients bei Verlust oder Diebstahl schon recht gut gegen Angriffe geschützt.
Jain, den sobald der Angreifer den Windows Login kennt, bringt dir der Rest nicht wirklich viel.
Könntest du das näher ausführen?
Klar.
Ich sehe insbesondere diesen Punkt nämlich grundsätzlich anders:
Das ist in der IT ganz Normal. 😁
Wenn du 10 ITler nach deren Meinung befragst, dann kann es nicht selten passieren,
dass du darauf dann mindestens 10 unterschiedliche Antworten bekommst, die dann je nach Tageszeit auch noch variieren können . 🤪
Der privaten Wireguard Schlüssel des Clients kann ausschließlich mit administrativen Rechten (die Benutzer sind selbstverständlich keine lokalen Admins) ausgelesen werden. Und dies wäre nur möglich, wenn der Client bereits mit entsprechender Schadsoftware infiziert ist.
Jup und genau der Punkt, dass wenn der Client infiziert ist, der Angreifer dank "AlwaysOn" VPN und ohne weitere Hürden auf dein Hauptsystem durchspazieren kann, bereitet der Versicherung auch die Sorgen.
In einem solchen Fall nützt bei mobilen Clients, die 99% der Zeit sowieso immer im VPN eingebucht wären (auch bei einer MFA Lösung), aber auch die 2FA nichts, da Angreifer über die Schadsoftware dann genau so gut die aktive VPN missbrauchen könnten.
Ja, aber bei weitem nicht ganz so nach Lust und Laune, wie bei deiner Lösung.
Die SSL-VPN's die wir bei unseren Kunden konfigurieren, werden nach Ablauf einer gewissen Frist immer zwangsläufig getrennt und danach muss sich der User erneut mit 2FA einwählen.
Das soll verhindern, dass wenn ein Angreifer schon ein externes Gerät wie auch immer gekapert hat, er dieses auf jeden Fall z.B. nicht über das ganze Wochenende benutzen kann, um das Hauptsystem zu infiltrieren. 😉
2FA ist doch im Grunde der Goldstandard, Benutzerpasswörter vor Phishing oder MITM zu schützen.
Ähm, fast. 2FA schützt nicht wirklich davor, dass ein Angreifer dein Benutzernahmen und das Passwort nicht klauen kann, sondern eher dann, wenn der Angreifer diese bereits erbeutet hat. Denn ohne den Quasi dritten Faktor, z.B. einem Token, kommt er bei mit MFA Abgesicherten Diensten mit einem geklauten Benutzernahmen und Passwort auch nicht weiter.
Und solange eure Benutzer für die interne Authentifizierung, einen Benutzernamen und vor allem auch ein Passwort eingeben müssen, besteht immer die Gefahr, dass sie, vor allem das gleiche Passwort, auch bei vielen anderen externen Zugängen, wie z.B. 0815 Online-Shops benutzen.
Sind asymmetrische Zertifikate nicht mindestens gleichwertig?
Die asymmetrische Zertifikate sichern meiner Ansicht nach, bei dir lediglich die "Integrität" des VPN's ab, sprich, dass man von Aussen nicht so einfach an die durch den VPN fliessenden Daten herankommen kann.
Sobald jedoch einer der EndPoint's selbst übernommen wird, bietet dir dieses Konstrukt überhaupt keinen Schutz, im Gegenteil, durch das "AlwaysOn" hast du meiner Ansicht nach, dann ein riesiges Loch in deinem primären Schutzwall klaffen.
Natürlich kann man diesen Problem mit dem Aufstellen von weiteren Schutzwällen wie IPS, ATP & Co ein Stückweit entgegen wirken, jedoch kostet jeder Schutzwall auch immer extra und zwar sowohl bei der Anschaffung als auch bei der Pflege.
Ich möchte an der Stelle mal auf folgende Beispiele hinaus, um meinen Gedankengang zu erläutern:
Angenommen ich authentifiziere mich als Nutzer bei M365
Angenommen ich authentifiziere mich als Nutzer bei M365
M365 ... OK ... wie sage ich das jetzt am Besten, ohne dass mir danach diese Cloud-Jünger wieder mein ganzes Fell abfackeln wollen. 🤔
Ähm, ja, des M365 isch a ganz jefährliche Rakettawissenschaft, vor allem mit AD-Sync und so. 🤪
Gruss Alex
1
Hi,
ich verfolge diese interessante Diskussion mit den unterschiedlichen Standpunkten und muß sagen, daß ich einige Aspekte so noch nicht auf dem Schirm hatte (irgendwann wird man betriebsblind). Bei mit läuft es ähnlich wie beim Themenstarter: Bitlocker auf dem HO-PC bzw. Notebooks, Zugang zur Wireguard-Config nur als lokaler Administrator, der User meldet sich am Samba-Server mit Benutzernamen und Passwort an (isch abe gar kein Active Directory..).
Wie wäre denn es mit einer Authentifizierung an einem Radius-Server mit MFA , z.B. am Opnsense-Router, auf dem ja schon der Wiregurad-Server läuft?
Bin für jede Anregung dankbar.
Grüße
Michael
ich verfolge diese interessante Diskussion mit den unterschiedlichen Standpunkten und muß sagen, daß ich einige Aspekte so noch nicht auf dem Schirm hatte (irgendwann wird man betriebsblind). Bei mit läuft es ähnlich wie beim Themenstarter: Bitlocker auf dem HO-PC bzw. Notebooks, Zugang zur Wireguard-Config nur als lokaler Administrator, der User meldet sich am Samba-Server mit Benutzernamen und Passwort an (isch abe gar kein Active Directory..).
Wie wäre denn es mit einer Authentifizierung an einem Radius-Server mit MFA , z.B. am Opnsense-Router, auf dem ja schon der Wiregurad-Server läuft?
Bin für jede Anregung dankbar.
Grüße
Michael
Guten Abend @MysticFoxDE
vielen Dank für deine Rückmeldung. Die meisten Sachen kann ich gut nachvollziehen und gerade weil es in der IT zu solchen Themen viele verschiedene Meinungen geben kann, freue ich mich über den regen Austausch.
Ich fasse die Sicherheitsrisiken mal in zwei Punkten zusammen:
Bei Punkt 1 sehe ich definitiv, wie du, Verbesserungspotential. Reicht ja schon, dass der Nutzer sein Passwort noch auf nem' Zettel in der Notebooktasche durch die Gegend trägt. Hier sollten wir im Grunde genommen schauen, dass schon der Windows Login auf dem mobilen Endgerät um 2FA ergänzt wird. Damit wäre dieser Punkt ja mehr oder weniger erledigt.
Punkt 2 verstehe ich natürlich grundsätzlich auch, sehe aber nicht, wieso das so relevant ist. Dahingehend waren auch meine anderen beiden Gegenbeispiele gemeint:
Was unterscheidet einen Angreifer auf einem mobilen Client mit VPN von einem Angreifer, der Zugriff auf einen Client im internen Firmennetz oder auf einen Client an einer Zweigstelle hätte, die via Site-2-Site vernetzt ist?
Ich verstehe nicht, warum es hier plötzlich so relevant sein soll, Angreifern auf einem Client mit VPN das Leben "etwas schwerer" zu machen, wenn sie am Ende auch jeden anderen Client im internen Firmennetz gleichermaßen missbrauchen könnten. Oder alternativ einfach warten könnten, bis der Mitarbeiter die VPN mittels 2FA hergestellt hat. Da von den mobilen Clients fast nur via RDS gearbeitet wird, muss die VPN eben effektiv dauerhaft mitlaufen.
Nicht falsch verstehen: Es ist grundsätzlich natürlich immer sinnvoll, Angreifern das leben schwerer zu machen, wo es nur geht, aber ich versuche das immer realistisch zu betrachten und zu schauen, welche Maßnahme mit welchem Aufwand wie viel bringt.
Daher sehe ich aktuell allein durch die Clients mit Wireguard noch kein großes Loch in der primären Schutzwall, da eben auch von rund 100 weiteren Clients jederzeit Netzwerkzugriff ohne 2FA besteht.
Sowohl der WireGuard Manager Dienst (zuständig für das Einrichten der anderen verbindungsspezifischen Dienste), als auch die einzelnen Verbindungsdienste laufen alle unter "Lokales System".
M365 und Azure AD Hybrid ist ein Thema für sich, aber du kannst mein Argument mit 2FA Login und anschließender Session Cookies oder JWTs im Grunde auf jeden Onlinedienst übertragen, alle sind gleichermaßen anfällig, sobald Angreifer im System sind oder Zugriff auf's Windows Konto und den Browser haben - 2FA hin oder her.
Viele Grüße
Joshua
vielen Dank für deine Rückmeldung. Die meisten Sachen kann ich gut nachvollziehen und gerade weil es in der IT zu solchen Themen viele verschiedene Meinungen geben kann, freue ich mich über den regen Austausch.
Ich fasse die Sicherheitsrisiken mal in zwei Punkten zusammen:
- Diebstahl / Verlust des Geräts bei bekanntem Benutzerpasswort
- Angreifer bzw. Schadsoftware sind/ist bereits auf dem mobilen Endgerät
Bei Punkt 1 sehe ich definitiv, wie du, Verbesserungspotential. Reicht ja schon, dass der Nutzer sein Passwort noch auf nem' Zettel in der Notebooktasche durch die Gegend trägt. Hier sollten wir im Grunde genommen schauen, dass schon der Windows Login auf dem mobilen Endgerät um 2FA ergänzt wird. Damit wäre dieser Punkt ja mehr oder weniger erledigt.
Punkt 2 verstehe ich natürlich grundsätzlich auch, sehe aber nicht, wieso das so relevant ist. Dahingehend waren auch meine anderen beiden Gegenbeispiele gemeint:
Was unterscheidet einen Angreifer auf einem mobilen Client mit VPN von einem Angreifer, der Zugriff auf einen Client im internen Firmennetz oder auf einen Client an einer Zweigstelle hätte, die via Site-2-Site vernetzt ist?
Ich verstehe nicht, warum es hier plötzlich so relevant sein soll, Angreifern auf einem Client mit VPN das Leben "etwas schwerer" zu machen, wenn sie am Ende auch jeden anderen Client im internen Firmennetz gleichermaßen missbrauchen könnten. Oder alternativ einfach warten könnten, bis der Mitarbeiter die VPN mittels 2FA hergestellt hat. Da von den mobilen Clients fast nur via RDS gearbeitet wird, muss die VPN eben effektiv dauerhaft mitlaufen.
Nicht falsch verstehen: Es ist grundsätzlich natürlich immer sinnvoll, Angreifern das leben schwerer zu machen, wo es nur geht, aber ich versuche das immer realistisch zu betrachten und zu schauen, welche Maßnahme mit welchem Aufwand wie viel bringt.
Daher sehe ich aktuell allein durch die Clients mit Wireguard noch kein großes Loch in der primären Schutzwall, da eben auch von rund 100 weiteren Clients jederzeit Netzwerkzugriff ohne 2FA besteht.
und mit welchem Konto läuft dieser "Wireguard-Dienst" und welche Berechtigungen hat dieses?
Sowohl der WireGuard Manager Dienst (zuständig für das Einrichten der anderen verbindungsspezifischen Dienste), als auch die einzelnen Verbindungsdienste laufen alle unter "Lokales System".
Ähm, ja, des M365 isch a ganz jefährliche Rakettawissenschaft, vor allem mit AD-Sync und so. 🤪
M365 und Azure AD Hybrid ist ein Thema für sich, aber du kannst mein Argument mit 2FA Login und anschließender Session Cookies oder JWTs im Grunde auf jeden Onlinedienst übertragen, alle sind gleichermaßen anfällig, sobald Angreifer im System sind oder Zugriff auf's Windows Konto und den Browser haben - 2FA hin oder her.
Viele Grüße
Joshua
Zitat von @JoRu1407:
Was unterscheidet einen Angreifer auf einem mobilen Client mit VPN von einem Angreifer, der Zugriff auf einen Client im internen Firmennetz oder auf einen Client an einer Zweigstelle hätte, die via Site-2-Site vernetzt ist?
Was unterscheidet einen Angreifer auf einem mobilen Client mit VPN von einem Angreifer, der Zugriff auf einen Client im internen Firmennetz oder auf einen Client an einer Zweigstelle hätte, die via Site-2-Site vernetzt ist?
Das hängt ja von der Infrastruktur im Unternehmensnetzwerk ab ...
Bestenfalls wird der VPN gar nicht bis in das inner U-Netzeerrk durchgeschaltet, sondern endet auf einem VPN-Gateway hinzer der 1. Firewall...
Im Anschluss kann der Benutzer sich mit 2FA sm Unternejhmensnetzwerk anmelden, ...
... aber via [Reverse-]Proxy, Anwendungsserver, RDP-Proxy, etc...
... und kommt erst bei Erfolg durch die 2te Firewall zu den internen Ressourcen ...
... soweit nötig ... Applikationsserver z.B. könnten auch in der DMZ stehen, sodass der User für die Nutzung einzelner Applikationen gar nicht ins interne Netz durchgeschaltet werden muss ...
Das ist aber sehr Unternehmensspezifisch .
Moin @JoRu1407,
Ja, mit Windows Login und 2FA ist das ganze auf jeden Fall um einiges sicherer und damit sollte sich dann auch die Versicherung, meiner Ansicht nach zufrieden geben.
Ich würde dir, insbesondere bei externen Geräten gerne den Login über z.B. einen Yubikey empfehlen, inclusive der Einstellung, dass der angemeldete Benutzer abgemeldet wird, sobald der Yubikey gezogen wird. 😉
Zudem hat der Login über die Yubikeys noch einen ganz anderen Charm. 😁
Denn so muss ein Benutzer, vorausgesetzt die Interne Infrastruktur ist 100% SSO fähig, das Passwort überhaupt nicht mehr kennen und kann es demzufolge auch nirgends extern verwenden, wo es dann geklaut werden könnte. 😎
Na hoffentlich unter anderem die Tatsache, dass das internen Firmennetz und auch die Zweigstelle(n), durch mächtige SGW's (Security-Gateway alla Sophos XGS & Co.) welches Dinge wie IPS, ATP, SSL-Inspektion und Co. beherrschen geschützt ist, die es dem Angreifer, am Besten so gut wie unmöglich machen, einen Client im Inneren zu infizieren.
Weil du an einen internen Client, wegen den hoffentlich vorhandenen und bissigen Wachhunden (SGW & Co.), im Normallfall nicht ganz so einfach ran kommst, wie an einen externen Client, der im schlimmsten Fall nur hinter einer Fritze oder noch schlimmer hängt, sprich, nur von einem Chihuahua bewacht wird. 🤪
Na ja, per RDP kann ein Angreifer eben nicht das dahinterliegende System mal so kurz hops nehmen, zumindest solange der User selbst noch davor sitzt, weil er sich dadurch quasi enttarnen würde.
Daher ist es meiner Ansicht nach mitunter auch sehr wichtig, dass man so gut es geht sicherstellt, dass die VPN Verbindung nur dann aktiv ist, wenn der User auch tatsächlich vor dem externen Rechner sitzt.
👍👍👍
Wie schon oben geschrieben, die internen Clients, sollten im Normalfall viel besser geschützt sein als die externen, daher kannst du die auch nicht wirklich 1:1 vergleichen.
M365 und Azure AD Hybrid ist ein Thema für sich, aber du kannst mein Argument mit 2FA Login und anschließender Session Cookies oder JWTs im Grunde auf jeden Onlinedienst übertragen, alle sind gleichermaßen anfällig, sobald Angreifer im System sind oder Zugriff auf's Windows Konto und den Browser haben - 2FA hin oder her.
Jup und genau deswegen halte ich überhaupt nichts davon, vor allem eine interne Authentifizierungsstelle mit einer externen zu koppeln. 😉
Denn Dingen wie AD-Sync & Co, machen zwar auf der einen Seite das Leben für die Admins aber auch die User auf der einen Seite viel einfacher, auf der anderen Seite aber auch viel viel gefährlicher. 😔
Gruss Alex
Ich fasse die Sicherheitsrisiken mal in zwei Punkten zusammen:
- Diebstahl / Verlust des Geräts bei bekanntem Benutzerpasswort
- Angreifer bzw. Schadsoftware sind/ist bereits auf dem mobilen Endgerät
Bei Punkt 1 sehe ich definitiv, wie du, Verbesserungspotential. Reicht ja schon, dass der Nutzer sein Passwort noch auf nem' Zettel in der Notebooktasche durch die Gegend trägt. Hier sollten wir im Grunde genommen schauen, dass schon der Windows Login auf dem mobilen Endgerät um 2FA ergänzt wird. Damit wäre dieser Punkt ja mehr oder weniger erledigt.
Ja, mit Windows Login und 2FA ist das ganze auf jeden Fall um einiges sicherer und damit sollte sich dann auch die Versicherung, meiner Ansicht nach zufrieden geben.
Ich würde dir, insbesondere bei externen Geräten gerne den Login über z.B. einen Yubikey empfehlen, inclusive der Einstellung, dass der angemeldete Benutzer abgemeldet wird, sobald der Yubikey gezogen wird. 😉
Zudem hat der Login über die Yubikeys noch einen ganz anderen Charm. 😁
Denn so muss ein Benutzer, vorausgesetzt die Interne Infrastruktur ist 100% SSO fähig, das Passwort überhaupt nicht mehr kennen und kann es demzufolge auch nirgends extern verwenden, wo es dann geklaut werden könnte. 😎
Punkt 2 verstehe ich natürlich grundsätzlich auch, sehe aber nicht, wieso das so relevant ist. Dahingehend waren auch meine anderen beiden Gegenbeispiele gemeint:
Was unterscheidet einen Angreifer auf einem mobilen Client mit VPN von einem Angreifer, der Zugriff auf einen Client im internen Firmennetz oder auf einen Client an einer Zweigstelle hätte, die via Site-2-Site vernetzt ist?
Was unterscheidet einen Angreifer auf einem mobilen Client mit VPN von einem Angreifer, der Zugriff auf einen Client im internen Firmennetz oder auf einen Client an einer Zweigstelle hätte, die via Site-2-Site vernetzt ist?
Na hoffentlich unter anderem die Tatsache, dass das internen Firmennetz und auch die Zweigstelle(n), durch mächtige SGW's (Security-Gateway alla Sophos XGS & Co.) welches Dinge wie IPS, ATP, SSL-Inspektion und Co. beherrschen geschützt ist, die es dem Angreifer, am Besten so gut wie unmöglich machen, einen Client im Inneren zu infizieren.
Ich verstehe nicht, warum es hier plötzlich so relevant sein soll, Angreifern auf einem Client mit VPN das Leben "etwas schwerer" zu machen, wenn sie am Ende auch jeden anderen Client im internen Firmennetz gleichermaßen missbrauchen könnten.
Weil du an einen internen Client, wegen den hoffentlich vorhandenen und bissigen Wachhunden (SGW & Co.), im Normallfall nicht ganz so einfach ran kommst, wie an einen externen Client, der im schlimmsten Fall nur hinter einer Fritze oder noch schlimmer hängt, sprich, nur von einem Chihuahua bewacht wird. 🤪
Oder alternativ einfach warten könnten, bis der Mitarbeiter die VPN mittels 2FA hergestellt hat. Da von den mobilen Clients fast nur via RDS gearbeitet wird, muss die VPN eben effektiv dauerhaft mitlaufen.
Na ja, per RDP kann ein Angreifer eben nicht das dahinterliegende System mal so kurz hops nehmen, zumindest solange der User selbst noch davor sitzt, weil er sich dadurch quasi enttarnen würde.
Daher ist es meiner Ansicht nach mitunter auch sehr wichtig, dass man so gut es geht sicherstellt, dass die VPN Verbindung nur dann aktiv ist, wenn der User auch tatsächlich vor dem externen Rechner sitzt.
Nicht falsch verstehen: Es ist grundsätzlich natürlich immer sinnvoll, Angreifern das leben schwerer zu machen, wo es nur geht, aber ich versuche das immer realistisch zu betrachten und zu schauen, welche Maßnahme mit welchem Aufwand wie viel bringt.
👍👍👍
Daher sehe ich aktuell allein durch die Clients mit Wireguard noch kein großes Loch in der primären Schutzwall, da eben auch von rund 100 weiteren Clients jederzeit Netzwerkzugriff ohne 2FA besteht.
Wie schon oben geschrieben, die internen Clients, sollten im Normalfall viel besser geschützt sein als die externen, daher kannst du die auch nicht wirklich 1:1 vergleichen.
Ähm, ja, des M365 isch a ganz jefährliche Rakettawissenschaft, vor allem mit AD-Sync und so. 🤪
M365 und Azure AD Hybrid ist ein Thema für sich, aber du kannst mein Argument mit 2FA Login und anschließender Session Cookies oder JWTs im Grunde auf jeden Onlinedienst übertragen, alle sind gleichermaßen anfällig, sobald Angreifer im System sind oder Zugriff auf's Windows Konto und den Browser haben - 2FA hin oder her.
Jup und genau deswegen halte ich überhaupt nichts davon, vor allem eine interne Authentifizierungsstelle mit einer externen zu koppeln. 😉
Denn Dingen wie AD-Sync & Co, machen zwar auf der einen Seite das Leben für die Admins aber auch die User auf der einen Seite viel einfacher, auf der anderen Seite aber auch viel viel gefährlicher. 😔
Gruss Alex
Zitat von @MysticFoxDE:
Ich würde dir, insbesondere bei externen Geräten gerne den Login über z.B. einen Yubikey empfehlen, inclusive der Einstellung, dass der angemeldete Benutzer abgemeldet wird, sobald der Yubikey gezogen wird. 😉
Zudem hat der Login über die Yubikeys noch einen ganz anderen Charm. 😁
Denn so muss ein Benutzer, vorausgesetzt die Interne Infrastruktur ist 100% SSO fähig, das Passwort überhaupt nicht mehr kennen und kann es demzufolge auch nirgends extern verwenden, wo es dann geklaut werden könnte. 😎
Zudem hat der Login über die Yubikeys noch einen ganz anderen Charm. 😁
Denn so muss ein Benutzer, vorausgesetzt die Interne Infrastruktur ist 100% SSO fähig, das Passwort überhaupt nicht mehr kennen und kann es demzufolge auch nirgends extern verwenden, wo es dann geklaut werden könnte. 😎
Über dein Einsatz von Yubikeys haben wir schon bei verschiedenen Kunden nachgedacht, da ich das Konzept grundsätzlich gut finde. Das wäre hierfür definitiv eine gute Option. 😊
Na hoffentlich unter anderem die Tatsache, dass das internen Firmennetz und auch die Zweigstelle(n), durch mächtige SGW's (Security-Gateway alla Sophos XGS & Co.) welches Dinge wie IPS, ATP, SSL-Inspektion und Co. beherrschen geschützt ist, die es dem Angreifer, am Besten so gut wie unmöglich machen, einen Client im Inneren zu infizieren.
Weil du an einen internen Client, wegen den hoffentlich vorhandenen und bissigen Wachhunden (SGW & Co.), im Normallfall nicht ganz so einfach ran kommst, wie an einen externen Client, der im schlimmsten Fall nur hinter einer Fritze oder noch schlimmer hängt, sprich, nur von einem Chihuahua bewacht wird. 🤪
Zumindest beim betreffenden Kunden kann ich das so nicht bestätigen - Allerdings muss ich mich an dieser Stelle vielleicht auch outen: Wir setzen nach wie vor eher auf Endpoint Protection Lösungen (für Server und Clients) und weniger auf zentrale SGW's / USG's etc...
Warum? Das ist ein Thema, über das wir auch schon häufig diskutiert haben und das eigentlich auch mal ein eigenes Thema verdient hätte - Ich werde mal einen Beitrag zum Austausch eröffnen, da das den Rahmen hier sprengen wird. Der Kunde betreibt keine öffentlichen Dienste, IDS, IPS wird daher nicht benötigt, Mails laufen via M365 und werden von einen zusätzlich vorgeschalteten Security Anbieter gefiltert (ja auch das ist wieder ein eigenes Thema), ATP- und SSL-Inspection läuft durch die Endpoint Protection nur auf den Clients und Servern. Daher kann man im ursprünglich beschriebenen Kundenszenario schon sagen, dass mobile Clients ähnlich gut abgesichert sind wie interne. Ob das nun gut oder schlecht ist, ist eine andere Frage. Zumindest stellte das für den Versicherer bisher kein Problem dar. 😁
Moin @JoRu1407,
das eine, sprich Endpoint Protection ersetzt meiner Ansicht nach aber noch lange nicht das andere, sprich ein SGW.
Im Gegenteil, erst durch den Verbund von Beiden, kannst du meiner Meinung nach, wirklich eine brauchbare Schutzmauer aufbauen.
Gruss Alex
Wir setzen nach wie vor eher auf Endpoint Protection Lösungen (für Server und Clients) und weniger auf zentrale SGW's / USG's etc...
das eine, sprich Endpoint Protection ersetzt meiner Ansicht nach aber noch lange nicht das andere, sprich ein SGW.
Im Gegenteil, erst durch den Verbund von Beiden, kannst du meiner Meinung nach, wirklich eine brauchbare Schutzmauer aufbauen.
Gruss Alex
An dieser Stelle nur der Verweis auf einen separaten Beitrag, da ich auch eine Austausch zu diesem Thema sehr spannend finde: Sinn oder Unsinn von USGs, SGWs, NGFWs
Trotzdem freue ich mich auf weiteren Austausch zum VPN-Thema! 😁
Trotzdem freue ich mich auf weiteren Austausch zum VPN-Thema! 😁
- Welche Lösungen setzt Ihr ein?
- Hat jemand Versicherungen, die Wireguard und geschützte Endpoints als ausreichend ansehen?
- Wie bewertet Ihr in diesem Kontext "moderne" SD-WAN Lösungen wie ZeroTier, Tailscale, etc.?
@MysticFoxDE
Man kann durch aus das AD nehmen, aber dann muss das Konzept einfach schlüssig und wasserdicht sein. Sprich nicht nur VPN, sondern auch Windows Anmeldung, Applikcation, RDS, etc. mit MFA sichern.
Ich lese hier 8 Personen, 5 verschiedenen Ansichten. Was nun?
@JoeDevlin
@JoRu1407
@MirkoKR
Gruß,
Dani
SSL-VPN, am Besten nicht mit AD gekoppelt, sprich, eigener Benutzerkreis + 2FA.
Damit rennst du bei der Versicherung ganz sicher die Tür ein. 😉
Deine User werden dich dafür aber wahrscheinlich eher lynchen. 🙃
das kannst du bei KMU machen mit 30, 100 oder 500 Nutzern. Aber bei Unternehmen mit mehreren tausend MA ist das meisten nicht mehr administriebar.Damit rennst du bei der Versicherung ganz sicher die Tür ein. 😉
Deine User werden dich dafür aber wahrscheinlich eher lynchen. 🙃
Man kann durch aus das AD nehmen, aber dann muss das Konzept einfach schlüssig und wasserdicht sein. Sprich nicht nur VPN, sondern auch Windows Anmeldung, Applikcation, RDS, etc. mit MFA sichern.
Wenn du 10 ITler nach deren Meinung befragst, dann kann es nicht selten passieren,
dass du darauf dann mindestens 10 unterschiedliche Antworten bekommst, die dann je nach Tageszeit auch noch variieren können . 🤪Ich lese hier 8 Personen, 5 verschiedenen Ansichten. Was nun?
@JoeDevlin
Wir haben in unserer GPO konfiguriert, dass nach zehn fehlerhaften Login-Versuchen das System neu startet und der Bitlocker Key eingegeben werden muss.
Damit der vermeidliche Sicherheitszaun ein Loch weniger hat, solltest du zusätzlich unbedingtn den Pre-Boot PIN einführen. Dazu hat Kollege @DerWoWusste einen ausführlichen Beitrag verfasst. Unabhängig davon können 10 Versuche schon 10 zu viel sein.@JoRu1407
Wireguard richtet für jede konfigurierte Verbindung einen separaten Windows-Dienst ein. Sobald dieser läuft, steht auch die Connection. Wir möchten mit diesem Konstrukt erreichen, dass der User im Grunde gar nicht mit der VPN in Berührung kommt.
Das Design funktioniert nur, solange keiner der Nutzer auf dem Gerät Mitglied der "Netzwerk Operatoren" oder "Administratoren" ist. Anderenfalls hast du das nächste Loch im Sicherheitszaun.Zusätzlich ließe sich ja auch jederzeit das Wireguard Zertifikat des Geräts sperren.
Meinst du das Zertifikat welches mehr oder weniger Self-Signd ist oder habt ihr eine PKI mit entsprechenden OCSP Responder und CRL?!Bei Punkt 1 sehe ich definitiv, wie du, Verbesserungspotential. Reicht ja schon, dass der Nutzer sein Passwort noch auf nem' Zettel in der Notebooktasche durch die Gegend trägt
Das muss organisatorische, schriftlich geregelt und geschult werden. Nur so kannst du als Unternehmen rechtlich schützen und Verstädnis bei der MA erlangen.Was unterscheidet einen Angreifer auf einem mobilen Client mit VPN von einem Angreifer, der Zugriff auf einen Client im internen Firmennetz oder auf einen Client an einer Zweigstelle hätte, die via Site-2-Site vernetzt ist?
Aus meiner Sicht ist dieses Denken einfach überholt. Setze ich die Security Brille auf, ist ein Zero Trust Modell heutezutage der ideale Weg. Damit gibt es eigentlich auch keine granulare Unterscheid mehr zwischen LAN und VPN. Einen Graben braucht es natürlich nach wie vor, aber den Mauer und den Graben ziehe ich um eine wichtige Dienste und Applicationen.Da von den mobilen Clients fast nur via RDS gearbeitet wird, muss die VPN eben effektiv dauerhaft mitlaufen.
Alternativ RDS über RDGW und 2FA bereitstellen. Dann kannst du dir den VPN OVerhead sparen. Der Kunde betreibt keine öffentlichen Dienste, IDS, IPS wird daher nicht benötigt
Die Firewall kann trotzdem von vermeidlichen Angreifer unaufgefordert "geprüft" werden.@MirkoKR
... soweit nötig ... Applikationsserver z.B. könnten auch in der DMZ stehen, sodass der User für die Nutzung einzelner Applikationen gar nicht ins interne Netz durchgeschaltet werden muss ...
Kann man drüber diskutieren. Wenn die Applikation nicht nur aus dem LAN und VPN sondern auch über das Internet erreichbar ist, gehört sie in die DMZ.Gruß,
Dani
