TOC

So richten Sie ModSecurity mit Apache unter Ubuntu 14.04 und Debian 8 ein

Einführung

ModSecurity ist eine kostenlose Webanwendungs-Firewall (WAF), die mit Apache, Nginx und IIS funktioniert. Es unterstützt eine flexible Regel-Engine zur Ausführung einfacher und komplexer Vorgänge und verfügt über einen Core Rule Set (CRS), der Regeln für SQL-Injection, Cross Site Scripting, Trojaner, Agenten für ungültige Benutzer, Sitzungsentführung und viele andere Exploits enthält. Für Apache wird es als zusätzliches Modul geladen, das die Installation und Konfiguration vereinfacht.

Voraussetzungen

Um diesem Tutorial zu folgen, benötigen Sie:

Schritt 1 - Installieren von ModSecurity

In diesem Schritt installieren wir ModSecurity.

Aktualisieren Sie zunächst die Paketindexdateien.

sudo apt-get update

Installieren Sie dann ModSecurity.

sudo apt-get install libapache2-mod-security2 -y

Mit dem folgenden Befehl können Sie überprüfen, ob das ModSecurity-Modul geladen wurde.

sudo apachectl -M | grep --color security2

Wenn die Ausgabe "+ security2_module (shared) +" lautet, bedeutet dies, dass das Modul geladen wurde.

Die Installation von ModSecurity enthält eine empfohlene Konfigurationsdatei, die umbenannt werden muss.

sudo mv /etc/modsecurity/modsecurity.conf-recommended /etc/modsecurity/modsecurity.conf

Zuletzt laden Sie Apache neu.

sudo service apache2 reload

Eine neue Protokolldatei für ModSecurity wird im Apache-Protokollverzeichnis unter + / var / log / apache2 / modsec_audit.log + erstellt.

Schritt 2 - Konfigurieren von ModSecurity

ModSecurity ist sofort einsatzbereit, da es Regeln benötigt, um zu funktionieren. In diesem Schritt werden zunächst einige Konfigurationsanweisungen aktiviert.

Um die Konfigurationsanweisungen in diesem Schritt zu finden und zu ersetzen, verwenden wir + sed +, einen Stream-Editor. Sie können die https://www.digitalocean.com/community/tutorial_series/using-sed [+ sed + tutorial series] lesen, um mehr über das Tool zu erfahren.

Zu aktivierende grundlegende Anweisungen

Die Standardkonfigurationsdatei von ModSecurity ist auf "+ DetectionOnly " eingestellt, wodurch Anforderungen gemäß den Übereinstimmungen mit den Regeln protokolliert werden und nichts blockiert wird. Dies kann durch Bearbeiten der Datei " modsecurity.conf " und Ändern der Direktive " SecRuleEngine +" geändert werden. Wenn Sie dies auf einem Produktionsserver ausprobieren, ändern Sie diese Anweisung erst, nachdem Sie alle Ihre Regeln getestet haben.

sudo sed -i "s/SecRuleEngine DetectionOnly/SecRuleEngine On/" /etc/modsecurity/modsecurity.conf

Die Direktive "+ SecResponseBodyAccess +" konfiguriert, ob Antwortkörper gepuffert werden (d. H. gelesen von ModSecurity). Dies ist nur erforderlich, wenn Datenlecksuche und -schutz erforderlich sind. Wenn Sie es daher aktiviert lassen, werden die Droplet-Ressourcen aufgebraucht und die Protokolldatei vergrößert. Daher wird es deaktiviert.

sudo sed -i "s/SecResponseBodyAccess On/SecResponseBodyAccess Off/" /etc/modsecurity/modsecurity.conf

Optionale zu ändernde Anweisungen

Es gibt andere Direktiven, die Sie möglicherweise anpassen möchten, indem Sie "+ / etc / modsecurity / modsecurity.conf " bearbeiten. Die Direktiven ` SecRequestBodyLimit ` und ` SecRequestBodyNoFilesLimit +` begrenzen die maximale Datenmenge, die in Ihre Webanwendung gepostet werden kann.

Insbesondere gibt die Direktive "+ SecRequestBodyLimit " die maximale POST-Datengröße an. Wenn ein Client etwas Größeres sendet, antwortet der Server mit einem Fehler: http://en.wikipedia.org/wiki/List_of_HTTP_status_codes#413[413 Request Entity Too Large]. Wenn Ihre Webanwendung keine Datei-Uploads hat, kann dieser Wert so belassen werden, wie er ist. Der in der Konfigurationsdatei angegebene vorkonfigurierte Wert beträgt 13107200 Byte (12,5 MB). Wenn Sie diesen Wert ändern möchten, suchen Sie die folgende Zeile ` modsecurity.conf +`:

Optionale Änderung der modsecurity.conf-Direktive

SecRequestBodyLimit

In ähnlicher Weise begrenzt "+ SecRequestBodyNoFilesLimit " die Größe der POST-Daten abzüglich der Datei-Uploads. Dieser Wert sollte so niedrig wie möglich eingestellt werden, um die Anfälligkeit für DoS-Angriffe (Denial-of-Service) zu verringern, wenn jemand sehr große Anforderungskörper sendet. Der in der Konfigurationsdatei vorkonfigurierte Wert beträgt 131072 Byte (128 KB). Wenn Sie diesen Wert ändern möchten, suchen Sie die folgende Zeile ` modsecurity.conf +`:

Optionale Änderung der modsecurity.conf-Direktive

SecRequestBodyNoFilesLimit

Eine Anweisung, die sich auf die Serverleistung auswirkt, lautet "+ SecRequestBodyInMemoryLimit ". Diese Richtlinie ist so gut wie selbsterklärend. Es gibt an, wie viele „Request Body“ -Daten (POSTed Data) im Arbeitsspeicher (RAM) gespeichert werden sollen. Alle weiteren Daten werden auf der Festplatte abgelegt (genau wie beim Auslagern). Da Droplets SSDs verwenden, ist dies kein großes Problem. Dies kann jedoch geändert werden, wenn Sie Arbeitsspeicher zur Verfügung haben. Der vorkonfigurierte Wert für diese Anweisung beträgt 128 KB. Wenn Sie diesen Wert ändern möchten, suchen Sie die folgende Zeile ` modsecurity.conf +`:

Optionale Änderung der modsecurity.conf-Direktive

SecRequestBodyInMemoryLimit

Schritt 3 - Testen einer SQL-Injection

Bevor wir einige Regeln konfigurieren, erstellen wir ein PHP-Skript, das für SQL-Injection anfällig ist, um den Schutz von ModSecurity zu testen.

Greifen Sie zunächst auf die MySQL-Eingabeaufforderung zu.

mysql -u root -p

Erstellen Sie hier eine MySQL-Datenbank mit dem Namen * sample * und stellen Sie eine Verbindung dazu her.

create database ;
connect ;

Erstellen Sie dann eine Tabelle mit einigen Anmeldeinformationen - dem Benutzernamen * sammy * und dem Passwort * password *.

create table users(username VARCHAR(100),password VARCHAR(100));
insert into users values('sammy','password');

Beenden Sie abschließend die MySQL-Eingabeaufforderung.

quit;

Als nächstes erstellen Sie das Anmeldeskript im Apache-Dokumentenstamm.

sudo nano /var/www/html/login.php

Fügen Sie das folgende PHP-Skript in die Datei ein. Stellen Sie sicher, dass Sie das MySQL-Passwort im folgenden Skript in das zuvor festgelegte Passwort ändern, damit das Skript eine Verbindung zur Datenbank herstellen kann:

/var/www/html/login.php

<html>
<body>
<?php
   if(isset($_POST['login']))
   {
       $username = $_POST['username'];
       $password = $_POST['password'];
       $con = mysqli_connect('localhost','root','','sample');
       $result = mysqli_query($con, "SELECT * FROM `users` WHERE username='$username' AND password='$password'");
       if(mysqli_num_rows($result) == 0)
           echo 'Invalid username or password';
       else
           echo '<h1>Logged in</h1><p>This is text that should only be displayed when logged in with valid credentials.</p>';
   }
   else
   {
?>
       <form action="" method="post">
           Username: <input type="text" name="username"/><br />
           Password: <input type="password" name="password"/><br />
           <input type="submit" name="login" value="Login"/>
       </form>
<?php
   }
?>
</body>
</html>

Dieses Skript zeigt ein Anmeldeformular an. Öffnen Sie Ihren Browser und navigieren Sie zu "+ http: /// login.php +", um ihn anzuzeigen. Wenn Sie das richtige Paar von Anmeldeinformationen eingeben, z. sammy im Feld * Benutzername * und Passwort im Feld * Passwort * sehen Sie die Meldung * Dies ist Text, der nur angezeigt wird, wenn Sie mit gültigen Zugangsdaten angemeldet sind *. Wenn Sie zum Anmeldebildschirm zurückkehren und falsche Anmeldeinformationen verwenden, wird die Meldung * Ungültiger Benutzername oder ungültiges Kennwort * angezeigt.

Der nächste Job besteht darin, eine SQL-Injection zu versuchen, um die Anmeldeseite zu umgehen. Geben Sie im Feld Benutzername Folgendes ein.

Benutzername für SQL Injection

' or true --

Beachten Sie, dass nach "+ - +" ein Leerzeichen stehen sollte, damit diese Injektion funktioniert. Lassen Sie das Passwortfeld leer und klicken Sie auf den Login-Button. Das Skript zeigt die Nachricht an, die für authentifizierte Benutzer bestimmt ist! Im nächsten Schritt werden wir dies verhindern.

Schritt 4 - Regeln einrichten

In diesem Schritt richten wir einige ModSecurity-Regeln ein.

Aktivieren des CRS

Zur Vereinfachung gibt es eine Reihe von Regeln, die bereits zusammen mit ModSecurity installiert sind. Diese werden als CRS (Core Rule Set) bezeichnet und befinden sich im Verzeichnis "+ / usr / share / modsecurity-crs ". Um diese Regeln zu laden, müssen wir Apache so konfigurieren, dass er " .conf " - Dateien in diesen Verzeichnissen liest. Öffnen Sie daher die " security2.conf +" - Datei zum Bearbeiten.

sudo nano /etc/apache2/mods-enabled/security2.conf

Fügen Sie die beiden folgenden rot hervorgehobenen Anweisungen vor der letzten Zeile in der Datei ein (+ </ IfModule> +).

Aktualisierte security2.conf

       IncludeOptional /etc/modsecurity/*.conf


</IfModule>

Speichern und schließen Sie die Datei.

Ausschließen von Verzeichnissen / Domänen (optional)

Manchmal ist es sinnvoll, ein bestimmtes Verzeichnis oder einen Domänennamen auszuschließen, wenn eine Anwendung wie phpMyAdmin ausgeführt wird, da ModSecurity SQL-Abfragen blockiert. Es ist auch besser, Admin-Backends von CMS-Anwendungen wie WordPress auszuschließen. Wenn Sie dieses Lernprogramm auf einem neuen Server ausführen, können Sie diesen Schritt überspringen.

Um ModSecurity für einen vollständigen VirtualHost zu deaktivieren, platzieren Sie die folgenden Anweisungen in den Block + <VirtualHost> […​] </ VirtualHost> + in seiner virtuellen Hostdatei.

<IfModule security2_module>
   SecRuleEngine Off
</IfModule>

Um ein bestimmtes Verzeichnis wegzulassen (zum Beispiel "+ / var / www / wp-admin"):

<Directory "">
   <IfModule security2_module>
       SecRuleEngine Off
   </IfModule>
</Directory>

Wenn Sie ModSecurity in einem Verzeichnis nicht vollständig deaktivieren möchten, verwenden Sie die Direktive "+ SecRuleRemoveById +", um eine bestimmte Regel oder Regelkette durch Angabe ihrer ID zu entfernen.

<LocationMatch "">
   <IfModule security2_module>
       SecRuleRemoveById
   </IfModule>
</LocationMatch>

Aktivieren der SQL-Injection-Regel

Als nächstes werden wir die SQL-Injektionsregeldatei aktivieren. Die erforderlichen Regeldateien sollten mit dem Verzeichnis "+ activated_rules " verknüpft sein, das dem Verzeichnis " mods-enabled " von Apache ähnelt. Wechseln Sie in das Verzeichnis " activated_rules +".

cd /usr/share/modsecurity-crs/activated_rules/

Erstellen Sie dann einen symbolischen Link aus der Datei + modsecurity crs_41_sql_injection_attacks.conf.

sudo ln -s ../base_rules/modsecurity_crs_41_sql_injection_attacks.conf .

Laden Sie abschließend Apache neu, damit die Regeln wirksam werden.

sudo service apache2 reload

Öffnen Sie nun die zuvor erstellte Anmeldeseite und versuchen Sie, dieselbe SQL-Injection-Abfrage im Feld Benutzername zu verwenden. Da wir in Schritt 2 die Direktive "+ SecRuleEngine " in " On " geändert haben, wird der Fehler "* 403 Forbidden *" angezeigt. (Wenn " SecRuleEngine " der Option " DetectionOnly " überlassen wurde, ist die Injektion erfolgreich, aber der Versuch wird in der Datei " modsec_audit.log +" protokolliert.)

Da dieses PHP-Anmeldeskript nur zum Testen von ModSecurity gedacht ist, sollten Sie es jetzt nach Abschluss des Tests entfernen.

sudo rm /var/www/html/login.php

Schritt 5 - Schreiben Sie Ihre eigenen Regeln

In diesem Abschnitt erstellen wir eine Regelkette, die die Anforderung blockiert, wenn bestimmte häufig mit Spam verbundene Wörter in ein HTML-Formular eingegeben werden.

Zunächst erstellen wir ein PHP-Beispielskript, das die Eingabe aus einem Textfeld abruft und dem Benutzer wieder anzeigt. Öffne eine Datei mit dem Namen "+ from.php" zum Bearbeiten.

sudo nano /var/www/html/form.php

Fügen Sie den folgenden Code ein:

/var/www/html/form.php

<html>
   <body>
       <?php
           if(isset($_POST['data']))
               echo $_POST['data'];
           else
           {
       ?>
               <form method="post" action="">
                       Enter something here:<textarea name="data"></textarea>
                       <input type="submit"/>
               </form>
       <?php
           }
       ?>
   </body>
</html>

Benutzerdefinierte Regeln können zu jeder Konfigurationsdatei hinzugefügt oder in ModSecurity-Verzeichnissen abgelegt werden. Wir werden unsere Regeln in einer separaten neuen Datei mit dem Namen "+ modsecurity_custom_rules.conf +" ablegen.

sudo nano /etc/modsecurity/.conf

Fügen Sie Folgendes in diese Datei ein. Die beiden Wörter, die wir blockieren, sind * blockiertesWort1 * und * blockiertesWort2 *.

modsecurity_custom_rules.conf

SecRule REQUEST_FILENAME "form.php" "id:'400001',chain,deny,log,msg:'Spam detected'"
SecRule REQUEST_METHOD "POST" chain
SecRule REQUEST_BODY "@rx (?i:(|))"

Die Syntax für "+ SecRule " lautet " SecRule VARIABLES OPERATOR [ACTIONS] ". Hier haben wir die Kettenaktion verwendet, um die Variablen " REQUEST_FILENAME " mit " form.php ", " REQUEST_METHOD " mit " POST " und " REQUEST_BODY " mit dem regulären Ausdruck " (@ rx) " string "abzugleichen + (BlockiertesWort1 | BlockiertesWort2) + `. Das "? I: " führt eine Übereinstimmung ohne Berücksichtigung der Groß- / Kleinschreibung durch. Bei einer erfolgreichen Übereinstimmung aller dieser drei Regeln wird die Meldung " ACTION " abgelehnt und mit der Meldung " msg Spam detect" protokolliert. + "Die Kettenaktion simuliert das logische UND, um alle drei Regeln zu erfüllen.

Speichern Sie die Datei und laden Sie Apache neu.

sudo service apache2 reload

Öffnen Sie "+ http: /// form.php +" im Browser. Wenn Sie Text eingeben, der BlockiertesWort1 oder BlockiertesWort2 enthält, wird eine Seite 403 angezeigt.

Da dieses PHP-Formularskript nur zum Testen von ModSecurity gedacht ist, sollten Sie es jetzt entfernen, nachdem der Test durchgeführt wurde.

sudo rm /var/www/html/form.php

Fazit

In diesem Tutorial haben Sie gelernt, wie Sie ModSecurity installieren und konfigurieren und benutzerdefinierte Regeln hinzufügen. Weitere Informationen finden Sie in der official ModSecurity-Dokumentation.

Related