Sippenhaft

CGI-Programme sind immer wieder beliebte Ziele für Angreifer. Sei es, weil sie Fehler enthalten oder der Entwickler zu lasche Sicherheitsmaßnahmen implementiert hat. Um zu verhindern, dass CGI-Programme querschlagen und eventuell sogar noch den Webserver mit in die Tiefe der Hölle reißen, kann Hiawatha sie mit Hilfe eines CGI-Wrappers einsperren. Dieser verpasst den CGI-Programmen auf Wunsch auch noch eine andere User-ID.

Um das Gefängnis einzurichten, wählt der Admin man als erstes ein Verzeichnis als CGI-Root-Verzeichnis aus, in dem alle CGI-Programme und Skripte landen. In Anlehnung aus Listing 1 könnte dies beispielsweise »/usr/local/var/www/hiawatha/cgi« sein. Der Wrapper wird dann ausschließlich CGI-Programme und -Skripte ausführen, die aus diesem Verzeichnis stammen.

Als nächstes muss eine weitere Konfigurationsdatei namens »cgi-wrapper.conf« her. Sie liegt im gleichen Verzeichnis wie die »httpd.conf« , für gewöhnlich also in »/usr/local/etc/hiawatha« . Das Hiawatha-Archiv bringt eine Vorlage mit, in der alle Zeilen vorsorglich auskommentiert sind.

IDie Datei »cgi-wrapper.conf« teilt dem Wrapper zunächst mit, welche Programme er außerhalb des CGI-Root-Directory noch ausführen darf. In der Regel sind dies die Interpreter für die verwendete Skriptsprachen:

CGIhandler = /usr/bin/php5-cgi
CGIhandler = /usr/bin/perl

Die Bezeichnung »CGIhandler« ist hier etwas unglücklich gewählt, da sie mit der gleichnamigen Einstellung aus der »httpd.conf« nur wenig gemein hat. Ist auch das geschehen, sperrt man die CGI-Programme endlich ein:

Wrap = wrap_id; /usr/local/var/www/hiawatha/cgi; tim

Ganz vorne steht der Name des Käfigs. Ihn muss man im Hinterkopf behalten, da er gleich noch in der »httpd.conf« eine Rolle spielt. Nach einem Semikolon folgt dann das CGI-Root-Directoy und schließlich am Ende der Benutzername (oder die ID), unter dem die CGI-Programme zukünftig laufen. Wenn der Verzeichnisname ein Pipesymbol enthält, wie zum Beispiel in:

Wrap = wrap_id; /usr/local/var/www/hiawatha|cgi; tim

verwendet der CGI-Wrapper den Teil vor dem senkrechten Strich als Chroot-Verzeichnis und steckt den Rest in eine solche Umgebung. In diesem Fall ist darauf zu achten, dass die CGI-Handler ebenfalls im Chroot-Verzeichnis verfügbar sind.

Damit steht der CGI Wrapper in den Startlöchern, man muss Hiawatha in der »httpd.conf« nur noch anweisen ihn zu nutzen:

WrapCGI = wrap_id

Da ein Wrapper einen Namen erhält (in diesem Beispiel wrap_id), lassen sich in der »cgi-wrapper.conf« gleich mehrere von ihnen definieren und diese dann jeweils in verschiedenen virtuellen Hosts einsetzen (siehe Kasten "Virtuelle Gastgeber").

Neue Rechtschreibung

Als letzten Leckerbissen bietet Hiawatha noch ein »UrlToolkit« , das ähnlich wie »mod_rewrite« beim Apache-Server funktioniert: Jede URL, die der Webserver in die Finger bekommt, gleicht er mit vorgegebenen Mustern ab. Liegt eine Übereinstimmung vor, führt Hiawatha eine festgelegte Aktion aus. Als Testmuster sind alle regulären Ausdrücke erlaubt. Listing 3 zeigt dazu in Anlehnung an [3] ein kleines Beispiel.

Listing 3

Beispiele für zwei Regelwerke mit dem UrlToolkit

UrlToolkit {
    ToolkitID = diversetests
    Match ^/php/ Return
    Match /index.php4(.*) Rewrite /index.php$1
}
UrlToolkit {
    ToolkitID = geheim
    Call diversetests
    Match /geheim(.*) DenyAccess
}

Das Ganze sieht auf den ersten Blick etwas kryptischer aus, als es tatsächlich ist: Listing 3 definiert zwei Regelsätze. Der obere hört auf den Namen (die »ToolkitID« ) »diversetests« , der zweite auf »geheim« . Der Regelsatz »diversetests« prüft zunächst, ob die URL mit »/php/« beginnt. Sofern dies der Fall ist, soll Hiawatha alle weiteren Tests in diesem Regelsatz beenden (»Return« ). Andernfalls ist zu prüfen, ob die URL mit »index.php4« beginnt. In dem Fall soll Hiawatha diese Zeichenkette gegen »/index.php« ersetzen, also die »4« im Dateinamen kippen.

Der zweite Regelsatz »geheim« ruft als erstes seinen Kollegen »diversetests« auf (»Call« ) und verweigert anschließend jeden Zugriffsversuch auf das Unterverzeichnis »/geheim« . Einen Überblick über alle weiteren Aktionen gibt Tabelle 1.

Tabelle 1

Mögliche Aktionen des UrlToolkits

Aktion

Beschreibung

Match »regex« »aktion«

Führt die »aktion« aus, wenn »regex« mit der URL übereinstimmt, »regex« ist dabei ein regulärer Ausdruck

Call »toolkit_id«

Führe die Regel »toolkit_id« aus

DenyAccess

Verweigert den Zugriff (403 Fehler)

Exit

 

Stoppt die komplette Auswertung aller Regeln

FastCGI »fcgi_id«

Verwende FastCGI Server »fcgi_id« und beendet die Auswertung

Goto »toolkit_id«

Führt die Regel »toolkit_id« aus und stoppt

Redirect »url«

Leitet den Client auf die Seite »url« weiter

RequestURI »exists|isfile|isdir« »Return|Exit«

Wenn die URL als Datei, beziehungsweise Verzeichnis exsitiert, stoppt die Auswertung

Return

Kehrt von der aktuellen Regel zurück

Rewrite »replace« »[max_loop]« »[Continue|Return]«

Ersetzt die gefundene Zeichenkette »max_loop« -mal gegen »replace« und beendet die Auswertung

Skip »anzahl«

Überspringt die folgenden »anzahl« Zeilen

Nachdem die Regeln in der »httpd.conf« festgelegt sind, bleibt nur noch dem Webserver mitzuteilen, welchen Regelsatz er verwenden soll:

UseToolkit = geheim

Die jetzt komplette Hiawatha-Konfiguration führt abschließend noch einmal Listing 4 auf.

Listing 4

Die komplette Hiawatha-Konfiguration

httpd.conf:

#Basiskonfiguration
Binding {
        Port = 80
        Interface = 192.168.2.123
}
Binding {
        Port = 443
        Interface = 129.168.2.123
        UseSSL = yes
        ServerKey = /usr/local/etc/hiawatha/serverkey.pem
}
WebsiteRoot = /usr/local/var/www/hiawatha
Hostname = localhost
#Logfiles
SystemLogfile = /usr/local/var/log/hiawatha/system.log
AccessLogfile = /usr/local/var/log/hiawatha/access.log
ErrorLogfile = /usr/local/var/log/hiawatha/error.log
GarbageLogfile = /usr/local/var/log/hiawatha/system.log
#Cache
CacheSize = 15
CacheMaxFilesize = 128
CacheMinFilesize = 256
#CGI
ExecuteCGI = yes
CGIextension = cgi
CGIhandler = /usr/bin/php5-cgi:php,php5
TimeForCGI = 5
#Nutze Wrapper:
WrapCGI = wrap_id
#Sicherheitsfunktionen
ServerId = www-data
ConnectionsTotal = 150
ConnectionsPerIP = 10
BanOnGarbage = 300
BanOnMaxReqSize = 60
BanOnFlooding = 10/1:35
BanOnCMDi = 60
BanOnSQLi = 70
BanlistMask = allow 192.168.2.111, deny 192.168.0.0/16
RebanDuringBan = yes
#UrlToolkit
UrlToolkit {
        ToolkitID = diversetests
        Match ^/php/ Return
        Match /index.php4(.*) Rewrite /index.php$1
}
UrlToolkit {
        ToolkitID = geheim
        Call diversetests
        Match /geheim(.*) DenyAccess
}
UseToolkit = geheim

cgi-wrapper.conf:

CGIhandler = /usr/bin/php5-cgi
CGIhandler = /usr/bin/perl
Wrap = wrap_id; /usr/local/var/www/hiawatha/cgi; tim

Ausblick

Neben den hier im Fokus stehenden Sicherheitsfunktionen besitzt Hiawatha noch weitere pfiffige Fähigkeiten. So geht der Webserver bei der Gzip-Kompression etwas cleverer vor als seine Kollegen und bietet die Möglichkeit eigener Error-Handler. Sofern vom Client eine XML-Datei angefordert wurde und eine passende XSLT-Datei vorliegt, führt Hiawatha auf Wunsch automatisch eine XSL-Transformation durch. Wem die Ausführungsgeschwindigkeit von CGI-Skripten zu langsam ist, kann den FastCGI-Mechanismus einschalten. Und mit Zugriffsrechten auf Verzeichnissen kennt sich Hiawatha ebenfalls aus. Für frei bestimmbare Dateitypen darf man sogar die Upload-Geschwindigkeit drosseln.

Wer jetzt Blut geleckt hat und tiefer in Hiawatha einsteigen möchte, dem empfiehlt sich die Lektüre des etwas knappen Howto [3]. Es beschreibt auch, wie man den Webserver mit AppAmor und Grsecurity [4] kombiniert.

Virtuelle Gastgeber

Wie viele andere seiner Kollegen, kann auch Hiawatha mehrere, voneinander unabhängige Internetauftritte ausliefern. Dazu weist man dem physischen Server zunächst mehrere (Domain-)Namen zu, so dass alle Browseranfragen zwangsweise immer beim selben Webserver landen. Dieser sieht anhand der mitgeschickten URL, welcher Internetaufritt gemeint ist. Neben der eigentlichen Homepage entstehen so aus Sicht des Clients mehrere weitere, virtuelle Hosts. Diese Technik ist insbesondere bei Webhostern beliebt, die so für mehrere kleine Auftritte nur einen Rechner mit nur einer kostbaren IP-Adresse bereitstellen müssen.

Um Hiawatha mit virtuellen Hosts auszurüsten, erstellt man in der »httpd.conf« für jeden von ihnen eine eigene Sektion nach dem Muster:

VirtualHost {
        WebsiteRoot = /var/www/nochneseite/wwwroot
        Hostname = www.meinvirtueller.de
        ...
}

Innerhalb der Klammern darf man nun fast alle Einstellungen verwenden, die auch bei der eigentlichen Seite (in der Hiawatha-Terminologie die sogenannte Default Website) zum Einsatz kamen. Es gibt sogar einige Funktionen, die ausschließlich virtuellen Hosts zur Verfügung stehen, darunter vier interessante »Prevent« -Sicherheitsmechanismen. So unterbindet ein

PreventCMDI = yes

Command-Injection-Angriffe, indem Hiawatha präventiv Rückstriche, Pipesymbole und Semikola in der URL, sowie den POST-Daten gegen einen Unterstrich ersetzt. Da diese recht rigorose Vorgehensweise hochgeladene Binärdateien verstümmelt, ist sie standardmäßig abgeschaltet.

Um Cross-Site Request Foregery (CSRF) kümmert sich ein

PreventCSRF = yes

Der virtuelle Host ignoriert dann alle von einem Browser gesendeten Cookies, sofern er über einen externen Link zu Hiawatha kam.

PreventSQLi = yes

nimmt SQL-Injections in die Mangel, indem es einen Schrägstrich vor jedes Hochkomma (»'« ) in der URL, den POST-Daten und Cookies stellt. Das funktioniert genau so wie die Magic Quotes aus PHP, weshalb man »PreventSQLi« nur dann einschalten sollte, wenn man keine PHP-Skripte verwendet. Genau wie ihre Kollegin »PreventCSRF« zerstört diese Funktion unter Umständen hochgeladene Binärdateien.

Die letzte Sicherheitsfunktion im Bunde:

PreventXSS = yes

soll Angriffe per Cross-Site-Skripting (XSS) verhindern, indem sie alle Kleiner-als, Größer-als, Hochkomma und Anführungsstriche in der URL durch Unterstriche ersetzt.

Infos

  1. Webserver Hiawatha: http://www.hiawatha-webserver.org
  2. Distribution Puppy Linux: http://www.puppylinux.com
  3. Hiawatha Howto: http://www.hiawatha-webserver.org/howto
  4. Grsecurity: http://www.grsecurity.net

Ähnliche Artikel

comments powered by Disqus
Mehr zum Thema

Neue Version des sicheren Webservers Hiawatha

Die neue Hiawatha-Version bringt einige kleine Verbesserungen und drosselt die Weiterentwicklung.

Artikel der Woche

Eigene Registry für Docker-Images

Wer selber Docker-Images herstellt, braucht auch eine eigene Registry. Diese gibt es ebenfalls als Docker-Image, aber nur mit eingeschränkter Funktionalität. Mit einem Auth-Server wird daraus ein brauchbares Repository für Images. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Google+

Ausgabe /2019