Bundesamt für Sicherheit in der Informationstechnik

M 5.115 Integration eines Webservers in ein Sicherheitsgateway

Verantwortlich für Initiierung: IT-Sicherheitsbeauftragter, Leiter IT

Verantwortlich für Umsetzung: Administrator, IT-Sicherheitsbeauftragter

Die Integration eines Webservers in ein Sicherheitsgateway ist in vielen Fällen kritisch, da ein Webserver oft hohe Anforderungen an die Netz-Bandbreite stellt. Neben der Sicherstellung der Verfügbarkeit ist zum Schutz vor gezielten Angriffen auch die Wahl der richtigen Variante zur Server-Platzierung wichtig, da Webserver auf Grund ihrer hohen "Sichtbarkeit" besonders Angriffen ausgesetzt sind und in Webserver-Programmen in der Vergangenheit oft Sicherheitslücken vorhanden waren.

Im folgenden werden drei Szenarien beschrieben, wie ein Webserver in ein Sicherheitsgateway integriert werden kann:

  • Integration ohne Verwendung eines Reverse Proxy
  • Integration unter Verwendung eines Reverse Proxy, der die Auslastung des Webservers reduzieren soll.
  • Integration unter Verwendung eines Reverse Proxy und mit zusätzlicher Absicherung durch einen weiteren Paketfilter.

In allen drei Fällen wird der Server nicht hinter einem ALG , sondern nur hinter einem Paketfilter aufgestellt, da der ALG den Gesamtdurchsatz des Systems unter Umständen zu stark beeinträchtigen kann. Daher sind die Empfehlungen auch dann anwendbar, wenn nur ein einfaches Sicherheitsgateway (bestehend nur aus einem Paketfilter) eingesetzt wird. Der Webserver sollte in keinem Fall im internen Netz angesiedelt werden.

Bei besonderen Sicherheitsanforderungen kann es trotzdem erforderlich sein, den Webserver mit einem eigenen ALG abzusichern, der den Webserver und darauf betriebene Webanwendungen vor bestimmten Arten von Angriffen (Cross-Site Scripting, Command Injection und ähnliches) schützt. Entsprechende ALGs existieren von verschiedenen Anbietern. Bei komplexeren Webanwendungen wird der Einsatz eines solchen ALG empfohlen.

Webserver ohne Verwendung eines Reverse Proxy

Bestehen keine besonderen Anforderungen an die Sicherheit des Webservers selbst und kann der Server die ankommenden Anfragen problemlos bewältigen, so bietet es sich an, den Webserver in einer eigenen DMZ des externen Paketfilters anzusiedeln.

Durch entsprechende Paketfilterregeln sollte sichergestellt werden, dass der Webserver vor Angriffen von außen so weit wie möglich geschützt wird. Zusätzlich sollte durch weitere Filterregeln dafür gesorgt werden, dass ein Angreifer selbst nach einer erfolgreichen Kompromittierung des Webservers selbst so wenig weiteren Schaden wie möglich anrichten kann. In der folgenden Tabelle sind Empfehlungen zusammengestellt.

Quelle Ziel Entscheidung Bemerkungen
Allgemein      
Webserver externes Netz und internes Netz Nur Pakete erlauben, die zu einer Verbindung gehören, die vom anderen Rechner initiiert wurde Der Webserver antwortet nur auf Anfragen. Eigene Verbindungen brauchen nicht aufgebaut zu werden
Kommunikation des Webservers mit dem Internet      
Externes Netz Webserver Port 80 erlauben Port 80 ist der Standardport
Externes Netz andere Ports des Webservers verbieten  
Kommunikation des Webservers mit dem internen Netz      
Internes Netz Webserver Port 80 erlauben Nutzung des Webservers auch vom internen Netz aus
Internes Netz (gegebenenfalls Einschränkung auf Administrationsnetz) Webserver Port 22 (SSH) erlauben Administration und Datenübertragung erfolgen per SSH und SCP
Internes Netz andere Ports des Webservers verbieten  
Protokollierung      
Webserver Loghost UDP-Port 514 erlauben Übertragung der Protokolldaten zum Loghost

Dabei wird davon ausgegangen, dass die Administration des Webservers aus dem internen Netz über eine SSH-Verbindung abgewickelt wird und dass die WWW-Daten per SCP auf den Webserver übertragen werden. Weiter wird davon ausgegangen, dass auf dem Webserver kein DNS verwendet wird. Eine Namensauflösung ist zum normalen Betrieb nicht notwendig. Für die Erstellung von Zugriffsstatistiken oder sonstigen Auswertungen kann sie gegebenenfalls später erfolgen. Die auf dem Webserver anfallenden Protokolldaten werden über das Netz an einen eigenen Loghost geschickt (siehe auch M 4.225 Einsatz eines Protokollierungsservers in einem Sicherheitsgateway ).

Dadurch, dass keine Verbindungen zugelassen werden, die vom Webserver aus initiiert werden, kann beispielsweise ein Angreifer, der den Webserver kompromittiert hat, entscheidend behindert werden. Meist benötigt ein Angreifer nämlich zur Fortsetzung seines Angriffs nach dem Einbruch weitere Tools, die er von externen Rechnern nachlädt. Wenn dies wegen entsprechender Paketfilterregeln nicht möglich oder deutlich erschwert ist, so brechen weniger geschickte oder entschlossene Angreifer (beispielsweise Script Kiddies) den Angriff eventuell sogar ab.

Falls die Administration des Webservers auf andere Weise abgewickelt oder die WWW-Daten auf andere Weise auf den Webserver übertragen werden, so sollten für die jeweils genutzten Protokolle entsprechende Filterregeln umgesetzt werden.

Webserver unter Verwendung eines Reverse Proxy

Im ersten Szenario trägt der Webserver die gesamte Belastung durch eingehende Anfragen. Soll der Webserver von eingehenden Anfragen entlastet werden, kann ein Reverse Proxy eingesetzt werden, der häufig wiederkehrende Anfragen aus seinem Cache beantwortet und so die Belastung des Webservers selbst reduziert.

Zur Erzielung eines möglichst hohen Durchsatzes ist es notwendig, Webserver und Reverse Proxy in der gleichen DMZ aufzustellen. Der Zugriff aus dem nicht-vertrauenswürdigen Netz sollte nur auf den Reverse Proxy gestattet sein, der direkte Zugriff auf den Webserver aus dem nicht-vertrauenswürdigen Netz sollte durch den äußeren Paketfilter unterbunden werden.

Webserver und Reverse Proxy in getrennten DMZs

Reverse Proxies wurden meist nicht primär unter dem Aspekt der Sicherheit entwickelt. Daher sollte gegebenenfalls in Betracht gezogen werden, den Reverse Proxy durch einen weiteren Paketfilter vom Webserver zu trennen. Dies erhöht die Sicherheit für den Webserver, kann aber andererseits zu einer Reduzierung der zur Verfügung stehenden Bandbreite führen.

Auf diese Weise können bei einer etwaigen Kompromittierung des Reverse Proxy unerwünschte Zugriffe vom Reverse Proxy auf den Webserver (z. B. auf Administrationsports) unterbunden werden. Diese Lösung ist in der folgenden Abbildung dargestellt.

Diese Lösung ist äquivalent dazu, den Reverse Proxy und den Webserver in unterschiedlichen DMZs des äußeren Paketfilters anzusiedeln. Ob die zusätzliche Filterstufe eingesetzt werden soll muss im konkreten Einsatzszenario abgewogen werden.

Prüffragen:

  • Grenzen entsprechende Paketfilterregeln die ein- und ausgehenden Verbindungen des Webserver auf das erforderliche Maß ein?

  • Betrifft Webserver unter Verwendung eines Reverse Proxy: Ist der Reverse Proxy in der selben DMZ aufgestellt, wie der Web-Server, wenn ein hoher Datendurchsatz erforderlich ist?

  • Betrifft Webserver unter Verwendung eines Reverse Proxy: Wird der direkte Zugriff auf den Web-Server aus dem nicht-vertrauenswürdigem Netz durch einen äußeren Paketfilter unterbunden?

  • Betrifft Webserver und Reverse Proxy in getrennten DMZ : Wird der Reverse Proxy durch einen zusätzlichen Paketfilter vom Web-Server getrennt?

Stand: 13. EL Stand 2013