pingcastle - Ergebnisse umsetzen

[roccomarcy 20]

Okay, grad nochmal geschaut - tatsächlich steht der Wert auf 1. 

 

Das heißt für mich erstmal oben genannte LAN Manager Auth anpassen und danach Extended Protection konfigurieren, right?

[NorbertFe 1.983]

Ja korrekt. Der sollte wie MS auch verlinkt auf 5 gesetzt werden (Send NTLMv2 response only. Refuse LM & NTLM)

 

 

 

Interessant, wie man so ein vergniesgnatteltes Exchange System betreibt und sich dann jetzt per PingCastle langsam vortastet. ;)

bearbeitet 19. Juni von NorbertFe

[NilsK 2.902]

Moin,

 

vor 15 Stunden schrieb roccomarcy:

Reicht es nicht, wenn ich es einmal ändere und die Domänen-Controller replizieren sich?

 

da die wichtige Antwort hierauf noch nicht gegeben wurde: Man muss das Kennwort tatsächlich zweimal ändern, sonst ist der Vorgang nicht ausreichend wirksam. Beim krbtgt-Konto wird neben dem aktuellen Kennwort auch das vorangegangene gespeichert, damit Replikationsverzögerungen nicht zum Ausfall führen. Es funktionieren auch beide Kennwörter. Ändert man nur einmal, dann wird ein Angreifer also nicht wirksam rausgeschmissen.

 

Der nötige Abstand von 10 Stunden "plus ein bisschen" zwischen den beiden Änderungen hängt mit der Lifetime der ausgestellten Tickets zusammen. Hier könnte ein Angreifer im System "überleben", wenn die beiden Änderungen innerhalb der Lifetime vorhandener Tickets geschehen.

 

Gruß, Nils

 

[testperson 1.631]

Zum Zurücksetzen des krbtgt-Kennworts gibt es bspw. hier noch ein Script, welches das ganze "simuliert" bzw. die Voraussetzungen testet und ein Logfile schreibt: Public-AD-Scripts/Reset-KrbTgt-Password-For-RWDCs-And-RODCs.md at master · zjorz/Public-AD-Scripts · GitHub

[cj_berlin 1.289]

Da gibt es auch einen dreitägigen Kurs beim IT-Administrator-Verlag, wo solche Sachen (unter vielem anderen) aufgedröselt werden  

 

War das noch innerhalb der Forums-Richtlinien?

bearbeitet 20. Juni von cj_berlin

[testperson 1.631]

OT: Ist dieser Kurs evtl. auch als vor Ort Kurs geplant?

[cj_berlin 1.289]

vor 17 Minuten schrieb testperson:

OT: Ist dieser Kurs evtl. auch als vor Ort Kurs geplant?

Ich konnte den Verlag noch nicht davon überzeugen. Das war der ursprüngliche Vorschlag. Ich plane aber noch was anderes, ausschließlich Hands-On, das wird vor Ort sein. Muss sich aber erst manifestieren.

 

EDIT: Also vermutlich frühestens Ende des Jahres, und dann schon unter Berücksichtigung von Server 2025.

bearbeitet 20. Juni von cj_berlin

[roccomarcy 20]

Guten Morgen zusammen,

 

ich habe mit NorbertFe auf anderer Ebene Kontakt aufgenommen, um die Probleme außerhalb des Forum zu lösen. Ergebnisse kann ich nachgelagert in den Thread packen, solang von Norbert nichts dagegen spricht. Den Einwand von cj_berlin habe ich berücksichtigt und mir/uns für kommende Veranstaltung im Juli einen Slot reserviert.

 

Ich denke in der Kombination werden sich die Themen gut lösen lassen und auch das Wissen Inhouse stärken.

Gruß

[toao 1]

1 hour ago, NilsK said:

Moin,

 

 

da die wichtige Antwort hierauf noch nicht gegeben wurde: Man muss das Kennwort tatsächlich zweimal ändern, sonst ist der Vorgang nicht ausreichend wirksam. Beim krbtgt-Konto wird neben dem aktuellen Kennwort auch das vorangegangene gespeichert, damit Replikationsverzögerungen nicht zum Ausfall führen. Es funktionieren auch beide Kennwörter. Ändert man nur einmal, dann wird ein Angreifer also nicht wirksam rausgeschmissen.

 

Der nötige Abstand von 10 Stunden "plus ein bisschen" zwischen den beiden Änderungen hängt mit der Lifetime der ausgestellten Tickets zusammen. Hier könnte ein Angreifer im System "überleben", wenn die beiden Änderungen innerhalb der Lifetime vorhandener Tickets geschehen.

 

Gruß, Nils

 

 

Hallo allerseits,
 

wohl war und danke für die Ausführungen, bis auf: "Hier könnte ein Angreifer im System "überleben", wenn die beiden Änderungen innerhalb der Lifetime vorhandener Tickets geschehen." - Andersherum, je kürzer die Zeitspanne ist, desto eher wird der Angreifer "rausgekegelt". In einem Cyberattack Szenario kann dies sogar erwünscht sein, trotz der Tatsache, dass dies auch auf andere ausgestellte Tickets Auswirkungen hat, die dann ungültig werden und der (Business)-Service dahinter zum Erliegen kommt.

 

Zu ein paar Punkten der Liste,

auch wenn der TO schon mit NorbertFe sich weiter abgestimmt hat, eventuell bringt es dem einen oder anderen eine zusätzliche Sicht auf die Dinge:
 

1. Bitte sicherstellen, dass Backups & erfolgreiche Restore-Tests deines Forest vorhanden sind. Obwohl ich dies in all den Jahren nicht erlebt habe, dass etwas "schief" gelaufen ist, gäbe es in Deinem Falle von 2012 auf 2016 keine Rollback Möglichkeit. Daher würde ich dies eher beantworten mit: Likelihood, dass etwas "schief" geht: Nahezu unmöglich.

 

2. Vorab Analyse über das Log Deiner Domain Controller: Microsoft-Windows-SMBServer/Audit mit der ID 3000 durchführen und für eine Zeit lang auswerten. Best case, leer.

 

3. Bevor man dazu übergeht "Send NTLMv2 response only. Refuse LM & NTLM" einzustellen, am besten Vorab Analyse über die  Logs Deiner Domain Controller: Log Name Security, ID4776 und Ausschau halten nach "Microsoft_Authentication_Package_V1_0" . Alternativ auf Memberservern die Logs von Security, ID4624 durchforsten.

 

5. Niemals alle priviledged accounts hinzufügen, je nach Szenario sägst Du Dir den Ast ab. Mindestens 1 (besser 2) priviledged accounts (idealerweise Built-In Administrator account (nicht deaktiviert) + 1 Break Glass Account) nicht hinzufügen.

 

7. Obacht, abhängig gemäß dem Status der ACL, führt das Entfernen dazu, dass 3rd Party Solutions auf die Nase fliegen. Praxisbeispiel, einige 3rd Party Solution setzen auf die Permission "Read Account restrictions" auf, dies is inkludiert in der ACE Pre-2000 aber nicht in der ACE Authenticated Users innerhalb derselben ACL. Vorab Analyse über Domain Controller Security Logs ist hier ratsam, zum Beispiel über Securty, 4662, welche Dir genau anzeigt welche Properties versucht werden auszulesen. *Randnotiz: Je nach Historie, alter des Forests, sollte in der Pre-Windows 2000 Compatible Access die zusätzlichen Einträge "ANONYMOUS LOGON" oder "Everyone" stehen, würde ich den Fokus eher darauf legen und hier etwas rigeroser vorgehen und diese (ohne Analyse) entfernen. Aber, dies muss jeder für sich (und die Firma) selbst entscheiden :)

 

Sorry bin jetzt nicht wirklich auf die Reihenfolge und auf die Kritikalität eingegangen, hoffe dennoch das die eine oder andere Information weiterhilft und eventuell einen weiteren Denkanstoß mit sich zieht.

 

Bye,

toao

[NorbertFe 1.983]

vor 3 Minuten schrieb toao:

Andersherum, je kürzer die Zeitspanne ist, desto eher wird der Angreifer "rausgekegelt".

Genau das hat Nils geschrieben:

Zitat

Hier könnte ein Angreifer im System "überleben", wenn die beiden Änderungen innerhalb der Lifetime vorhandener Tickets geschehen

Heißt, wenn man nicht auf die Lifetime der vorhandenen Tickets Rücksicht nehmen kann/will/muss, dann kann man die Änderung im Krisenfall eben auch innerhalb weniger Sekunden ändern (je nach Umgebung mal ein paar mehr).

vor 7 Minuten schrieb toao:

Obacht, abhängig gemäß dem Status der ACL, führt das Entfernen dazu, dass 3rd Party Solutions auf die Nase fliegen. Praxisbeispiel, einige 3rd Party Solution setzen auf die Permission "Read Account restrictions" auf, dies is inkludiert in der ACE Pre-2000 aber nicht in der ACE Authenticated Users innerhalb derselben ACL.

Sieht jetzt nicht wirklich anders aus als meine Aussage:

WEnn man nicht ganz viele LDAP Abfragen stellt die bestimmte sonst nicht lesbare Attribute benötigen, kann man das relativ easy abschalten. Ich lass mich aber gern belehren.

 

Es gibt genug Praxisbeispiele, die eben wie deins dann gelten. Das geht nicht nur um das Lesen der Account restrictions, sondern bspw. in sehr viel häufigerem Umfang um das Auslesen von Mitgliedschaften der Nutzer, was eben dann auch nicht mehr funktioniert. Da dann noch abhängig welches der diversen Groupmembership Attribute ausgelesen werden muss usw. usf.

 

Dem Rest deiner Aussage stimme ich natürlich zu, wobei man dann auch das entsprechende Auditing erstmal anschalten darf und vor allem auch auswerten, was je nach Größe und Häufigkeit der Abfragen echt mühsam werden kann. :)

[toao 1]

4 minutes ago, NorbertFe said:

Genau das hat Nils geschrieben:

Heißt, wenn man nicht auf die Lifetime der vorhandenen Tickets Rücksicht nehmen kann/will/muss, dann kann man die Änderung im Krisenfall eben auch innerhalb weniger Sekunden ändern (je nach Umgebung mal ein paar mehr).

Immer wenn ich den Satz vom Nils lese, lese ich es anders raus  Dann bin ich ja beruhigt, dass Nils das genauso meinte.

Bye,

toao

[daabm 1.304]

vor 6 Stunden schrieb NorbertFe:

was je nach Größe und Häufigkeit der Abfragen echt mühsam werden kann. :)

 

Großes Wort, gelassen ausgesprochen. Wir haben eh schon Mühe mit den Sec-Eventlogs. Sind überall auf 4 GB konfiguriert, aber wir könnten genauso auch auf 100 MB setzen, hätte den gleichen Nutzen. Mit 100 MB würden sie 5 Minuten Rollover haben, mit den 4 GB sind es etwa 6 Stunden. Objekt-Auditing in AD scheidet völlig aus, das kostet zu viel (Splunk).

[cj_berlin 1.289]

6h mit 4GB für das Security Log ist doch super  

 

Objekt-Auditing direkt in Splunk zu blasen ist sicherlich selbst für ne Bank eine recht unerschwingliche Nummer, da muss man vorher Profile bilden und vorfiltern...

[v-rtc 88]

vor 10 Stunden schrieb cj_berlin:

Ich konnte den Verlag noch nicht davon überzeugen. Das war der ursprüngliche Vorschlag. Ich plane aber noch was anderes, ausschließlich Hands-On, das wird vor Ort sein. Muss sich aber erst manifestieren.

 

EDIT: Also vermutlich frühestens Ende des Jahres, und dann schon unter Berücksichtigung von Server 2025.

Hands On ist das Beste was einem Kurs passieren kann!

[daabm 1.304]

vor 26 Minuten schrieb cj_berlin:

da muss man vorher Profile bilden und vorfiltern...

 

Das macht ne andere Truppe, das läuft aus Splunk raus weiter in Graylog/QRadar. Problem für uns ist grad der Eingangskanal Splunk mit Lizensierung auf Events pro Sekunde. Aber da arbeiten wir an einer Alternative.