13
Exchange 2013 Activ-Sync und Outlook-Anywhere absichern bei KMU
Hallo,
gibt es eigentlich einen Weg um Active-Sync, OMA und OWA für KMUs bezahlbar abzusichern.
Eigentlich ist es nicht mein Problem.
Ich sage dem Kunden was er machen soll und wenn er das Geld dafür nicht ausgeben möchte, pech.
Dieser Kunde hat einen 2012R2 mit AD, DNS, DHCP, Exchange 2013, File-Server, etc.
Also schon außerhalb des erlaubten, aber es ist halt KMU, kleine Kunden, wenig Budget.
Ich frage mich aber ob es nicht doch einfache Möglichkeiten gibt.
Im Eventlog sieht man halt viele Zugriffsversuche.
Immer nur ein Benutzername zur Zeit und keinen Benutzername mit mehreren Kennwörtern.
Einen Bruteforce-Schutz wie Fail2Ban gibt es ja hier nicht.
Kann man "einfach" einen Reverse-Proxy mit fail2ban davor schalten?
3 falsche Zugriffe und IP für 24h sperren?
Ich habe irgendwie auch keine kommerziellen Produkte gefunden die sowas bereitstellen.
Stefan
gibt es eigentlich einen Weg um Active-Sync, OMA und OWA für KMUs bezahlbar abzusichern.
Eigentlich ist es nicht mein Problem.
Ich sage dem Kunden was er machen soll und wenn er das Geld dafür nicht ausgeben möchte, pech.
Dieser Kunde hat einen 2012R2 mit AD, DNS, DHCP, Exchange 2013, File-Server, etc.
Also schon außerhalb des erlaubten, aber es ist halt KMU, kleine Kunden, wenig Budget.
Ich frage mich aber ob es nicht doch einfache Möglichkeiten gibt.
Im Eventlog sieht man halt viele Zugriffsversuche.
Immer nur ein Benutzername zur Zeit und keinen Benutzername mit mehreren Kennwörtern.
Einen Bruteforce-Schutz wie Fail2Ban gibt es ja hier nicht.
Kann man "einfach" einen Reverse-Proxy mit fail2ban davor schalten?
3 falsche Zugriffe und IP für 24h sperren?
Ich habe irgendwie auch keine kommerziellen Produkte gefunden die sowas bereitstellen.
Stefan
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 296961
Url: https://administrator.de/forum/exchange-2013-activ-sync-und-outlook-anywhere-absichern-bei-kmu-296961.html
Ausgedruckt am: 12.04.2025 um 22:04 Uhr
13 Kommentare
Neuester Kommentar
Hallo,
"wenig Budget" ist immer so eine Sache - IT-Sicherheit kostet halt ein wenig bis ziemlich viel (je nachdem was man haben will). Vielleicht solltest du noch ein wenig Überzeugungsarbeit bei deinem Kunden leisten. Ein "Einbruch" in die Systeme mit Downtime kann auch teuer werden!
Ich würde durchaus einen Reverse-Proxy mit verschiedenen Prüfungs- und Sicherheitsmechanismen dazwischen schalten.
Zu dem Bruteforce-Schutz: Du kannst das auch über die Active-Directory mit einer Passwortpolicy erledigen. Unter "Computerkonfiguration\Richtlinien\Windows-Einstellungen\Sicherheitseinstellungen\Kontosperrungsrichtlinien" kannst du deinen Bruteforce-Schutz ganz gut definieren.
"wenig Budget" ist immer so eine Sache - IT-Sicherheit kostet halt ein wenig bis ziemlich viel (je nachdem was man haben will). Vielleicht solltest du noch ein wenig Überzeugungsarbeit bei deinem Kunden leisten. Ein "Einbruch" in die Systeme mit Downtime kann auch teuer werden!
Ich würde durchaus einen Reverse-Proxy mit verschiedenen Prüfungs- und Sicherheitsmechanismen dazwischen schalten.
Zu dem Bruteforce-Schutz: Du kannst das auch über die Active-Directory mit einer Passwortpolicy erledigen. Unter "Computerkonfiguration\Richtlinien\Windows-Einstellungen\Sicherheitseinstellungen\Kontosperrungsrichtlinien" kannst du deinen Bruteforce-Schutz ganz gut definieren.
Hallo,
ja, deshalb meinte ich ja "ist eigentlich nicht mein Problem".
Aber man kann ja mal nach Lösungen suchen.
ForeFront gibt es nicht mehr und VPN ist auch nicht so praktikabel.
Kann man mit einem ReverseProxy denn einen Brute-Force-Schutz realisieren.
EIn Captcha bringt ja bei ActiveSync nix.
Die Richtilinen greifen ja nicht, da jeder Benutzername nur ein mal probiert wird.
Man müßte Fehl-Versuche pro IP-Adresse ermitteln und dann die IP sperren.
Kann ein RP einen Fehlerhafte Anmeldung ermitteln durch einen 403 oder so?
Stefan
ja, deshalb meinte ich ja "ist eigentlich nicht mein Problem".
Aber man kann ja mal nach Lösungen suchen.
ForeFront gibt es nicht mehr und VPN ist auch nicht so praktikabel.
Kann man mit einem ReverseProxy denn einen Brute-Force-Schutz realisieren.
EIn Captcha bringt ja bei ActiveSync nix.
Die Richtilinen greifen ja nicht, da jeder Benutzername nur ein mal probiert wird.
Man müßte Fehl-Versuche pro IP-Adresse ermitteln und dann die IP sperren.
Kann ein RP einen Fehlerhafte Anmeldung ermitteln durch einen 403 oder so?
Stefan
Squid als Reverse-Proxy sollte auch die Verwendung von Fail2Ban unterstützen.
Ich sehe eher ein Problem bei der Auswertung der Zugriffe. Prinzipiell kann ja nur der Exchange wirklich sagen, ob die Authentifizierung fehlgeschlagen ist.
Der Squid/Fail2Ban bekommt das theoretisch nicht mit (oder sehe ich das falsch?!).
Du müsstest eine Authentifizerung am Reverse-Proxy konfigurieren. Allerdings erschwert das die Verwendung von Active-Sync und auch Outlook-Anywhere.
Welche Benutzernamen werden denn abgefragt? Tatsächlich existierende Benutzernamen oder eher deutsche "Standardnamen".
Laut den Logs wird pro Benutzername nur ein Passwort probiert? Dann sollte die Chance auf Erfolg bei ausreichend komplexen Passwörtern für den Angreifer nicht sonderlich hoch sein - das was der da macht ist ja kein wirkliches Brute-Force. Wenn es immer die gleiche IP bzw. eine aus dem gleichen Subnetz ist könntest du doch auch über eine dauerhafte Sperrung dieses IP-Bereichs nachdenken....
Ich sehe eher ein Problem bei der Auswertung der Zugriffe. Prinzipiell kann ja nur der Exchange wirklich sagen, ob die Authentifizierung fehlgeschlagen ist.
Der Squid/Fail2Ban bekommt das theoretisch nicht mit (oder sehe ich das falsch?!).
Du müsstest eine Authentifizerung am Reverse-Proxy konfigurieren. Allerdings erschwert das die Verwendung von Active-Sync und auch Outlook-Anywhere.
Welche Benutzernamen werden denn abgefragt? Tatsächlich existierende Benutzernamen oder eher deutsche "Standardnamen".
Laut den Logs wird pro Benutzername nur ein Passwort probiert? Dann sollte die Chance auf Erfolg bei ausreichend komplexen Passwörtern für den Angreifer nicht sonderlich hoch sein - das was der da macht ist ja kein wirkliches Brute-Force. Wenn es immer die gleiche IP bzw. eine aus dem gleichen Subnetz ist könntest du doch auch über eine dauerhafte Sperrung dieses IP-Bereichs nachdenken....
Hallo,
hast Du da einen Link zu einer Anleitung.
Ich finde es schon wieder komisch. Alle reden davon, aber google findet nur eine handvoll Anleitungen und die meisten unvollständig mit dem Vermek "Kannst ja mal fertig machen". Das sollte doch ideal standard sein?
Dafür könnte man ja sogar einen fertiges System verteilen.
lokale IP, Domäne, URL vom Exchange, Zertifikat und fertig
fail2band und RP kann ja alles ideal standard sein.
Naja...
Es sind elnigsche Namen in alphabetischer Reihenfolge.
gonualez, goodman, gray, green, gregory, ...etc
ca. 200-300 pro Tag
Stefan
hast Du da einen Link zu einer Anleitung.
Ich finde es schon wieder komisch. Alle reden davon, aber google findet nur eine handvoll Anleitungen und die meisten unvollständig mit dem Vermek "Kannst ja mal fertig machen". Das sollte doch ideal standard sein?
Dafür könnte man ja sogar einen fertiges System verteilen.
lokale IP, Domäne, URL vom Exchange, Zertifikat und fertig
fail2band und RP kann ja alles ideal standard sein.
Naja...
Es sind elnigsche Namen in alphabetischer Reihenfolge.
gonualez, goodman, gray, green, gregory, ...etc
ca. 200-300 pro Tag
Stefan
Nein eine genaue Anleitung dazu habe ich leider ebenfalls nicht zur Hand.
Wir hier nutzen dafür eine Sophos-UTM. Im Prinzip sind das die genannten Softwareprodukte. Sophos hat sich den Squid/Apache/Snort/etc. geschnappt, bisschen modifiziert und eine einheitlich Verwaltungsoberfläche drüber gebaut - funktionieret eigentlich ziemlich gut!
Deine gesuchte Funktion unterstütz der Reverse-Proxy allerdings ebenfalls nicht - Vor allem ist die Aussicht auf Erfolg für den Angreifer ziemlich gering. Ich würde auf interne Passwortrichtlinien setzen die ausreichend komplexe Passwörter voraussetzen und danach die IPs analysieren. Wenn das IP's aus dem russichen/chinesichen/"was weiß ich noch alles" -Raum sind dann kannst du die ja getrost komplett sperren.
Desweitern sind es ja anscheinen Namen/Passwort Zuordnungen die überhaupt nicht auf die internen Strukturen passen. Wenn man solche Dienste ins Internet stellt lässt sich sowas auch relativ schwer vermeiden.
Wir hier nutzen dafür eine Sophos-UTM. Im Prinzip sind das die genannten Softwareprodukte. Sophos hat sich den Squid/Apache/Snort/etc. geschnappt, bisschen modifiziert und eine einheitlich Verwaltungsoberfläche drüber gebaut - funktionieret eigentlich ziemlich gut!
Deine gesuchte Funktion unterstütz der Reverse-Proxy allerdings ebenfalls nicht - Vor allem ist die Aussicht auf Erfolg für den Angreifer ziemlich gering. Ich würde auf interne Passwortrichtlinien setzen die ausreichend komplexe Passwörter voraussetzen und danach die IPs analysieren. Wenn das IP's aus dem russichen/chinesichen/"was weiß ich noch alles" -Raum sind dann kannst du die ja getrost komplett sperren.
Desweitern sind es ja anscheinen Namen/Passwort Zuordnungen die überhaupt nicht auf die internen Strukturen passen. Wenn man solche Dienste ins Internet stellt lässt sich sowas auch relativ schwer vermeiden.
Hallo,
Sorgen mache ich mir nicht direkt.
Aber ich erhalte vom Monitoring für 2-3 Kunden jeden Tag eine Warnung.
Mal sind es 20 mal sind es 500 Versuche.
'
Die IPs kommen von überall her. China, Indien, Frankreich, Dänemark, USA, Deutschland, etc.
Man sieht das besser bei unseren Webservern. Da nutzen die Angreifen große IP-Proxy.
Teilweise hunderte IPs bei Brute-Force-Angriffe auf Wordpress.
Ein Fail2Ban wäre schön.
Viele Grüße
Stefan
Sorgen mache ich mir nicht direkt.
Aber ich erhalte vom Monitoring für 2-3 Kunden jeden Tag eine Warnung.
Mal sind es 20 mal sind es 500 Versuche.
'
Die IPs kommen von überall her. China, Indien, Frankreich, Dänemark, USA, Deutschland, etc.
Man sieht das besser bei unseren Webservern. Da nutzen die Angreifen große IP-Proxy.
Teilweise hunderte IPs bei Brute-Force-Angriffe auf Wordpress.
Ein Fail2Ban wäre schön.
Viele Grüße
Stefan
Naja, aber wie gesagt: Wie soll der Proxy den fail denn mitbekommen?
Ich persönlich habe einen Apache als reversen Proxy davor, das klappt sogar mit dem Zertifikat vom Exchange, dem Autodiscover usw.
Ich weiß nicht, ob fail2ban wirklich erforderlich ist. Letztendlich kommt man per bruteforce ja immer nur in eine Mailbox - und das mit verhältnismäßig hohem Aufwand.
Ich persönlich habe einen Apache als reversen Proxy davor, das klappt sogar mit dem Zertifikat vom Exchange, dem Autodiscover usw.
Ich weiß nicht, ob fail2ban wirklich erforderlich ist. Letztendlich kommt man per bruteforce ja immer nur in eine Mailbox - und das mit verhältnismäßig hohem Aufwand.
1
für mich macht das beschriebene angriffsszenario keinen Sinn bzw. hat keine Aussicht auf Erfolg. Ein Passwort pro Benutzername und danach ein kompletter Wechsel der Daten ist doch Quatsch. So viel "Glück" kann man ja fast nicht haben, dass da mal ein Name-Passwort-Paar passt.
Weiß Jemand wieviele Versuche man pro Benutzernamen hat?
Für Active-Sync, OWA bei Exchange 2013?
Und wenn wir dabei sind, für RDP bei 2012R2?
Alles unter Standardeinstellungen?
Für Active-Sync, OWA bei Exchange 2013?
Und wenn wir dabei sind, für RDP bei 2012R2?
Alles unter Standardeinstellungen?
Im Default müsste es keine Beschränkung geben
Es wird alles zentral über die Gruppenrichtlinie definiert. Prinzipiell sind dadurch alle Dienste betroffen an dem sich ein Benutzer mit AD-Informationen anmelden kann. Dazu zählt auch RDP bei einem Terminalserver. Wir haben beispielsweise verschiedene Self-Service-Portale oder eine Owncloud-Instanz die auf die Benutzerdaten der AD zurückgreift - da funktioniert das logischerweise auch...
Es wird alles zentral über die Gruppenrichtlinie definiert. Prinzipiell sind dadurch alle Dienste betroffen an dem sich ein Benutzer mit AD-Informationen anmelden kann. Dazu zählt auch RDP bei einem Terminalserver. Wir haben beispielsweise verschiedene Self-Service-Portale oder eine Owncloud-Instanz die auf die Benutzerdaten der AD zurückgreift - da funktioniert das logischerweise auch...
Heist also, dass man unendlich viele Versuche für ein einzelnes Postfach hat.
Und bei Active-Sync wird es vermutlich auch kein Delay geben.
Also kann man hunderte Kennwörter pro Sekunde überprüfen.
Ich gehe mal davon aus, dass mindestens 50% der Exchange-Server so im Internet erreichbar laufen.
Das ist doch nicht gut...
Stefan
Und bei Active-Sync wird es vermutlich auch kein Delay geben.
Also kann man hunderte Kennwörter pro Sekunde überprüfen.
Ich gehe mal davon aus, dass mindestens 50% der Exchange-Server so im Internet erreichbar laufen.
Das ist doch nicht gut...
Stefan
Zitat von @StefanKittel:
Heist also, dass man unendlich viele Versuche für ein einzelnes Postfach hat.
Und bei Active-Sync wird es vermutlich auch kein Delay geben.
Also kann man hunderte Kennwörter pro Sekunde überprüfen.
Heist also, dass man unendlich viele Versuche für ein einzelnes Postfach hat.
Und bei Active-Sync wird es vermutlich auch kein Delay geben.
Also kann man hunderte Kennwörter pro Sekunde überprüfen.
Jop, grundsätzlich ist das so.
Ich gehe mal davon aus, dass mindestens 50% der Exchange-Server so im Internet erreichbar laufen.
Das ist doch nicht gut...
Das ist doch nicht gut...
Da hast du auch recht. Aber eigentlich sollte der Betreiber eines Exchange-Servers die Konfiguration an die Gegebenheiten der Umgebung anpassen.
Zitat von @StefanKittel:
Heist also, dass man unendlich viele Versuche für ein einzelnes Postfach hat.
Heist also, dass man unendlich viele Versuche für ein einzelnes Postfach hat.
Mein Kennwort hat 15 Zeichen. Zusätzlich fehlt Dir auch noch der Benutzername und die Domänenangabe (der Server lässt nur Anmeldungen a 'la DOMAENE\benutzername zu).
Viel Erfolg.
Ich gehe mal davon aus, dass mindestens 50% der Exchange-Server so im Internet erreichbar laufen.
Ich gehe davon aus, dass mindestens 85% der Exchange-Server so im Internet erreichbar laufen
