mod security
Archivierte Anleitung
Dieser Artikel wurde archiviert. Das bedeutet, dass er nicht mehr auf Richtigkeit überprüft oder anderweitig gepflegt wird. Der Inhalt wurde für keine aktuell unterstützte Ubuntu-Version getestet. Wenn du Gründe für eine Wiederherstellung siehst, melde dich bitte in der Diskussion zum Artikel. Bis dahin bleibt die Seite für weitere Änderungen gesperrt.
Zum Verständnis dieses Artikels sind folgende Seiten hilfreich:
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]:
libapache2-mod-security2 (universe)
Befehl zum Installieren der Pakete:
sudo apt-get install libapache2-mod-security2
Oder mit apturl installieren, Link: apt://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:
/var/log/syslog
/var/log/apache2/access.log
/var/log/apache2/error.log
/var/log/apache2/modsec_audit.log
/var/log/apache2/modsec_debug.log
Links¶
ModSecurity 🇬🇧
Apache 2.4 - Hauptartikel
Apache/Sicherheit Übersichtsartikel