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. 1. 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.

Inbound-Regeln

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

1. 1. 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.

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.