Absichern von (E)SAE-Umgebungen - IPSec Best Practices Update
6116
post-template-default,single,single-post,postid-6116,single-format-standard,bridge-core-3.0.1,,qode-title-hidden,qode-child-theme-ver-1.0.0,qode-theme-ver-28.7,qode-theme-bridge,disabled_footer_top,qode_header_in_grid,qode-wpml-enabled,wpb-js-composer js-comp-ver-6.9.0,vc_responsive

Absichern von (E)SAE-Umgebungen – IPSec Best Practices Update

In diesem Artikel zum Thema IPSec wollen wir unseren Artikel ESAE Serie Teil 5 – Windows IPSec aus dem März 2019 aufgreifen und einige zusätzliche Betrachtungen hinzufügen. Wie an dieser Stelle schon geschrieben, handelt es sich bei IPSec (Kurzform für „Internet Protocol Security“) um eine Erweiterung der TCP/IP-Protokoll-Suite, die eine gesicherte Kommunikation über potenziell unsichere IP-Netze wie das Internet ermöglichen soll. Der Kontext dieses und des verlinkten Vorgängerartikels zu IPSec ist die Absicherung der Kommunikation innerhalb einer Tier 0-Umgebung. Während in der im Vorgängerartikel beschriebenen Lösung IPSec für ein- und ausgehende Verbindungen innerhalb der Tier 0 erforderlich ist, wird in diesem Artikel eine Lösung vorgestellt, die weniger restriktiv ist und IPSec nur anfordert und damit im Betrieb etwas einfacher zu implementieren und zu warten ist.

Vor- & Nachteile

In diesem Abschnitt fassen wir kurz die wesentlichen Vor- und Nachteile von IPSec zusammen, ohne zu sehr ins Detail einzusteigen.

IPSec bietet folgende Vorteile:

    • IPSec bietet eine beidseitige Authentifizierung zwischen zwei Kommunikationspartnern mit Kerberos v5-Protokoll, mit x.509-Zertifikaten oder einem Preshared Key. Die letzte Methode mit einem Preshared Key wird aus Sicherheitsgründen nicht empfohlen und wird üblicherweise in der Praxis nur für Testszenarien benutzt.
    • Optionale Verschlüsselung der Daten auf IP-Ebene.
    • Da IPSec auf der IP-Ebene implementiert ist, funktioniert es unabhängig von den verwendeten Applikationen.

 

Folgende Nachteile gibt es in Verbindung mit IPSec:

    • Die Connection Security Rules für IPSec werden üblicherweise per Group Policy Objects (GPO) auf die Endgeräte verteilt. Dafür ist die Mitgliedschaft in einer Active Directory-Domäne die Voraussetzung für das Endgerät. Das ist in den meisten Unternehmen ohnehin der Fall, kann sich aber in bestimmten Umgebungen wie z.B. in einer DMZ, in der möglicherweise nicht alle Windows-Systeme AD-Domänenmitglieder sind, als kleinerer Nachteil erweisen.
    • Werden x.509-Zertifikate für die Authentifizierung verwendet, wird entweder eine interne PKI benötigt oder Zertifikate müssen extern bei einem entsprechenden Anbieter eingekauft werden.
    • Die Verwendung von IPSec erhöht die Komplexität und kann zuweilen die Fehlersuche und -behebung verkomplizieren.
    • Bei der Verwendung der IPSec-Verschlüsselung wird auf den beteiligten Systemen die CPU höher belastet.

Aufwand vs. Nutzen

Hier wollen wir nochmal den Aufwand für die Konfiguration dem Nutzen gegenüberstellen.

Authentifizierung

Die Kommunikationspartner werden in IPSec über Kerberos v5 oder mit Zertifikaten beidseitig authentifiziert. Dabei kann angegeben werden, ob die Authentifizierung nur angefordert wird oder ob sie erforderlich ist. Im ersten Fall wird eine IP-Verbindung zwischen zwei Endgeräten auch dann zustande kommen, wenn die Authentifizierung fehlschlägt, wenn zum Beispiel bei zertifikatsbasierter Authentifizierung auf einem der Endgeräte kein gültiges Zertifikat installiert ist. Im zweiten Fall wird im Fehlerfall keine IP-Verbindung zum Zielsystem möglich sein.

Die Implementierung von Regeln, die eine Authentifizierung nur anfordern, jedoch nicht zwingend erfordern, bringen nur dann einen Sicherheitsgewinn, wenn die IPSec-Verbindung verschlüsselt wird.

Wird eine beidseitige Verbindung zwingend gefordert, wird eine deutlich verbesserte Sicherheit erreicht, weil eine Verbindung vom Zielsystem abgelehnt wird. Vor allen Dingen bei der Verwendung von Zertifikaten ist nur eine Verbindung möglich, wenn auf dem System ein gültiges Zertifikat installiert ist.

Nachteil in dieser Konfiguration ist wiederum, dass bei Fehlkonfiguration keine Verbindung möglich ist und dies eine hohe Komplexität und viel Aufwand im Betrieb für Fehlersuche und Entstörung mit sich bringt.

In der Praxis dürfte bei der Verwendung von Zertifikaten eine interne PKI in den meisten Fällen Voraussetzung sein. Der Erwerb von Zertifikaten bei einem externen Zertifikatsanbieter ist nur dann wirtschaftlich, wenn es sich um keine größere Anzahl von Systemen handelt, wie das zum Beispiel bei Servern in einer DMZ der Fall ist, der nur eine begrenzte Anzahl öffentlicher Dienste anbietet.

Verschlüsselung

Eine IPSec-Verbindung lässt sich optional verschlüsseln. Bei der Verwendung von aktuellen Betriebssystemen und Applikationen sollten in aller Regel keine alten Protokolle mehr zum Einsatz kommen, in denen Kennwörter im Klartext übertragen werden. Bei aktuell unterstützten Windows-Versionen sollte ohnehin darauf geachtet werden, durchgängig Kerberos zu verwenden und NTLMv2 möglichst abzuschalten. Der zusätzliche Vorteil einer Verschlüsselung mit IPSec ist, dass auch die Nutzdaten verschlüsselt werden. Ob dieser Vorteil den zusätzlichen Konfigurationsaufwand lohnt, muss dann von Fall zu Fall individuell bewertet werden.

Einschränkung von Remote Administration auf authentifizierte Systeme

In Verbindung mit Inbound-Regeln in der Windows Defender Firewall bietet IPSec die Möglichkeit, dass nur beidseitig über IPSec authentifizierte Systeme einen Remote Administrationszugang zu Tier 0-Systemen haben.

    • Es wird eine Connection Security-Regel angelegt, die eine zertifikatsbasierte Authentifizierung anfordert.
    • Die Inbound-Regeln für die Remote Administrationsdienste RDP (Port 3389) und PowerShell Remoting (Port 5985) werden so konfiguriert, dass diese nur IPSec-authentifizierte Verbindungen zulassen.

Damit erreicht man, dass Tier 0-Systeme nur von Systemen mit einem gültigen Zertifikat administriert werden können. Das sind dann insbesondere die Privileged Access Workstations (PAW), die für die Administration vorgesehen sind.

Im Folgenden wird nochmal die Vorgehensweise beschrieben.

Connection Security-Regel

Es wird die Verschlüsselung mit IPSec konfiguriert und eine Connection Security-Regel in einer GPO erstellt.

      1. Erstellen einer neuen GPO.
      2. Zu Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Windows Defender Firewall with Advanced Security -> Windows Defender Firewall with Advanced Security – LDAP://CN=<CN> navigieren.
      3. Rechter Mausklick auf den untergeordneten Eintrag für Windows Defender Firewall with Advanced Security – LDAP://CN=<CN> und Properties auswählen.
      4. Auf der Registerkarte IPSec Settings für die Option Exempt ICMP form IPSec Yes auswählen und anschließend Customize.

5. Auf der Registerkarte IPSec Settings für die Option Exempt ICMP form IPSec Yes auswählen und anschließend Customize.

6. Auf Add klicken.

7. Hier den jeweils stärksten Algorithmus auswählen. SHA-384 als Integrity algorithm, AES-CBC 256 als Encryption algorithm und Elliptic Curve Diffie-Hehllman P-384 als Key exchange algorithm. Mit OK bestätigen.

8. Die neu erstellte Security-Methode an erste Stelle schieben.

9. Unter Data protection (Quick Mode) die Option Advanced auswählen und auf Customize.

10. Die Option Require encryption for all connection security rules that use these settings und auf Add.

11. Auch hier wieder den jeweils stärksten Algorithmus auswählen. AES-GCM 256 als Encryption algorithm und ebenso als Integrity algorithm.

12. Und auch hier wieder die neu erstellte Konfiguration an erste Stelle schieben.

13. OK klicken.

14. OK klicken.

15. OK klicken.

16. Zu Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Windows Defender Firewall with Advanced Security -> Windows Defender Firewall with Advanced Security – LDAP://CN=<CN> -> Connection Security Rules.

17. Rechter Mausklick auf Connection Security Rules -> New Rule.

18. Auf der Seite Rule Type die Option Isolation auswählen.

19. Auf der Seite Requirements die Option Request authentication for inbound and outbound connections auswählen.

20. Auf der Seite Authentication Method die Option Advanced auswählen und auf Customize klicken.

21. Auf der linken Seite unter First authentication auf Add klicken.

22. Die Option Computer certificate from this certification authority (CA) auswählen und auf Browse klicken.

23. In diesem Dialogfeld das korrekte Root-Zertifikat auswählen (im Zweifel dien Eigenschaften des Zertifikats und ggf. den Thumbprint überprüfen).

24. Konfiguration mit OK bestätigen.

25. OK klicken.

26. Auf der Seite Authentication Method auf Next klicken.

27. Auf der Seite Profile auf Next klicken.

28. Auf der Seite Name einen Namen wie Request certificate authentication for inbound and outbound connections wählen und Finish klicken.

Inbound-Regeln

Die Inbound-Regeln für RDP und Windows Remote Management werden ebenfalls am einfachsten per GPO erstellt.

      1. Erstellen einer neuen GPO.
      2. Zu Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Windows Defender Firewall with Advanced Security -> Windows Defender Firewall with Advanced Security – LDAP://CN=<CN> -> Inbound Rules.
      3. Rechter Mausklick auf Inbound Rules -> New Rule.
      4. Auf der Seite Rule Type die Option Predefined und die Gruppe Remote Desktop auswählen.

5. Auf der Seite Predefined Rules werden nun alle Regeln in der Gruppe Remote Desktop angezeigt und alle sind ausgewählt. Auswahl akzeptieren und Next klicken.

6. Auf der Seite Action die Option Allow the connection if it is secure auswählen.

7. Auf der Seite Users auf Next.

8. Auf der Seite Computers auf Finish.

Diese Schritte für die Inbound-Regeln der Gruppe Windows Remote Management wiederholen. PowerShell Remoting basiert dabei auf dem Windows Remote Management.

GPO und Zertifikate verteilen

Alle Systeme in der Tier 0 erhalten dann gültige Zertifikate und können sich gegenseitig authentifizieren und verschlüsselt miteinander kommunizieren. Bei den Zertifikaten ist zu beachten, dass in der Enhanced Key Usage Extension mindestens folgende Zwecke eingetragen sind:

    • Server Authentication (1.3.6.1.5.5.7.3.1)
    • Client Authentication (1.3.6.1.5.5.7.3.2)
    • IP security IKE intermediate (1.3.6.1.5.5.8.2.2)

Die GPOs mit den Connection Security- und den Inbound-Regeln werden dann auf alle Systeme in der Tier 0 verteilt, d.h. sie werden auf alle OUs, die Computerkonten von Tier 0-Systemen enthalten, verlinkt.

Wenn Tier 0-Systeme die Inbound-Regeln via GPO erhalten, werden diese in der Windows Defender Firewall doppelt angezeigt; die Regeln aus der GPO sind dabei mit einem Schloss versehen.

Wenn es für einen Dienst oder Port mehrere Regeln gibt, wird die spezifischere Regel angewandt. In diesem Fall ist die spezifischere Regel diejenige mit der Einschränkung auf sichere Authentifizierung, die wir zuvor in der GPO erstellt haben. Das bedeutet, die lokal existierende Default-Regel wird damit für RDP und PowerShell Remoting ignoriert.

Empfehlung / Meinung

In dieser oben vorgestellten Konfiguration wird also erreicht, dass Systeme in der Tier 0 nur von anderen Tier 0 bzw. Privileged Access Workstations mit einem gültigen Zertifikat per RDP und PowerShell Remoting administriert werden können. Zusätzlich werden in dieser alle Verbindungen zwischen Tier 0-Systemen per IPSec verschlüsselt. Da die Connection Security-Regel für IPSec die Authentifizierung nur anfordert, aber nicht erforderlich macht, können Systeme ohne gültiges Zertifikat aus Tier 1 und 2 nach wie vor wie gewohnt mit den Tier 0-Systemen kommunizieren.

Aus unserer Sicht wird damit eine Tier 0-Umgebung sinnvoll abgesichert, da wichtige Protokolle zur Administration (RDP, PowerSell Remoting) nur von definierten Systemen erreicht werden können. Übernimmt ein Angreifer beispielsweise ein schlechter abgesichertes Tier 2-System, kann von dort nicht administrativ auf ein Tier 0-System zugegriffen werden. Gleichzeitig bleibt der administrative Mehraufwand aber überschaubar. Applikationsspezifische Kommunikation wird nur abgesichert, wenn ein gültiges Zertifikat vorhanden ist. Tier 2-Clients können aber wie gewohnt mit dem Serversystem kommunizieren. Dies ist insofern unkritisch, da die allermeisten modernen Applikationen ohnehin verschlüsselt kommunizieren und der IPSec Tunnel nur eine sinnvolle Ergänzung darstellt.

Mit dem aktuellen Artikel haben wir unseren initialen Ansatz, IPSec einzuführen und möglichst restriktiv vorzugehen, geringfügig angepasst und somit das Beste aus Kosten/Nutzen-Sicht erreicht. Dennoch hat der initiale Artikel ggf. weiterhin seine Daseinsberechtigung. Denkt man an sehr regulierte bzw. Hochsicherheitsumgebungen, kann es sinnvoll sein, weiterhin so strikt wie möglich vorzugehen und dafür Erschwernisse bei der Administration einzugehen.

LATEST POSTS