Gast Geschrieben 5. März 2009 Melden Teilen Geschrieben 5. März 2009 Hallo, man kann per GPO den NTLM Hash deaktivieren, damit das Kennwort cracken erschwert wird. Anschließend muss das Kennwort geändert werden, damit der Hash gelöscht wird. Hat dieses Deaktivieren des NTLM Hash irgendwelche Nachteile? Wir nutzen nur Server ab Windows 2000 SP4 /überwiegend 2003 SP2, Clients XP SP2. Viele Grüße Stefan Zitieren Link zu diesem Kommentar
NorbertFe 2.035 Geschrieben 5. März 2009 Melden Teilen Geschrieben 5. März 2009 Hat dieses Deaktivieren des NTLM Hash irgendwelche Nachteile? Ja, man kann ihn nicht mehr per Bruteforce bearbeiten ;) Bye Norbert Zitieren Link zu diesem Kommentar
Gast Geschrieben 5. März 2009 Melden Teilen Geschrieben 5. März 2009 Hehe, genau deswegen möchte ich das ja durchführen. Ansonsten sind keine Nachteile bekannt? Zitieren Link zu diesem Kommentar
NorbertFe 2.035 Geschrieben 5. März 2009 Melden Teilen Geschrieben 5. März 2009 Ausser denen, die hier dokumentiert sind, kenne ich keine: How to prevent Windows from storing a LAN manager hash of your password in Active Directory and local SAM databases Bye Norbert Zitieren Link zu diesem Kommentar
rakli 13 Geschrieben 5. März 2009 Melden Teilen Geschrieben 5. März 2009 Hier zwei interessante Links: http://support.microsoft.com/kb/299656 http://www.microsoft.com/germany/technet/sicherheit/newsletter/kennwoerter2.mspx Rakli Zitieren Link zu diesem Kommentar
grizzly999 11 Geschrieben 5. März 2009 Melden Teilen Geschrieben 5. März 2009 Hallo, man kann per GPO den NTLM Hash deaktivieren, damit das Kennwort cracken erschwert wird. Du meinst den LM-Hash. Und dann gibt es nochden NT-Hash, und die Authentifizierung heißt NTLM_Authentifizierung ;) Aber wenn du keine alten Clients mehr hast oder keine Verbidnung zu OS/2, dann brauchst du den LM-HASHnicht mehr. grizzly999 Zitieren Link zu diesem Kommentar
Gast Geschrieben 5. März 2009 Melden Teilen Geschrieben 5. März 2009 Genau das meinte ich doch, grizzly :D Habt dank, wir brauchen den LM Hash nicht. Ich werde ihn deaktivieren. Zitieren Link zu diesem Kommentar
Dukel 454 Geschrieben 5. März 2009 Melden Teilen Geschrieben 5. März 2009 Es gibt natürlich auch einen ntlm hash, da ntlm auch mit hashes arbeitet. Diesen kann man in der Version 1 auch per GPO deaktivieren, indem man nur noch ntlm v2 erlaubt. Zitieren Link zu diesem Kommentar
grizzly999 11 Geschrieben 6. März 2009 Melden Teilen Geschrieben 6. März 2009 Es gibt natürlich auch einen ntlm hash, da ntlm auch mit hashes arbeitet.Diesen kann man in der Version 1 auch per GPO deaktivieren, indem man nur noch ntlm v2 erlaubt. Du darfst mir ruhig glauben, ich weiß in dem Fall ziemlich genau, was ich schreibe. Ansonsten empfehle ich dir auch die ganzen Artikel und Bücher und Security Resource Kits (einige Zig an der Zahl) dazu durchzulesen, so wie ich es die letzten 10 Jahre ununterbrochen getan habe :wink2: Besonders gut zu diesem Thema die Artikel von Jesper Johannson, teilw. auch von Steve Riley. grizzly999 Zitieren Link zu diesem Kommentar
solinske 10 Geschrieben 6. März 2009 Melden Teilen Geschrieben 6. März 2009 Hash Attacken sind echt ein alter Hut nur so nebenbei! Man sollte nur noch Kerberos V5 zur Authentiizierung nutzen. Was Grizzly gesagt hat kann ich nur empfehlen, denn die Artiekl/Bücher/Session von Jesper Johanson sind absolut Pflicht. Dort wird auch erklärt, dass ein saltet Hásh keine Alternative ist. Sicherheit flächendeckend zu implementieren ist ein langer und gut geplanter Prozess. Zitieren Link zu diesem Kommentar
NilsK 2.937 Geschrieben 7. März 2009 Melden Teilen Geschrieben 7. März 2009 Moin, Hash Attacken sind echt ein alter Hut nur so nebenbei! Man sollte nur noch Kerberos V5 zur Authentiizierung nutzen.[...] Dort wird auch erklärt, dass ein saltet Hásh keine Alternative ist. sorry, aber knapp vorbei ist auch daneben. AD legt Kennwörter als Hashes in seiner Datenbank ab. Darum geht es. Das hat mit dem Authentifizierungsprotokoll erst mal nichts zu tun. Auch im Fall von Kerberos ist eine Kennwortauthentisierung nötig, es sei denn man hat auf Smartcards o.ä. umgestellt. Gruß, Nils Zitieren Link zu diesem Kommentar
olc 18 Geschrieben 7. März 2009 Melden Teilen Geschrieben 7. März 2009 Hi, da möchte ich mich Nils anschließen - als kleiner Querverweis dazu sei noch die Datenschleuder #93 genannt, die auf Seite 34 auf das Problem (bei lokalen Konten) eingeht. Im Grunde ist es aber das gleiche Problem in AD Umgebungen - dort muß der Zugriff auf die AD-Objekte bzw. konkret die jeweiligen Attribute / die Datenbank oder den LSASS-Prozess entsprechend möglich sein, was jedoch mit etwas Arbeit eines "Profis" theoretisch möglich ist. Die Registirerung ist auf DCs auch ein Thema, da dort das Konto des Wiederherstellungskontos gespeichert ist (lokale SAM). Den LM-Hash zu deaktivieren ist also schon einmal eine gute Sache, das steigert die Sicherheit, selbst wenn der NTLM-Hash dann immer noch "gebrochen" werden kann - hier ist jedoch mehr Rechenpower bzw. Aufwand notwendig als beim LM-Hash. Starke Kennwörter bieten dann bei NTLM noch eine Sicherheitssteigerung, das Verschlüsseln der HDD bei DCs ist eine weitere Schutzmaßnahme (falls diese entwendet werden). Gleiches gilt natürlich auch für die Backups der Systeme. Viele Grüße olc Zitieren Link zu diesem Kommentar
solinske 10 Geschrieben 8. März 2009 Melden Teilen Geschrieben 8. März 2009 Man könnte auch einfach sehr lange Kennwörter nutzen, dann ist die Sache auch schnell erledigt ;-) Zitieren Link zu diesem Kommentar
olc 18 Geschrieben 8. März 2009 Melden Teilen Geschrieben 8. März 2009 Hi, das habe ich oben schon geschrieben. ;) Allein lange Kennwörter helfen jedoch nicht, das ist heutztage nur ein kleiner Stolperstein - LM-Hash hat kein "salt", wenn ich mich recht entsinne. Daher ist ein Angriff keine "große Sache" - Stichwort "rainbow tables" etc. Zusätzlich helfen Dir längere Kennwörter bei LM-Hash auch recht wenig, da diese in mehrere Teile gesplittet werden, die wiederum "unabhängig" voneinander angegriffen werden können. Lediglich Kennwörter größer 16-Zeichen helfen da, jedoch wären dann Applikationen, die LM-Hash nutzen wollen, eh außen vor. Von daher kann man es also gleich Deaktivieren. Eine Einzelmaßnahme ist jedoch nicht viel Wert, es muß immer ein Gesamtkonzept erarbeitet werden. Das Deaktivieren eines "schwachen Hashes" wie dem LM-Hash ist da nur eine Komponente. Das Deaktivieren macht etwa wenig Sinn, wenn man danach nicht alle Kennwörter vom Computer- und Benutzerkonten ändert. Das vergessen meiner Erfahrung nach viele Unternehmen. Gerade bei Service-Accounts verzichten viele Firmen darauf - und genau diese Accounts sind recht gefährdet, denn der alte Hash ist demnach immer noch gültig, bis irgendwann vielleicht doch einmal eine Kennwortänderung erfolgt. Viele Grüße olc Zitieren Link zu diesem Kommentar
grizzly999 11 Geschrieben 8. März 2009 Melden Teilen Geschrieben 8. März 2009 Lediglich Kennwörter größer 16-Zeichen helfen da, jedoch ..... Kennwörter länger als 14 Zeichen ;) Für den LM-Hash werden die Kennwörter in 2x 7 Zeichen lange Chunks gesplittet. Allein lange Kennwörter helfen jedoch nicht, ..... Das stimmt haargenau, gilt aber auch für NT-Hashes. Wenn man die Hashes hat, ist man bereits gehackt! :eek: Ein "guter" Angreifer braucht die Hashes nicht mehr Hacken, der startet den Angriff nur allein mit dem Hash. Habe ich auch schon ein paar mal demonstriert. Dabei kann das Kennwort auch volle 127 Zeichen lang sein. Das würde ich nie cracken können, aber authentifizieren kann ich mich damit problemlos. Von daher ist die Deaktivierung des LM-Hashes zwar eine klitzekleine Maßnahme, mehr aber auch nicht. Wichtiger ist: es erst dar niemand an die Hashes kommen, was aber im Bereich der lokalen Rechner sehr schwierig bis gar nicht zu verwirklichen ist. Wie olc es sagte, ein Security-Konzept diesen Bereich betreffend muss umfassend und weitreichend sein, ansonsten sind Aktionen wie Deaktivieren von bestimmten Hashes oder Unterbinden von bestimmten Authentifizierungsverfahren unnützer Aktionismus. grizzly999 Zitieren Link zu diesem Kommentar
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.