Apache/mod security

Dieser Artikel wurde für die folgenden Ubuntu-Versionen getestet:

Dieser Artikel ist mit keiner aktuell unterstützten Ubuntu-Version getestet! Bitte hilf mit, indem du diesen Artikel testest. Wiki/FAQ - häufig gestellte Fragen (Abschnitt „Wikiartikel-testen“).

Zum Verständnis dieses Artikels sind folgende Seiten hilfreich:

  1. Einen Editor verwenden

  2. Root-Rechte

  3. Ein Terminal öffnen

  4. Installation von Programmen

Inhaltsverzeichnis
  1. Vorbereitung
  2. Installation
  3. Konfiguration
  4. Kontrolle
  5. Problembehebung
  6. Links

Dieser Artikel beschränkt sich auf die Sicherung des Webservers Apache unter Ubuntu 14.04 durch das Modul ModSecurity 🇬🇧. Einen übergeordneten Artikel findet man im Wiki unter Apache/Sicherheit.

mod_security arbeitet ähnlich einem Intrusion Prevention System (IPS). Die Entwickler des Moduls nennen die Regeln corerules. Wird gegen eine dieser corerules verstoßen, so wird dies vom Modul aktiv gemeldet. Hier ist zwischen einer Warnung und einem Fehler zu unterscheiden. Fehler werden mit einer ID versehen. Bei einem Fehler wird der Netzwerkverkehr des anfragenden Clients blockiert. Die Meldungen werden in der /var/log/apache2/error.log ausgegeben. Zudem führt das Modul unter /var/log/apache2/modsec_audit.log eine ausführliche Protokolldatei.

Hier ein Beispiel für einen Fehler mit phpMyAdmin. Fehler und Blockade mit der dazugehörigen ID sind gelb hervorgehoben:

Sat Dec 15 21:18:45 2012] [error] [client 221.345.123.67] ModSecurity: Access denied with code 403 (phase 1). Match of "streq %{SESSION.UA}" against "TX:ua_hash" required. [file "/usr/share/modsecurity-crs/optional_rules/modsecurity_crs_16_session_hijacking.conf"] [line "35"] [id "981060"] [msg "Warning - Sticky SessionID Data Changed - User-Agent Mismatch."] [hostname "meinedomain.net"] [uri "/phpmyadmin/js/cross_framing_protection.js"] [unique_id "UMzbJX8AAQEAACPAHPMAAAAJ"]

Achtung!

Apache-Module sollte man immer in ihren /etc/apache2/mods-available/*.conf-Dateien ändern, nie in ihren /etc/apache2/mods-enabled/*.load-Dateien!

Vorbereitung

Um überprüfen zu können, ob dieses Modul auch ordnungsgemäß arbeitet, gibt es eine denkbar einfache Lösung. Man erstellt im document-root des Webservers eine Datei test.php [1][2] und folgendem Inhalt:

1
2
3
4
<?php
$secret_file = $_GET['secret_file'];
include ( $secret_file);
?>

Ruft man nun in einem beliebigen Browser die URL http://SERVER_IP_ODER_NAME/test.php?secret_file=/etc/passwd auf, wird die Datei /etc/passwd angezeigt, was sicherlich nicht im Sinne des Serverbetreibers ist...

Installation

mod_security ist direkt in den Paketquellen von Ubuntu enthalten. Benötigt wird folgendes Paket [4]:

Wiki/Vorlagen/Installbutton/button.png mit apturl

Paketliste zum Kopieren:

sudo apt-get install libapache2-mod-security2 

sudo aptitude install libapache2-mod-security2 

Anschließend muss das Modul noch aktiviert werden. Dies geschieht am einfachsten mit den folgenden Befehlen im Terminal:

sudo a2enmod security2 

Hinweis:

Um Fehlermeldungen auf Grund eines unzureichenden Header Response Handlings zu erhalten, sollte das Modul ModHeaders 🇬🇧 aktiviert werden. Dies geschieht am einfachsten mit den folgenden Befehlen im Terminal:

sudo a2enmod headers 

Konfiguration

Corerules

Hinweis:

Die Konfigurationsdateien für dieses Modul befindet sich unter /etc/modsecurity/modsecurity.conf-recommended.

Damit Apache diese Konfigurationsdatei auch lädt, kopiert man diese:

sudo cp /etc/modsecurity/modsecurity.conf-recommended /etc/modsecurity/modsecurity.conf 

Öffnet man nun die Datei /etc/modsecurity/modsecurity.conf mit einem beliebigen Texteditor, befindet sich das Modul im Erkennungsmodus (Detectionmode). In diesem Modus werden keine corerules geladen und es wird daher kein Client aktiv blockiert.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
# -- Rule engine initialization ----------------------------------------------

# Enable ModSecurity, attaching it to every transaction. Use detection
# only to start with, because that minimises the chances of post-installation
# disruption.
#
SecRuleEngine DetectionOnly # Operationsmodus

#SecFilterSelective SCRIPT_FILENAME "export\.php$" chain
#SecFilterSelective ARG_what "\.\."
...
...
..
.

Mit der Installation von mod_security werden corerules mitgeliefert, die jedoch in der Voreinstellung nicht geladen werden. Hierzu muss man die Datei /etc/modsecurity/modsecurity.conf bearbeiten. Die Datei sollte am Beginn den Befehl SecRuleEngine On beinhalten. Ebenso muss der Pfad zu den corerules angegeben werde. Die mitgelieferten corerules befinden sich im Verzeichnis /usr/share/modsecurity-crs/.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
# -- Rule engine initialization ----------------------------------------------

# Enable ModSecurity, attaching it to every transaction. Use detection
# only to start with, because that minimises the chances of post-installation
# disruption.
#
#SecRuleEngine DetectionOnly
#
SecRuleEngine On                                   

Include /usr/share/modsecurity-crs/*.conf
Include /usr/share/modsecurity-crs/base_rules/*.conf
Include /usr/share/modsecurity-crs/optional_rules/*.conf

#SecFilterSelective SCRIPT_FILENAME "export\.php$" chain
#SecFilterSelective ARG_what "\.\."
....
...
..
.

Experten-Info:

Corerules werden von modsecurity-corerules 🇬🇧 kontinuierlich weiterentwickelt und stehen zum Download zur Verfügung.

Hinweis:

Per Voreinstellung schreibt das Modul seine Ausgaben nach /opt/modsecurity/var/audit/. Möchte man dies ändern, sucht man in der Datei /etc/modsecurity/modsecurity.conf (unter Ubuntu 12.04 /etc/apache2/conf.d/modsecurity.conf) nach dem Absatz:

1
# -- Audit log configuration -------------------------------------------------

Hier kann man den Absatz wie folgend editieren:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
# Log the transactions that are marked by a rule, as well as those that
# trigger a server error (determined by a 5xx or 4xx, excluding 404,
# level response status codes).
.
..
...
# Use a single file for logging. This is much easier to look at, but
# assumes that you will use the audit log only ocassionally.
#
SecAuditLogType Serial

# Specify the path for concurrent audit logging.
#SecAuditLogStorageDir /opt/modsecurity/var/audit/
SecAuditLog /var/log/apache2/modsec_audit.log
...
..
.

Die Konfiguration mit aktiven corerules wird nun neu geladen.

sudo service apache2 restart
sudo service apache2 force-reload 

Kontrolle

Mit dem zu Beginn erstellten Dokument kann man kontrollieren, ob das Modul auch adäquat arbeitet. Man ruft in einem beliebigen Browser die URL http://SERVER_IP_ODER_NAME/test.php?secret_file=/etc/passwd auf. Erhält man ein "HTTP 403 -access denied", arbeitet das Modul wie vorgesehen.

Anwendungen/Dienste ausschließen

Wenn man Anwendungen/Dienste am Webserver erreichen will, wird mod_security dies verweigern. Wie am obigen Beispiel mit phpMyAdmin deutlich wird, kann man nun auf Grund der Fehlermeldungen in der /var/log/apache2/error.log die Fehler-IDs filtern und freigeben.

Achtung!

Je weniger Fehler-IDs man freigibt, desto klüger. Des Weiteren sollte man für jede/n Anwendung/Dienst die Fehler-IDs individuell herausarbeiten. Generell alle Fehler freizugeben, kommt einem Untergraben von mod_security gleich und hebelt damit dessen Wirkung aus.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
# -- Rule engine initialization ----------------------------------------------

# Enable ModSecurity, attaching it to every transaction. Use detection
# only to start with, because that minimises the chances of post-installation
# disruption.
#
#SecRuleEngine DetectionOnly
SecRuleEngine On

Include /usr/share/modsecurity-crs/*.conf
Include /usr/share/modsecurity-crs/base_rules/*.conf
Include /usr/share/modsecurity-crs/optional_rules/*.conf

#SecFilterSelective SCRIPT_FILENAME "export\.php$" chain
#SecFilterSelective ARG_what "\.\."

#Rule to exclude phpmyadmin
<LocationMatch '^/phpmyadmin/'>
SecRuleRemoveById 981143,981185,981186,981203,981144,981060,981184,981203
</LocationMatch>

# -- Request body handling ---------------------------------------------------

# Allow ModSecurity to access request bodies. If you don't, ModSecurity
# won't be able to see any POST parameters, which opens a large security
# hole for attackers to exploit.
#
SecRequestBodyAccess On
....
...
..
.

Hinweis:

Wenn man eine sehr ausführliche debug-Informationen des Moduls erhalten möchte, sucht man in der /etc/apache2/conf.d/modsecurity.conf nach dem Absatz:

1
# -- Debug log configuration -------------------------------------------------

Hier kann man den Absatz wie folgend editieren:

1
2
3
4
5
6
7
# The default debug log configuration is to duplicate the error, warning
# and notice messages from the error log.
#
#SecDebugLog /opt/modsecurity/var/log/debug.log
#SecDebugLogLevel 3
SecDebugLog /var/log/apache2/modsec_debug.log
SecDebugLogLevel 5

"SecDebugLogLevel 5" stellt die ausführlichste Ausgabe dar.

Nach einem neuerlichen Laden der Konfiguration, kann man nun (wie im Beispiel am Anfang des Artikels beschrieben) auf phpMyAdmin zugreifen.

sudo service apache2 restart
sudo service apache2 force-reload 

Problembehebung

Dieses Modul arbeitet nur mit dem Webserver Apache. Fehler sind in den folgenden Log-Dateien ersichtlich: