Ubuntu 14.04 Trusty Tahr
Ubuntu 12.04 Precise Pangolin
Dieser Artikel beschränkt sich auf die Sicherung des Webservers Apache unter Ubuntu 14.04 und Ubuntu 12.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"]
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 des Webservers eine Datei test.php [1][2] und folgendem Inhalt:
1 2 3 4 | <?php $secret_file = $_GET['secret_file']; include ( $secret_file); ?> |
Anschließend muss der Webserver neu gestartet werden [3]:
sudo service apache2 reload
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...
mod_security ist direkt in den Paketquellen von Ubuntu enthalten. Benötigt wird folgendes Paket [4]:
libapache2-mod-security2 (universe)
mit apturl
Paketliste zum Kopieren:
sudo apt-get install libapache2-mod-security2
sudo aptitude install libapache2-mod-security2
libapache2-modsecurity (universe)
mit apturl
Paketliste zum Kopieren:
sudo apt-get install libapache2-modsecurity
sudo aptitude install libapache2-modsecurity
Anschließend muss das Modul noch aktiviert werden. Dies geschieht am einfachsten mit den folgenden Befehlen im Terminal:
Ubuntu 14.04:
sudo a2enmod security2
Ubuntu 12.04:
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 Konfigurationsdateien für dieses Modul befindet sich unter /etc/modsecurity/modsecurity.conf-recommended und in Ubuntu 12.04 unter /etc/apache2/mods-available/mod-security.conf.
Damit Apache diese Konfigurationsdatei auch lädt, kopiert man diese:
Ubuntu 14.04:
sudo cp /etc/modsecurity/modsecurity.conf-recommended /etc/modsecurity/modsecurity.conf
Ubuntu 12.04:
sudo cp /etc/modsecurity/modsecurity.conf-recommended /etc/apache2/conf.d/modsecurity.conf
Öffnet man nun die Datei /etc/modsecurity/modsecurity.conf (unter Ubuntu 12.04 /etc/apache2/conf.d/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 (unter Ubuntu 12.04 /etc/apache2/conf.d/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 "\.\." .... ... .. . |
Corerules werden von modsecurity-corerules kontinuierlich weiterentwickelt und stehen zum Download zur Verfügung.
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
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.
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 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 .... ... .. . |
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
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 8. März 2016 14:43 von gopi erstellt.