Mittwoch, 22. August 2012


Topthema

Donnerstag, 20. Oktober 2005 | Topthema

About Security #28: Standorte für Webserver

(Link zum Artikel: http://www.entwickler.de/entwicklerde/kolumnen/024838)
  • Teilen
  • kommentieren
  • empfehlen
  • Bookmark and Share

In About Security #27 lernten Sie einige typische Sicherheitsprobleme im Zusammenhang mit Webservern kennen. In dieser Folge erhalten Sie Informationen für die Wahl des richtigen Standorts für den Webserver.

N E U ! Security aktuell
Täglich aktuelle Security-Infos!

Die erste Entscheidung, die bei der Standortwahl zu treffen ist, lautet: Soll der Webserver im eigenen Unternehmen oder bei einem Hosting-Provider aufgestellt werden? Ein Hosting-Provider besitzt in der Regel eine bessere Anbindung an das Internet als das eigene Unternehmen. Allerdings müssen unter Umständen sensitive Daten außerhalb des Unternehmensnetzes gespeichert werden. Bei der Unterbringung im eigenen Unternehmen wird die eigene Internetanbindung mit dem Verkehr das Webservers belastet, muss also entsprechend dimensioniert werden. Dafür bleiben alle sensitiven Daten im lokalen Netz. Auch die Anbindung an eine lokale Datenbank ist in diesem Fall einfacher. Es ist kein großes Problem, sensitive Daten über eine gesicherte Verbindung zum Hosting-Provider zu übertragen. Die Frage ist vielmehr, ob man diesem die sensitiven Daten anvertrauen will. Im eigenen Unternehmen kann man eine beliebig restriktive Zugangs- und Zugriffskontrolle einführen, während man bei Inanspruchnahme eines Hosting-Providers zumindest die Zugangskontrolle aus der Hand gibt.

Der Webserver ...

Im Folgenden wird davon ausgegangen, dass der Webserver im eigenen Unternehmen untergebracht wird:

Webserver im Unternehmen
>> WS ist der Webserver

Der Webserver ist neben dem Mailserver der gefährdetste Rechner des Unternehmens, da er möglichst uneingeschränkt von außerhalb zugänglich sein soll. Trotzdem muss er durch eine Firewall vor unerwünschten Zugriffen aus dem Internet geschützt werden. Auch wenn im Idealfall nur die Protokolle HTTP und HTTPS aktiviert und alle anderen Ports geschlossen sind, besteht die Gefahr, dass einem Angreifer das Öffnen einer Hintertür mit einem weiteren Port gelingt. Außerdem kann eine HTTP-fähige Firewall zur Abwehr bestimmter Angriffe, zum Beispiel von Würmern wie Nimda, genutzt werden.

Firewall vor dem Webserver

Eine weitere Firewall muss zwischen dem Webserver und dem lokalen Netz des Unternehmens installiert werden. Dadurch wird verhindert, dass ein Angreifer, der die Kontrolle über den Webserver erlangt, auf das lokale Netz zugreifen kann. Der Webserver steht also in der so genannten demilitarisierten Zone (DMZ).

Webserver in der demilitarisierten Zone
... und ein Datenbankserver ...

Muss der Webserver auf einen Datenbankserver zugreifen, gibt es wieder zwei Möglichkeiten: Der Datenbankserver steht im lokalen Netz oder in der demilitarisierten Zone. Ein Angreifer, der den Webserver unter seine Kontrolle bringt, ist nur einen Schritt vom Datenbankserver entfernt. Daher sollte dieser ebenfalls in der demilitarisierten Zone untergebracht werden, um ein Eindringen in das lokale Netz zu verhindern. Die Daten eines weiteren Datenbankservers im lokalen Netz können problemlos auf dem Datenbankserver in der demilitarisierten Zone gespiegelt werden. In die Gegenrichtung müssen sehr restriktive Schutzmaßnahmen beachtet werden.

Datenbankserver in der demilitarisierten Zone
>> DBS ist der Datenbankserver
... und ein Applikationsserver

Ein eventuell benötigter Applikationsserver wird ebenso in der demilitarisierten Zone untergebracht, da er ebenfalls durch einen erfolgreichen Angreifer auf den Webserver gefährdet ist.

Applikations-Server in der demilitarisierten Zone
>> AS ist der Applikationsserver
Alle zusammen

Als nächster Schritt ist die Verbindung der einzelnen Server an der Reihe. Je ein Paketfilter (bisher ziemlich ungenau als Firewall bezeichnet) trennt die demilitarisierte Zone vom lokalen Netz und vom Internet. Ein oder mehrere Application Level Gateways (ALGs) verbinden Web-, Datenbank- und Applikationsserver miteinander und mit den Paketfiltern. Paketfilter, Application Level Gateway und das zugehörige Konzept ergeben die eigentliche Firewall, manchmal (zum Beispiel im Grundschutzhandbuch des BSI) auch Sicherheits-Gateway genannt.

Ein Application Level Gateway
>> ALG ist das Application Level Gateway
Mehrere Application Level Gateways

Falls der Schutzbedarf gering ist, können statt des Application Level Gateway auch Paketfilter verwendet werden.

Paketfilter und Application Level Gateway
About Security: Die komplette Serie

Ein Paketfilter entscheidet anhand der Header-Informationen der UDP- beziehungsweise TCP-Pakete auf der Basis vorgegebener Filterregeln, wie mit den empfangenen Paketen zu verfahren ist. Es können sowohl komplette Protokolle gesperrt als auch nur bestimmte Pakete eines Protokolls durchgelassen werden. Da der Paketfilter nur auf Netzzugangs-, Netzwerk- und Transportebene des TCP/IP-Schichtenmodells arbeitet, hat er keinen Einblick in den Inhalt der Kommunikationsverbindung.

Ein Application Level Gateway untersucht den Datenverkehr auf der Anwendungsebene des TCP/IP-Schichtenmodells und kann daher die Inhalte der Kommunikationsverbindung entsprechend vorgegebener Regeln filtern.

Wird auf den Anschluss an das lokale Netz verzichtet, entfällt die zweite Firewall, und der Aufbau entspricht prinzipiell dem bei der Unterbringung des Webservers bei einem Hosting-Provider. In diesem Fall kommt jedoch eine Möglichkeit zur Fernwartung der Server hinzu.

Ab der nächsten Folge dreht sich alles um Firewalls. Die sind ein zentraler Bestandteil aller Schutzmaßnahmen, wenn zwei oder mehr Netze miteinander verbunden werden.

Wenn Sie Fragen oder Themenvorschläge haben, können Sie diese gerne an die angegebene E-Mail-Adresse senden oder im Security-Forum einbringen!

Carsten Eilers

About Security – Übersicht zum aktuellen Thema "Sichere Webanwendungen"

Kommentare

Folgende Links könnten Sie auch interessieren

  • Advantage Database Server  [25.04.2005]
    [http://entwickler.de/zonen/portale/psecom,id,102,buch,275,.html]
  • Fünf Performance-Tipps für ADO.NET  [23.06.2006]
    [http://entwickler.de/zonen/portale/psecom,id,101,online,831,.html]
  • No Religion!  [10.02.2004]
    [http://entwickler.de/zonen/portale/psecom,id,101,online,494,.html]
  • Nachgebessert  [21.06.2005]
    [http://entwickler.de/zonen/portale/psecom,id,101,online,401,.html]
  • Aktive Daten  [07.03.2003]
    [http://entwickler.de/zonen/portale/psecom,id,101,online,321,.html]