Remo vorstellen - Eine einfache Möglichkeit, eine unsichere Online-Anwendung mit ModSecurity abzusichern

Angenommen, Sie haben eine unangenehme Anwendung auf Ihrem Apache-Webserver, die von einigen Idioten aus der Marketingabteilung installiert wurde und die Sie weder patchen noch entfernen können. Vielleicht liegt es an Ressourcenproblemen, einem Mangel an Know-how, einem Mangel an Quellcode oder möglicherweise sogar aus politischen Gründen. Folglich müssen Sie sie schützen, ohne sie zu berühren. Es gibt ModSecurity, aber man sagt, das sei nur für Experten. Eine einfache Alternative ist Remo, ein grafischer Regel-Editor für ModSecurity, der mit einem Whitelist-Ansatz kommt. Es hat alles, was Sie brauchen, um die Anwendung abzusichern.

Für dieses Tutorial verwenden wir eine wirklich einfache Testanwendung. Eine, die so hässlich ist, dass nicht einmal Ihre Marketingabteilung sie haben möchte. Aber hey, es ist nur ein Tutorial.

';
  echo $_POST['command'];
  echo '
';
  system($_POST['command'], $retval); # benötigt für 'ls' Befehle
  echo '

ls.php: Ein kleines Skript, das Sie besser von Ihrer Seite entfernen, solange Sie können.

Die direkte Ausführung eines beliebigen Shell-Befehls, der in Form des Parameters command übermittelt wird, macht ls.php zu einem unerwünschten Gast auf fast jedem Webserver - oder zu einem perfekten Testfall, um Remo auszuprobieren, um sich vor den Gefahren dieses Skripts zu schützen. Was ist also Remo? Auf remo.netnea.com erfahren Sie, dass es als einfache Möglichkeit gedacht ist, ModSecurity zu konfigurieren, ohne zuerst ein Sicherheitszauberer zu werden. Der zweite Haken ist, dass Remo Whitelist-Regeln schreibt, während die meisten Leute ModSecurity mit einem Blacklisting-Ansatz verwenden. Blacklisting bedeutet, dass Sie ModSecurity alles über alle bekannten Angriffe erzählen. Whitelisting macht es umgekehrt: Es stellt sicher, dass Ihre Anwendung nur die Eingaben erhält, die Sie wirklich möchten. Damit ls.php nur ls-Befehle als seinen Befehlsparameter erhält und darüber hinaus stellen Sie sicher, dass keine schmutzigen Tricks mit Backticks und Semikolons innerhalb des Parameters möglich sind. Kurz gesagt: Remo hilft dabei, die Eingabevalidierung auf dem Server durchzuführen, ohne die Anwendung zu berühren.

Installation

Sie können Remo im Online-Demo auf der Homepage ausprobieren. Diese funktioniert gut, wenn Sie Remo ausprobieren möchten, ohne es zuerst zu installieren. Die Installation ist auch nicht sehr schwierig, selbst ohne aktuelle Distributionspakete. Stellen Sie sicher, dass Sie Ruby, irb und die Ruby-SQLite3-Bindings installiert haben, bevor Sie herunterladen.

Ich habe Folgendes auf meinem Ubuntu-Testrechner gemacht; es sollte auch für Debian funktionieren:

aptitude install ruby irb libsqlite3-ruby1.8

Was Remo betrifft, können Sie entweder eine Version herunterladen oder einen Snapshot des neuesten Subversionsbaums machen. Die Remo-Download-Seite sagt Ihnen, welche Bäume alle Unit-Tests bestanden haben. Angenommen, wir laden eine Version herunter und installieren sie. Gehen Sie zur Download-Seite und holen Sie sich die Beta-Version 0.2.0. Entpacken Sie das Tarball und starten Sie den WEBrick-Rails-Server. Von der Kommandozeile aus reduziert sich das auf:

wget http://remo.netnea.com/files/remo-0.2.0.tar.gz  
tar xvzf remo-0.2.0.tar.gz  
cd remo-0.2.0  
ruby script/server  
direct browser to http://localhost:3000/main/index

Sie sollten etwas wie dies erhalten:

Remo, wie es nach der Installation aussieht.

Wir sind hier ein wenig in Eile, da dieses Tutorial kurz gehalten werden soll. Daher werde ich Ihnen nur die notwendigen Dinge zeigen, um die Testanwendung abzusichern. Eine Art praktischer Leitfaden. Es gibt genügend Zeit für Sie, Remo selbst zu erkunden.

Die Anwendung absichern

Entfernen Sie alle Standardanfragen im Fenster und erstellen Sie eine neue.

Eine neue Anfrage zu Remo hinzufügen.

Klicken Sie auf den Text „klicken, um zu bearbeiten“ und geben Sie den Pfad Ihrer Anwendung ein: /ls.php, ändern Sie dann die HTTP-Methode in POST. Öffnen Sie die Details der Anfrage und fügen Sie einen neuen Post-Parameter mit der Schaltfläche p* neben den Post-Parametern hinzu. Klicken Sie auf den Namen (klicken, um zu bearbeiten) und machen Sie ihn zu command. Dies ist der Parameter, der von unserer Beispielanwendung ls.php übermittelt wird.

Rechts vom Namen befindet sich der Wertebereich des Parameters. Dies ist der zentrale Teil von Remo. Hier definieren Sie, welche Werte für den Parameter akzeptabel sind. Denken Sie daran, dies ist Whitelisting: Wir definieren genau, was akzeptabel ist. Es gibt einige vordefinierte Werte, aber wir müssen in diesem Fall mit „Benutzerdefiniert“ arbeiten. Wenn Sie die Details des Parameters command öffnen, gibt es ein Feld namens „Benutzerdefinierte Regex“. Hier sucht Remo nach dem Regex, wenn der Wertebereich „Benutzerdefiniert“ ist. Ich werde ls[0-9a-zA-Z-\x20_.]{0,64} verwenden. Dies ist der Befehl ls, gefolgt von einer optionalen Gruppe von Zeichen, die aus Zahlen, Buchstaben, Bindestrichen, dem Leerzeichen, dem Unterstrich und dem Punkt bestehen. Kein Semikolon, keine Schrägstriche, keine Backticks, keine deutschen Umlaute, keine Unicode-Sonderzeichen: Dies ist Ihr Server und Sie möchten hier keinen Mist.

Der Schutz für ls.php ist im Gange mit der Definition des POST-Parameters command.

Eine Anfrage, die diese Bedingung nicht erfüllt, schlägt fehl. Das Standardverhalten von Apache bei einer fehlgeschlagenen Anfrage besteht darin, einen HTTP-Statuscode 501 zurückzugeben: Methode nicht implementiert. Aber seien wir nett: Als Statuscode (fehlgeschlagene Domainübereinstimmung) geben Sie 302 für HTTP-Weiterleitung ein und darunter bei Location (fehlgeschlagene Domainübereinstimmung) geben Sie die URL Ihres Unternehmens wie http://www.netnea.com ein. So wird jemand, der es versäumt, den richtigen Parameter bereitzustellen, auf die Website Ihres Unternehmens umgeleitet. Tatsächlich können Sie den Parameter obligatorisch machen, indem Sie auf optional klicken, und darunter können Sie auch ein spezielles Verhalten für fehlgeschlagene obligatorische Bedingungen festlegen. Aber in unserem Fall muss der Parameter nicht obligatorisch sein.

Wenn Sie sich fragen, wie dieser reguläre Ausdrucksparameter in eine ModSecurity-Regel umgewandelt wird, dann werfen Sie einen Blick auf die folgende Grafik:

So wird eine Remo-Parameterkonfiguration in eine ModSecurity-Regel übersetzt.

Es beschreibt, wie Ihr Remo-Parameter in eine ModSecurity-Regel übersetzt wird und was während der Auswertung passiert. Es läuft darauf hinaus: Jeder HTTP-Anfrageparameter wird mit dem Wertebereich verglichen, der in Remo definiert ist, und wenn er nicht passt, wird der gesamten Anfrage der Zugriff verweigert.

In die Praxis umsetzen

Damit gesagt, lassen Sie uns das ModSecurity-Regelsatz generieren. Klicken Sie auf die Schaltfläche „Generieren“ in der Symbolleiste und speichern Sie die Datei, die Sie erhalten. Dies ist die Regeldatei in der ModSecurity-Regelsprache. Nehmen Sie diese Datei und speichern Sie sie an einem Ort, an dem Apache sie finden kann. Es lohnt sich übrigens, einen Blick darauf zu werfen, um zu verstehen, wie Remo ModSecurity verwendet. Dann müssen Sie sicherstellen, dass ModSecurity auf Ihrem Webserver aktiviert ist. Remo generiert ModSecurity 2-Regelsätze, da es zwischen 1.9 und 2.0 ein großes Update und eine Erweiterung der Konfigurationssprache gegeben hat und Remo diese neuen Funktionen benötigt. Falls Ihre Distribution keine ModSecurity-Pakete bereitstellt, können Sie die meisten davon von http://www.modsecurity.org erhalten. Andernfalls können Sie es immer selbst kompilieren. Es ist nicht zu viel Aufwand.

Es ist am besten, Ihre Regeldatei in Ihre Apache-Konfiguration wie folgt einzufügen:

    Include /etc/apache2/rulefile.conf

Dann laden Sie Ihren Apache neu und probieren Sie es aus (ich verwende das Kommandozeilenwerkzeug curl in der Demonstration, aber Ihr Browser wird auch gut sein):

curl --data "command=ls -l" http://localhost/ls.php

-rw-r--r--  1 sam    staff     353 Feb  7 13:05 index.html  
-rw-r--r--  1 sam    staff     248 Apr 23 05:35 ls.php  
...

Also funktioniert das immer noch. Wie wäre es mit einem Missbrauch von ls.php?

curl --data "command=ls -l; cat /etc/passwd" http://localhost/ls.php

  
  
  
  
Gefunden
  
Das Dokument wurde hier verschoben.
  
  
Apache/2.2.3 (Debian) PHP/5.2.0-8 Server bei railsmachine Port 80
  

Den Angreifer erwischt! Es gibt ein Audit-Log, das in der Konfigurationsdatei definiert ist. Standardmäßig befindet sich dies unter /var/log/apache2/modsec_audit.log. Es wird in unserem Fall wie folgt aussehen:

...  
--2957a220-H--  
Nachricht: Zugriff verweigert mit Weiterleitung zu http://www.netnea.com mit Status 302 (Phase 2).   
Übereinstimmung von "rx ^(ls\x20[0-9a-zA-Z-_.]{0,64})$" gegen "ARGS:command" erforderlich. [id "1"]   
[msg "Postparameter command hat die Gültigkeitsprüfung nicht bestanden. Wertebereich: Benutzerdefiniert."] [Schweregrad "FEHLER"]  
Aktion: Abgefangen (Phase 2)  
...

Bevor Sie in den Produktionsmodus wechseln, stellen Sie sicher, dass dieses Protokoll nicht zu groß wird. Tatsächlich möchten Sie möglicherweise zu viel Logging deaktivieren, wenn Sie mit der Einrichtung fertig sind. Die Protokolldatei ist von Remo standardmäßig so konfiguriert, dass sie vollständige Anforderungsprotokollierung zu Debugging-Zwecken durchführt. Dies umfasst alles, sogar Passwörter. Wenn Sie mit dem Testen fertig sind, sollten Sie den Parameter SecAuditLogParts in der Regeldatei auf einen sinnvolleren Wert setzen. ABHZ ist eine Option. So werden nur HTTP-Header und die ModSecurity-Audit-Zusammenfassung protokolliert.

Dies war also ein schneller Überblick über Remo. Es gibt mehr auf der Remo-Website zu finden. ModSecurity.org hat großartige Dokumentationen, die Ihnen alles über die Konfigurationssprache erzählen. Darüber hinaus gibt es ein Kern-Regelsatz, der Ihnen in Situationen hilft, in denen Sie nicht die Zeit haben, Ihre Anwendung in Remo zu modellieren. Der Kern-Regelsatz ist immer ein guter Ausgangspunkt, da er 90 % der Angriffe mit sehr wenig Aufwand abfängt.

Remo ist alles andere als ausgereift, aber es ist einsatzbereit und mit einer hilfreichen Benutzerbasis könnte es sich zu einem interessanten Tool entwickeln, um Webanwendungen abzusichern. Ihre Anwendung muss nicht so einfach sein wie die in diesem Tutorial verwendete. Größere Anwendungen mit Dutzenden von URLs und vielen Parametern funktionieren ebenfalls gut.