Unterschiedliche Passwörter für lokale Admin

[olc 18]

Ja. "Aufgeweckt" wurden meine Cliente-Betreuer, als beim diesjährigen Premier-Auftakt ein Microsoft-Sicherheitsmensch erklärt, dass bei so gut wie allen gehakten ADs, die sie gefunden haben, PtH im Spiel war.

 

Ah, ok. Kenne die Veranstaltung und den Inhalt. :)

 

Es gibt dazu eine nette Aussage (sicher nicht neu, aber ich finde sie gut):

 

Es existieren genau zwei Arten von IT-Umgebungen

• In Kategorie 1 wissen die Verantwrtlichen davon, daß sie von Malware befallen oder alternativ gehackt (APT) wurden (oder beides).
• In Kategorie 2 wissen sie es nicht.
• Eine Kategorie 3 gibt es nicht. ;)

 

Vollkommen korrekt. Natürlich wäre es perfekt, wenn man ein Tool hat, das alle Aspekte erfüllt.

 

Gibt es das jemals...? :) Zumal sich Angriffsvektoren ja mit den Gegenmaßnahmen ändern...

 

Aber selbst wenn man weiß, dass man einen Aspekt mangels Werkzeug zuerst mal nur organisatorisch und mit Disziplin erfüllen kann, heißt das nicht, dass man die anderen Aspekte deswegen komplett ignorieren kann.

 

Bin ich vollkommen bei Dir. Jede Maßnahme ist für sich genommen erst einmal eine gute Maßnahme.

 

Der Sicherheitsbeauftragte hier fährt da ein ziemlich gute Linie: Anstelle eines massiven Stahltor und dann links und rechts einen kaputten Jägerzaun, lieber ein nicht ganz so gutes Tor, dafür aber insgesamt einen besseren Zaun.

 

Ich weiß natürlich nicht woher ihr kommt (historisch betrachtet in Bezug auf IT-Security) - sicher ist das ein erster guter Start, aber mittelfristig reicht das eben (leider) nicht.

Verstehe mich nicht falsch - ich sitze nicht im Elfenbein-Turm. Es muß nur immer klar sein, daß die ganzen "halben" Maßnahmen schlicht fast nichts bringen.

Solange nicht fundamentale Änderungen im Betrieb von IT-Umgebungen stattfinden, in Bezug auf die Prozesse, Administration, die Benutzer als auch eingesetzter Technik, sind die "Zäune" immer zu niedrig. Punkt. :)

 

Prima. Danke für den Link, sieht auf den ersten Blick gar nicht schlecht aus.

 

Gibt noch mehr und ähnliche Systeme, je nach Anwendungszweck.

Microsoft Consulting hat da soweit ich weiß auch eine Lösung gebaut, FIM basierend. Weiß nicht, ob da auch lokale Kennwörter geändert werden.

"CyberArk" hat auch in die Richtung etwas.

 

Eine  Idee  wäre noch ein Challenge/Response-Verfahren  über Telefon.

 

Ich meine, in Safeguard gibt  es ein solches  Verfahren. Eine  Verschlüsselung mobiler Geräte sollte eh  Standard sein.

 

Nein, ist es nicht. Denn wenn Du erst ein Benutzer-Ticket hast, bist Du durch mit dem Thema. Game Over.

 

Viele Grüße

olc

[zahni 550]

Nein, ist es nicht. Denn wenn Du erst ein Benutzer-Ticket hast, bist Du durch mit dem Thema. Game Over.

Sorry, jetzt stehe ich auf dem Schlauch, welches ticket meinst Du ?  Ich meine Challenge/Response eine einmalig mögliche Anmeldung. Der Lokale Admin muss für jede erneute Anmeldung mit einer neuen Challenge neu anrufen.

Ja, wäre aufwendig.

 

Hm,  aber lokale  Kennwörter  sind  ohne Verschlüsselung in jedem Fall leicht zu knacken.  Ladet Euch mal SySS ein. Dann werdet Ihr feststellen, dass auch ein aktives PXE-Boot im  Bios keine gute Idee ist

[olc 18]

...schau Dir PtH einmal genauer an. :)

 

Etwa hier:

• http://en.wikipedia.org/wiki/Pass_the_hash
• http://www.microsoft.com/en-us/download/details.aspx?id=36036

 

Viele Grüße

olc

[zahni 550]

Ok, vielleicht habe ich mich falsch ausgedrückt.

 

Es ging mir um das konkrete Problem der lokalen Anmeldung eines lokalen Admins.

Hier könnte ich mir eine Art Challenge-Response-Verfahren vorstellen.

Natürlich nur, wenn entsprechende Masterschlüssel der Lösung gut gesichert sind. Z.B. mit einer HD-Verschlüsselung.

 

Dass die Windows-Passwort-Hash u.a. in der SAM-DB nicht sicher sind, ist schon klar. 

(schöne Grüße von SySS ;) )

Zumindest hier könnte Microsoft mal ein wenig nachsalzen.

 

Die  Alternativ für PiH (bezogen auf NTLM) ist dann vermutlich Kerberos mit AES256 Verschlüsselung.

Leider in Windows als alleiniges Protokoll nur schwer bis nicht  implementierbar.  Wobei hier  vermutlich wieder die Bugtraq 42435 in die Suppe spuckt.

[RobertWi 81]

Ich weiß natürlich nicht woher ihr kommt (historisch betrachtet in Bezug auf IT-Security) - sicher ist das ein erster guter Start, aber mittelfristig reicht das eben (leider) nicht.

 

Das ist allgemein vollkommen klar. In der IT-Sicherheit kann es schon per Definition keinen Stillstand geben. Wir sind immer nur "Verteidiger" und haben Angreifer gegen uns, die über eine theoretisch unbegrenzte Zeitmenge verfügen. Es wird daher nie eine vollkommen sichere Umgebung geben, und man darf sich nie ausruhen.

 

Verstehe mich nicht falsch - ich sitze nicht im Elfenbein-Turm. Es muß nur immer klar sein, daß die ganzen "halben" Maßnahmen schlicht fast nichts bringen.

 

Ist schon kein Problem. Aber irgendwo muss man anfangen.

 

Solange nicht fundamentale Änderungen im Betrieb von IT-Umgebungen stattfinden, in Bezug auf die Prozesse, Administration, die Benutzer als auch eingesetzter Technik, sind die "Zäune" immer zu niedrig. Punkt. :)

 

Wie oben schon gesagt: Prinzipbedingt sind die Zäune immer zu niedrig.

 

Microsoft Consulting hat da soweit ich weiß auch eine Lösung gebaut, FIM basierend. Weiß nicht, ob da auch lokale Kennwörter geändert werden.

 

FIM hatten wir schon beleuchtet und erfüllte mehrere Wünsche nicht und war damit zu teuer. Für Berechtigungsmanagement wird zur Zeit "8MAN" angeschaut. Auch eine Baustelle. Was nützen die besten Passworte, wenn niemand einfach nachvollziehen kann, wer wo Berechtigungen auf diversen TB Storage mit 5000 bis 6000 Freigaben hat.

 

"CyberArk" hat auch in die Richtung etwas.

 

Sieht auf den ersten Blick auch interessant aus.

[olc 18]

Ok, vielleicht habe ich mich falsch ausgedrückt.

 

Es ging mir um das konkrete Problem der lokalen Anmeldung eines lokalen Admins.

Hier könnte ich mir eine Art Challenge-Response-Verfahren vorstellen.

Natürlich nur, wenn entsprechende Masterschlüssel der Lösung gut gesichert sind. Z.B. mit einer HD-Verschlüsselung.

 

Ok, angekommen. :)

 

Dass die Windows-Passwort-Hash u.a. in der SAM-DB nicht sicher sind, ist schon klar. 

(schöne Grüße von SySS ;) )

Zumindest hier könnte Microsoft mal ein wenig nachsalzen.

 

Hat Microsoft, die "Mitigation" heißt Bitlocker.

 

Die  Alternativ für PiH (bezogen auf NTLM) ist dann vermutlich Kerberos mit AES256 Verschlüsselung.

Leider in Windows als alleiniges Protokoll nur schwer bis nicht  implementierbar.  Wobei hier  vermutlich wieder die Bugtraq 42435 in die Suppe spuckt.

 

Na ja, leider auch nicht wirklich. Es gibt ein ähnliches Angriffsszenario auch für Kerberos, siehe Stichwort "Golden Ticket": http://rycon.hu/papers/goldenticket.html

 

Das ist allgemein vollkommen klar. In der IT-Sicherheit kann es schon per Definition keinen Stillstand geben. Wir sind immer nur "Verteidiger" und haben Angreifer gegen uns, die über eine theoretisch unbegrenzte Zeitmenge verfügen. Es wird daher nie eine vollkommen sichere Umgebung geben, und man darf sich nie ausruhen.

 

:)

 

Ist schon kein Problem. Aber irgendwo muss man anfangen.

 

Ja, dann aber gleich beim Fundament anstatt ein paar Fenster ins Leere zu bauen. :)

 

Bitte verzeih mir da meine Erbsenzählerei - leider sehe ich nur allzu häufig den "Vorsatz" es besser zu machen, um dann schlußendlich (wenn überhaupt) bei halbgaren Umsetzungen zu landen, bei denen sich die Firmen dann noch einreden, sie wären nun "sicher" (Zitat) oder hätten das Sicherheitsniveau spürbar angehoben.

 

Meine persönliche Erfahrung ist: ehrlich sein, egal wie schmerzhaft es ist. Solange wir uns noch gegenseitig einreden, es würde alles nicht so schlimm werden, wird sich nichts ändern. Siehe mein Zitat oben zu den beiden Kategorien von IT-Netzwerken. Nicht paranoid sein, aber auch nicht vollkommen naiv. Letzteres ist zumindest meiner Erfahrung nach die Regel. Und/oder noch renitent dazu.

 

Wie oben schon gesagt: Prinzipbedingt sind die Zäune immer zu niedrig.

 

:)

 

FIM hatten wir schon beleuchtet und erfüllte mehrere Wünsche nicht und war damit zu teuer. Für Berechtigungsmanagement wird zur Zeit "8MAN" angeschaut. Auch eine Baustelle. Was nützen die besten Passworte, wenn niemand einfach nachvollziehen kann, wer wo Berechtigungen auf diversen TB Storage mit 5000 bis 6000 Freigaben hat.

 

Soll ich jetzt mal provozieren und "A-G-DL-P" einwerfen? *duckundweg*

 

Viele Grüße

olc

[RobertWi 81]

Soll ich jetzt mal provozieren und "A-G-DL-P" einwerfen? *duckundweg*

 

Was hat "A-G-DL-P" mit fehlenden Werkzeugen zur Dokumentation und einfacher Verwaltung zu tun? Irgendwann sind die Grenzen von ADUC, Freigabe-Manager und Excel-Dateien erreicht und spätestens wenn ITIL ins Spiel kommt, muss man quasi zwangsläufig auf Dritt-Anbieter zurückgreifen.

 

Aber das war jetzt nicht Thema hier.

[olc 18]

Was hat "A-G-DL-P" mit fehlenden Werkzeugen zur Dokumentation und einfacher Verwaltung zu tun? Irgendwann sind die Grenzen von ADUC, Freigabe-Manager und Excel-Dateien erreicht und spätestens wenn ITIL ins Spiel kommt, muss man quasi zwangsläufig auf Dritt-Anbieter zurückgreifen.

 

Aber das war jetzt nicht Thema hier.

 

Sofern das A-G-DL-P onzept sauber umgesetzt wurde, brauchst Du nicht auf der Zielressource prüfen, welche Zugriffe existieren. Du kannst es schlicht anhand der Gruppenmitgliedschaften evaluieren.

 

Aber ja, das ist die rein technische Betrachtung. Workflows und Prozessmanagement sind eine andere Ebene dabei.

 

P.S.: ADUC ist tot. ADAC/PowerShell lebt. 

 

Viele Grüße

olc

[blub 115]

Hallo Robert,

 

In meiner alten Firma hatten wir dazu eine selbst entwickelte Lösung am Start.

 

In einer zentralen OracleDB waren alle lokalen Passwörter von Clients und Servern zufallsgeneriert gespeichert. Die Passwortänderung erfolgte nur in der Datenbank selbst. Das neue PW wurde verschlüsselt und gesichert an die Clients geschickt und angewendet.

Da war auch bei Bedarf ein automatischer PW-Wechsel konfigurierbar.

 

Hat man ein lokales Passwort benötigt, bekam man dies nur von der Datenbank mitgeteilt.

Ich habe das System nicht entwickelt, nur mitbenutzt. Es hat jedenfalls funktioniert.

 

Kai

 

[xaxoxix 1]

wir handhaben das mit einem eigenem programm (in .net entwickelt), dass über die aufgabenplanung jeden tag beim betreffende lokale administrationskonto ein nach einer bestimmten logik erstelltes passwort vergibt. damit fahren wir sehr gut.

[Dr.Melzer 191]

@xaxoxix:

 

Bitte achte doch darauf in Zukunft auch Großbuschstaben zu benutzen. Je besser deine Beiträge lesbar sind umso besser kann dir geholfen werden.

[h-d.neuenfeldt 21]

Ausgehend von

Die lokalen Konten werden via Gruppenrichtlinien erzeugt.

 

ist der Rechner bei der Erstkonfiguration also am Netzwerk.

Warum dann nicht in der Shell mit

NET USER [username [password | *] [options]] [/DOMAIN]

 

das Passwort auf einen den Vorgaben entsprechenden Wert ändern ?

Dieser Wert kann dann ja auch problemlos in einer Excel-Datei landen

 

Solange der Rechner online verfügbar ist, kann man dies vom Server aus jederzeit wiederholen.

 

Wo liegt der Sinn in einem sich ändernden Passwort, wenn der Rechner offline ist ?

Wenn das Gerät gestohlen wurde, wird eh jeder die Platte ausbauen und als ReadOnly bearbeiten um an die Daten zu kommen

bearbeitet 27. März 2014 von h-d.neuenfeldt

[Daniel -MSFT- 129]

Warum dann überhaupt lokale Admin-Konten? Ich würde allen lokalen Adminkonten die Remoteanmeldung über das Netz verbieten und sie deaktivieren. Dazu Bitlocker an mit TPM & PIN und Du hast ein recht hohes Sicherheitsniveau erreicht.

 

Falls der Client dann mal offline gewartet werden muss, kann mit DaRT oder ähnlichen Tools der Account aktiviert werden.

 

BTW: Seit Vista ist das deswegen auch die Standardeinstellung. Deaktiviertes Administratorkonto mit leerem Kennwort (Accounts ohne Kennwort hinterlassen keinen Hash und können generell seit XP nicht über das Netzwerk genutzt werden).

 

Ist ja nicht so, als wenn wir hier nichts tun würden