9
Angriffe auf OWA - Nutzerkonten schützen, Sperrung verhindern
Hallo,
vielleicht hat hier jemand eine Idee; folgendes Problem:
Wir haben einen OnPrem Exchange 2019 laufen, OWA ist aktiviert. Seit kurzem wird im Sekundentakt versucht sich einzuloggen (mit zum Teil alten, und deaktivierten Konten). Ungünstig ist jetzt aber, dass eben auch Konten von aktiven Mitarbeitern betroffen sind. Da wir recht starke Passwortrichtlinien haben ist meine Angst, dass wir tatsächlich gehackt werden eher gering. Was nur sehr ärgerlich ist, dass diese Konten dann aufgrund der Anmelderichtlinien gesperrt werden und die betroffenen Mitarbeiter sich nicht mehr an der Domäne (Server 2019, kein Azure) anmelden können.
Das automatische Entsperren erfolgt nach 2 Stunden, max. Fehlversuche sind 3. Ich könnte jetzt natürlich die Zeit für das automatische Entsperren runtersetzen und die Fehlversuche rauf. Das ist meiner Ansicht nach aber nicht wirklich zweckmäßig. Ich persönlich wäre ja für die Einführung von MFA. Da das aber mit Bordmitteln nicht gegeben ist geht hier der Weg über einen Drittanbieter und die lassen sich das auch ganz gut bezahlen... es wird wohl früher oder später trotzdem darauf hinaus laufen, nur bis dahin wäre eine schnelle und einfache Lösung des Problems wünschenswert.
Folgende Ideen kamen auf:
- Einfache Passwortabfrage auf HTML Basis vor das eigentliche Login-Portal schalten, damit der Angreifer keine direkte Möglichkeit hat, sich mit irgendwelchen Anmeldedaten einzuloggen (hier fehlt allerdings das Know-How ob und in wie weit sich das Portal, abgesehen von CSS, bearbeiten lässt)
- OWA für Mitarbeiter am Standort mit Outlook am PC deaktivieren (hat leider keinen Erfolg gebracht, Konten wurden trotzdem gesperrt)
- Wie oben genannt, MFA einführen (ist aber nichts was auf die Schnelle umgesetzt werden kann)
Bin um jede Anregung dankbar
vielleicht hat hier jemand eine Idee; folgendes Problem:
Wir haben einen OnPrem Exchange 2019 laufen, OWA ist aktiviert. Seit kurzem wird im Sekundentakt versucht sich einzuloggen (mit zum Teil alten, und deaktivierten Konten). Ungünstig ist jetzt aber, dass eben auch Konten von aktiven Mitarbeitern betroffen sind. Da wir recht starke Passwortrichtlinien haben ist meine Angst, dass wir tatsächlich gehackt werden eher gering. Was nur sehr ärgerlich ist, dass diese Konten dann aufgrund der Anmelderichtlinien gesperrt werden und die betroffenen Mitarbeiter sich nicht mehr an der Domäne (Server 2019, kein Azure) anmelden können.
Das automatische Entsperren erfolgt nach 2 Stunden, max. Fehlversuche sind 3. Ich könnte jetzt natürlich die Zeit für das automatische Entsperren runtersetzen und die Fehlversuche rauf. Das ist meiner Ansicht nach aber nicht wirklich zweckmäßig. Ich persönlich wäre ja für die Einführung von MFA. Da das aber mit Bordmitteln nicht gegeben ist geht hier der Weg über einen Drittanbieter und die lassen sich das auch ganz gut bezahlen... es wird wohl früher oder später trotzdem darauf hinaus laufen, nur bis dahin wäre eine schnelle und einfache Lösung des Problems wünschenswert.
Folgende Ideen kamen auf:
- Einfache Passwortabfrage auf HTML Basis vor das eigentliche Login-Portal schalten, damit der Angreifer keine direkte Möglichkeit hat, sich mit irgendwelchen Anmeldedaten einzuloggen (hier fehlt allerdings das Know-How ob und in wie weit sich das Portal, abgesehen von CSS, bearbeiten lässt)
- OWA für Mitarbeiter am Standort mit Outlook am PC deaktivieren (hat leider keinen Erfolg gebracht, Konten wurden trotzdem gesperrt)
- Wie oben genannt, MFA einführen (ist aber nichts was auf die Schnelle umgesetzt werden kann)
Bin um jede Anregung dankbar
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 6651355711
Url: https://administrator.de/contentid/6651355711
Ausgedruckt am: 25.11.2024 um 00:11 Uhr
9 Kommentare
Neuester Kommentar
Das mit dem HTML Login verstehe ich nicht, der soll ja wohl hoffentlich nicht den regulären Login ersetzen. Du suchst vermutlich etwas wie einen Web Application Proxy (WAF), sowas wird auch von einigen Firewalls angeboten (z.B. Sophos). Man kann das aber auch mit Microsoft Servern umsetzen, ist allerdings nicht ganz einfach, ich habe mich entschieden Exchange wieder hinters VPN zu stecken.
Geo Blocking wäre vielleicht der einfachste Weg diese Brutforce Attacken zu unterbinden.
Edit: Wenn das wirklich gezielte Angriffe auf euch mit euren Benutzerdaten sind würde ich auch Strafanzeige stellen. Sollten die Angriffe dann von Deutschen IPs laufen gäbe es dann vielleicht auch eine juristische Handhabe.
Geo Blocking wäre vielleicht der einfachste Weg diese Brutforce Attacken zu unterbinden.
Edit: Wenn das wirklich gezielte Angriffe auf euch mit euren Benutzerdaten sind würde ich auch Strafanzeige stellen. Sollten die Angriffe dann von Deutschen IPs laufen gäbe es dann vielleicht auch eine juristische Handhabe.
1
Moin.
Einführung von MFA. Da das aber mit Bordmitteln nicht gegeben ist...
Du kannst ohne Kosten virtuelle SmartCards einführen. Das ist, wenn eine interne CA vorhanden ist, nicht weiter schwierig.
Zitat von @ukulele-7:
Das mit dem HTML Login verstehe ich nicht, der soll ja wohl hoffentlich nicht den regulären Login ersetzen.
Das mit dem HTML Login verstehe ich nicht, der soll ja wohl hoffentlich nicht den regulären Login ersetzen.
Nein, um Gottes Willen! Den würde ich einfach vor die reguläre Anmeldung schalten, quasi als erste Hürde, um zu verhindern, dass die Konten nicht direkt gesperrt werden. Also ein Login vorm Login. Keine elegante Lösung und auch für den Endnutzer eher nervig. Aber eben weniger nervig als alle 30 Minuten ein gesperrtes Konto zu haben...
Zitat von @ukulele-7:
Geo Blocking wäre vielleicht der einfachste Weg diese Brutforce Attacken zu unterbinden.
Geo Blocking wäre vielleicht der einfachste Weg diese Brutforce Attacken zu unterbinden.
Ja, das war auch eine Idee. Blöderweise sehe ich im Eventlog nicht von welcher IP die Anmeldeversuche kommen. Ich meine Event ID 4625 ist der Failed Login. Da ist leider nichts auszulesen, ausser DASS ein Anmeldeversuch fehlgeschlagen ist, nicht woher.
Auf meinem Cloud Server lief ein Reverse Proxy mit Fail2Ban im Hintergrund. Das war natürlich recht komfortabel, scheint aber für Windows nicht so einfach umsetzbar.
Desweiteren könntest Du bei deinen Konten festlegen, wo sie sich authentifizieren dürfen (Default: überall). Ändert man diesen Default auf dem User zugeordnete Rechner, wird der Angreifer keine Kontensperrungen mehr verursachen können.
Auf meinem Cloud Server lief ein Reverse Proxy mit Fail2Ban im Hintergrund. Das war natürlich recht komfortabel, scheint aber für Windows nicht so einfach umsetzbar.
Ich wollte schon immer mal wail2ban testen. Bin aber noch nicht dazu gekommen.
Blöderweise sehe ich im Eventlog nicht von welcher IP die Anmeldeversuche kommen.
Aber im IIS-Log solltest du das sehen können. Ist aber Handarbeit.
Mit Geoblocking verhinderst du geschätzte >90% der Anmeldeversuche. Und wenn du das auch noch auf Port 25 ausdehnst verhinderst du auch noch ebensoviel SPAM 😉
Manuel
Moin,
Ich hoffe mal, dass der Exchange nicht nackig im Internet hängt, sondern mit guter Firewall abgesichert ist.
Bei uns habe ich das so gemacht:
Gruß
bdmvg
Ich hoffe mal, dass der Exchange nicht nackig im Internet hängt, sondern mit guter Firewall abgesichert ist.
Bei uns habe ich das so gemacht:
- 2FA über die Firewall: Das Windows-PW und der Nutzername reichen nicht aus, um sich erfolgreich authentifizieren zu können. Der 2. Faktor wird zuerst von der Firewall geprüft, bevor sie die Authentifizierung gegen die Domäne fährt.
- Geändertes Schema für die Login-Namen: z.B. die ersten 3 des Nachnamens gefolgt von den ersten 3 des Vornamens. Damit kannst Du den Namen quasi in einen dritten Faktor wandeln.
Gruß
bdmvg
Um die IP Adressen zu sichten gibt es dieses Free Tool.
AttackTracer
Der list die IPs aus den Windows Event
AttackTracer
Der list die IPs aus den Windows Event
2
Moin,
Alternativ müsste jede moderne WAF sowas mit Hilfe der Erkennung von Brut-Force mildern oder sogar vermeiden können. Praktische Erfahrung dazu habe nicht. Da wir für dieses Szenario auf AD FS + WAP + 2FA setzen.
Gruß,
Dani
ein, um Gottes Willen! Den würde ich einfach vor die reguläre Anmeldung schalten, quasi als erste Hürde, um zu verhindern, dass die Konten nicht direkt gesperrt werden. Also ein Login vorm Login. Keine elegante Lösung und auch für den Endnutzer eher nervig. Aber eben weniger nervig als alle 30 Minuten ein gesperrtes Konto zu haben...
dieser Wunsch erfüllst du dir bequem mit AD FS in Kombination mit WAP. Wichtig hierbei ist, dass anschließend die Anmeldung an OWA und ECP auf SAML umgestellt werden müssen. Danach wird mit Hilfe Extranet Smart Lockout Protection sichergestellt, dass das eigentliche Benutzerkonto nicht gesperrt wird, wenn die Versuche über das Internet erfolgen.Alternativ müsste jede moderne WAF sowas mit Hilfe der Erkennung von Brut-Force mildern oder sogar vermeiden können. Praktische Erfahrung dazu habe nicht. Da wir für dieses Szenario auf AD FS + WAP + 2FA setzen.
Gruß,
Dani
Mit AD FS habe ich das auch mal machen wollen. Bin sehr schnell zu der Erkenntnis gelangt das mich das total abfu und habe es gelassen aber grundsätzlich ist das der Microsoft best practice Weg.
