[[Vorlage(Archiviert)]] {{{#!vorlage Wissen [:Editor: Einen Editor verwenden] [:sudo: Root-Rechte] [:Terminal: Ein Terminal öffnen] [:Pakete installieren: Installation von Programmen] }}} [[Inhaltsverzeichnis(1)]] Dieser Artikel beschränkt sich auf die Sicherung des Webservers [:Apache:] unter [:Trusty:Ubuntu 14.04] durch das Modul [https://modsecurity.org/ ModSecurity] {en}. Einen übergeordneten Artikel findet man im Wiki unter [:Apache/Sicherheit:]. mod_security arbeitet ähnlich einem [wikipedia:Intrusion_Prevention_System: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 [:MySQL/Werkzeuge#phpMyAdmin:phpMyAdmin]. Fehler und Blockade mit der dazugehörigen ID sind gelb hervorgehoben: >Sat Dec 15 21:18:45 2012] [mark][error][/mark] [client 221.345.123.67] ModSecurity: [mark]Access denied with code 403 (phase 1)[/mark]. 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"] [mark][id "981060"][/mark] [msg "Warning - Sticky SessionID Data Changed - User-Agent Mismatch."] [hostname "meinedomain.net"] [uri "/phpmyadmin/js/cross_framing_protection.js"] [unique_id "UMzbJX8AAQEAACPAHPMAAAAJ"] {{{#!vorlage Warnung 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: {{{#!code php }}} 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]: {{{#!vorlage Paketinstallation libapache2-mod-security2, universe }}} Anschließend muss das Modul noch aktiviert werden. Dies geschieht am einfachsten mit den folgenden Befehlen im Terminal: {{{#!vorlage Befehl sudo a2enmod security2 }}} {{{#!vorlage Hinweis Um Fehlermeldungen auf Grund eines unzureichenden ''Header Response Handlings'' zu erhalten, sollte das Modul [https://httpd.apache.org/docs/2.4/mod/mod_headers.html ModHeaders] {en} aktiviert werden. Dies geschieht am einfachsten mit den folgenden Befehlen im Terminal: {{{#!vorlage Befehl sudo a2enmod headers \}}} }}} = Konfiguration = == Corerules == {{{#!vorlage 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: {{{#!vorlage Befehl 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. {{{#!code apache # -- 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/'''. {{{#!code apache # -- 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 "\.\." .... ... .. . }}} {{{#!vorlage Experten Corerules werden von [http://spiderlabs.github.com/owasp-modsecurity-crs/ modsecurity-corerules] {en} kontinuierlich weiterentwickelt und stehen zum Download zur Verfügung. }}} {{{#!vorlage 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: {{{#!code apache # -- Audit log configuration ------------------------------------------------- \}}} Hier kann man den Absatz wie folgend editieren: {{{#!code apache # 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. {{{#!vorlage Befehl 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. {{{#!vorlage Warnung 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. }}} {{{#!code apache # -- 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 SecRuleRemoveById 981143,981185,981186,981203,981144,981060,981184,981203 # -- 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 .... ... .. . }}} {{{#!vorlage 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: {{{#!code apache # -- Debug log configuration ------------------------------------------------- \}}} Hier kann man den Absatz wie folgend editieren: {{{#!code apache # 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. {{{#!vorlage Befehl 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 = * [https://modsecurity.org/ ModSecurity] {en} * [https://modsecurity.comodo.com/ ModSecurity Overview] {en} * [http://spiderlabs.github.com/owasp-modsecurity-crs/ modsecurity-corerules] {en} ## * [:Apache:Apache 2.2] und * [:Apache_2.4:] - Hauptartikel * [:Apache/Sicherheit:] {Übersicht} Übersichtsartikel #tag: Apache, Internet, Sicherheit, Server