Dieser Artikel wurde archiviert, da er - oder Teile daraus - nur noch unter einer älteren Ubuntu-Version nutzbar ist. Diese Anleitung wird vom Wiki-Team weder auf Richtigkeit überprüft noch anderweitig gepflegt. Zusätzlich wurde der Artikel für weitere Änderungen gesperrt.
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 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"]
Apache-Module sollte man immer in ihren /etc/apache2/mods-available/*.conf-Dateien ändern, nie in ihren /etc/apache2/mods-enabled/*.load-Dateien!
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!
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/ |
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
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
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.
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.
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
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
Diese Revision wurde am 2. August 2015 14:52 von aasche erstellt.