Kontosperrung bei Kennwortfehleingabe - Vorteile, Nachteile, Angriffe

Mitglied: DerWoWusste

DerWoWusste (Level 5) - Jetzt verbinden

12.10.2020, aktualisiert 13.10.2020, 1346 Aufrufe, 22 Kommentare, 10 Danke

Das hier untersuchte Problem ist anwendbar in allen Windowsdomänen, deren Domänenauthentifizierung allein über Kennwörter läuft.
Es ist seit vielen Jahren bekannt und doch habe ich noch keine Untersuchung gesehen, die auch ausführlich auf Gegenmaßnahmen eingeht.
Worum es geht: jeder, der schon einmal eine Domäne härten wollte, stößt früher oder später auf das Thema Kennwortrichtlinien und ebenso Kontosperrungsrichtlinien (automatische Sperrung bei wiederholter Kennwortfehleingabe).

Beispielsweise empfiehlt das BSI im IT-Grundschutz-Kompendium 2020:
Die Richtlinien für Domänen und Domänencontroller MÜSSEN sichere Einstellungen für Kennworte, Kontensperrung, Kerberos-Authentisierung, Benutzerrechte und Überwachung umfassen

Und was fehlt hierbei? Eine Beschreibung des „wie sicher muss es denn sein?“.
Aber gut, man darf davon ausgehen, dass wenn das BSI „Kontensperrung“ schon aufführt, es zumindest nicht empfehlen würde, diese in den Grundeinstellungen zu betreiben, denn das würde bedeuten, es würde gar nicht automatisch gesperrt, Kennwörter könnten beliebig häufig falsch eingegeben werden.

Und tatsächlich, man findet weiter in den Umsetzungshinweisen https://www.bsi.bund.de/DE/Themen/ITGrundschutz/ITGrundschutzKompendium/ ...
Im Folgenden werden Vorgaben für die Sicherheitseinstellungen aufgezeigt, die als Ausgangsbasis für die Sicherheitseinstellungen innerhalb einer Gruppenrichtlinie dienen können. Die angegebenen Werte müssen auf jeden Fall an die lokalen Bedingungen angepasst werden.

Kontosperrungsrichtlinien
• Kontensperrungsschwelle: 3 Ungültige Anmeldeversuche
• Kontosperrdauer: 0 (Hinweis: Konto ist gesperrt, bis Administrator Sperrung aufhebt)
• Kontosperrungszähler zurücksetzen nach: 30 Minuten

Der folgende Text soll bei der Suche nach dem besten Weg helfen.

Worin besteht nun das Problem?

Wenn ich als Admin ein Konto bei Fehleingabe automatisch sperre, ja dieses sogar gesperrt lasse, bis der Admin die Sperrung aufhebt, dann ist es möglich, dass der Gesperrte ein wenig sauer wird. Ja es ist sogar möglich, dass er sich über den Admin beschwert, denn er hat sich zum Beispiel am Wochenende extra in die Firma bewegt, knüppelt Überstunden, und hat in seinem Tran lediglich 3x das Kennwort falsch eingegeben und konnte nun nicht arbeiten und das trifft seine Arbeitsplanung hart. Naja…wenn Wochenendarbeit anberaumt ist, dann muss wohl auch ein Admin verfügbar sein für solche Fälle, aber egal, sagen wir mal, die Einstellung kann zu Unmut führen.

Das eigentliche Problem mit der Kontensperrung ist aber ein ganz anderes: ich gehe nun mal zu einem gesperrten PC, da sitzt gerade niemand, der blöde Herr Müller ist wohl eine rauchen. Nun gebe ich dreimal den Buchstaben a als Kennwort ein und schon ist Herrn Müllers Konto gesperrt. Der wird sich ärgern, ach ist das schön, das mache ich morgen gleich noch einmal! Mobbing für Arme.

Der Admin wird dann früher oder später gefragt werden, ob man da nicht was tun kann, zum Beispiel die automatische Sperrung für den Herrn Müller zumindest temporär abschalten könnte. Klar, das geht, wenn man PSOs und nicht GPOs verwendet, dann könnte man Ausnahmen definieren (mit GPOs wäre diese Einstellung zwingend global gültig, mit PSOs nicht).

Wird der Admin nun dieser Bitte nachkommen? Darf er der Bitte nachkommen? Das wird der IT-Sicherheitsbeauftragte entscheiden müssen, nicht der Admin.

Welches Risiko ist denn überhaupt da, wenn man nun eine automatische Sperrung ganz abschaltet? Nun, dann könnte jemand versuchen, Kennwörter per Brute-Force zu knacken. Ist das realistisch? Kommt da jemand anspaziert, startet sein Tool/Skript und versucht nun Müllers Kennwort zu knacken? Wie läuft das ab?

Ich spiele mal Angreifer. Zunächst einmal stelle ich fest, ob es eine Kontosperrungsrichtlinie gibt – die gibt es nicht, gut!
Dann schaue ich mir den Anzugreifenden an, wo kann der sich anmelden? Überall. Sehr, sehr gut!
Dann schaue ich mal, wie lange sein Kennwort noch gültig ist: 6 Monate, passt!
Nun mal sehen, wie lang sein Kennwort sein könnte… Minimum 8 Zeichen…hm, weniger gut. Komplex muss es auch sein… auch nicht so gut. (all diese Infos kann man per Default als jedermann auf der Kommandozeile auslesen).

Würde ein Angreifer nun sein angedachtes Bruteforcing angehen, oder nicht? Das ist nicht mit Sicherheit zu beantworten. Stattdessen möchte ich mir vorstellen, dass ich den Müller bei der Kennworteingabe beobachte. Ich sehe zwar nicht genau, was der da eintippt, aber immerhin sehe und höre ich, dass Müllers Kennwort 8 Zeichen hat und dass der Müller da zweimal Shift gedrückt hat und zwar am Anfang (großes G war das, glaube ich) und am Ende (das war wohl ein „!“). Und zwischendrin hat der Müller auf jeden Fall noch ein x und ein u getippt, das habe ich auch gesehen aber ich bin bei der Position der beiden unsicher, vielleicht war das x der vierte und u der fünfte, vielleicht aber auch der fünfte und der sechste Buchstabe… Somit bleiben noch vier Zeichen zu erraten, alles waren Kleinbuchstaben, und ebenso ist die Position der beiden bekannten mittleren Buchstaben nicht ganz klar, was den Kennwortraum noch einmal verdoppelt.

Um die Rechnung abzukürzen, ich komme bei ca. 900.000 möglichen Kennwörtern raus(/1,4 Mio, wenn auch ä,ö,ü mitgezählt werden).
Ich habe bekanntlich bis zu 6 Monate Zeit, um diese durchzuprobieren, das macht rund 5000 (/8000) Kennwörter am Tag, das ist lachhaft wenig und somit leichte Beute für einen Bruteforce-Angriff – dieser wird mit Sicherheit gelingen. Ohne auf die Art und Weise des Bruteforcings näher eingehen zu wollen, hier nur eine Hausnummer: selbst auf schwachen PCs und mit rechenschwachen Domänencontrollern sollte es möglich sein, etwa 20 Kennwörter pro Sekunde zu testen, somit kann ich an einem einzigen Arbeitstag von 8 Stunden schon mehr als eine halbe Million Kennwörter testen, spätestens nach 2(/3) Tagen hätte ich also Müllers Kennwort! Wer nun sagt "das wird aber auffallen, denn DCs loggen ja Fehlversuche", der hat Recht. Aber findet diese Auswertung regelmäßig statt? Evtl. ist das Kind da schon längst in den Brunnen gefallen.

Dass dieses Gedankenspiel nicht nur einen böswilligen Angreifer voraussetzt, sondern auch ein erfolgreiches vorangegangenes „Shouldersurfing“ (der Angreifer kann Teile des Kennwortes bei der Eingabe mitlesen) sowie eine nicht sonderlich harte Kennwortrichtlinie, ist mir klar. Dennoch halte ich das für ein sehr reales Beispiel.

Wie kann ich nun einem Angreifer dieses Bruteforcing erschweren ohne gleichzeitig eine überaus harte Kennwortrichtlinie einführen zu müssen? Na, ich setze eine automatische Sperrung bei Fehleingabe! Was ich da als Anzahl eintrage, ist ziemlich Banane, lass mich Euch mal vorrechnen, was passiert, wenn ich den Höchstwert von 999 erlaubten Versuchen bis zur Sperrung nutze. Ich stelle als Admin also ein, dass für 30 Minuten gesperrt wird, sobald das Kennwort 999 Mal falsch eingegeben wurde.

Der Bruteforcer muss also ständig Zwangspausen einlegen um nicht an diese Schwelle zu stoßen. Wie lang ist diese Pause? Auch das ist konfigurierbar. Lass uns dort mal ein einstellen: Kontosperrungszähler zurücksetzen nach: 1440 Minuten (=1 Tag).
Das bedeutet für den Bruteforcer, dass er nur ca. 1000 Kennwörter (genauer: maximal 998) pro Tag testen kann, womit er also für die 900.000 (/1.4 Mio) Möglichkeiten 900 (/1400) Tage zu tun hätte – bis dahin ist das Kennwort längst mehrfach geändert worden.

Was aber wäre, wenn ein Programm, das Müller nutzt, sein Kennwort gespeichert hat und dieser Müller ändert sein Kennwort? Dann wird der Automatismus im Programm eventuell so oft versuchen, das alte Kennwort einzugeben, bis das Konto gesperrt ist (Automatismen können sehr dumm sein…)! Er wäre dann auf einen Admin angewiesen, um ihn zu entsperren, da er nicht 24 Stunden warten möchte, um diese wichtige Wochenendarbeit zu erledigen. Hm, vielleicht setzen wir diese Sperrdauer doch eher so, wie das BSI vorschlägt auf 30 Minuten. Auch bei „Kontosperrungszähler zurücksetzen nach…“ folgen wir dem BSI und setzen es ebenso auf 30 Minuten. Wie viele Kennwörter kann der Bruteforcer nun täglich in 8 Stunden durchdaddeln? Nun, alle 30 Minuten 1000 Kennwörter, das macht (8:00/8:30/9:00/…15:30/16:00) rund 17.000 pro Tag. Bekomme ich damit die 900.000 Möglichkeiten in 6 Monaten durchgetestet? Leicht und lässig schaffe ich das in 2-3 Monaten (3-4 Monate bei 1,4 Mio).

Doch Moment, hat das BSI nicht vorgeschlagen, bereits nach 3 (!) Fehlversuchen zu sperren? Dann hätte ich also pro Tag nur 3, nein 2x17=34 Versuche und würde die 900.000 Kombinationen selbst in 50 Jahren Dienstzeit nicht schaffen .

Na sauber, das ist doch was. Also hilft die automatische Sperrung gegen Bruteforcing unter Umständen sehr effektiv!
Die beiden Stellschrauben "Lockout Observation Window" (beeinflusst die Dauer der Zwangspause) und die Anzahl der zugelassenen Fehlversuche ("Lockout Threshold") spielen also zusammen und müssen nur passend austariert werden, damit es unwahrscheinlich wird, dass sich selbst bei arg verkleinertem Kennwortraum noch ein Bruteforcing lohnt. Ohne auf Vorschriften zu achten sagt mir mein Bauchgefühl, dass 100 Fehlversuche kombiniert mit einem Observation Window von einem Tag passen sollte - dann dauert das Bruteforcing von 1 Mio Kennwörtern nämlich fast satte 30 Jahre, niemand ist genervt durch zu schnelles Sperren und ein manuelles "Mobbingsperren" wird auch sehr erschwert.

Fazit: ich denke nicht, dass Angreifer so vorgehen, nein. Das ist hier Theorie und die Theorie ist zwar denkbar, aber Angreifer werden wohl eher andere Wege versuchen, um Identitäten anderer Nutzer zu kapern. Dennoch ist eine automatische Kontensperrung definitiv eine Überlegung wert und evtl. sogar vorgeschrieben!
Ok, das war bis hierher tatsächlich alles Vorrede und Vorüberlegung!

Ich gehe des Weiteren von einer Firma aus, die den BSI-Empfehlungen folgt und eine automatische Sperrung nach 3 Fehlversuchen eingestellt hat und den Zähler nach 30 Minuten zurücksetzt und dann sogar dauerhaft sperrt, bis der Admin die Sperre aufhebt.
Ich wechsele jetzt die Rolle von einem Bruteforcer hin zu einem ganz tollen Spaßvogel. Einem Spaßvogel, der ein wenig skripten kann und sich ein wenig mit dem Active Directory auskennt, also zumindest weiß, wie man die Einstellungen die da herrschen, ausliest. Ich schreibe also ein Skript (oder kopiere mir eins aus dem Internet), was Folgendes macht:

1 es liest alle Nutzerkontennamen der Domäne aus, die aktive Konten haben und sich überall anmelden dürfen
2 es gibt für all diese Konten 3x das falsche Kennwort „a“ ein.

Das Skript parke ich auf einem USB-Stick und gehe mit diesem zum nächstbesten PC, den ich ungesperrt vorfinde und starte es.
Was passiert dann? Bei einer Firma mit sagen wir mal 200 aktiven AD-Nutzern sind diese in ca. 30 Sekunden (!) allesamt gesperrt. Das umfasst auch alle Dienstekonten und alle Admins, die diese Sperrung wieder aufheben könnten. Moment, alle Gallier Admins? Nein, zum Glück gibt es noch den eingebauten Domänenadmin „Administrator“, der nicht gesperrt werden kann! Kurz geprüft, lässt das BSI überhaupt zu, dass wir diesen aktiviert belassen? Ja, tut es, puh… sonst sähe es nun finster aus.

Auf jeden Fall wird nach kurzer Zeit ein kollektiver Aufschrei durch die Firma gehen, soviel ist mal sicher. Den wird der Admin nicht überhören.
Wenn der diensthabende Admin auf Draht ist, hat er sogar das Kennwort dieses eingebauten Kontos am Start (Umschlag im Safe), meldet sich damit an, erzeugt eine Userliste und lässt ebenso gegen diese ein Skript zur Entsperrung laufen und nach weniger als 10 Sekunden Laufzeit ist der Spuk vorbei. Wenn der Admin auf Draht ist, kann er nun sogar sehen, dass der „Angriff“ von IP-Adresse x.x.x.x ausging und wird sich mal ansehen welcher Rechner das ist, wo der steht und wer da sitzt… mittlerweile ist der Angreifer natürlich pfeifend von dannen und der arme Kerl, der seinen Rechner ungesperrt hinterlassen hat, wird sich ein paar ernste Fragen anhören müssen.

Welcher Schaden ist entstanden?

Alles stand eine Weile still, evtl. sind sogar Dienste, deren Konten gesperrt wurden abgestürzt und müssen nun erst einmal gesucht und wieder neu gestartet werden.
Zudem hat die Belegschaft nicht unbedingt laut gelacht über diese Zwangspause und wird natürlich auch die Skills des Admins in Frage stellen.
Was wäre denn gewesen, wenn jemand das Skript gestartet hätte, wenn der Admin krank ist und ohne Vertretung (Vertreter existiert auf dem Papier, ist aber gerade zur Mittagspause, oder er ist da, weiß aber nicht, was zu tun ist)? Dann würden satte 30 Minuten vergehen, bis sich die Konten automatisch wieder entsperren. Wenn der Angreifer besonders lustig sein will, sperrt er natürlich am Schluss auch das Konto des Nutzers, der das Skript startet und danach (per Kommando) noch dessen Bildschirm, fügt dem Skript einen Timeout von 30 Minuten hinzu und lässt es dann wiederholt als Schleife laufen. Autsch, der Ausfall wird dauern!
Es wäre sogar denkbar, diesen Angriff als Nebelkerze nebenher zu einem Angriff gegen die Fileserver zu starten - ein bißchen Verwirrung stiften und vom eigentlichen ablenken!

Ok, soweit zum Angriff, kommen wir nun zur Gegenwehr.

Was ist hier schiefgelaufen, abgesehen von dem eher menschlichen Umstand, dass ein Rechner mal nicht gesperrt war?

1. Der Rechner war nicht nur ungesperrt, sondern der Angreifer war sich sicher, dass er ein wenig Zeit für den Angriff hat, da er die Gewohnheiten der missbrauchten Nutzer kennt!
Abhilfe: wenn die PCs von einigen wirklich regelmäßig nicht gesperrt werden, so muss das angesprochen werden! Betriebsvereinbarungen inklusive Sanktionen könnten helfen!

2. Die Parameter, wann sich Konten sperren und wann der Counter zurückgesetzt wird, waren zu hart eingestellt.
Abhilfe: diese „Härtungen“ sollten überdacht werden (siehe Vorüberlegungen und Beispiele weiter oben). MUSS der Betrieb hier wirklich den Vorschlägen des BSIs folgen?

3. Eine Softwarekomponente (wie auch immer gearteter Wächter oder Appliance) hätte die massenhaften Fehlanmeldungen erkennen können und hätte je nach Einstellung den Netzwerkverkehr zwischen diesem Gerät und den DCs frühzeitig kappen können.
Abhilfe: Es gibt ja Intrusion-Detection-Systeme, die so konfiguriert werden können, dass sie dieses oder jenes Blocken. Testet doch mal aus, ob Eure ggf. vorhandenen Systeme diese Art Angriff erkennen, indem Ihr einfach mal so viele Testkonten erzeugt wie ihr Nutzer habt und diese dann automatisiert „angreift“. Erkennen Sie das nicht, prüft, ob man das schärfer einstellen kann, falls es überhaupt geht.

4. Der Angreifer war in der Lage, auf dem PC ein Skript zu starten
Abhilfe: Das zu verbieten, ist gar nicht so leicht. Klar, man kann recht einfach die Nutzung von USB-Sticks verbieten und man kann auch per Applocker die Nutzung von Skripts verbieten, aber beides führt wieder zu dauerhaft vermindertem Komfort.

5. Der Angreifer konnte dieses Skript auf einfache Weise erstellen (Kontennamen konnten ausgelesen werden)
Abhilfe: Dass es ohne weiteres möglich ist, diese Infos auszulesen, heißt im Umkehrschluss nicht, dass es auch einfach ist, diese Infos unlesbar zu machen! Da sich einige Mechanismen in Programmen hierauf verlassen, wird ein Abschalten der Lesbarkeit dieser Details zwangsläufig Nebeneffekte haben. Hier ist Vorsicht geboten.

6. Es gab viele Konten, die sich überall anmelden können (Achtung, das ist der Default!)
Abhilfe: Dieser Punkt ist sehr interessant, wie ich finde. Warum sollte sich Lieschen Müller überall anmelden können? Ja, für Großraumbüros (evtl. setzt sich jeder fast täglich an einen anderen Platz und PC) ist das sinnvoll, aber in sehr vielen Unternehmensumgebungen ist das überflüssig! Kann man die Zahl beschränken, so wird der Angriff schwerer. Kann man die Zahl auf einen festen Mitarbeiter-PC reduzieren, so wird der Angriff sogar unmöglich! Diese Einschränkung der Anmeldeberechtigungen nimmt man direkt im Userobjekt im AD vor – man verwendet dazu NICHT die GPOs „Lokale Anmeldung zulassen/verweigern“ – diese helfen nicht!
capture - Klicke auf das Bild, um es zu vergrößern
Was man in jedem Fall machen MUSS: reduziert die Workstations, wo sich die Admins und die Dienstekonten anmelden können auf ein Minimum. Man braucht keine globalen Admins, glaubt mir das (wir nutzen keine!). Auf diese Weise können diese wichtigen Konten schon mal nicht ohne Weiteres angegriffen werden, Restrisiken siehe 7.

7. Der angreifende unbekannte PC durfte mit den DCs kommunizieren
Wenn jemand sagt, „bei uns werden die PCs eher nie ungesperrt sein, da sie sich nach spätestens 2 Minuten Leerlauf von alleine sperren“, der übersieht etwas Wichtiges: man könnte den Angriff auch von seinem eigenen PC aus durchführen. Denkt mal an eine Schule, an einen Informatikraum. Da zieht jemand sowas durch und behauptet im Nachhinein, er wäre das gar nicht gewesen, irgendein anderer muss das wohl bei ihm eingetippt haben in der Zeit, wo er bei der Gruppenarbeit gerade zum Nebenmann geschaut hat. Wird der nun bestraft, oder nicht?
Oder was wäre denn, wenn ich meinen Mini-PC mitbringe, und den kurzzeitig an das Netzwerkkabel meines Büro-PCs anstecke, nur so für 30 Sekunden, langt doch. Da die Mac-Adresse gar nicht zu meinem PC passt und ich den Mini-PC schnell wieder verschwinden lassen kann, wird niemand sicher sagen können, woher der Angriff kam, oder?
Das Problem ist nämlich: der angreifende PC muss dazu gar nicht in der Domäne sein. Wenn wir eingestellt haben, dass sich alle Nutzer von überall anmelden können (nochmal: das ist der Default!), dann kann ich auch einen Nicht-Domänen-PC für den Angriff nutzen! Ebenso könnte ich meinen BYOD-PC nehmen und ihn so nennen, wie eine für das anzugreifende Konto erlaubte Workstation.
Abhilfe: Dieser Punkt ist sehr einfach abgebacken: Firewalls, die mit Authentifizierung arbeiten (zum Beispiel die Windowsfirewall, wenn man gesicherte Regeln mit Kerberos-Authentifizierung benutzt), können den Datenverkehr von unbekannten Rechnern zum DC hin von vornherein verbieten.
Siehe https://medium.com/@cryps1s/endpoint-isolation-with-the-windows-firewall ...


Fazit: Ich denke, man muss sich mit diesem Problem auseinandersetzen. Die Ausrede „das ist in den letzten 10 Jahren auch nie vorgekommen“ zieht im Fall der Fälle leider nicht. Die Keule rauszuholen und die automatische Kontensperrung ganz zu deaktivieren, halte ich persönlich für gefährlich. Die beste Gegenmaßnahme ist meiner Ansicht nach 6. – Logonworkstations beschränken und evtl. 7., die Firewall mit Authentifizierung. Auch sollte man – sofern man darf – die Anzahl der erlaubten Fehlversuche überdenken und evtl. stark erhöhen. Dies verlangsamt auch den Angriff.
PS: das ist meine Meinung und nicht etwa der Weisheit letzter Schluss. Ich habe jedoch versucht, gründlich zu argumentieren. Wenn jemand nun Fragen dazu hat, oder Sachen in Zweifel zieht, oder nur seinen Senf dazugeben will, oder, oder, oder, dann nehmt Euch bitte Zeit, zumindest vorher den Beitrag gründlich zu lesen und verzichtet auf Schnellschüsse.
Mitglied: Dr.Bit
12.10.2020 um 14:03 Uhr
Sehr schön ausgearbeitet, und das in der kurzen Zeit von allgemeiner Frage bis zum Resultat. Respekt.
Ich pflichte Dir vollkommen bei. Allerdings ist eine solche Härtung im Angang auch eine Menge Arbeit.

🖖
Bitte warten ..
Mitglied: emeriks
12.10.2020, aktualisiert um 14:27 Uhr
Hi DWW,
klasse ausgearbeitet!
Das werde ich mit Sicherheit mal mit meinen Kollegen diskutieren.

Wir folgen bei uns im Großen und Ganzen den Empfehlungen des BSI. D.h. unserer DSB's tun das und hinterfragen das bei unserer Leitungsebene solange, bis irgendeine Leiterplatte an uns weitergibt: "Macht mal!"

Ich persönlich bin auch der Meinung, dass eine automatische Kontosperrung sein muss, aus genau jenen Gründen, welche Du auch genannt hast.

Wir loggen mit, wann und von wo aus ein Konto gesperrt wird. Gegen die von Dir genannten "Spiele" sind wir zwar erstmal anfällig. Aber wenn das jemand wiederholt machen sollte, dann hoffen wir, dem mit den Logs und den daraus folgend genehmigten weiterführenden detektivischen Maßnahmen auf die Schliche zu kommen. Die arbeitsrechtlichen Konsequenzen erwarte ich dann einfach von unserem AG. Wenn nicht, dann weiß ich auch nicht.

E.
Bitte warten ..
Mitglied: Dr.Bit
12.10.2020 um 14:42 Uhr
Zitat von emeriks:


Die arbeitsrechtlichen Konsequenzen erwarte ich dann einfach von unserem AG. Wenn nicht, dann weiß ich auch nicht.

Arbeitsrechliche Konsequenzen kommen spätestens dann nicht, wenn es ein "Kumpel" vom Chef ist, und wenn Andere das dann mitbekommen ist sowieso vorbei. Man muß die Geschäftsleitung abholen und denen eindringlich klar machen, wie wichtig das ist. Hierzu ist DWW´s Ausarbeitung auch sehr gut geeignet. Gleich ausdrucken und zu den Akten nehmen und dann alle paar Wochen beim Chef aufschlagen und ihn/sie damit nerven.

🖖
Bitte warten ..
Mitglied: maretz
12.10.2020 um 14:48 Uhr
Das man sich mit dem Problem auseinandersetzen muss - gar keine Frage. Allerdings gehe ich dabei sogar noch nen Schritt weiter und würde sagen das die LÖSUNG eben auch passen muss (und das is was natürlich bei dem zitierten BSI-Part nich so wirklich passt). Denn einfach nen Konto zu sperren und gesperrt zu lassen dann kannst du in mancher Firma auch einen Kollegen nur zum Freischalten einstellen - insbeondere wenn eben Accounts auch von aussen angepackt werden könnten (z.B. Mail-Accounts) die dann eine Sperre des gesamten Kontos mitziehen...

Weiterhin würde ich halt schauen - wenn es Windows hergibt -> z.B. HPs iLO macht es da recht schön (aus MEINER Sicht): 1x falsch eingegeben -> kein Problem... 2x falsch eingegeben: 10 Sek verzögerung... 3x dann 30 glaub ich,... Das ist aus meiner Sicht immer noch der beste Weg da es keine Sperrung braucht, wenn du irgendwann bei 5-10 Min Verzögerung angekommen bist ist jedes Script nutzlos, ein Benutzer kann sich aber in der Zeit (wenn er/sie wirklich soviele Fehler hatte) nen Kaffee zum Nachdenken holen. Denn auch das gibt es ja das man einfach Nervös wird und es einem in dem Fall einfach nich einfällt - vorzugsweise z.B. die PIN der Bankkarte wenn man grad kein Bargeld dabei hat und die Schlange hinter einem auch schon lang genug is... Andersrum kann ich aber eben auch bei Servern ggf. die Sperrung schon nach 2-3 Fehlversuchen machen und gleich mal nen Tag lang sperren (das reicht auch um jedes Script Sinnlos werden zu lassen) - grad wenn man eben sich per SSH-Key o.ä. anmeldet. So hat man als Benutzer immer noch das "Fallback" das man das Passwort nutzen kann (z.B. Fremder Rechner) ABER eben auch die Sicherheit das es nich durch "Erraten" geknackt wird. Denn selbst nen 4-Zeichen-Passwort würde da schon Monate für brauchen...

Weiterhin vergessen - aus meiner Sicht - die ganzen Richtlinien auch immer den menschlichen Faktor. Was passiert denn wenn ich für den Server X oder das Programm Y nur einmal im Monat das Passwort brauche (z.B. Abrechnungsprogramme) aber dann eben auch recht schnell gesperrt werde? Ich würde behaupten das in den meisten Fällen plötzlich das Kennwort am Monitor, unterm Keyboard oder wenns ganz Kreativ is in der Schreibtischschublade liegt und das die Sicherheit eigentlich sogar deutlich drunter leidet. Klar - das Kennwort wird sehr schnell gesperrt bei Fehlversuchen, schön. ABER ich erhöhe damit das Risiko das ein potentieller Angreifer einfach nur in der Abteilung anruft und fragt (wenn die Firma gross genug ist). Wenn man dann in der Buchhaltung anruft und sagt "Sorry, ich bin Kollege xyz vom Standort abc... ich hab mich schon 2x falsch angemeldet, bevor ich jetzt wieder gesperrt werde, kannst mir kurz das Passwort noch mal sagen" - und die Chance is umso höher umso mehr Kollegen die "nervige Sperrung" schon selbst erlebt haben... (sozusagen die digitale Version von "kannst mir mal schnell die Tür aufhalten" wenn man grad nen grossen Karton in der Hand hat und in nen Gebäude will...). MUSS nich klappen, aber die Chancen sind umso höher wenn die Mitarbeiter selbst oft genug in der "nervigen Situation" waren...
Bitte warten ..
Mitglied: emeriks
12.10.2020 um 14:49 Uhr
Zitat von Dr.Bit:
Arbeitsrechliche Konsequenzen kommen spätestens dann nicht, wenn es ein "Kumpel" vom Chef ist, und wenn Andere das dann mitbekommen ist sowieso vorbei.
Das ist bei uns nicht zu erwarten. Dafür sind wir "nicht klein genug".
Bitte warten ..
Mitglied: Dr.Bit
12.10.2020 um 15:03 Uhr
Zitat von emeriks:

Zitat von Dr.Bit:
Arbeitsrechliche Konsequenzen kommen spätestens dann nicht, wenn es ein "Kumpel" vom Chef ist, und wenn Andere das dann mitbekommen ist sowieso vorbei.
Das ist bei uns nicht zu erwarten. Dafür sind wir "nicht klein genug".
Wir eigentlich auch nicht >650. Auf der obersten Etage gibt es aber trotzdem immer "Klüngeleien".

🖖
Bitte warten ..
Mitglied: emeriks
12.10.2020 um 15:06 Uhr
Zitat von Dr.Bit:
Auf der obersten Etage gibt es aber trotzdem immer "Klüngeleien".
Aber sind da die "Spaßvögel" zu vermuten, welche die Firma lahmlegen?
Bitte warten ..
Mitglied: DerWoWusste
12.10.2020 um 15:09 Uhr
@maretz
Du schreibst
Weiterhin würde ich halt schauen - wenn es Windows hergibt -> z.B. HPs iLO macht es da recht schön (aus MEINER Sicht): 1x falsch eingegeben -> kein Problem... 2x falsch eingegeben: 10 Sek verzögerung... 3x dann 30 glaub ich,... Das ist aus meiner Sicht immer noch der beste Weg ...
Ja, das wäre sehr schön, aber Windows gibt das nicht her. An der Anmeldemaske (interaktiv) ja, auf der Kommandozeile: nein.
Wenn Du einen Weg findest, es einer Windowsdomäne per Zusatzsoftware beizubringen, sag Bescheid.
Bitte warten ..
Mitglied: radiogugu
12.10.2020 um 15:26 Uhr
Hallo und Hut ab.

Kurz und bündig das unheimlich komplexe Thema heruntergebrochen mit an der Realität angelehnten Beispiel-Szenarien.

Wir haben hier einen externen DSB der es ziemlich genau nimmt und wenn ich nachfrage: "wird das bei Ihnen auch so gehandhabt, wie Sie das fordern?", gibt es immer eine zu lange Pause, als dass ich ein "Ja" akzeptieren würde.

Die Grundeinstellungen für die Kennwortrichtlinien und die Sperrung der Konten haben wir so eingestellt, wie vom BSI "vorgeschlagen".
damit kommen wir super zurecht und das Gemurre in der Belegschaft ist weitesgehend verstummt.

Mit dieser Veranschaulichung kann auch jeder Laie dem Thema Sicherheit im Unternehmen eine ganze Menge mehr Gewicht zusprechen.

Danke für die Gedanken und deren verständlicher Niederschrift

Gruß
Radiogugu
Bitte warten ..
Mitglied: beidermachtvongreyscull
12.10.2020 um 20:32 Uhr
Schöner Artikel.

Ich fühle mich dahingehend bestätigt, dass Du ohne eine erfolgreiche Authentifizierung nicht an die Kontenliste herankommst.

Das erscheint mir als der einzige kritische Sicherheitspunkt, der die automatische Kontensperrung mit einem U9525-Effekt versieht.

Zur Erklärung: Nach der WTC-Katastrophe wurden Cockpittüren gepanzert. Auf dem Flug U9525 verhinderte u.a. eine aufbruchsichere Tür dieser Art, dass der mental intakte Pilot zurück ins Cockpit konnte.

Bei unserem überschaubaren Laden ist sehr schnell auszumachen, wenn jemand absichtlich so etwas tun würde.

Insofern bleibe ich meine Linie treu und belasse die Kontosperrungen nach 2 Fehlversuchen.
Bitte warten ..
Mitglied: TK1987
13.10.2020, aktualisiert um 16:52 Uhr
Moin,

schöne Arbeit.

Zitat von DerWoWusste:
Andererseits schreiben sie auch im selben GS-Kompendium:
Bei erfolglosen Anmeldeversuchen SOLLTE das System keinen Hinweis darauf geben, ob Passwort oder Benutzerkennung falsch sind.

Aha… sollen wir nun sperren, oder nicht? Wenn es nicht erkennbar sein „soll“, dass jemand ein Kennwort falsch eingegeben hat, dann kann man wohl kaum fordern („MUSS“), dass gesperrt wird, denn eine Sperrung zeigt sich dem Benutzer an der Anmeldemaske klipp und klar!
Den Satz kann man allerdings auch anders interpretieren: Es soll keine Differenzierung geben, welche der beiden Eingaben falsch ist - der Benutzername, oder das Kennwort.
Das ich eine Falscheingabe getätigt habe, ist ja so oder so immer ersichtlich - alleine schon durch die Tatsache, dass ich nicht eingeloggt werde.

Als zusätzliche Maßnahme gegen Bruteforce gibt es ja ergänzend auch noch die Möglichkeit, anzugeben, innerhalb welchen Zeitraums Fehlversuche auftreten dürfen. Wenn z.B. innerhalb von 5 Sekunden das Passwort 10x mal falsch eingegeben wurde, kann das ganz sicher kein Benutzer versehentlich getan haben.

Gruß Thomas
Bitte warten ..
Mitglied: DerWoWusste
13.10.2020 um 19:52 Uhr
Moin.

Es soll keine Differenzierung geben, welche der beiden Eingaben falsch ist
Da wirst Du Recht haben. Muss ich mal korrigieren.
gegen Bruteforce gibt es ja ergänzend auch noch die Möglichkeit...
Auf das Lockout Observation Window gehe ich ja ein. Das lies nochmal durch, es ist nicht das, was Du denkst. Es ist nicht der Zeitraum, in dem Fehlversuche auftreten dürfen, sondern der Zeitraum, nach dem der Fehlerzähler zurückgesetzt wird auf Null.
Bitte warten ..
Mitglied: TK1987
13.10.2020 um 20:13 Uhr
Zitat von DerWoWusste:
Auf das Lockout Observation Window gehe ich ja ein. Das lies nochmal durch, es ist nicht das, was Du denkst. Es ist nicht der Zeitraum, in dem Fehlversuche auftreten dürfen, sondern der Zeitraum, nach dem der Fehlerzähler zurückgesetzt wird auf Null.
Hab ich schon so verstanden, deswegen sagte ich ja auch ergänzend gibt es eben auch noch die von mir beschriebene Methode, um Bruteforce-Angriffe erkennen und verhindern (oder zumindest ausbremsen) zu können.
Bitte warten ..
Mitglied: DerWoWusste
13.10.2020 um 20:24 Uhr
Dann beschreib bitte, wovon du sprichst, ich kann nicht folgen.
Bitte warten ..
Mitglied: TK1987
14.10.2020 um 08:17 Uhr
Ich meine das genau so wie ich es ob beschrieben habe.

Zum Beispiel: Ein kleines Powershellscript, welches in geregelten Abständen die Protokolldatei ausliest und die fehlerhaften Loginversuchen auswertet.
Häuft sich eine Falschanmeldung eines Benutzers, wird geprüft, in welchem Zeitintervall ist das geschehen. Ist der Intervall zu kurz, um von Menschenhand getippt worden zu sein, hat wohl jemand versucht das Passwort zu knacken -> Dauerhafte Kontosperrung bis zur Klärung, Mitteilung an Administratoren über den Vorgang usw.

Das Ganze natürlich zusätzlich zu Lockout Observation Window.
Bitte warten ..
Mitglied: DerWoWusste
14.10.2020 um 08:21 Uhr
Aha. Und womit setzt du das um?
Bitte warten ..
Mitglied: TK1987
14.10.2020 um 08:35 Uhr
Was meinst du damit? Scheduled Task der alle Nase lang anläuft.
Bitte warten ..
Mitglied: DerWoWusste
14.10.2020 um 08:55 Uhr
Ich fürchte, das ist per Task so nicht umsetzbar. Versuch's mal, der DC wird sein Log gar nicht so schnell filtern lassen, wie ich Dir die Konten sperre.
Ich habe mir das schon angesehen,
Bitte warten ..
Mitglied: NetzwerkDude
19.10.2020, aktualisiert um 10:05 Uhr
Schöner Artikel

Ach ja: Bei den Kontosperrungsrichtlinien nicht vergessen das nur der original Domain Administrator mit der SID S-1-5-21domain-500 nie gesperrt wird.
Falls man also den deaktiviert hat, und auf alle anderen Accounts Domainweit Kontosperrichtlienen angewendet hat: Besteht die Gefahr das einem alle accounts gesperrt werden falls ein scherzkeks alle accounts bruteforced
Bitte warten ..
Mitglied: DerWoWusste
19.10.2020 um 10:11 Uhr
Jou, so steht es bereits im Artikel.
Bitte warten ..
Mitglied: NetzwerkDude
19.10.2020 um 10:20 Uhr
Wollte ich nur nochmal anmerken, nicht das jemand es ohne auto-reaktivierung einrichtet und dann auch alle administrativen accounts gesperrt sind
Bitte warten ..
Mitglied: DerWoWusste
19.10.2020, aktualisiert um 10:25 Uhr
Auto-Reaktivierung kann man bei dem nicht abschalten. Aber man könnte das Konto selbst deaktiviert haben, deshalb habe ich es schon angemerkt. Ebenso habe ich angemerkt, wie man die anderen Domänenadmins davor bewahrt, von diesem Scherz betroffen zu werden.
Bitte warten ..
Heiß diskutierte Inhalte
Windows Server
Hyper-V Server vs Datacenter?
holliknolliFrageWindows Server26 Kommentare

Hallo, hat jemand Erfahrung mit dem - kostenlosen - Hyper-V-Server? Ich meine, warum teure Lizenzen für Datacenter zahlen, wenn ...

LAN, WAN, Wireless
Spanning Tree Probleme
gelöst predator66FrageLAN, WAN, Wireless12 Kommentare

Hallo, wir haben hier eigenartige Spanningtree Probleme, die wir zur Zeit nicht gelöst bekommen: New Root Port MAC ist ...

Notebook & Zubehör
Business Support HP, Dell, Lenovo etc
fuzzyLogicFrageNotebook & Zubehör10 Kommentare

Moin, ich arbeite derzeit fast ausschließlich mit HP und frage mich wie es auf Support Baustelle bei anderen Herstellern ...

Exchange Server
Zustellbestätigung deaktivieren
defiant01FrageExchange Server10 Kommentare

Hallo, ich stehe vor der Aufgabe bei einem Postfach die Zustellbestätigung für eingehende Mails zu deaktivieren. Der User geht ...

E-Mail
Ticketsystem mit mailflow
CraftdorFrageE-Mail8 Kommentare

Hallo, Ich bin auf der Suche nach einem Ticketsystem das am besten Freeware ist und einfach nur eine Ankommende ...

Netzwerkgrundlagen
PfSense Virtuele IP mit NAT auf eine IP im VLAN90 zum VLAN30
OIOOIOOIOIIOOOIIOIIOIOOOFrageNetzwerkgrundlagen8 Kommentare

Guten Tag, ich stehe hier mit einer neuen Herausforderung. Hab ein Internetradio, welches jedoch nur mit eine App gesteuert ...

Ähnliche Inhalte
Erkennung und -Abwehr

"Angriff auf unseren Shopserver" vom Mikrotik Shop

LochkartenstanzerInformationErkennung und -Abwehr11 Kommentare

Moin, kam gerade eine Email fmsweb, daß der mikrotik-shop gehackt worden wäre. und sie erpreßt würden: wir möchten Sie ...

Erkennung und -Abwehr

Ccleaner-Angriff war nur auf große Unternehmen gemünzt

LochkartenstanzerInformationErkennung und -Abwehr10 Kommentare

Wenn man dem Bericht glauben darf, sind die "kleinen" uninteressant gewesen. Aber wenn so en Angrff erfolgreich in großen ...

Informationsdienste

Trump vs Twitter - Angriff auf die Meinungsfreiheit?

FrankInformationInformationsdienste6 Kommentare

Trump nutzt Twitter rege. Nach Hinweisen auf Falschbehauptungen drohte er dem Dienst. Was das bedeutet und die Konsequenzen dazu ...

Sicherheit

BlueBorne: Neuer Bluetooth Angriff auf Millionen von Geräten

HenereInformationSicherheit1 Kommentar

Dank einer aktuellen Sicherheitslücke im Bluetooth-Protokolls unter Android, Linux, macOS und Windows können Millionen von Geräten über das Funkprotokoll ...

LAN, WAN, Wireless

WPA2 und WLAN-Sicherheit: Direkter Angriff auf WLAN-Router

magicteddyInformationLAN, WAN, Wireless

Siehe Bericht auf Heise, WPA2 und WLAN-Sicherheit: Direkter Angriff auf WLAN-Router Laut Bericht wurde eine direkte Angriffsmöglichkeit auf verwundbare ...

Verschlüsselung & Zertifikate

19 Jahre alter Angriff auf TLS funktioniert immer noch

BassFishFoxInformationVerschlüsselung & Zertifikate1 Kommentar

Interessant zu lesen. Der Bleichenbacher-Angriff gilt unter Kryptographen als Klassiker, trotzdem funktioniert er oft noch. Wie wir herausgefunden haben, ...

Berechtigungs- und IdentitätsmanagementBerechtigungs- und IdentitätsmanagementWebdienste und -serverWebdienste und -serverDatenbankenDatenbankenMonitoring & SupportMonitoring & SupportHybrid CloudHybrid CloudSmall Business ITSmall Business IT