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

© Jaroslaw Grudzinski, 123RF

Webwehr

Web Application Firewalls wehren bekannte Angriffe ab, bieten jedoch keinen Schutz vor den immer neuen Tricks der Cracker. Mod-SELinux schiebt ihnen den endgültigen Riegel vor.
High Availability lässt sich heute mit günstiger Hardware und einer großen Auswahl an kommerzieller sowie freier Software realisieren. ADMIN erklärt die ... (mehr)

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.

Auf Betriebssystem-Ebene löst der Administrator solche Probleme mit Hilfe von Mandatory Access Control (MAC). In diesem Bereich hat sich in letzten Jahren SELinux als Standard etabliert. Das Problem ist aber, dass SELinux 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.

SELinux für die Datenbank

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 SELinux 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)

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 SELinux-Regelwerk genau festlegen, welcher Benutzer beziehungsweise Prozess auf welches Datenbankobjekt zugreifen darf oder eben nicht. Das heißt, wie bei SELinux ü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, 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 SELinux-Regel erlaubt hat. Damit lässt sich das Vier-Augen-Prinzip von MAC-Regeln umsetzen.

Security Context in der Tabelle

Anders als bei den klassischen Systemobjekten, beispielsweise Dateien oder Verzeichnissen eines Dateisystems, bei denen der Security Context in den erweiterten Attributen gespeichert ist, hält SE PostgreSQL den Security Context für ein Datenbankobjekt in einem besonderen Systemkatalog vor. In solchen Systemkatalogen befinden sich bei relationalen Datenbanksystemen üblicherweise ihre Schemadaten und andere Meta-Informationen. SE PostgreSQL führt einen zusätzlichen Katalog mit dem Namen »sg_security« ein.

In diesem Katalog erledigt SE PostgreSQL das Mapping zwischen dem eigentlichen Security Context eines Objekts und einem Object Identifier (OID). Legt der Administrator ein neues Datenbankobjekt an, bekommt es einen numerischen OID zugwiesen. Um die Auflösung in die klassische String-Darstellung für einen Security Context kümmert sich die Datenbank selbst.

comments powered by Disqus
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

Ausgabe /2023