Unterschiedliche Passwörter für lokale Admin

[RobertWi 81]

Moin,

 

bei uns ist eine interessante Frage aufgetaucht, anlässlich einer Präsentation zu "Pass-the-Hash"-Angriffen.

 

Gegeben sein, dass auf den Client-PCs lokale Admins-Konten existieren. Das Benutzen von Domänen-Konten ist nur begrenzt möglich, weil Notebooks auch ohne Netzwerk administrierbar sein müssen. Und gegen sei auch, dass ein komplettes Deaktivieren von LM/NTLM oder der Einsatz von Multi-Faktor-Authentifikation aufgrund externer Abhängigkeiten nicht flächendeckend umsetzbar ist.

 

Die lokalen Konten werden via Gruppenrichtlinien erzeugt.

 

Gewünscht wird ein lokaler Admin, der aber auf den PCs unterschiedliche Passwörter hat, z.B. ein Standard-PW plus dem Computernamen. Alternativ auch eine "Datenbank" in der die PW stehen. Und so richtig schick wäre es, wenn die lokalen PW z.B. dort ein lokales Programm, auch noch regelmäßig geändert würden (z.B. durch Ergänzung der Kalenderwoche).

 

Wurde jemand schon mal mit einer solchen Aufgabe konfrontiert? Was könnten Lösungen sein - Dritt-Anbieter und Scripts eingeschlossen.

 

 

 

 

[NorbertFe 2.027]

Es gab von MS mal so ein geniales Teil, was das Schema erweitert hat und dann clientseitig immer das lokale Adminkennwort in ein Zufallskennwort geändert hat und dieses Kennwort in ein Confidential Attribut geschrieben. man mußte als Admin also erst in das AD schauen, um das jeweils aktuelle lokale Kennwort des Admins rauszufinden. ;) Fand die Lösung ziemlich cool.

http://code.msdn.microsoft.com/windowsdesktop/Solution-for-management-of-ae44e789

 

Vielleicht ne Idee? ;)

 

Bye

Norbert

[tesso 375]

Interessante Lösung, werde ich mal testen.

[olc 18]

Hi Robert,

 

die Lösung von Norbert ist tatsächlich ganz nett, auch wenn es offiziell nur ein "Sample" ist und sicher offene Fragen dazu existieren.

 

Wenn die PCs jedoch meist "offline" sind wird es grundsätzlich schwer, die Kennwörter zu ändern und zentral zu hinterlegen (in welcher Art auch immer).

 

Davon einmal ab zwei Rückfragen:

#1: Wer genau hat das administrativen Zugriff und wie findet die Rollentrennung auf den Systemen statt?

#2: Welche Domain-Accounts melden sich außer den lokalen Konten an den Systemen an (Admins, Service Accounts usw.)? In Bezug auf PtH eine nicht unwichtige Fragestellung. :)

 

Als grundlegende Aussage, egal ob die lokalen Administratoren-Kennwörter unterschiedlich sind auf den Maschinen oder nicht: die Ebene der Workstations läßt sich kaum langfristig schützen, je nach Umgebung. Das heißt Ihr müßt sinnvoll diese "low security" Systeme von den "high security" Systemen trennen(!) durch Zonenmodelle.

 

P.S.: Auch wenn es ein anderes Angriffsszenario (Stichwort "Golden TGT") ist - auch Kerberos ist in ähnlicher Art angreifbar. Nur als Hinweis, da Du lediglich LM/NTLM angesprochen hast. :)

 

Viele Grüße

olc

[NorbertFe 2.027]

Hi Robert,

 

die Lösung von Norbert ist tatsächlich ganz nett, auch wenn es offiziell nur ein "Sample" ist und sicher offene Fragen dazu existieren.

Ja, aber leider kommt von Seiten MS offiziell ja null Funktion in dieser Sache. Da hat sich seit Windows 2000 nix geändert. ;)

 

Wenn die PCs jedoch meist "offline" sind wird es grundsätzlich schwer, die Kennwörter zu ändern und zentral zu hinterlegen (in welcher Art auch immer).

Das ist aber prinzipbedingt so bei "offline" Systemen. ;)

 

 

Bye

Norbert

[olc 18]

Hi Norbert,

 

ohne die Diskussion hier abgleiten lassen zu wollen: nur das letzte Wort zu haben, ist kein Argument. ;) :P

 

Zu Deinem Punkt 1:

Wenn ich die Sicherheit erhöhen will stellt sich die Frage, wie ich das tue. Nutze ich ein Tool dafür (neben Prozessen usw.), muß ich sicherstellen, daß dieses Tool meinen Sicherheitsanforderungen gerecht wird. Ob ein Tool auf Codeplex dem entspricht, muß ich bewerten. Das ist mein Argument, nicht mehr und nicht weniger. :)

 

Zu Deinem Punkt 2:

Klar, aber das Anliegen des TO ist recht eindeutig und daher ist der Zeitraum, wie lange die Systeme offline sind, ein durchaus wichtiger Bewertungspunkt. Denn die Zeit, die bis zu einer Kennwortänderung vergeht, ist auch bei PtH sehr relevant.

 

Viele Grüße

olc

[NorbertFe 2.027]

Hi Norbert,

 

ohne die Diskussion hier abgleiten lassen zu wollen: nur das letzte Wort zu haben, ist kein Argument. ;) :p

Ich weiß, deswegen überlasse ich es nicht dir, sondern bringe noch ein zwei Ergänzungen. ;)

 

Zu Deinem Punkt 1:

Wenn ich die Sicherheit erhöhen will stellt sich die Frage, wie ich das tue. Nutze ich ein Tool dafür (neben Prozessen usw.), muß ich sicherstellen, daß dieses Tool meinen Sicherheitsanforderungen gerecht wird. Ob ein Tool auf Codeplex dem entspricht, muß ich bewerten. Das ist mein Argument, nicht mehr und nicht weniger. :)

Darum gings mir doch. Es gibt von MS _keine_ mir bekannte Lösung für das Management lokaler Kennworte. Und ja, ich kenne deine Meinung zu Passworten. ;) Mir ist auch klar, dass ein auf codeplex veröffentlichtes Projekt nicht zwingend im Highsecurity Umfeld "mal eben" eingesetzt wird. Es war meinerseits als Idee für die hier geäußerte Frage aufgeführt worden, weil ich die grundlegende Idee hinter dem Projekt ziemlich smart finde.

 

 

Zu Deinem Punkt 2:

Klar, aber das Anliegen des TO ist recht eindeutig und daher ist der Zeitraum, wie lange die Systeme offline sind, ein durchaus wichtiger Bewertungspunkt. Denn die Zeit, die bis zu einer Kennwortänderung vergeht, ist auch bei PtH sehr relevant.

Korrekt. Aber das Zusammenspiel zwischen offline und zentralem Management kann in dieser Form (Passworte) dann nicht sinnvoll handhaben lassen _können_. Denn irgendwo muß das neue Passwort ja "hinterlegt" werden (ausser im Konto selbst). Aber vielleicht hat ja hier noch jemand ne nette andere Idee.

 

Bye

Norbert

[olc 18]

Hi Norbert,

 

ich hab das Gefühl, daß wir uns hier bald im Kreis drehen... ;)

 

Darum hier mein finales Statement zu diesen Punkten - denn ich gehe davon aus, daß sie korrekt ankamen. ;)

 

Zu #1:
Es gibt am Markt diverse Drittanbieter, die solche Lösungen anbieten. Microsoft kann auch keine Lösungen für jedwede Fragestellung anbieten - Kritik also in allen Ehren, aber es ist eben wie es ist.

Und ja, ich stimme Dir zu: die Idee als solches ist smart, dem habe ich auch nicht widersprochen. Ich habe lediglich auf eine bisher nicht genannte Ebene hingewiesen, die insbesondere bei Sicherheitsdiskussionen zentrale Bedeutung hat.

 

Zu #2:

Ggf. muß der Ansatz verändert werden - siehe meine Fragen an Robert. Es geht mir also wie so häufig nicht darum, eine Lösung für eine Fragestellung zu finden, bei dem Ursache und Wirkung verwechselt wird.

 

BTW: wie kann man hier zitieren? Ich finde keine Möglichkeit eine Textpassage aufzuteilen in kleine Teile.

 

P.S.: So, nun wird es Zeit für Dein letztes Wort dazu. ;)

 

Viele Grüße

olc

bearbeitet 28. Februar 2014 von olc

[Sunny61 806]

BTW: wie kann man hier zitieren?

Meinst Du so in etwa? ;)

Ich finde keine Möglichkeit eine Textpassage aufzuteilen in kleine Teile.

Da ist 'Handarbeit' angesagt. Rechts unten auf Zitieren, und jetzt immer mit der ersten Zeile und der letzten Zeile Blöcke beginnen bzw. abschließen.

[NorbertFe 2.027]

Darum hier mein finales Statement zu diesen Punkten - denn ich gehe davon aus, daß sie korrekt ankamen. ;)

Klar, meine etwa nicht? ;)

 

Zu #1:

Es gibt am Markt diverse Drittanbieter, die solche Lösungen anbieten. Microsoft kann auch keine Lösungen für jedwede Fragestellung anbieten - Kritik also in allen Ehren, aber es ist eben wie es ist.

Ja, das ist meist die Aussage an solchen Stellen der Hersteller (damit meine ich explizit _nicht_ dich persönlich).

Und ja, ich stimme Dir zu: die Idee als solches ist smart, dem habe ich auch nicht widersprochen. Ich habe lediglich auf eine bisher nicht genannte Ebene hingewiesen, die insbesondere bei Sicherheitsdiskussionen zentrale Bedeutung hat.

Korrekt, wobei ich auch davon ausgehe, dass hier jemand der sich über PtH Gedanken macht, auch automatisch darüber nachdenkt, ob er einer Codeplex Projektseite/-lösung vertrauen will. Im Zweifel ist zumindest der Zugriff auf den Quellcode möglich. ;)

 

 

BTW: wie kann man hier zitieren? Ich finde keine Möglichkeit eine Textpassage aufzuteilen in kleine Teile.

Mittels ["Quote"] ["/Quote"]-Tags

 

 

Bye

Norbert

 

PS: Warum eigentlich ich? Könnt ja sein, dass du doch noch was sagen willst. :p 

Viele Grüße

olc

[RobertWi 81]

Moin,

 

danke für die rege Beteiligung. Ich hatte aufgrund der komplexen Fragestellung weniger befürchtet.

 

die Lösung von Norbert ist tatsächlich ganz nett, auch wenn es offiziell nur ein "Sample" ist und sicher offene Fragen dazu existieren.

 

ansehen werde ich mir das ganz sicher. Es sind ja auch "kleine" Lösungen mit Scripten denkbar.

 

Wenn die PCs jedoch meist "offline" sind wird es grundsätzlich schwer, die Kennwörter zu ändern und zentral zu hinterlegen (in welcher Art auch immer).

 

Nicht "meist", sondern "auch". Bei einem Server-/Client-Dienst würde ich hier gar keine technischen Schwierigkeiten sehen. Wenn der Server nicht erreichbar ist, wird das Passwort nicht geändert und landet auch nicht neu in der zentralen Datenbank. Damit sind dann die PW in DB und Client synchron, nur nicht so oft geändert.

 

Das spielt aber auch keine Rolle. Wichtig ist zuerst, dass die Hashes auf den einzelnen Clients unterschiedlich sind. Da ist es erstmal egal, ob das Passwort 1 Tage oder 1 Monat alt ist - es soll nur anders sein, als bei den anderen Clients. Und mehr oder weniger regelmäßig geändert werden.

 

 

#1: Wer genau hat das administrativen Zugriff und wie findet die Rollentrennung auf den Systemen statt?

 

Benutzerservice, eventuell auch lokale Systembetreuer. Diese haben keine weiteren Privilegien in Domäne oder Memberserver.

 

#2: Welche Domain-Accounts melden sich außer den lokalen Konten an den Systemen an (Admins, Service Accounts usw.)? In Bezug auf PtH eine nicht unwichtige Fragestellung. :)

 

Admins -> nie, aber es gibt halt auch kein Prinzip, dass das verhindert. In diesem Punkt geht es also nicht um 100%ige Sicherheit, sondern nur um Risiko-Senkung. Das Risiko, dass sich ein Trojaner, der PtH-Attacken fährt wird verringert, wenn Admins-Accounts auf den verschiedenen Clients andere PW haben. Und damit sinkt das Risiko, dass im Falle einer unerwünschten Admins-Anmeldung genau auf diesem Client ein Trojaner den Hash mitbekommt.

 

Systemaccounts lassen wir mal bewusst außen vor. Natürlich sind Accounts für Virenscanner-, Softwareverteilung und Systemmanagement ein sehr hohes Risiko.

 

Bei den lokalen Admins-Accounts geht es ja nicht nur um PtH. Wenn Kennwörter auf den Rechner überall gleich sind, sprechen die sich auch mal rum. Auch dass soll ja verhindert werden.

 

Service-Accounts müssen davon getrennt, für jede Anwendung einzelnen untersucht und im Sinne des "Least Privileges" angewendet werden.

 

Aber ich denke, nur weil man einen Punkt hat, der man als Risiko schlecht eindämmen kann, sollte man nicht alle anderen deswegen vernachlässigen.

 

Als grundlegende Aussage, egal ob die lokalen Administratoren-Kennwörter unterschiedlich sind auf den Maschinen oder nicht: die Ebene der Workstations läßt sich kaum langfristig schützen, je nach Umgebung. Das heißt Ihr müßt sinnvoll diese "low security" Systeme von den "high security" Systemen trennen(!) durch Zonenmodelle.

 

Vollkommen klar. Aber Sicherheit ist eben nicht nur ein Schalter, sondern besteht aus vielen Bestandteilen.

 

Mir ging es hier explizit um lokale Admins-Accounts.

 

P.S.: Auch wenn es ein anderes Angriffsszenario (Stichwort "Golden TGT") ist - auch Kerberos ist in ähnlicher Art angreifbar. Nur als Hinweis, da Du lediglich LM/NTLM angesprochen hast. :)

 

Weiß ich. Ist aber deutlich komplizierter.

 

Klar, aber das Anliegen des TO ist recht eindeutig und daher ist der Zeitraum, wie lange die Systeme offline sind, ein durchaus wichtiger Bewertungspunkt. Denn die Zeit, die bis zu einer Kennwortänderung vergeht, ist auch bei PtH sehr relevant.

 

Sicher, aber wie gesagt nur der zweite Schritt. Im ersten müssen die PW unterschiedlich sein. Und schon das ist schwer genug, umzusetzen.

 

Zu #1:

Es gibt am Markt diverse Drittanbieter, die solche Lösungen anbieten.

 

Beispiele? Wenn Du Angst hast, Namen zu nennen (was bei einer solchen Fragestellung i.d.R. kein Problem ist, denn ich frage ja explizit nach Anbietern), schick mir eine PM.

 

BTW: wie kann man hier zitieren? Ich finde keine Möglichkeit eine Textpassage aufzuteilen in kleine Teile.

 

Cursor in das Zitat stellen und mehrfach die Entertaste drücken. Zuerst kommen Leerzeilen, danach unterbrichst Du das Zitat.

[Sunny61 806]

Evtl. kannst Du die Passwörter ja zum Teil mit Systemvariablen setzen. Ich hab es nicht ausprobiert, aber evtl. hilft ja dieser Hint: http://www.gruppenrichtlinien.de/artikel/lokaler-administrator-install-agent-delegation-pro-computer/

[olc 18]

Moin, moin,

 

Moin,

 

danke für die rege Beteiligung. Ich hatte aufgrund der komplexen Fragestellung weniger befürchtet.

 

Ist ein aktuelles und interessantes Thema... :)

 

ansehen werde ich mir das ganz sicher. Es sind ja auch "kleine" Lösungen mit Scripten denkbar.

 

Des Teufels Advokat: ob diese "Lösungen" dann wirklich "sicherer" sind...? :)

 

Nicht "meist", sondern "auch". Bei einem Server-/Client-Dienst würde ich hier gar keine technischen Schwierigkeiten sehen. Wenn der Server nicht erreichbar ist, wird das Passwort nicht geändert und landet auch nicht neu in der zentralen Datenbank. Damit sind dann die PW in DB und Client synchron, nur nicht so oft geändert.

 

Ok, Du hattest eingangs explizit erwähnt, daß die Notebook-Systeme "offline" / ohne Netzwerk sind. Das hatte ich dahingehend interpretiert, daß es Dir auch um diesen konkreten Punkt geht. Mein Fehler, es war eine Annahme.

 

Das spielt aber auch keine Rolle. Wichtig ist zuerst, dass die Hashes auf den einzelnen Clients unterschiedlich sind. Da ist es erstmal egal, ob das Passwort 1 Tage oder 1 Monat alt ist - es soll nur anders sein, als bei den anderen Clients. Und mehr oder weniger regelmäßig geändert werden.

 

Ok, der Vollständigkeit halber sei dann aber auch gesagt, daß das nur ein ganz kleiner Teil der ganzen PtH Geschichte ist. Du scheibst weiter unten, daß es Dir grundsätzlich um unterschiedliche Kennwörter geht - volle Zustimmung hierbei. Wenn Du das aber in Deinem beschriebenen Szenario in den Kontext von PtH hebst, möchte ich widersprechen. :) Denn "nur" das Setzen von Kennwörtern löst das Problem nicht, solange administrative Gruppenmitglieder Anmeldungen am Zielsystem durchführen können. Das sind ja nur sehr bedingt lokale Administratoren.

 

Benutzerservice, eventuell auch lokale Systembetreuer. Diese haben keine weiteren Privilegien in Domäne oder Memberserver.

 

...und sie melden sich (remote) an den Systemen auch interaktiv an, korrekt? Das ist ein Problem im Kontext von PtH.

 

Admins -> nie, aber es gibt halt auch kein Prinzip, dass das verhindert. In diesem Punkt geht es also nicht um 100%ige Sicherheit, sondern nur um Risiko-Senkung. Das Risiko, dass sich ein Trojaner, der PtH-Attacken fährt wird verringert, wenn Admins-Accounts auf den verschiedenen Clients andere PW haben. Und damit sinkt das Risiko, dass im Falle einer unerwünschten Admins-Anmeldung genau auf diesem Client ein Trojaner den Hash mitbekommt.

 

Siehe oben. Ich stimme Dir zu, es ist eine sinnvolle und "erste" Maßnahme. Aber adressiert es wirklich das Problem? Meines Erachtens wirklich nur sehr, sehr begrenzt.

 

Systemaccounts lassen wir mal bewusst außen vor. Natürlich sind Accounts für Virenscanner-, Softwareverteilung und Systemmanagement ein sehr hohes Risiko.

 

Definitiv. Und genau daher müssen sie mit betrachtet werden. Und ja, ich weiß daß das wirklich nicht einfach ist. Aber die Weichen müssen eben gestellt werden.

 

Bei den lokalen Admins-Accounts geht es ja nicht nur um PtH. Wenn Kennwörter auf den Rechner überall gleich sind, sprechen die sich auch mal rum. Auch dass soll ja verhindert werden.

 

Das ist absolut sinnvoll und valide. :)

 

Service-Accounts müssen davon getrennt, für jede Anwendung einzelnen untersucht und im Sinne des "Least Privileges" angewendet werden.

 

Definitiv. 

 

Aber ich denke, nur weil man einen Punkt hat, der man als Risiko schlecht eindämmen kann, sollte man nicht alle anderen deswegen vernachlässigen.

 

+1

 

Vollkommen klar. Aber Sicherheit ist eben nicht nur ein Schalter, sondern besteht aus vielen Bestandteilen.

 

+1

 

Mir ging es hier explizit um lokale Admins-Accounts.

 

Ja, ich verstehe das. Mir wiederum ist wichtig darzustellen, daß Du damit den Schweizer Käse nur um ein Loch erleichterst, er aber dennoch genauso duftet wie vorher. ;)

Beispiele? Wenn Du Angst hast, Namen zu nennen (was bei einer solchen Fragestellung i.d.R. kein Problem ist, denn ich frage ja explizit nach Anbietern), schick mir eine PM.

 

Ein Beispiel wäre Lieberman: http://www.liebsoft.com/Random_Password_Manager/

Was keine Empfehlung darstellt, sondern nur ein Beispiel. :)

 

Das Produkt tut auch etwas mehr als "nur" Kennwörter ändern (lokal und AD), es geht um "temporäre" Gruppenmitgliedschaften usw.

 

Cursor in das Zitat stellen und mehrfach die Entertaste drücken. Zuerst kommen Leerzeilen, danach unterbrichst Du das Zitat.

 

Ok, danke auch dafür! Mein IE hat mir schlicht keinerlei Zitate angezeigt, Chrome tut es aber. Dann klappt es auch. :)

 

Viele Grüße (und viel Erfolg ;))

olc

[RobertWi 81]

Ist ein aktuelles und interessantes Thema... :)

 

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.

 

Denn "nur" das Setzen von Kennwörtern löst das Problem nicht, solange administrative Gruppenmitglieder Anmeldungen am Zielsystem durchführen können. Das sind ja nur sehr bedingt lokale Administratoren.

 

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

 

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.

 

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.

 

Da ist das Passwort- und Berechtigungskonzept ein Baustein und ich erstmal mit der Aufgabe dabei, überhaupt die Möglichkeiten zu evaluieren.

 

 

 

Ein Beispiel wäre Lieberman: http://www.liebsoft.com/Random_Password_Manager/

Was keine Empfehlung darstellt, sondern nur ein Beispiel. :)

 

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

[zahni 550]

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.