LDAP Risiko

[haiflosse 10]

Wir haben eine Nachricht erhalten dass es bei uns ein Sicherheitsrisiko bei LDAP gibt.

Genau handelt es sich um folgende Informationen:

LDAP-Banner – vollständiger Replay: 

Microsoft AD Domain Controller, Domain schule.intern, Hostname DC1.schule.intern:

• Domain: DC=schule,DC=intern

• Servername: DC1

• Forest/Domain Functional Level: 4 (= Windows Server 2008 R2!)

• SASL: DIGEST-MD5, EXTERNAL, GSS-SPNEGO, GSSAPI

• Tag: eol-product

Ich habe jetzt am Windows Server dies geprüft mit.

PS C:\Users\admin> Get-ADDomain | Select-Object DomainMode

         DomainMode

         ----------

Windows2008R2Domain

 

PS C:\Users\admin> Get-ADForest | Select-Object ForestMode

 

         ForestMode

         ----------

Windows2008R2Forest

 

PS C:\Users\admin> Get-ADDomainController -Filter * | Select-Object Name, OperatingSystem

 

Name OperatingSystem

---- ---------------

DC1  Windows Server 2019 Standard

 

Soweit ich sehen kann verwenden wir noch die alte Functional Level Windows2008R2Domain und Windows2008R2Forest.

Soweit ich weiter recherchiert habe kann man diese aber erhöhen, da wir aktuell nur noch Windows 2019 Server verwenden.

Active Director Domain und Vertrauensstellung öffnen:

Domain → „Domänenfunktionsebene erhöhen“

Forest → „Gesamtstrukturfunktionsebene erhöhen“

Danach sollte man wieder LDAP verwenden können – oder?

Bitte um eure Meinung und Feedback.

Vielen Dank

[cj_berlin 1.578]

Moin,

 

Betriebssystem und Functional Level ändern nur das Default-Verhalten, aber wenn Du anheben kannst, wirst Du auf andere Weise davon profitieren. Zu LDAP: https://it-pro-berlin.de/2024/06/ldap-deaktivieren-ein-reality-check/ und schau, ab ihr Signierung aktivieren könnt. Das ist das einzige, was hilft.

Nur aus Interesse: welches Tool war es, das dies gemeldet hat?

bearbeitet 11. April von cj_berlin

[haiflosse 10]

Vielen Dank für die Antwort. 

Die Meldung kommt von einem Unternehmen der das Netzwerk und Server auf Sicherheit geprüfte hat. 

Wie können wir noch die Signierung aktivieren. 

Vielen Dank 

[cj_berlin 1.578]

https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/enable-ldap-signing-in-windows-server da ist auch beschrieben, wie ihr vorher prüft, ob es knallen wird und wo 

[testperson 1.988]

Moin,

 

mich irritiert hier gerade der "Tag: eol-product". Ist das der Grund fürs "flaggen"? Wurde für die Prüfung von intern (LAN) oder von extern (WAN) gescannt?

 

Solange Windows Server 2016 / 2019 noch im Support sind, wäre ein FFL/DFL 2008 R2 für mich kein "EOL". Da ihr aber 2019er Domain Controller habt würden mir ad hoc als Vorteil für ein FFL/DFL 2016 einfallen

• Bei Einsatz von LAPS können die Passwörter verschlüsselt gespeichert werden
• Die Protected User werden AFAIK auf Kerberos-only / 4h TGT / AES erzwungen
• (Authentication Silos / Policies oder auch PAM)

Ggfs. noch zusätzlich folgende Artikelserie:

• Active Directory Hardening Series - Part 1 – Disabling NTLMv1 | Microsoft Community Hub
• Active Directory Hardening Series - Part 2 – Removing SMBv1 | Microsoft Community Hub
• Active Directory Hardening Series - Part 3 – Enforcing LDAP Signing | Microsoft Community Hub
• Active Directory Hardening Series - Part 4 – Enforcing AES for Kerberos | Microsoft Community Hub (Bei einem DFL/FFL 2008 R2 evtl. einmal vor dem April Patchday bewerten/prüfen.)
• Active Directory Hardening Series - Part 5 – Enforcing LDAP Channel Binding | Microsoft Community Hub
• Active Directory Hardening Series - Part 6 – Enforcing SMB Signing | Microsoft Community Hub
• Active Directory Hardening Series - Part 7 – Implementing Least Privilege | Microsoft Community Hub
• Active Directory Hardening Series - Part 8 – Disabling NTLM | Microsoft Community Hub

Als Hinweis: Prüft, was ihr davon eh schon umsetzt. Bewertet was ihr einfach umsetzen könnt und evtl. "schnell + viel" hilft. Setzt auf keinen Fall alles gleichzeitig und ohne es zu testen um.

 

Gruß

Jan

[NorbertFe 2.401]

vor 6 Stunden schrieb testperson:

Als Hinweis: Prüft, was ihr davon eh schon umsetzt.

Haha ;)

[cj_berlin 1.578]

vor 22 Stunden schrieb testperson:

mich irritiert hier gerade der "Tag: eol-product". Ist das der Grund fürs "flaggen"?

Genau deshalb habe ich nach dem Tool gefragt. Das hat ja nicht ein Mensch in den Report geschrieben, und wenn doch, Geld zurück verlangen.

[NilsK 3.140]

Moin,

 

Ein sehr schönes Beispiel, warum ich das Konzept "Pentest" kritisch sehe. Erstaunlich viele "Pentester" werfen dem Kunden Reports mit solchen Schlagworten hin, und das war es dann. Keine Erklärung, was das heißt, keine Erklärung, was da genau geprüft wurde, keine Erklärung, wie man das behebt. Was soll sowas?

 

Gruß, Nils

[cj_berlin 1.578]

Naja, diese Art von Finding in dieser Formulierung deutet mehr auf ein Konfigurations-Audit hin als auf einen Pentest. Das macht's aber nicht besser, im Gegenteil: Beim Pentest würde ich es noch akzeptieren, wenn keine Hinweise zur Behebung gegeben werden, aber beim Audit ist es das eigentliche Ziel der Übung.

[haiflosse 10]

Danke für die Antwort.

Das Tool kenne ich leider nicht mit dem Geprüft wurde.

Ich habe mit einem Netzwerktechniker für Windows Server gesprochen.

Er hat mir mitgeteilt, dass ich bei den Windows Webserver 2019 das Problem nicht mit LDAP haben sollte.

Zum Tag eol-product hat er auch mitgeteilt, dass es stimmt, dass der Server 2008 End of live (EOL) ist, da ich aber Windows Server 2019 im Einsatz habe sind diese nicht EOL.

Ein Höherstufen der Functional Level auf 2016 meint er ist trotzdem eine gute Idee, aber aus generellen und nicht aus Sicherheitsgründen.

Er meint die Nachricht könne ich ignorieren.

 

von der Firma, die das Netz geprüft habe, habe ich auf die Frage, ob dies auch bei Windows 2019 Server auftritt, folgende Antwort erhalten:

bitte prüfen sie unabhängig Ihrer Server OS Versionen die FW Config.

LDAP (389) inbound Extrem Kritisch

Anscheinend auch TCP445 (SMB!) inbound erlaubt = extrem kritisch

Ich empfehle Ihnen dringend ein Audit Ihrer Firewall konfiguration und ggf. auch der restlichen Infrastruktur.

 

Wie ist eure Meinung?

Danke

 

[NorbertFe 2.401]

vor 48 Minuten schrieb haiflosse:

LDAP (389) inbound Extrem Kritisch

Anscheinend auch TCP445 (SMB!) inbound erlaubt = extrem kritisch

Ich empfehle Ihnen dringend ein Audit Ihrer Firewall konfiguration und ggf. auch der restlichen Infrastruktur.

 

 

Der Test erfolgte aus dem Internet heraus? Dann würde ich das auch als extrem kritisch bezeichnen und mich wundern, dass die Umgebung überhaupt noch dir gehört. Der ffl und dfl wäre dann aber eh das Unwichtigste in dieser Situation.

 

vor 48 Minuten schrieb haiflosse:

Ein Höherstufen der Functional Level auf 2016 meint er ist trotzdem eine gute Idee, aber aus generellen und nicht aus Sicherheitsgründen.

Naja wie oben schon erwähnt, gibts da durchaus auch Sicherheitsgründe. ;)

bearbeitet 12. April von NorbertFe

[cj_berlin 1.578]

Was @NorbertFe sagte. Wenn der Test aus dem Internet erfolgte, gehört die Ugebung vermutlich bereits jemand anderem. Und da braucht ihr kein Audit der Firewall-Konfiguration, sondern das muss einfach zu, und wenn dabei irgendwas nicht mehr funktioniert, dann ist es so. Erst dann macht es überhaupt Sinn, ein Audit "der restlichen Infrastruktur" ins Auge zu fassen.


Wenn der Test intern war, dann MUSS ein Domain Controller LDAP auf Port 389 tcp/udp zulassen, und auch SMB, sonst könnten die Member ja keine Gruppenrichtlinien ziehen.

bearbeitet 12. April von cj_berlin

[NilsK 3.140]

Moin,

 

Das führt irgendwie zu den Fragen: wer hat denn da überhaupt was beauftragt und was würde wie geprüft?

 

Gruß, Nils

bearbeitet 13. April von NilsK
"wer", nicht "er" (Fipptehler)

[haiflosse 10]

Wir haben nochmals bei der Firma angefragt, die den Test durchgeführt haben ob LDAPs anstatt LDAP zu verwenden und haben folgende Antwort erhalten:

------------

Ich empfehle dringend , dass Sie LDAP (auch LDAPS) nicht am WAN verfügbar machen. 

Es bedarf einer Anpassung der Architektur, das ist auch anders lösbar. Das CERT.at darf das nicht sehen

-------------

Anscheinend soll und kann LDAP oder LDAPs auf externen Seiten nicht verwendet werden.

Wie würde dann eine andere Lösung aussehen?

Danke

[NorbertFe 2.401]

Ich würde vorschlagen, ihr holt euch jemanden, der euch bei dem Thema beraten und unterstützen kann. Denn das mal eben im Forum abzuhandeln dürfte schwer werden. Korrekt ist, man veröffentlicht keine internen Verzeichnisdienste einfach mal so ins WAN (und SMB auch nicht und zwar schon immer und nicht erst jetzt). Und wie die "andere Lösung" aussehen würde, könnte man dir auch erst sagen, nachdem man weiß, was ihr da aus welchem Grund derzeit überhaupt im Einsatz habt. Alles andere ist nur Glaskugelraten und das ist weder für dich besonders zielführend noch besonders spaßig im Forum.

 

Bis dann

Norbert