Active Directory Sicherheit Teil 4: Domain Controller

Teil 4 meiner Serie beschäftigt sich mit den Domain Controllern selbst. Wie sollte eine DC konfiguriert sein, was gibt es zu beachten und wie härte ich meine DCs sinnvoll.

Physische Sicherheit

Wenn es die Infrastruktur zulässt, sollten sich die DCs in einem eigenen Netzwerk-Segment befinden, in dem sonst keine anderen Server bereitgestellt werden. Zusätzlich sind die DCs vom Rest der Infrastruktur durch eine Firewall zu trennen. Ausschließlich die für die AD DS benötigten Ports und ggf. Ports für die Remote Verwaltung sind hierbei freizuschalten.

Daneben ist zu entscheiden, wo der DC steht. Vollwertige DCs sollten immer den Vorgaben der o.g. physischen Sicherheit folgen. An Remote Standorten, an denen diese physische Sicherheit unter Umständen nicht gegeben ist, sollten ausschließlich Read-only Domain Controller (RODCs) installiert und zumindest durch die Windows Defender Firewall geschützt werden (analog zu den normalen DCs).

Betriebssystem

Auf DCs sollte der „Software-Footprint“ möglichst klein gehalten werden.

Daher ist der erste Schritt, DCs als Server Core zu installieren. Eine Anmeldung am Desktop eines DCs und ggf. AD-Admintätigkeiten direkt auf dem DC ist nicht zu empfehlen. Dafür sollte es immer Admin-Clients mit Remote Admin Tools geben. Daher ist keine Desktop Installation erforderlich und sollten Wartungsarbeiten

Pagefile Encryption

Zwar geht die Verschlüsselung des Pagefiles etwas auf die Performance, allerdings sollte das zu Gunsten der Sicherheit in Kauf genommen werden, da das Pagefile durchaus sensible Daten enthält, die im Falle einer Kompromitierung des Systems möglichst nicht in die Hände eines Angreifers fallen sollten.
Konfigurieren lässt sich die Verschlüsselung per GPO:

Computer Configuration -> Policies -> Administrative Templates -> System -> Filesystem -> NTFS
=> Enable NTFS pagefile encryption: Enabled
Software Installationen

Monitoring Agents:
Die meisten Monitoring Produkte benötigen einen Agent, um ihr volles Potential zu nutzen, aber meist dann auch einen privilegierten Service Account. Auf DCs sollte daher auf ein Agent-basiertes Monitoring verzichtet werden. Die meisten Produkte können die wichtigsten Systemparameter und Services auch per WMI oder WinRM abfragen. Diese reichen für einen DC aus.

Security Information and Event Management (SIEM):
Bei SIEM Lösungen ist es genau umgekehrt, wie beim Monitoring. Die meisten Produkte arbeiten per Pull-Verfahren, greifen also mit einem privilegierten Service Account remote auf die System zu und holen sich die Eventlogs. Diese Zugriffe sollten abgeschaltet werden indem man hierfür einen Agent installiert, z.B. Snare. Snare benötigt keinen Service Account zum Abholen der Logs, sondern schickt die Logs (Push-Verfahren) an den zentralen SIEM Log Collector. Remote-Zugriffe werden somit reduziert.

Backup Agents:
Oft gesehen, immer unnötig! Eine externe Backup Software benötigt i.d.R. einen privilegierten Service Account. Ein Risiko, das unnötig ist. Selbst Microsoft rät davon ab, einen Restore eines DCs zu machen; das führt nur zu Problemen und kann unter Umständen das ganze AD korrumpieren. Wenn ein DC mal nicht mehr will, runterstufen, löschen, neu installieren, heraufstufen. Wozu also ein Backup? Lieber ein paar DCs mehr betreiben, als mit Backup und Restore herumhantieren. Will man unbedingt auf Nummer sicher gehen und zumindest den System State (inkl. AD Datenbank) sichern, reichen hierzu die Bordmittel locker aus.

Hypervisor Tools:
Sowohl VMware ESXi mit den VMware Tools, als auch Citrix XenServer mit den XenServer Tools benötigen eine eigene Installation, um Treiber und Management Funktionen bereitzustellen. Während die XenServer Tools immerhin auf .NET basieren, basieren die VMware Tools noch auf Visual C++ und installieren daher eine Vielzahl an VC++ Redistributable Versionen, die bekanntermaßen eine große Angriffsfläche bieten.
Um eine solche Installation zu vermeiden, sollten virtualisierte DCs möglichst auf Microsoft Hyper-V Hypervisoren installiert werden. Treiber und „Tools“ sind bei Microsoft Betriebssytemen bereits „Builtin“, sodass keine extra Komponenten installiert werden müssen.

Patch Management

Für das Patch Management der Server sollte ausschließlich WSUS verwendet werden – selbst dann, wenn eine andere Software Management Lösung im Einsatz ist. Drittprodukte benötigen i.d.R. eine eigene Agent Installation, die oftmals mit einem hochprivilegierten Benutzer ausgeführt wird. WSUS dagegen ist quasi „Windows Builtin“ und läuft ohne eigenen Benutzer.

Interaktive Anmeldung

Interaktive Anmeldungen an DCs sollten nach Best Practices nur über die lokale Konsole möglich sein und auch nur für Domain Admins, nicht für „normale“ Server Admins. Eine Remote-Anmeldung per RDP sollte nicht möglich sein. Wird eine Remote Anmeldung per RDP dennoch zugelassen, dann sollte diese zumindest nur über einen Jump Server möglich sein oder über ein Remote Desktop Gateway (siehe: Physische Sicherheit -> Windows Defender Firewall).

Internet Zugang & Web Browser

Ein DC hat keine Funktion, die einen Internet Zugang benötigt. Daher sollte jeglicher Zugang zum Internet gesperrt sein (z.B. an der Perimeter Firewall). Wird dennoch Zugriff ins Internet benötigt (z.B. für Windows Security Updates, weil es keinen WSUS gibt), ist darauf zu achten, dass die externe Firewall möglichste eine Freischaltung über eine Internet Service Database erlaubt (wie z.B. Fortigate). Somit ist gewährleistet, dass nur Windows Update-relevante Ziele und Ports erreichbar sind und sich diese auch mitändern, wenn sich auf Seiten von Microsoft etwas ändert.

Sollte ein DC eine Desktop Installation haben, statt eine Server Core, sollte darüber hinaus sichergestellt sein, dass Web-Browser auf DCs nicht funktionieren. Dies kann durch eine AppLocker Policy erreicht werden, in der sämtliche Browser, bzw. Publisher der Browser gesperrt werden.

RDP Absicherung

Sollte man sich dazu entscheiden, dass auf DCs per RDP zugegriffen werden kann (ob direkt oder per Gateway), ist eine Absicherung des RDP Protokolls zwingend erforderlich. Standardmäßig verwendet RDP Stand heute (RDP 10.0) Schannel Konfigurationen mit Verschlüsselungsprotokollen, Ciphers und Hashes, die bereits als nicht mehr sicher gelten (z.B. SSL 3.0, TLS 1.0, RC4, DES, MD5, SHA1). Es gibt auch seitens Windows keinen „einfachen“ Weg, dies umzustellen auf sichere Schannel Einstellungen. Möchte man dies tun, ist das ein mühsames Konfigurieren von unzähligen Registry Werten.

Erfreulicherweise hat sich ein findiger Admin gefunden der für diese Konfiguration ADMX-Templates erstellt hat und diese hier bereitstellt. Dadurch lassen sich die Schannel Einstellungen zentral per Group Policy konfigurieren und verteilen.

Folgende Einstellungen sind zur Absicherung empfohlen (Stand 11.09.2018):

  • Protocols: TLS 1.2
  • Ciphers: 3DES 168, AES 128/128, AES 256/256
  • Hashes: SHA256, SHA384, SHA512
  • Key Exchanges: Diffie-Hellman, PKCS, ECDH

Alternativ kann auch das kostenlose Tool IISCrypto genutzt werden, welches die Schannel Konfiguration per Click-and-Apply vornimmt. Hiermit lassen sich die erlaubten Schannel Werte relativ einfach einstellen. Hat man seine gewünschte Konfiguration, lässt sich diese in ein Template exportieren und auf mehrere Server anwenden. Auf DCs sollte man das immer manuell machen, auf anderen Servern kann man dies scripten und z.B. per PowerShell Remoting mit der CLI-Komponente von IISCrypto ausführen lassen.

\\<Domain>\<Share>\IISCrypto\iiscryptocli.exe /template \\<Server>\<Share>\IISCrypto\<Template>.ictpl /reboot

Zu beachten ist, dass die Anpassung bei beiden Optionen alle kryptographischen Funktionen des System ändert, nicht nur RDP!

Security Baseline Konfiguration

Für die Härtung der DCs gibt es z.B. folgende zwei Normen, an denen man sich orientieren kann:

Während die CIS Benchmarks von Microsoft unabhängig sind, aber dafür auch etwas schwerer zu verstehen sind, sind die Security Baselines natürlich aus der Sicht von Microsoft, aber dafür leichter zu implementieren. Bei den Security Baselines gibt es klare Vorgaben für verschiedene Systeme in Form von GP-Reports im HTML Format, während man aus den CIS Benchmarks erst aus dem Text rausfinden muss, welche Einstellung denn überhaupt Anwendung findet – es gibt z.B. keine eigene Benchmark für DCs, sondern nur Betriebssystem-Benchmarks, in denen dann der Scope der jeweiligen Einstellung angegeben ist (Standalone Server, Member Server, Domain Controller). Letztlich bleibt es einem selbst überlassen, welche Norm man verwendet. Ich persönlich verwende die Security Baseline von Microsoft seit ich einmal dank einer missverständlichen Einstellung aus den CIS Benchmarks den Zugriff auf die SYSVOL und NETLOGON Shares der DCs gesperrt hatte. Nicht gut!

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.