Active Directory Sicherheit Teil 2: Clients von privilegierten Benutzern

Teil 2 meiner Serie Active Directory Sicherheit beschäftigt sich mit dem physischen Arbeitsplatz von Mitarbeitern mit privilegierten Rechten. Auch hier fängt der Schutzbedarf bereits an der Arbeitsstation an, an dem der Admin mit seinem nicht privilegierten User angemeldet ist und seine Office Anwendung nutzt. Denn dies ist das Tor zu Systemen, an denen man sich dann mit privilegierten Usern authentifiziert.

Physikalischer Schutz

Der erste Ansatz ist natürlich der physikalische Schutz des Clients. Es gilt dafür zu sorgen, dass der Arbeitsplatz-Client des Admins weder entwendet, noch dessen Hardware manipuliert werden kann.

Auf folgende Ausstattung sollte der PC daher haben:

  • Chassis Lock – Schutz vor Öffnung des Gehäuses, um zu verhindern, dass z.B. unbefugt der RAM getauscht wird.
  • Kensington Lock – Schutz, um das Gerät physikalisch zu entwenden.

Alternativ ist es natürlich eine Lösung, dass die Arbeitsplatz-Clients des Admins nur noch Notebooks sind, die nach Ende der Arbeitszeit entweder mitgenommen oder in einem Safe verschlossen werden.

Virtualization Based Security (VBS)

Ein mit Windows 10 / Windows Server 2016 eingeführtes Sicherheitsfeature ist der sog. Credential Guard als Bestandteil der Virtualization Based Security. Kurz gesagt, Credential Guard isoliert Passwörter und deren Hashes durch VBS, damit nur privilegierte Systemsoftware darauf zugreifen kann, sprich Credential Guard erhöht die Sicherheit des Clients insbesondere auf Pass-The-Hash- und Pass-The-Ticket-Angriffe zum Auslesen von Passwort Hashes und Kerberos Tickets privilegierter Benutzer. Details dazu und zur Funktionsweise sind hier zu finden.

Voraussetzungen:

  • Windows 10 Enterprise / Windows Server 2016
  • Hardware:
    • 64-Bit Prozessor
    • UEFI mit aktivem Secure Boot
    • Passwortschutz für das UEFI (sonst könnte man ja z.B. Secure Boot deaktivieren)
    • Trusted Platform Module (TPM)

Ob euer PC die Systemvoraussetzungen erfüllt, lässt sich mit dem Device Guard and Credential Guard Hardware Readiness Tool prüfen.

Aktivieren / konfigurieren von Virtualization Based Security (VBS)

Um VBS zu aktivieren und zu konfigurieren bindet man eine Group Policy auf die OU mit den Admin Clients und konfiguriert folgende Einstellungen:

Computer Configuration / Policies / Administrative Templates / System / Device Guard
   Turn On Virtualization Based Security:   Enabled
      Select Platform Security Level:                      Secure Boot and DMA Protection
      Virtualization Based Protection of Code Integrity:   Enabled with UEFI lock
      Require UEFI Memory Attributes Table:
      Credential Guard Configuration:                      Enabled with UEFI lock

Um zusätzlich noch sicherzustellen, dass die Policy nur auf Admin Clients mit Windows 10 Clients mit Enterprise Edition angewendet wird, lässt sich die Policy zusätzlich noch per WMI filtern (OperatingSystemSKU 4 = Enterprise Edition CB/CBB, OperatingSystemSKU 125 = Enterprise Edition LTSB). Das kann natürlich weggelassen werden, wenn im Unternehmen eh nur Enterprise Edition installiert wird (z.B. über ein EA mit Microsoft).

SELECT Version,ProductType,OperatingSystemSKU FROM Win32_OperatingSystem WHERE (Version LIKE "10.%" AND ProductType = "1") AND (OperatingSystemSKU = "4" OR OperatingSystemSKU = "125")

VBS – insbesondere Credential Guard – darf NICHT auf Domain Controllern aktiviert werden!

Verschlüsselung der Betriebssytem-Disk/-Partition

Ein weiterer Schutzmechanismus für die Admin Clients ist die Verschlüsselung der Festplatte. Dies verhindert, dass im Falle eines Diebstahls der Festplatte diese in einem anderen PC angeschlossen und ausgelesen werden kann. Das Bordmittel BitLocker ist inzwischen eine Lösung, die auch hohe Sicherheitsstandards in Unternehmen erfüllt. Auch die Verschlüsselung mit BitLocker konfiguriert man vorzugsweise per Group Policy. Die folgenden Einstellungen sind Beispieleinstellungen für die OS Partition/Disk.

  • Encryption Algorithmen und Cipher Gruppen: höchste Verschlüsselung / Ciphers
  • Pre-Boot PIN nicht erforderlich für Secure Boot und DMA geschützte Geräte
  • Recovery nur per Agent und Passwort aus dem AD; keine Möglichkeit während des Setups das Passwort auszudrucken oder zu speichern – im Falle einer Kompromitierung kann ein Angreifer nicht mit einem „gefundenen“ Passwort/Key entschlüsseln, sondern es muss immer ein AD Admin / BitLocker Admin kontaktiert werden
  • Key Protectors: TPM mit Key (Key auf USB-Stick bei PCs/Notebooks oder SD-Karte bei Windows Tablets) – alternativ: nur TPM
Computer Configuration / Policies / Administrative Templates / Windows Components / BitLocker Drive Encryption
   Choose drive encryption method and cipher strength (Windows 10 [...] and later): Enabled
      Select the encryption method for operating system drives: XTS-AES 256-bit
   Disable new DMA devices when this computer is locked: Enabled
Computer Configuration / Policies / Administrative Templates / Windows Components / BitLocker Drive Encryption / Operating System Drives
   Allow devices with Secure Boot and protected DMA ports to opt out of preboot PIN: Enabled
   Allow Secure Boot for integrity validation: Enabled
   Choose how BitLocker-protected operating system drives can be recovered: Enabled
      Allow data recovery agent: True
      Configure user storage of BitLocker recovery information:
         Require 48-digit recovery password
         Do not allow 256-bit recovery key
      Omit recovery options from the BitLocker setup wizard: True
      Save BitLocker recovery information to AD DS for operating system drives: True
      Configure storage of BitLocker recovery information to AD DS: Store recovery passwords only
      Do not enable BitLocker until recovery information is stored in AD DS for operating system drives: False
   Require additional authentication at startup: Enabled
      Allow BitLocker without a compatible TPM: False
      Configure TPM startup: Do not allow TPM
      Configure TPM startup PIN: Do not allow startup PIN with TPM
      Configure TPM startup key: Require startup key with TPM
      Configure TPM startup key and PIN: Do not allow startup key and PIN with TPM

Analog dazu (ggf. etwas weniger stringent) kann die Verschlüsselung zusätzlicher Laufwerke und Wechseldatenträger konfiguriert werden.

Lokales Administrator-Konto oder die „Legende vom umbenannten Administrator“

Immer wieder hört man, dass es sinnvoll ist, das lokale Administrator-Konto umzubenennen in irgendwas „Unverfängliches“. Kurz gesagt: Das ist Quatsch und bringt überhaupt nichts.

Einen Angreifer interessiert es nicht, ob der lokale Admin nun Administrator, Supervisor oder Räuber Hotzenplotz heißt. Einen Angreifer interessiert nur die SID des Accounts. Die bleibt auch beim Umbenennen gleich und ist hinreichend bekannt (siehe hier).

Möchte man durch einen anders benannten lokalen Administrator einen Sicherheitsgewinn erreichen, so ist der Builtin Local Admin komplett zu deaktivieren und durch einen separaten neuen Benutzer zu ersetzen. Und selbst das ist eher eine Notlösung, denn kompromitiert ein Angreifer das System und schafft es, im abgesicherten Modus zu starten, hat er dennoch Zugriff auf das System, da in diesem Zustand der Builtin Administrator nicht deaktiviert ist.

Sinnvoller ist es daher, einfach den lokalen Administrator so zu verwenden, wie er nach der Installation vorhanden ist, aber auch hier die Anmeldung auf die lokale Konsole zu beschränken, sowie per LAPS dafür zu sorgen, dass das Passwort auf jeder Maschine anders ist.

Schutz des Arbeitsplatz-Clients durch eine Firewall

Zusätzlich zu den o.g. Maßnahmen sollten Arbeitsplatz-Clients durch Firewalls vom Rest der IT Infrastruktur getrennt sein. Das kann entweder eine richtige Hardware-Firewall sein (wenn z.B. alle Admins an einem Standort sitzen) oder durch die Windows Defender Firewall, wenn diese durch Group Policies zentral konfiguriert sind und keine Änderung durch den Benutzer zulassen. Inbesondere die Inbound Rules müssen so konfiguriert sein, dass möglichst wenig Services erreichbar sind (um die Konfiguration zu erleichtern, kann Outbound alles geöffnet sein).

Windows Defender Firewall with Advanced Security

Folgende Einstellungen sollten bei Nutzung der Windows Firewall konfiguriert sein:

Computer Configuration / Policies / Windows Settings / Security Settings / Windows Firewall with Advanced Security / Windows Firewall with Advanced Security - LDAP://...
   Properties
      Domain Profile / Settings / Customize / Rule merging / Apply local firewall rules: No
      Domain Profile / Settings / Customize / Rule merging / Apply local connection security rules: No
      Private Profile / Settings / Customize / Rule merging / Apply local firewall rules: No
      Private Profile / Settings / Customize / Rule merging / Apply local connection security rules: No
      Public Profile / Settings / Customize / Rule merging / Apply local firewall rules: No
      Public Profile / Settings / Customize / Rule merging / Apply local connection security rules: No
Computer Configuration / Policies / Windows Settings / Security Settings / Windows Firewall with Advanced Security / Windows Firewall with Advanced Security - LDAP://... / Inbound Rules
   Port Rule -> TCP/135 -> Allow the connection -> Profile: Domain/Private -> Name
Computer Configuration / Policies / Windows Settings / Security Settings / Windows Firewall with Advanced Security / Windows Firewall with Advanced Security - LDAP://... / Outbound Rules
   Port Rule -> TCP/All -> Allow the connection -> Profile: Domain/Private/Public -> Name
   Port Rule -> UDP/All -> Allow the connection -> Profile: Domain/Private/Public -> Name

Weitere Inbound Rules sind natürlich nach Bedarf zu konfigurieren, Port TCP/135 ist lediglich ein Beispiel. Als Konfigurationsbasis lassen sich auch die bereits existierenden Regeln eines Standard-Arbeitsplatz-Clients in die Group Policy importieren, da auf einem solchen Arbeitsplatz natürlich auch Standard-Anwendungen laufen, die ggf. Inbound Verbindungen brauchen, um sauber zu laufen (z.B. Microsoft Office Outlook, Skype for Business, etc.). Dennoch lässt sich das Regelwerk problemlos klein halten.

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.