mod security lucid
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 10.04 durch das Modul ModSecurity 🇬🇧. Eine entsprechende Anleitung für Ubuntu 12.04 gibt es unter Archiv/Apache/mod security. 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 (Standard: /var/www/) eine Datei test.php [1][2]und folgendem Inhalt.
1 2 3 4 | <?php $secret_file = $_GET['secret_file']; include ( $secret_file); ?> |
Nach einem Neustart des Webservers ist dieses Dokument nun geladen und verfügbar [3]:
sudo service apache2 reload
Ruft man in einem beliebigen Browser die URL http://SERVER_IP_ODER_NAME/test.php?secret_file=/etc/passwd
auf, wird nun die Datei /etc/passwd im HTML-Format angezeigt!
Installation¶
mod_security ist direkt in den Paketquellen von Ubuntu enthalten. Benötigt wird folgendes Paket [4]:
libapache-mod-security (universe)
Befehl zum Installieren der Pakete:
sudo apt-get install libapache-mod-security
Oder mit apturl installieren, Link: apt://libapache-mod-security
Konfiguration¶
Corerules¶
Hinweis:
Mit der Installation von mod_security werden corerules mitgeliefert, die jedoch in der Voreinstellung nicht geladen werden. Hierzu kann man die Datei /etc/apache2/mods-available/mod-security.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/doc/mod-security-common/examples/rules/.
Die Beispielkonfigurationsdateien für dieses Modul befinden sich unter /usr/share/doc/mod-security-common/examples/modsecurity.conf-minimal und /usr/share/doc/mod-security-common/examples/rules/modsecurity_crs_10_config.conf. Man kann diese Konfigurationsdateien nach einer lokalen Anpassung zur Verwendung bringen. Die folgende Konfigurationsdatei beinhaltet die wesentlichen Operationen der beiden oben genannten Konfigurationsdateien.
Man erstellt mit einem beliebigen Texteditor die Datei /etc/apache2/mods-available/mod-security.conf und folgendem Inhalt.
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 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 | <IfModule mod_security2.c> # Basic configuration options SecRuleEngine On Include /usr/share/doc/mod-security-common/examples/rules/modsecurity_crs_10_global_config.conf Include /usr/share/doc/mod-security-common/examples/rules/optional_rules/*.conf Include /usr/share/doc/mod-security-common/examples/rules/base_rules/*.conf SecRequestBodyAccess On SecResponseBodyAccess Off # Handling of file uploads # TODO Choose a folder private to Apache. # SecUploadDir /opt/apache-frontend/tmp/ SecUploadKeepFiles Off # Debug log SecDebugLog /var/log/apache2/modsec_debug.log SecDebugLogLevel 3 # Serial audit log SecAuditEngine RelevantOnly SecAuditLogRelevantStatus ^5 SecAuditLogParts ABIFHZ SecAuditLogType Serial SecAuditLog /var/log/apache2/modsec_audit.log # Maximum request body size we will # accept for buffering SecRequestBodyLimit 131072 # Store up to 128 KB in memory SecRequestBodyInMemoryLimit 131072 # Buffer response bodies of up to # 512 KB in length SecResponseBodyLimit 524288 # Verify that we've correctly processed the request body. # As a rule of thumb, when failing to process a request body # you should reject the request (when deployed in blocking mode) # or log a high-severity alert (when deployed in detection-only mode). SecRule REQBODY_PROCESSOR_ERROR "!@eq 0" \ "phase:2,t:none,log,deny,msg:'Failed to parse request body.',severity:2" # By default be strict with what we accept in the multipart/form-data # request body. If the rule below proves to be too strict for your # environment consider changing it to detection-only. You are encouraged # _not_ to remove it altogether. SecRule MULTIPART_STRICT_ERROR "!@eq 0" \ "phase:2,t:none,log,deny,msg:'Multipart request body \ failed strict validation: \ PE %{REQBODY_PROCESSOR_ERROR}, \ BQ %{MULTIPART_BOUNDARY_QUOTED}, \ BW %{MULTIPART_BOUNDARY_WHITESPACE}, \ DB %{MULTIPART_DATA_BEFORE}, \ DA %{MULTIPART_DATA_AFTER}, \ HF %{MULTIPART_HEADER_FOLDING}, \ LF %{MULTIPART_LF_LINE}, \ SM %{MULTIPART_SEMICOLON_MISSING}, \ IQ %{MULTIPART_INVALID_QUOTING}'" # Did we see anything that might be a boundary? SecRule MULTIPART_UNMATCHED_BOUNDARY "!@eq 0" \ "phase:2,t:none,log,deny,msg:'Multipart parser detected a possible unmatched boundary.'" </IfModule> # Include the virtual host configurations: Include /etc/apache2/sites-enabled/ |
Experten-Info:
Corerules werden von modsecurity-corerules 🇬🇧 kontinuierlich weiterentwickelt und stehen zum Download zur Verfügung.
Anschließend muss das Modul noch aktiviert werden. Dies geschieht am einfachsten mit den folgenden Befehlen im Terminal:
sudo a2enmod mod-security
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
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 501 - method not implemented, 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 | <IfModule mod_security2.c> # Basic configuration options SecRuleEngine On Include /usr/share/doc/mod-security-common/examples/rules/modsecurity_crs_10_global_config.conf Include /usr/share/doc/mod-security-common/examples/rules/optional_rules/*.conf Include /usr/share/doc/mod-security-common/examples/rules/base_rules/*.conf #Rule to exclude phpmyadmin <LocationMatch '^/phpmyadmin/'> SecRuleRemoveById 981143,981185,981186,981203,981144,981060,981184,981203 </LocationMatch> SecRequestBodyAccess On SecResponseBodyAccess Off .... ... .. . |
Nach einem neuerlichen Laden der Konfiguration, kann man nun (wie im obigen Beispiel 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.2 und Apache 2.4 - Hauptartikel
Apache/Sicherheit Übersichtsartikel