Exchange Webseite absichern

Microsoft betreibt Exchange online angeblich ohne vorgelagerte Loadbalancer oder Schutzfunktionen. On-Premises werden aber immer noch gerne Reverse Proxy-Server etabliert. Das ist immer noch eine gute Idee, denn Exchange wehrt sich immer noch nicht gegen Kennwort Angriffe. Was macht Microsoft anders?

Dienste mit HTTP

Es hat sich mittlerweile bestätigt, dass quasi alle Lösungen auf HTTPS über Port 443 setzen und damit nicht nur die Zugriffe auf externe Dienste, z.B. Office 365, über einen ausgehenden Proxy ermöglichst werden müssen sondern auch eigene Dienste in der Regel per https erreichbar gemacht werden. Ein Dienst ist z.B. Exchange, welcher gleich mehrere Dienste bereit stellt:

  • MAPI/http (Outlook)
  • EWS (Outlook ;Skype for Business u.a.)
  • ActiveSync (Mobilgeräte)
  • OWA (Browser)
    Aber auch andere Plattformen, z.B. SharePoint oder Skype for Business nutzen Webdienste, die aus dem Internet erreichbar sein müssen.

Anforderungen

 Dazu gibt es mehrere Anforderungen von Firmen, z.B.:

  • Adressumsetzung
    Interne Server nutzen meist „private“ Adressen und sind ohne aktive Umsetzung von Paketen nicht erreichbar. Pakete müssen also per Reverse-NAT oder über einen Reverse Proxy veröffentlicht werden
  • DoS-Schutz
    Viele Systeme haben selbst keinen DoS-Schutz gegen sehr hohe Anmeldeversuche. Daher kann ein vorgeschaltetes System z.B. die Anzahl der Anmeldeversuche pro User/Client beschränken, um solche Angriffe zu reduzieren. Dazu muss das System natürlich auch in den verschlüsselten Datenverkehr rein schauen
  • SSL Offloading
    Früher war es auch durchaus ein Ziel, die Last durch SSL-Verschlüsselung vom Applikationsserver auf den Reverse-Proxy zu übertragen, um die Leistung zu steigern
  • PreAuthentication
    Interessant ist natürlich der Portalgedanke, dass sich der Anwender nur einmal an einem Portal anmeldet und dann auf alle für ihn zugelassenen Applikationen durchgreifen kann. Das funktioniert natürlich nur für Webbasierte Applikationen aber nicht für Programme, die http außerhalb des Browsers nutzen
  • Content/Malware Filterung, Verhaltenserkennung
    Wenn ein Reverse-Proxy auch in den Inhalt schaut, kann er zugleich auch die Inhalte gegen bekannte Muster (Viren), Dateiformate (EXE, COM, DOC statt DOCX) prüfen und ggfls. blockieren. Das ist aber auch nur eingeschränkt möglich, da „False Positive“ natürlich die Funktion stören

Nutzungarten

Beim Einsatz mit Exchange ist generell einmal zwischen drei Nutzungsarten zu unterscheiden:

  • dem interaktiven Zugang per Browser (OWA)
    Hier steuert der Anwender die Nutzung und Proxy-Server und Portal können der umfangreich das Verhalten verändern, z.B. durch eine Preauthentifizierung, Multifaktor-Abfragen, Single-SignOn auch für andere Webseiten etc. In der Regel übermittelt der Anwender seine Anmeldedaten in einem Formular (SSL gesichert), so dass das Portal das Kennwort „kennt“ und die Anmeldung an nachgelagerten Diensten für den Benutzer ausführen kann. „Constraint Delegation“ ist hier in der Regel keine Anforderung.
  • dem Zugang durch den Anwender über Applikationen (Outlook, SfB, Smartphone etc.)
    Hier gibt es weniger Möglichkeiten dem Anwender einen Dialog anzuzeigen. Der Reverse-Proxy muss also die Anfragen passieren lassen oder zumindest nicht stören. Meist kann er eh nicht die höheren Protokolle (MAPI/http, ActiveSync, EWS) verstehen und sinnvoll filtern. Er beschränkt sich also auf eine Pre-Authentifizierung. Hierbei ist zu beachten, dass einige Client das Kennwort per „Basic-Auth“ nicht an System senden, deren Namen nicht als „Trusted Intranet“ gelistet sind. (siehe auch https://www.msxfaq.de/skype_for_business/client/lync_und_ews.htm#trustmodeldata )
    hier wäre es dann wichtig, dass der Client auch „Negotiate/NTLM“ als Authentifizierungsverfahren angeboten bekommt. Damit hat aber der Reverse-Proxy keinen Zugriff mehr auf das originale Kennwort des Clients. Indem Fall muss der ReverseProxy dann mittelst „Constraint Delegation“ und Kerberos zu den nachliegenden Clients gehen. Das ist aktuell nicht eingerichtet. Die externen Clients bekommen nur „Basic“ als Authentifizierungsverfahren angeboten
    https://www.msxfaq.de/windows/kerberos/kerberosconstraint.htm
  • Der Verbindung von Servern untereinander (Migration in/von der Cloud, Free/Busy-Anzeigen etc.
    Für die Verbindung von Servern untereinander kommt in der Regel aber keine Kombination aus Benutzername/Kennwort zum Einsatz. Hier wird WSSecurity oder OAUTH2 mit „Trusted Certificates“ genutzt. So eine Veröffentlichung können die wenigsten Proxy-Server unterstützen. Daher werden z.B. die Office 365 Source-IP-Adressen häufig per Bypass durchgelassen. Auch die Filterung nach UserAgents ist eine Option, auch wenn Sie natürlich sehr einfach gefälscht werden kann. Eine gewisses Vertrauen an die Sicherheit der letztlich ausführenden Systeme muss mitgebracht werden. Soweit aber bekannt ist, betreibt Microsoft seine Exchange Server Frontend direkt am Internet und filtert per Firewall nur Ports. Eine Deep-Inspection unterbleibt,

Für den produktiven Einsatz in Firmen ist es auch weiterhin möglich, den Zugriff von unbekannten Clients durch einen Reverse-Proxy mit Inspection und sogar PreAuth zu führen, wenn die Authentifizierung den Anforderungen der Clients gerecht wird. Eine Beschränkung auf “Basic“ ist aus heutiger Sicht aber trotz HTTPS nicht wirklich sicher, da auch die Administratoren auf der anderen Seite wissen, wie man SSL aufbricht. Insbesondere Internet Cafes und Schadsoftware auf Privat-PCs können dies sehr einfach durchführen. Hier setzen Firmen dann auf MFA und Conditional Access, um abgefischte Kennwort nicht zu einem Risiko werden zu lassen.

Reverse Proxy not supportet

Für Office 365 ist es allerdings gar nicht supportet, dass ein „Inspection Proxy“ den SSL-Datenstrom aufbricht, da die beiden Endpunkte sich entsprechend authentifizieren.

Letztlich ändert es aber nichts daran, dass andere Dienste wie Skype for Business Client von extern nur dann an EWS kommen, wenn EWS entsprechend erreichbar ist. Es muss als "Autodiscover" funktionieren und der Client und Server eine passende Authentifizierung aushandeln.

Die Wahl der Authentifizierung

Viele Firmen stellen immer noch OWA und andere Dienste per "Formular" oder "BasicAuthentication" bereit. Beide Verfahren sind im höchsten Maße natürlich "kompatible" aber auch beide auch sehr unsicher. Jeder, dem es gelingt, den SSL-Tunnel auszubrechen, kann die Anmelddaten einfach extrahieren. Sie stehen quasi im Klartext drin. (Siehe auch Risiko SSL-Inspection)

Eine Antwort darauf könnte natürlich der Verzicht auf "Basic" und "Forms" sein, wenn alle Clients z.B. NTLM unterstützen. Die hierbei übertragenen Anmeldedaten enthalten kein Kennwort, sondern wurden mit dem Kennwort verschlüsselt und nur der Server kann die gleiche Kalkulation ausführen. Ein Wechsel auf NTLM/Negotiate nach extern hätte mehrere Vorteile

  • Integrierte Anmeldung von „Firmen Clients
  • Verschlüsselte Übertragung des Kennwort (NTLM2 hash oder besser) statt basic

Allerdings bedeutet dies auch

  • Ohne Formular gibt es keine echte "Abmelden-Funktion" da der Browser die Credentials sich merkt
  • Browser-Add-ons können auch die Anmeldedaten abfischen.
  • Pre Authentication durch eine Reverse Proxy erfordert Kerberos Constraint Delegation.(Siehe auch Kerberos - Constraint Delegation und Double Hop)

Sicher kann ein Reverse Proxy anhand des UserAgent der Anfrage abschätzen, ob es ein Browser mit interaktiver Anmeldemaske ist und dem Anwender wieder ein Formular anbieten. Aber es hindert einen Angreifer nicht daran, über EWS oder ActiveSync sich als App-Client auszugeben und damit Kennwort-Attacken zu fahren. Es müsste also schon der Reverse Proxy diese Fehlversuche abfangen.

OAUTH/Tokens statt Credentials

Office 365 Dienste erwarten in der Regel gar kein Kennwort vom Anwender. Wenn Sie z.B. auf Exchange Online zugreifen und ihr Client dies unterstützt, dann leitet Sie Exchange Online zu einem ADFS-Service in der Cloud (Microsoft EVOSTS) um. Der fragt dann nach ihrem Anmeldenamen und erkennt anhand der Domain, ob er auch ein Kennwort anfordert oder sie auch noch zum On-Premises ADFS-Server umleiten muss.

Selbst wenn der Client kein "ModernAuth" unterstützt, dann leitet Exchange das Kennwort "im Auftrag" des Benutzers an den EVOSTS weiter und bekommt ein Ticket.

Anders als On-Premises übernimmt hier nicht der Exchange Server (IIS) die Authentifizierung. Auch Sharepoint-Online, OneDrive, Teams, Graph und viele andere Dienste arbeiten so. Der EVOSTS ist der zentrale Authentifizierungsserver, der entweder das Kennwort abfragt oder den Client zum On Premise ADFS sendet, der dann mit einem Ticket zurückkommt. Auf jeden Fall stellt der EVOSTS dann ein Ticket mit der Identität des Anwenders (UPN) aus, welchem dann von den eigentlichen Diensten vertraut wird.

Damit ist aber auch klar, dass der EVOSTS der erste Punkt ist, an dem ein Einbruchsversuch erkannt werden und der sich auch dagegen wehren kann. Er kennt den User aber auch den angesprochenen Dienst und die Client-IP-Adresse.

Damit ist es nicht allzu schwer dann zu viele Fehlversuche einfach zu drosseln oder zu verwerfen. Ist ist allemal besser, wenn der Anwender ein paar Minuten per Sekunden sich nicht anmelden kann als dann ein Einbruchsversuch zu einfach gemacht wird.

Allzu oft meldet sich bei Office 365 ein Anwender in der Regel sowieso nicht an, da das Ticket für den Dienst selbst einige Stunden gültig ist und er auch ein "Renewal"-Ticket bekommt, mit der er sich wieder ein neues Ticket besorgen kann.

Das gleiche Prinzip könnten Sie auch On-Premises einführen. Sie müssten z.B.: nur bei Exchange oder SharePoint eben auch die Authentifizierung per ADFS aktivieren.

Sobald diese Umstellung erfolgt ist, müssen sich nun alle Clients natürlich ein Ticket besorgen. Der ADFS-Service muss entsprechend "Verfügbar" bereitgestellt werden und auch von extern erreichbar sein, wenn mobile Anwender weiterhin Zugriff haben sollen. Aber das ist es nicht allein. Auch interne Anwender müssen sich nun per Token authentifizieren, da NTLM und Kerberos so nicht mehr nutzbar sind. Der Schutz gegen Kennwort-Attacken etc. können Sie nun aber zentral auf dem ADFS-Service konfigurieren. Für Zugriffe von intern ist das meist nicht erforderlich, da hier der ADFS-Server per Kerberos den Client authentifiziert. Aus dem Internet hingegen hilft die Extranet Lockout-Funktion.

Weitere Links