Kerberos Samba 4 RSAADSI RC4-HMAC

Hallo,

mir ist letztens aufgefallen, daß zumindest unter Windows für den Kerberos-Sitzungschlüssel auch RSAADSI RC4-HMAC verwendet wird. Das ist ja leider nicht wirklich sicher. Kann man das deaktivieren oder wird das unbedingt benötigt?

Viele Grüße,
SirTux

Moin,

der Grund, warum dieser Verschlüsselungsalgorithmus in Windows-Active-Directory-Servern noch unterstützt wird, ist mal wieder der breite Arsch der heiligen Kompatibilitätskuh. Er ist derjenige, der für die alten NT-Hashes benutzt wird. Richtig alte Server und Clients könnten diesen Mechanismus theoretisch noch benötigen.

Die Samba-Entwickler wiederum versuchen ihr bestens, so gut es geht zu einem AD kompatibel zu sein. Dazu gehört dann halt auch die Unterstützung solch archaischer Sicherheitsfeatures.

Wenn ich’s richtig verstehe, dann besteht dann ein Problem mit diesem Verschlüsselungsverfahren, wenn a) ein Angreifer in den Besitz des Hashes kommt (z.B. falls noch irgendwo das Protokoll NTLMv1 verwendet wird oder durch Einbruch auf einem AD-Server – dann ist aber eh schon Hopfen und Malz verloren) und b) er einen AD-Server bei der Authentifizierung bei der Verbindung auf die Verwendung dieses alten Verfahrens herunterhandeln kann. Wenn noch NTLMv1 eingesetzt werden sollte, so hat man es aber eh schon mit Uralt-Clients oder -Servern zu tun, und dann ist fraglich, ob das Abschalten dieses Algorithmus diese Clients/Server nicht komplett aussperren würde!

Die aktuell (= seit mehr als zehn Jahren) eingesetzten Authentifizierungsprotokolle (NTLMv2) schicken nicht mehr die Hashes selber durch die Leitung und sind daher sicherheitstechnisch absolut OK. Das bedeutet, dass zum Erlangen der Passworthashes der bereits erwähnte Einbruch auf einem AD-Server selber notwendig wird, und wenn der glückt, dann ist die Katze so oder so aus dem Sack. Siehe auch dieser Blog-Post, der sehr ähnlich argumentiert. Bei aktuellen Protokollen ist das Leaken der Passwordhashes schlicht kein Szenario mehr, über das man sich Sorgen machen müsste.

Univention selber unterstützt das Abschalten dieses Algorithmusses nicht, aber Sie können’s natürlich selber ausprobieren. Was dazu alles angepasst werden müsste? Gute Frage, allen voran auf jeden Fall die Kerberos-Konfigurationsdateien »/etc/krb5.conf«, »/var/lib/samba/private/krb5.conf«. Die im ersten verlinkten Artikel erwähnten Gruppenrichtlinien hingegen wirken sich auf Samba-AD-DCs nicht aus.

Meiner Meinung nach ist es den Aufwand schlicht nicht wert (und ich bin jemand, der penibel darauf achtet, selbst im lokalen Netzwerk ausschließlich https zu verwenden; BTW: Das Univention-Forum hat ein mieses SSL-Zertifikat :frowning: ).

Gruß,
mosu

Hallo,

Danke für die Erläuterungen. Dann ist das ganze doch nicht so problematisch wie ich dachte. Dennoch wäre es schön, wenn man das ganze Abschalten könnte. In den Templates möchte ich dafür dann aber auch nicht rumpfuschen. Es wäre schön, wenn Univention sich der Sache annehmen würde.

Wie siehts denn eigentlich mit einer Downgrade-Attacke auf NTLMv1 aus? Wäre dies denkbar, oder ist zumindest dafür die Unterstützung aus den neueren Windows-Versionen rausgepflogen?

Meiner Meinung nach ist es den Aufwand schlicht nicht wert (und ich bin jemand, der penibel darauf achtet, selbst im lokalen Netzwerk ausschließlich https zu verwenden; BTW: Das Univention-Forum hat ein mieses SSL-Zertifikat :( ).

Was ist denn mit dem Zertifikat, außer daß der CN nicht zum Domainnamen paßt?

Moin,

Das kann ich so nicht beantworten. Ich meine, dass man Windows-Clients via Gruppenrichtlinie so konfigurieren kann, dass ausschließlich NTLMv2 (und damit weder LanManager- noch NTLMv1-Authentifizierung) verwendet wird. Was aber der Standard ist, das weiß ich nicht. Google sollte helfen.

Genau das. Was bei modernen Browsern bei jedem Aufruf unglaublich nervt. Und es ist nicht so, als ob das Zertifikat schon seit Ewigkeiten im Einsatz wäre – nee, es wurde gerade erst im Dezember ausgestellt.

Ich glaub, ich bitte Univention mal direkt um ein anständiges Zertifikat :slight_smile:

Hallo,

seit Errata-Update 153 scheint es ja jetzt möglich zu sein die hier angesprochenen Probleme anzugehen mit

ucr set samba/ntlm/auth='no' samba/ldap/server/require/strong/auth='yes'

Oder übersehe ich da was?

Viele Grüße,
SirTux

Mastodon