Webserver vor Einbrüchen schützen mit Mod-Selinux

Web-basierte Applikationen entwickeln sich immer mehr zu einem beliebten Angriffspunkt für Einbruchsversuche in Computersysteme. Vor modernen Angriffsmethoden wie SQL Injection und Cross Site Scripting bieten klassische Firewallsysteme keinen Schutz, somit kann ein Fehler in einer Webapplikation fatale Folgen haben. Erstens sind Webapplikationen extrem dynamisch und komplex, zweitens kann der Entwickler einer Webanwendung nicht in die Zukunft blicken und alle möglichen Gefahren bereits im Vorfeld erkennen und eliminieren.

Eine Barriere bilden so genannte Web Application Firewalls (WAF), die mit Wissen über die beschriebenen Angriffe ausgestattet sind. Zusätzlich hat sich im Open-Source-Umfeld in den letzten Jahren Mod-Security [1] verbreitet. Hierbei handelt es sich um ein Apache-Modul, das anhand von Regelsätzen den eingehenden Datenstrom auf verdächtige Inhalte überwacht. Mod-Security arbeitet ähnlich wie ein Intrusion-Detection-System, das anhand einer Pattern-Datenbank unerwünschte Datenpakete verwirft. Hiermit lässt sich bereits ein großer Anteil gefährlicher Pakete vor der Übergabe an die Webapplikation abfangen.

Aber was passiert mit Paketen, die trotzdem durchrutschen? Systemen, die auf Basis von Pattern Matching arbeiten, erkennen ja nur bekannte Muster wieder und versagen bei bisher unbekannten Angriffsmethoden. Dann würde das eigentlich unerwünschte Paket problemfrei durchgereicht und könnte innerhalb der Webapplikation Schaden anrichten.

SE Linux für die Datenbank

Auf Betriebssystem-Ebene löst der Administrator solche Probleme mit Hilfe von Mandatory Access Control (MAC). In diesem Bereich hat sich in letzten Jahren SE Linux als Standard etabliert. Das Problem ist aber, dass SE Linux nur den Zugriff auf Systemressourcen einschränkt. Nun stehen jedoch beim Einsatz von Webapplikationen primär Web- beziehungsweise Applikationsserver und Datenbanken im Vordergrund und benötigen daher besonderen Schutz.

Mit Hilfe von Security Enhanced PostgreSQL (SE PostgreSQL, [2]) und Mod-Selinux [3] lassen sich nun auch Webapplikationen und deren Zugriff auf einzelne Datenbankobjekte unter den Schutzschild von SE Linux stellen. Dass dies zwingend notwendig ist, demonstriert eine Studie der Little Earth Corporation (LAC) vom März 2009 (Abbildung 1). Hiernach zeigt sich eine deutliche Zunahme der Angriffe auf Web-basierte Applikationen von 53 Prozent im Jahr 2006 auf über 90 Prozent im Jahre 2008.

Abbildung 1: Die Angriffe auf Webapplikationen haben in den letzten Jahren erheblich zugenommen. (Quelle: Little Earth Corporation)

Eigener Security Context

Bei klassischen PostgreSQL-Installationen meldet sich ein Benutzer mit seinem Benutzernamen an und authentifiziert sich mit seinem Passwort. Der Benutzer erhält dann Zugriff auf alle Objekte, die für dieses Konto zugänglich sind, wobei das Benutzerkonto unabhängig vom eigentlichen Systemkonto ist. Im Fall von SE PostgreSQL teilt die Funktion »getpeercon()« dem Security Context des zugreifenden Client-Sockets entweder den Security Context eines zugreifenden Benutzers oder den eines Prozesses mit. Somit bekommt jede Verbindung zur Datenbank einen individuellen Security Context zugewiesen.

Da der Administrator bei SE PostgreSQL auch jede Tabelle und jedes darin enthaltene Objekt mit einem Security Label versehen darf, kann er über das zentrale SE-Linux-Regelwerk genau festlegen, welcher Benutzer beziehungsweise Prozess auf welches Datenbankobjekt zugreifen darf oder eben nicht. Das heißt, wie bei SE Linux üblich, dass zwei Zugriffsprüfungen erfolgreich zu passieren sind, bevor das angeforderte Objekt ausgeliefert wird. Zuerst muss der Zugriff auf Basis der Datenbank-basierten Authentifizierung gestattet sein, im zweiten Schritt überprüft das System dann, ob das Security Label des zugreifenden Sockets die nötigen Rechte für das angefragte Objekt hat.

Nur wenn beide Tests erfolgreich abgelaufen sind, liefert die Datenbank das gewünschte Objekt aus, sonst kommt es zu einer Fehlermeldung und einem Eintrag im Log. Selbst der Datenbank-Administrator hat nur dann Zugriff auf ein bestimmtes Objekt, wenn der zuständige Security-Administrator diesen Zugriff explizit über eine entsprechende SE-Linux-Regel erlaubt hat. Damit lässt sich das Vier-Augen-Prinzip von MAC-Regeln umsetzen.