ubuntuusers.de

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)

Paketliste zum Kopieren:

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

Diese Revision wurde am 10. Februar 2020 09:53 von Heinrich_Schwietering erstellt.
Die folgenden Schlagworte wurden dem Artikel zugewiesen: Internet, Apache, Server, Sicherheit