Apache als Reverse Proxy für Exchange Server (Teil 2)

Im ersten Teil des Artikels wurde die Installation und Konfiguration von Apache als Reverse Proxy für Exchange Server durchgeführt, dieser Artikel kümmert sich um die Installation und Konfiguration von ModSecurity als Web Application Firewall für Exchange 2019. Bei ModSecurity handelt es sich um eine Open Source Web Application Firewall, welche mit einem entsprechenden Regelwerk, Exchange vor gängigen Angriffen schützen kann.

Installation von ModSecurity und OWASP ModSecurity Core Rule Set

Zunächst wird das Apache Modul modSecurity installiert und aktiviert:

apt-get install libapache2-mod-security2
a2enmod security2
mv /etc/modsecurity/modsecurity.conf-recommended /etc/modsecurity/modsecurity.conf
systemctl restart apache2

Jetzt kann das Regelwerk OWASP ModSecurity Core Rule Set runtergeladen und in die Konfiguration eingebunden werden:

cd /tmp
wget https://github.com/coreruleset/coreruleset/archive/refs/tags/v3.3.2.tar.gz
tar xvf v3.3.2.tar.gz
mkdir /etc/apache2/modsecurity-crs/
mv coreruleset-3.3.2/ /etc/apache2/modsecurity-crs/
cd /etc/apache2/modsecurity-crs/coreruleset-3.3.2/
mv crs-setup.conf.example crs-setup.conf

In der Datei „/etc/apache2/mods-enabled/security2.conf“ muss nun die Zeile „IncludeOptional /usr/share/modsecurity-crs/*.load“ auskommentiert und durch die folgenden beiden Zeilen hinzugefügt werden:

IncludeOptional /etc/apache2/modsecurity-crs/coreruleset-3.3.2/crs-setup.conf
IncludeOptional /etc/apache2/modsecurity-crs/coreruleset-3.3.2/rules/*.conf
Apache als Reverse Proxy für Exchange Server (Teil 2)

Um ModSecurity zu aktivieren kann jetzt einmal die Apache Konfiguration überprüft und anschließend neu gestartet werden:

apache2ctl -t
systemctl restart apache2

Anpassung der OWASP Regeln für Exchange 2019

Dazu wird die Datei „/etc/apache2/sites-available/001-exchange-proxy.conf“ angepasst. Für MapiOverHTTP liefern beispielsweise die folgenden 3 Regeln False/Positives:

  • 920420
  • 949110
  • 980120

Diese 3 Regeln können im Abschnitt „MAPIoverHTTP“ wie folgt deaktiviert werden:

<LocationMatch "/mapi/*">
SecRuleRemoveById 920420 949110 980120
</LocationMatch>
Apache

Für EWS sind ein paar müssen die folgenden Regeln abgeschaltet werden:

  • 921130
  • 941100
  • 941130
  • 941140
  • 941160
  • 941180
  • 941190
  • 941250
  • 941260
  • 949110
  • 980130

Im Abschnitt „EWS“ wird daher der folgende Block eingefügt:

<LocationMatch "/EWS/Exchange.asmx">
SecRuleRemoveById 921130 941100 941130 941140 941160 941180 941190 941250 941260 949110 980130
</LocationMatch>
Apache

Wie zu erkennen ist, wird mit „LocationMatch“ die URI angegeben und mit „SecRuleRemoveById“die Regeln, welche abgeschaltet werden sollen.

Das Logfile „/var/log/apache2/exchange_443_error.log“ liefert Hinweise, welche Regeln Probleme verursachen können. Da ModSecurity in der Standardeinstellung auf „DetectOnly“ steht, also nur protokolliert, aber nichts blockiert, kann man in aller Ruhe schauen, welche Regeln problematisch sind. Das Log lässt sich beispielsweise mit dem folgenden Befehl live verfolgen:

tail -f /var/log/apache2/exchange_443_error.log

Bevor ModSecurity in den Blocking-Modus versetzt werden kann, müssen jetzt also möglichst viele Funktionen getestet werden. In Outlook sollten daher möglichst viele Funktionen ausprobiert werden, in OWA möglichst viel angeklickt werden. Programme und Tools welche auf Exchange Schnittstellen wie EWS zugreifen, getestet werden.

Wenn man sich das Log mit „tail“ anschaut, wird man wahrscheinlich schnell von der Masse der Einträge erschlagen, daher kann der folgende Befehl nur die nötigsten Informationen zu Regeln auflisten, welche im Log angeschlagen haben:

grep ModSecurity /var/log/apache2/exchange_443_error.log | grep "\[id" | sed -E -e 's#^.*\[id "([0-9]*).*hostname "([a-z0-9\-\_\.]*)"].*uri "(.*?)".*"#\1 \2 \3#' | cut -d\" -f1 | sort -n | uniq -c | sort -n
ModSecurity

Mit dem Befehl lässt sich erkennen, welche Regeln auf welche URIs angeschlagen haben. Der Screenshot zeigt beispielsweise die Regeln für OWA. Ich habe immer ein Protokoll/Programm nach dem anderen getestet, zunächst Outlook, dann Autodiscover, dann EWS, zum Schluss OWA.

Da jede Exchange Installation anders ist und sich die verwendeten Programme/Tools unterscheiden, muss jeder für sich die richtigen Regeln identifizieren. Wie bereits erwähnt arbeitet ModSecurity erst einmal nur Modus „DetectOnly“, wenn alle wichtigen Funktionen getestet wurden (ActiveSync nicht vergessen), dann kann ModSecurity in den „Blocking Modus“ geschaltet werden. Dazu wird die Datei „/etc/modsecurity/modsecurity.conf“ bearbeitet und der Wert für „SecRuleEngine“ auf „On“ gesetzt:

ModSecurity

Danach noch einmal Apache neustarten:

systemctl restart apache2

Wer möchte kann zum Schluss noch bekannte schädliche IP Adressen sperren, dazu kann das „Project Honeypot“ verwendet werden. Alles was dazu nötig ist, ist ein kostenloser Account bei Project Honeypot und einen entsprechenden API Key:

Project HoneyPot

In der Datei „/etc/apache2/modsecurity-crs/coreruleset-3.3.2/crs-setup.conf“ kann der API Schlüssel eingetragen und die Konfiguration aktiviert werden:

Project HoneyPot

Zum guter Letzt noch einmal Apache neu starten und wieder ausgiebig testen.

7 Gedanken zu „Apache als Reverse Proxy für Exchange Server (Teil 2)“

  1. Hallo und guten Abend,

    bin wieder begeistert von deinen Anleitungen, nur ein kleiner Hinweis, was mir ein wenig Schweißperlen eingebracht hat..

    hatte „SecRuleEngine“ auf „On“ gestellt und danach ging etwas leider nicht mehr. Also wollte ich wieder zurückstellen, und der korrekte Wert um wieder auf den „Beobachtungsmodus“ zu kommen lautet „SecRuleEngine DetectionOnly“ und nicht „DetectOnly“. Nimmt man „DetectOnly“ kommt der Apache nicht mehr zurück und verweigert den Start.

    Viele Grüße und immer weiter so!

    Alex

    Antworten
  2. Hallo,
    ich hätte da noch eine Frage/kleines Problem…. vielleicht hat jemand eine Antwort, ich habe leider noch nichts gefunden.

    Wenn ich „SecRuleEngine“ auf „On“ stelle, werden Mails über ActiveSync nicht mehr versendet, sobald ein etwas größerer Anhang der Mail beigefügt ist. Sobald ich wieder auf „DetectionOnly“ zurück gehe, wird die Mail korrekt versendet.

    Von daher vermute ich, dass es irgendwo noch einen Parameter gibt, welcher hier auf die Größe wirkt, nur leider finde ich den nicht.

    Vielen Dank schon einmal für eine Rückmeldung, ob das Problem auch bei anderen Auftritt!

    Viele Grüße
    Alex

    Antworten
    • …okay, gefunden…

      in der „/etc/modsecurity/modsecurity.conf“ müssen die Werte „SecRequestBodyLimit“, „SecRequestBodyNoFilesLimit“ und „SecRequestBodyInMemoryLimit“ entsprechend konfiguriert werden, um Mails größer als 128 KB versenden zu können.

      Antworten
  3. ich möchte mich der Frage von MaGo anschließen was die Verwendung für Exchange 2016 betrifft
    Ich habe die mal testweise installiert, jedoch bekomme ich andere Ergebnisse bei den Abfragen der Logs als hier aufgezeigt

    Antworten
    • das Suchen der passenden ID’s nimmt etwas Zeit in Anspruch
      funktioniert gut, nur habe ich die SecRuleRemoveById nicht bei /EWS sondern bei /owa/* eingetragen, ansonsten ging z.B. senden oder löschen nicht etc.

      Antworten

Schreibe einen Kommentar