Fortigate: Das Exchange Admin Center (ECP) von extern sperren
Einleitung:
Angesichts der entdeckten Sicherheitslücken auf den Exchange-Servern sollten man den externen Zugriff auf das Exchange Control Panel (ECP) immer deaktivieren: https://webmail.meinedomain.com/ecp
Falls der direkte Zugriff auf das Webmail nicht notwendig ist, sollte man OWA auch gleich mit sperren.
Dies ist nicht bei allen Exchange Server-Versionen wie 2013 einfach und unkompliziert. Es ist besser, den externen Zugriff über die Firewall zu blockieren.
Je früher ein Angriffsversuch geblockt wird, desto besser.
Dies ist einfach zu bewerkstelligen, wenn ihr eine (lizenzierte) Fortigate mit einer virtuellen IP für Ihren Exchange Server verwendet.
Vorbereitungen:
Um das Ganze umsetzen zu können, benötigt ihr das Zertifikat für eure externe Adresse (im Beispiel webmail.meinedomain.com )
So gehts:
Unter System –> Certificates muss das Zertifikat für den Server importiert werden. In diesem Fall hatte ich die meinedomain-zertifikat.p12 Datei und das Kennwort dazu. Danach ist ein Eintrag für das Zertifikat unter „Local Certificate“ sichtbar.
Die ist notwendig, weil der Webfilter sonst den https-Verkehr komplett ignoriert!
Nun muss man unter „Security Profiles“ –> „SSL/SSH Inspection” ein neues Profil erstellen.
Diesem Profil gibt man einen Namen und wählt dort dann unter „Enable SSL inspection of“ den Punkt „Protecting SSL Server“ aus.
Bei „Server Certificate“ muss man nun das zum Mailserver passende Zertifikat aussuchen.
Wenn es nicht wählbar ist, dann liegt das wahrscheinlich daran, dass das Zertifikat im falschen Ort gespeichert ist. Es sind nicht alle Bereiche, die man unter „Certificates“ sieht, verfügbar.
Dann am besten das Zertifikat löschen und noch mal neu (und anders) importieren.
Achtung: Wenn das Zertifikat abläuft, muss es natürlich auch in der Forti neu importiert werden. Dazu kann man sich ja z.B. einen Merker im Kalender setzen.
Jetzt baut man unter „Security Profiles“ –> „Web Filter” den passenden Filter zusammen:
URL | Type | Action | Status |
offizielle-IP/ecp | Simple | Block | Enable |
webmail.meinedomain.com /ecp | Simple | Block | Enable |
*.meinedomain.com/ecp | Simple | Block | Enable |
webmail.meinedomain.com/ecp.* | Simple | Block | Enable |
Jetzt öffnet man unter „Policy & Objects“ –> „IPv4 Policy“ und sucht sich den Verkehr von „untrust“ zum Mailserver heraus und aktiviert dort unter „Web Filter“ den oben gebauten Filter und unter „SSL Inspection“ nimmt man dann noch die SSL Regel dazu, für die man das Zertifikat importiert hat.
Warum ist es notwendig die SSL-Inspection zu verwenden?
Ohne diese SSL-Regel mit dem passenden Zertifikat ist der Datenverkehr über https für die Firewall komplett intransparent.
Das kann man leicht testen, in dem man die neue SSL-Regel aus der Konfiguration herausnimmt und durch eine der Standardregeln ersetzt. Der Webfilter läuft dann ins Leere, weil der Datenverkehr nicht eingesehen werden kann.
Nachtrag:
Natürlich kann man den Zugriff auch in den IIS-Einstellungen des Exchange abdrehen, aber da man ja nicht weiß, welche Lücken in Zukunft noch bei IIS und Exchange gefunden werden, ist der Datenfluss meiner Meinung nach so früh wie möglich zu unterbinden.
Das kann man natürlich auch noch zusätzlich machen, um sich abzusichern. Z.B., wenn die Lizenz der Fortigate nicht rechtzeitig verlängert wird oder der Webfilter aus anderen Gründen nicht greift.
Vielen Dank, habe ich gut umsetzen können!
Der Ansatz ist gut, aber schon mit geringer krimineller Energie (Eintrag von z.B. mail.fraud.com als Name für die angegriffene Public IP im Hosts-File und Aufruf von https://mail.fraud.com/ecp) auszuhebeln . Mit den beiden Einträgen
*/ecp*
*/owa/auth/logon.aspx?replaceCurrent=1&url=https%3a%2f%2f*%2fecp
jeweils als „Wildcard“ und „Block“ im „Static URL Filter“ sollte die Policy „dicht“ sein.