Gründe, die gegen eine Kontensperrung nach x falschen Kennworteingaben sprechen

Moin...

Ist aber kein Grund es abzuschalten...hätte ja auch was anderes sein können...Bruteforce und wenn das kennwort dann eben Hallo123! statt Hallo123 heisst, dann kommt man irgendwann drauf

Ja hatten wir.

Weil es den Benutzern nicht wirklich immer moeglich war richtig zu tippen.
Ist mittlerweile Geschichte da W10 etwas andere Moeglichkeiten bietet.

BFF

N'Abend.

Doch - deswegen isses ja abgeschaltet. Spätestens, wenn man nen Exchange öffentlich zugänglich hat (und keinen Kemp o.ä. davor betreibt), ist das ein prima Ziel für nen DDoS-Angriff. Kann natürlich auch jeder Praktikant von intern per PowerShell für nen DDoS nutzen etc.

Das Abschalten sollte aber nur dort geschehen, wo andere Sicherheitskriterien konsequent durchgesetzt werden wie z.B. Passwortlänge > 12 Zeichen, entsprechendes Monitoring auf Datenabfluss etc. Andernfalls ist das Blockieren nach x falschen Versuchen das "last resort", um größeres Unheil zu verhindern. "Exoten", wie etwa Lösungen, die nach ner falschen Kennworteingabe n Sekunden verzögern, sind natürlich auch nützlich, ich hab' sowas aber in >20 Jahren in der IT erst zwei Mal live in Betrieb gesehen.

Die Frage nach dem "Warum abschalten" ist glaub' ich recht einfach zu beantworten. Der Rattenschwanz an Möglichkeiten und sonstigen Konfigurationen füllt aber ganze Vortragswochen....

Cheers,
jsysde

hatte das mal, kleine Klitsche, Sicherheitskritischer Bereich - UTM ausgefallen, dachten erst Hitze oder so, dabei hat die irgendwann gesagt, ne, will nicht mehr...ging einfach nix mehr. Und jetzt sag ich dir, das war gut, egal was der Unternehmenskunde dir sagt, lieber, du sagst, die Pfeiffe hat sich 5 mal vertippt und wenn du dafür 1000€ abrechnest ist der Unternehmenskunde immer noch besser dran, als wenn das ganze Netz Ihm um die Ohren fliegt. Die Partnerfirma, ca 150Mio Umsatz sehr gute Gewinnzahlen (kannst von träumen in dem Umsatzsegment) war für 2 Wochen tot, weil Sie da durchkamen und alles "mitgenommen" haben...

Also, JA, besser bissl ärger, weil Massenlockout (was ich auch eher ausschliessen würde - weil viel zu auffällig!), als 2 Wochen komplett tot und alles neu...Kannst ja auch mal rechnen, 150Mio /52 Wochen...die Attacke hat nur durch entgangenen Gewinn die über eine 1Mio gekostet. Waren aber wohl auch nicht so gut ausgestattet. (die dort stehende UTM war für den Normalfall gut gesized) Aber besser dicht machen als dann alles (oder etwas zu viel) rein lassen...

JA ist deaktiviert, dank WIndows 10 Enterprise Hello und YubiKey Einsatz ist das Passwort eh obsolet geworden.

Hallo,

Wenn ein Benutzer 3-5 mal nicht in der Lage ist, sein Passwort richtig einzutippen, dann hat er im System nichts zu suchen!

Sicherlich gibt es dann wieder die Tante aus der Buchhaltung die nervt, aber das überlebt man..

Grüße an Dich,

ich hatte es mal in Erwägung gezogen, bleibe aber lieber meinem Vorsatz treu, dass Daten unter (dauerhaftem) Verschluss besser sind, als wenn ich auch nur eine winzige Chance einräume, dass jemand mit unbegrenzten Versuchen durch die Authentifizierungssperren bricht und mir die Bude ausräumt.

Was ich meinen Nutzern einräume:

• Sie müssen ihr Kennwort nicht mehr ändern.

Was ich dafür aber verlange:

• Die Kennwörter müssen eine bestimmte Komplexität haben.
• 2 Fehlversuche max sonst dauerhafte Sperrung (nicht zeitlich beschränkt).
• Unsere Webportale (auch Exchange OWA) sind 2FA-gesichert.
• Nutzer- Anmeldename hat keinerlei Ähnlichkeit mit der E-Mailadresse.

Den Konsens tragen alle mit. Damit scheinen wir gut zu fahren.

Der Gefahr eines Massenaussperrens stehe ich gelassen gegenüber, denn ohne den Aufbau des Anmeldenamens zu kennen, ist es schwierig hier jemanden von außen auszusperren. Das geht alleine schon wegen 2FA nicht. Der 2. Faktor wird von der Firewall geprüft und wenn der schon nicht stimmt, erfolgt keine Kontaktierung der Server. Zusätzlich habe ich einen Notfalladminaccount mit sehr langem Anmeldenamen und noch längerem Passwort. Diesen zu sperren, halte ich für eher unwahrscheinlich.

Gruß
bdmvg

Ich verstehe den Zusammenhang zu Kontosperrungen und einer ausgefallenen/überlasteten UTM nicht?


Aber das Argument, dass jemand böswillig damit von außen den Betrieb lahm legen kann, wollte ich auch bringen.
Ich nehme dazu einfach die Domain der Firma, suche nach so ca. 20-25 generischen Subdomains ("exchange", "owa", "webmail"...) und wenn ich deren Outlook Web Access gefunden habe, kippe ich für jede Mailadresse die ich kenne einfach so 10-15 falsche Anmeldungen rein. Muss ja nichtmal ein variables Kennwort sein - einfach 10x versuchen mit Kennwort "xyz" anzumelden.
Das mache ich für jedes mir bekannte Mailkonto und dann arbeitet da niemand mehr, weil ja alle Konten gesperrt sind.
Ich will das Konto nicht aufmachen, ich will ja nur verhindern, dass es überhaupt jemand nutzen kann. Und das kann ich ja nicht nur einmal machen, das kann ich durchgängig so laufen lassen.
Dagegen hilft dann nur, das OWA ausschließlich per VPN oder "Trusted Networks" erreichbar zu machen, was aber meistens den Sinn des OWA konterkariert. Oder man verwendet konsequent 2FA und macht es zur Voraussetzung, dass der Login aus fremden Netzen überhaupt funktioniert - und muss sich dann nicht mehr so sehr vor Bruteforce gruseln, weil selbst ein bekanntes Kennwort keine Verwendung des Kontos ermöglicht.
Lediglich überwachen sollte man auf theoretisch erfolgreiche Logins, die dann an 2FA gescheitert sind.


Das "DoS-durch-Kontosperrung" ging eine zeitlang bei Telekom-DSL-Zugängen übrigens auch. Da konntest du dich an einem beliebigen Anschluss (auch Reseller-Anschlüsse von 1&1) versuchen mit fremder Leute Zugangsdaten anzumelden. WIMRE ging das aber sogar, wenn man versuchte sich mit diesen Zugangsdaten auf der Telekom-Webseite anzumelden - das war dann auch schlechter zurückverfolgbar als bei den DSL-Einwahlen
Du musstest nur den Benutzer kennen - was relativ leicht war, da einige Leute das als ihre reguläre Mailadresse verwendeten - und irgendein Phantasiekennwort versuchen, nach genug fehlerhaften Anmeldungen (ich glaube, man brauchte so ca. 30-40 Versuche) wurde das T-Online-Konto gesperrt und der legitime Besitzer des Zugangs konnte sich nicht mehr ins Internet einwählen. Kontofreischaltung nur mit neuem Kennwort, das musste man bei der Hotline beantragen und wurde per Post verschickt.
Das hat die Telekom dann, weil es eine beliebte DoS-Methode wurde, dann abgestellt. Und inzwischen ist es ja eh dank BNG obsolet geworden.

Der Endeffekt ist derselbe, die UTM (IPS/IDS) hat die Möglichkeit auszufallen (= gar nichts mehr durch zu lassen -> Kontosperrung) oder eben nicht mehr zu funktionieren und im Zweifel Pakete durch zu lassen, die zwangsläufig eigentlich den entsprechenden Regeln entsprechen. ;)

Ist natürlich immer eine Abwägung, VPN ist gut und Recht, aber auf den mobil-devices für Mails..?

Da helfen dann aber eine klare Segmentierung des Netzes und ggf. IDS/IPS und Flooding Prevention. Zeigt aber auch mal wieder: Mitgebrachte Devices ins "semi interne" = interne client Netz zu lassen ist Blödsinn. Dafür gibt es ein extra Netz.

Cool. Bin gespannt drauf.

Die Sperrung erfolgt aber doch über eine ungültige Authentifizierung. Durch Probieren falscher Credentials (richtiger Nutzer, falsches PW) werden Konten u.a. gesperrt.

Da bin ich bei Dir. Aber auch hier braucht es erstmal einen gültigen Domänenzugriff. Meine 2016er-Domäne verweigert diese Auskunft, wenn nicht die Workstation Mitglied oder/und der Nutzer Mitglied ist. Zumindest ergibt das mein eben durchgeführter Versuch.

Wenn Du die Kontenliste hast, bin ich bei Dir. Um Authentifizierungsversuche zu starten, reicht ein beliebiger Rechner. Aber das Auslesen der Konten braucht aus meiner Sicht immernoch einen Domänenrechner. Korrigiere mich, wenn ich falsch liegen sollte.


Ich bin immernoch der Ansicht, dass es besser ist, die Daten liegen zugriffsgeschütztr -auch wenn das Geschöpf den Schöpfer ausperrt- als dass jemand von außen zu einfach reinkommt.

Und den physischen/technischen Netzwerkzugriff sollte man als Admin ebenfalls unter Kontrolle haben.


Bin sehr gespannt.

Damit ich mir nicht ständig anhören muss, dass das der Account gesperrt wurde und wenn ich diesen freigebe, ich gleichzeitig ein neues Passwort vergeben muss, was den aktuellen Sicherheitsstandards entspricht. Selbiges ist der Fall, wenn der Benutzer sein Passwort nicht mehr weiß. Setze ich es zurück, entspricht es nicht deren "Wünschen" oder sie ändern es gleich auf "HalloWelt123"... Eigentlich die falsche Richtung, was ich jedoch noch ändern will, muss nur leider die Füße stillhalten...

Bitte.

Wir haben es abgeschaltet, denn es ist eine super Möglichkeit für einen Angriff, um alle Konten unternehmensweit zu sperren. Lieber vernünftige Passwörter und ein Monitoring für fehlgeschlagene Log-in Versuche.

Hi,
wir fangen dies von außen über unsere MS ADFS-Server mit smartlockout ab. Spam mit falschen Passwörtern von außen hat also keinen Einfluss auf den Kontenzugriff von innen. Alle Notebookuser authentisieren sich per always on vpn immer an den "inneren" Servern. Dies gilt auch für die O bzw M365 Konten. Die einzigen, die ab und an Probleme damit haben, wenn mal wieder eine Welle von Fehlanmeldungen aus China kommen, sind unsere Smartphone User, ist aber sehr überschaubar solange ihre access token noch gültig sind. Alles in allem funktioniert das smart lockout recht gut, da es auch differenziert zwischen Quellen mit vorher erfolgreicher Anmeldung oder unbekannte Adressen. Dazu noch etwas Geoblocking der Firewall