Checkliste Active Directory Absicherung

Ich versuche auf dieser Seite die wichtigsten Punkte zur Absicherung eines Active Directory zusammenzuhalten. Die Liste wird aber nie vollständig sein.

Risikoabschätzung

Bei vermutlich den meisten Firmen kommt heute ein Windows Active Directory als zentrale Identitätsverwaltung zum Einsatz. Anwender, Computer und Dienste authentifizieren sich gegen das AD und erhalten so entsprechende Berechtigungen zum Zugriff auf Daten. Gelingt es einem Angreifer, solche Zugangsdaten zu erhalten oder sich sogar beliebige Zugangsdaten zu generieren, dann kann er die damit verbundenen Berechtigungen ausüben, z.B. Dateien und andere Informationen kopieren und ausleiten, Kopien und Backups entfernen, Daten verschlüsseln und vieles mehr. Die Praxis zeigt, dass es immer wieder vorkommt.

Dabei gilt es aber zu unterscheiden, ob die unerlaubten Zugriffe durch "Fehler eines Menschen", z.B. Phishing oder durch Lücken im System oder Fehlkonfigurationen ermöglicht wurden. Gegen Fehler der Anwender können "Awareness-Schulung", Multi-Faktor Authentifizierung, gehärtete Clientsysteme, getrennte Admin-Stationen etc. helfen. Sicherheitslücken lassen sich nach deren Erkennung und der Bereitstellung von Patches oder Anleitungen durch den Hersteller stopfen und hoffentlich haben Angreifer diese in der Zeit dazwischen nicht ausgenutzt. Oft sind es aber auch schwache Konfigurationen, die aus Kompatibilitätsgründen noch nicht deaktiviert wurden. Im Tagesgeschäfts hat ein Administrator hat doch immer wieder andere "wichtigere" Dinge zu tun.

Auch eine Microsoft Serie beleuchtet nur vier Punkte:

Das ist ein netter Anfang aber bei weitem nicht ausreichend.

Checkliste

Die folgende Liste soll daher eine erste Anlaufstelle sein, welche Einstellungen aus meiner Sicht heute angegangen werden sollten oder müssen. Einige Dinge sind schnell und mit geringem Risiko umsetzbar. Andere Einstellungen sollten mit vorheriger Analyse und Auswertung vorbereitet werden.

Einstellung Erledigt

Adminkonten

"Der größte Risikofaktor ist der Domain Admin!" Das ist leider wahr denn immer noch arbeiten zu viele Personen und Dienste mit zu umfangreichen Berechtigungen, weil es einfach "bequem" war, dies so einzurichten. Gerade "DomainAdmins" sind die allmächtigen Götter, die aber auch alles kaputt machen können. Ich habe schon vor vielen Jahren auf Adminkonzept dazu etwas geschrieben und hier nur die Stichpunkte.

  • Benutzer mit Postfach sind keine Administratoren
    Denn ansonsten kann AdminSDHolder zuschlagen und z.B. ActiveSync verhindern
  • Administratoren haben kein Postfach und greifen auf kein Postfach zu
    Hier ist AdminSDHolder weniger das Problem sondern eher, dass ein Admin versehentlich eine Malware im Postfach öffnet
  • Administratoren melden sich nicht auf normalen PCs an und nutzen kein VPN mit ihrem AdminKonto
    Können Sie sicher sein, dass dort keine Malware, Keylogger o.#. auf sie wartet? Über Anmeldebeschränkungen (LogOnLocally) können Sie dies zusätzlich steuern. Auch sollten die Konten von extern nie per BruteForce o.ä. erreichbar sein, so dass ein Angreifer erst ein normale Konto kapern muss, ehe dann überhaupt weiter gehen kann und auffällt, wenn das Konto dann z.B. mehrfach angemeldet ist.
  • Normale Anwender kommen nicht auf die Server Konsole
    Sie könnten damit ja Rechte von Freigaben umgehen und direkt auf Disks zugreifen. Ausnahme sind natürlich Terminal Server/Citrix-Server
  • Besonders starke Kennworte für Administratoren
    Auch normale Anwender sollten starke Kennworte nutzen aber Administratoren sind noch einmal sensibler. Mittels Fine-grained Password Policy ist einiges möglich
  • Nur "aktive privilegierte Konten"
    Prüfen Sie regelmäßig, welche privilegierten Konten (Admin-Benutzer aber auch Dienstkonten) sich länger nicht angemeldet haben. Vielleicht können Sie diese besser deaktivieren oder mit Ablaufdatum versehen und er bei Bedarf auf Zeit reaktivieren. z.B. für externe Dienstleister. Prüfen Sie auch, ob Dienste als GMSA - Group Managed Service Account gestartet werden können.
    Und natürlich gilt immer: "Weniger ist mehr"
  • "Protected Group" und Delegation
    Schützen Sie ihre Administratoren z.B. durch die Mitgliedschaft in der Gruppe und so NTLM zu verhindern. Achten Sie zudem darauf, dass diese Konten z.B. nicht für Kerberos - Constraint Delegation genutzt werden können.
  • Member in Administrativen Gruppen
    Die Schema-Admin-gruppe sollte leer sein und wer mehr als 2-3 DomainAdmins hat, hat kein Adminkonzept. In "Exchange Servers" sollten auch nur Server sein. Prüfen Sie ihre Berechtigungsgruppen auf falsche Mitglieder und prüfen Sie auch einmal AdminSDHolder.
  • Protokollierung
    Aktivieren sie die Überwachung für An/Abmeldungen. Denkbar ist auch ein Auditing auf Änderungen bei administrative Gruppen.

Die Liste könnte ich noch weiter führen.

Windows Versionen

Natürlich kann ich noch Windows XP-Clients mit Windows 2008DCs betreiben und genau solche Umgebungen habe ich auch 2024! noch gefunden. Da ist es aber schon Glück, dass nichts passiert ist, wenn Windows XP kann nur unsichere SMB1, TLS 1.2 ist per Default nicht aktiv, MD5 noch unterstützt. Das sind Extrembeispiele aber wenn sie Systeme ohne Support und Updates weiter betreiben, dann sollte sie eine schriftliche Risikoabschätzung habe, die die Gründe beschreibt. Ich bin sehr sicher, dass im Fall des Falles keine Versicherung einspringt und persönliche Haftungen schmerzhaft sind.

AD Backup und Restore

Wenn ihr AD "verloren" wurde, was durch den Ausfall aller DCs, aber auch einen Konfigurationsfehler oder Hackerangriff passieren kann, dann ist eine Wiederherstellung eines bekannten Zustands oft besser als ein Neuaufbau. Dazu müssen Sie aber ihr Backup regelmäßig machen und die Schritte der Wiederherstellung dokumentiert haben. Es hilft nichts, wenn sie dank 802.1x mit Radius am AD nicht mehr ins Netzwerkkommen und der Windows DHCP/DNS-Server keine Adressen verteilt und eine Anmeldung am VMWare vCenter mangels AD nicht mehr möglich ist. Das sind nur ein paar Beispiele.

DCs absichern

Die Domain Controller sind das Herz des AD und wenn ein Angreifer an oder sogar auf den DC kommt, dann ist ihr gesamtes System in Gefahr. Daher sollten Sie ein paar Dinge besser lassen, insbesondere je größer ihre Firma ist. Bei sehr kleinen Firmen kann ich schon verstehen, dass Sie vielleicht Dienste auf Servern kombinieren.

  • RDP-Zugang
    Der Zugriff per RDP oder jegliche andere Software auf die Konsole oder eine Session auf dem Server muss stark gesichert sein. DAs kann eine Firewall im Netzwerk oder auch auf dem Server selbst sein, die den Zugriff auf den RDP-Port auf ausgewählte Clients beschränkt. Zudem sollte die erweiterte Sicherheit aktiv bleiben.
  • Druckserver
    Ein Domain Controller sollte kein Spooler sein, denn über die Installation von Treibern und andere Lücken kann das AD geschwächt werden. Siehe dazu auch PrintNightmare Print Spooler Exploit
  • Zusatzdienste (DNS, DHCP, PKI)
    Überlegen Sie sich mehrfach, ob sie solche Dienste mit auf dem DC kombinieren. Sicher sind gerade DNS und DHCP auch "Infrastrukturdienste" aber spätestens wenn Sie die Verwaltungsberechtigungen auf verschiedene Personen verteilen wollen, sollten dies auch eigene Systeme sein. Eine PKI auf einem DC nutze ich nur in einem Test-Labor um z.B. Zertifikat für Computer auszustellen. Sobald Sie mit der PKI aber mehr machen, sollten Sie diese separat aufstellen. Eine PKI lebt meist länger als ein DC.
  • Firewall
    "Normalerweise" ist auf jeden Windows Server die eingebaute Firewall aktiv und erlaubt generell nur die Erreichbarkeit von Diensten, die von einem privilegierten Benutzer installiert wurden. Eine fremde Software kann nicht mal so einfach eine eingehende Verbindung öffnen. Aber die Standardeinstellungen beschränken weder ausgehende Verbindungen (Ausgehende Firewall ) noch werden eingehende Verbindungen anhand der Source-IP beschränkt. Das ist für einen DC auch nicht einfach, wenn man mal von RDP absieht. Dennoch sollten Sie mal darüber nachdenken ob z.B. jeder dann den Agent der Monitoring-Lösung zur Überwachung oder den Backup Agent zur Sicherung erreichen muss. Auch die ADWS-Services könnten beschränkt werden.

Auch hier gibt es noch viele weitere Möglichkeiten wie SecureBoot, Bitlocker, IPSec, Berechtigungen von Backup, Antivirus und Monitoring, Schutz virtueller Server gegen "Clone" etc. die speziell bei Domaincontrollern zu diskutieren sind. 

SMB1 Abschaltung

SMB ist das primäre Protokoll zum Zugriff auf Dateien über Freigaben und quasi seit Windows for Workgroups im Einsatz. Aber es hat einige Evolutionsschritte durchlaufen, um neue Funktionen zur halten und Lücken zu schließen. Aber auch hier ist "Rückwärtskompatibilität" das KO-Schlagwort, um sich um die Abschaltung der alten Versionen zu drücken. Windows XP und frühere können nur SMB1 und wer SMB1 abschaltet, sperrt diese Systeme komplett aus. Aber für die Fälle gibt es Lösungen (Siehe Alte Clients) und sollte sie nicht hindern. Neuere Windows Server Versionen haben SMB1 per Default abgeschaltet.

LDAP Signing

Die primäre Schnittstelle zum Lesen aber auch Ändern von AD-Objekten ist LDAP und es wäre doch bitte, wenn ein Angreifer ihre Sitzung übernehmen kann. Dagegen können Sie sich besser schützen, denn per Default erlaubt das AD auch ein LDAP-Zugriff und Anmeldung über Port 389 und nicht nur LDAPs mit TLS-Schutz.

PAC Signing

Tatsächlich konnte ein Angreifer quasi ein vom KDC ausgestelltes Tiket nehmen, ändern und die Signatur anpassen, damit es von anderen Server as "Gültig" anerkannt wird. Erst die PAC-Signierung verhindert diesen Missbrauch und sollte auf jeden Fall aktiviert werden. Seit 10 Okt 2023 sollte diese der Default sein aber stellen Sie sicher, dass der KRB-Ke auch AES nutzt.

Kerberos Key Rollover

Alle Domain Controller stellen über die "KDC"-Funktion entsprechende Kerberos Tickets aus. Das KDC hat dazu aber auch ein "Geheimnis", welches sich alle Server der Domain teilen. Das Konto des "krbtgt"-Kontos ist besonders zu schützen und sollte laut Microsoft mindestens einmal im Jahr auch geändert werden .Wenn Sie den Verdacht haben, dass ein Angreifer irgendwie die Daten erhalten hat, z.B. über ein Backup-Band, DC-Snapshot o.ä., dann sollte Sie das Kennwort zweimal ändern, um sogenannte "Golden Ticket"-Angriffe abzuwehren.

Kerberos RC4 Abschaltung

Die Verschlüsselung und Signierung von Kerberos-Tickets kann über verschiedene Verfahren erfolgen. MD5 ist mittlerweile per Default deaktiviert aber das auch 2024 noch per Default mögliche RC4-Verfahren gilt schon als "knackbar" und sollte nicht mehr genutzt werden. Die meisten Server und Clients bieten schon lange AES128/AES256 an aber noch kann ein Angreifer z.B. ein "Downgrade" erzwingen. Prüfen Sie, ob sie bei Kerberos auch RC4 auf dem Server abschalten können. Sogar Windows XP kann AES.

RPC Sealing

Seit 11 Juli 23 sollte auch diese Lücker per Default auf allen Server mit aktuellen Updates geschlossen sein. Wenn Sie natürlich noch etwas ältere Patchstände oder gar Windows Versionen nutzen (z.B. 2008/2012/2021R2), dann wird es höchste Zeit für ein Upgrade.

LM/NTLM Abschaltung

In vielen Umgebungen werden als falsch verstandener "Rückwärtskompatibilität" immer noch schwache Anmeldeverfahren wie LM oder NTLM genutzt, die normalerweise niemand mehr braucht. Aktivieren Sie das Logging auf den Servern und schauen sie, wer noch nicht NTLMv2 oder Kerberos nutzt. Zuerst sollten Sie sicherstellen, dass alle Server NTLMv2 mit anbieten und dann auf den Clients nach und nach NTLMv1 verbieten. Wenn dann auf den Servern keine alten Anmeldungen mehr erscheinen, dann stellen Sie den Server auf "LM/NTLM abweisen" um.

Denken Sie dabei auch an Systeme wie z.B. Radius, die bei der Nutzung von PAP/MSCHAP/MSCHAPv2 per Default mit NTLM arbeiten. Erst EAP-MSCHAPv2 und PEAP nutzt NTLMv2. Sie können aber Radius auch sagen, dass er NTLMv2 für die anderen Protokolle nutzen soll:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\RemoteAccess\Policy\Enable NTLMv2 Compatibility:DWORD=1

Vielleicht können wir in naher Zukunft komplett auf NTLM verzichten und alles über Kerberos absichern.

Extended Protection

Aber selbst mit NTLMv2 sind sie nicht zwingend "sicher", denn auch hier sind MITM-Attacken möglich und erst Anfang 2024 hat Microsoft z.B. in Exchange die Default-Einstellungen entsprechend angepasst, damit über den IIS dieser Angriff nicht mehr möglich ist. Prüfen Sie diese Einstellung aber auch auf anderen Webservern, die NTLM anbieten

TLS Aktivieren (RDP, LDAP etc.)

Wenn der DC wirklich nur DC ist, dann sind Zugriff per SMB2, Kerberos etc per Default recht gut gesichert. Aber LDAP (389 TCP) und GC (3268/TCP) lauschen auf Anfragen ohne Verschlüsselung. Sicher haben die meisten DCs ein "SelfSigned"-Zertifikat für LDAPS aber dem vertraut niemand und damit ist kein Man in the Middle (MITM)-Schutz möglich. Nutzen die die Change alle Zugriffe per TLS auf TLS 1.2 oder höher abzusichern und ein gültiges Zertifikat zu nutzen. Das kann auch eine interne private PKI sein. Sorgen Sie in dem Zuge auch dafür, dass ihre intern PKI sicher ist (Siehe Cert Logon Unsicherheit (KB5014754))

Pre Windows 2000 Group

Diese Gruppe ist nur dafür da, damit Mitglieder fast "alle" Felder im AD lesen dürfen. Ansonsten könnten Programme ein Problem bekommen, die noch auf NT4-APIs zugreifen und nicht mit den Standardrechten des ADs zurecht kommen. Ich kenne keine Software und die Gruppe sollte immer leer sein. Sie müssen Sie ja nicht gleich löschen.

AD dsHeuristics

Wussten Sie, dass per Default jeder Domain Benutzer bis zu 10 Computer in eine Domain aufnehmen kann und dann als "Owner" dieses AD-Objekte auch umfangreich ändern kann, z.B. SPN ändern und ein Zertifikat für das Konto anfordern kann? Das sollten Sie umgehend ändern und in dem Zuge auch die Einstellungen von dsHeuristics prüfen und ggfls. anpassen.

Security Tools

Wir sprechen hier über Einstellungen aus Servern und in Konfgurationen. Da liegt es nahe, die fraglichen Einstellungen durch eine Software auslesen und überprüfen zu lassen. Am Anfang kann das manuell erfolgen, um dann die Punkte anzugehen. Interessant könnte eine automatische regelmäßige Überprüfung mit aktualisierten Regeln sein, so dass das Sicherheitsniveau hoch bleibt. Es gibt sogar kostenfreie Tools zum "Selbst-Assessment", die ich jedem ans Herz legen möchte, wenn Sie keinen Dienstleister mit einer Analyse beauftragen wollen. Sie erhalten so relativ schnell einen ersten Überblick. Beachten Sie aber auch, dass die Tools erst einmal die "einfachen" Dinge prüfen. Erwarten Sie keine Analyse ihres Dateiserver oder Exchange Server über falsch gesetzte Zugriffsrechte von Benutzern. Für das Active Directory und Domain Controller sind Sie aber einer guter Startpunkt.

 

Das war ganz sicher nicht alles sondern ist ein erster Aufschlag. Sie sehen aber, dass ein "einfach so installiertes AD" vielleicht nicht ausreichend sicher ist. Dies gilt insbesondere, wenn ihr Active Directory schon einige Jahres und Versionen alt ist.

Was kommt dann?

Die Liste ist, wie anfangs geschrieben, ein Startpunkt. Sicherheit ist kein Zustand sondern eine Prozess und auch wenn Sicherheit quasi bei jedem meiner Schritte mit im Boot ist, so widme ich mich vielen anderen Themen. Aber Sie können die Checkliste als Startpunkt nutzen und ansonsten empfehle ich ihnen immer wieder ihre Aktuelle Umgebung gegen verschiedene Checklisten zu prüfen. Neben meiner einfachen HTML-Seite gibt es viele Werkzeuge, die oft auch als kostenfreie (limitierte) Version bereitstehen.

Gehen Sie davon aus, dass die "bösen Akteure" auch solche Werkzeuge haben und nutzen.

Gerade die beiden ersten Tools prüfen beide über 100  verschiedene OnPremises-Einstellungen und geben Hinweise auf bessere Einstellungen.

Zudem sollten sie sich wirklich die Zeit nehmen, die Windows Updates auf sicherheitsrelevante Veränderungen zu kontrollieren. Meine Seite Windows Security Changes 2023 zeigt gut, dass Microsoft einige Verbesserungen erst vorbereitet aber teils über Jahre hinweg nicht automatische aktiviert. Es liegt an ihnen, ob sie gewisse Möglichkeiten zur besseren Absicherung nach einer Bewertung und Überprüfung ihrer Umgebung schon früher aktivieren.

Übrigens: Net at Work bietet Security Assessment und Analysen an.
https://www.netatwork.de/security-assessment-tool-schwachstellen-mit-csat-sofort-erkennen/
https://www.netatwork.de/security-operations-center-soc/
Aber Anrufen müssen Sie schon selbst.

Weitere Links