entwickler.com

Nachdem in der letzten Woche einige typische Sicherheitsprobleme im Zusammenhang mit Webservern aufgezeigt wurden, geht es in dieser Woche um die Wahl des richtigen Standorts für den Webserver.

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.

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

	›› 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.

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 sogenannten demilitarisierten Zone (DMZ).

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.

	›› DBS ist der Datenbankserver

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.

	›› AS ist der Applikationsserver

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 Leve 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, [1]) auch Sicherheits-Gateway genannt.

	›› ALG ist das Application Level Gateway

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

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.

In der nächsten Woche wird das Thema "Firewall" vertieft.

Carsten Eilers

• About Security (#1): IT-Sicherheit – Was ist das eigentlich?
• About Security (#2): Angriffsszenarien
• About Security (#3): Eindringlinge abwehren
• About Security (#4): Gefährdung aus der Peripherie
• About Security (#5): Der Pufferüberlauf
• About Security (#6): Ausnutzung von Pufferüberlauf-Schwachstellen
• About Security (#7): Gegenwehr – Pufferüberläufe verhindern
• About Security (#8): Vorbeugung – Pufferüberläufe verhindern
• About Security (#9): Sourcecode Audit – Pufferüberläufe finden
• About Security (#10): Software-Audit – Schwachstellensuche in Binaries
• About Security (#11): SQL-Injection
• About Security (#12): SQL-Injection verhindern
• About Security (#13): Mit Stored Procedures gegen SQL-Injection
• About Security (#14): Cross-Site Scripting
• About Security (#15): Cross-Site Scripting verhindern
• About Security (#16): Skriptcode einschleusen
• About Security (#17): HTTP Request Smuggling
• About Security (#18): Spielarten des HTTP Request Smuggling, 1
• About Security (#19): Spielarten des HTTP Request Smuggling, 2
• About Security (#20): HTTP Request Smuggling erkennen und verhindern
• About Security (#21): HTTP Response Splitting, 1
• About Security (#22): HTTP Response Splitting, 2
• About Security (#23): Caches vergiften
• About Security (#24): Caches indirekt vergiften
• About Security (#25): Entführen von Webseiten
• About Security (#26): Gefahren für Webanwendungen
• About Security (#27): Gefahren für Webserver