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.

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

Schreibe einen Kommentar