[[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 [:Lucid:Ubuntu 10.04] durch das Modul [https://modsecurity.org/ ModSecurity] {en}. 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 [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 (Standard: '''/var/www/''') eine Datei '''test.php''' [1][2]und folgendem Inhalt. 

{{{#!code php
<?php
$secret_file = $_GET['secret_file'];
include ( $secret_file);
?>
}}}

Nach einem Neustart des Webservers ist dieses Dokument nun geladen und verfügbar [3]:

{{{#!vorlage Befehl
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]:

{{{#!vorlage Paketinstallation
libapache-mod-security, universe
}}}

= Konfiguration =
== Corerules ==
{{{#!vorlage 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. 
{{{#!code apache
<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/

}}}

{{{#!vorlage Experten
Corerules werden von [http://spiderlabs.github.com/owasp-modsecurity-crs/ modsecurity-corerules] {en} 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: 
{{{#!vorlage Befehl
sudo a2enmod mod-security
}}}

{{{#!vorlage Hinweis
Um Fehlermeldungen auf Grund eines unzureichenden ''Header Response Handlings'' zu erhalten, sollte das Modul [https://httpd.apache.org/docs/2.2/mod/mod_headers.html ModHeaders] {en} aktiviert werden.
}}}

Dies geschieht am einfachsten mit den folgenden Befehlen im Terminal: 

{{{#!vorlage Befehl
sudo a2enmod headers
}}}

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 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.

{{{#!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
<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. 

{{{#!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}
 * [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