Sie befinden sich hier: Themen IT-Grundschutz-Kataloge. Inhalt. Dokumententitel: M 4.223 Integration von Proxy-Servern in das Sicherheitsgateway - IT-Grundschutz-Kataloge - Stand 2006
direkt zu der Navigation Servicebereich. direkt zu der Hauptnavigation. direkt zur Themennavigation. direkt zum Seiteninhalt.

M 4.223 Integration von Proxy-Servern in das Sicherheitsgateway

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

Verantwortlich für Umsetzung: Administrator

HTTPS-Sicherheitsproxy

Der HTTPS-Proxy sollte den eintreffenden Datenverkehr entschlüsseln, der Inhaltefilterung zuleiten und daraufhin den Datenverkehr wieder verschlüsseln. Der temporär unverschlüsselte Datenverkehr kann auf unerwünschte Inhalte untersucht werden.

Im besten Fall wird ein HTTPS-Proxy vom angeschafften ALG unterstützt. Dann bietet sich der in Abbildung dargestellte, relativ einfache Aufbau an. Hier wird der Übersichtlichkeit halber der Fall betrachtet, in dem die Filterung auf einer eigenen Komponente durchgeführt wird. Vielfach wird die Filterung jedoch vom Hersteller bereits in das ALG integriert.

Integration eines internen HTTPS-Proxies

Abbildung: Integration eines internen HTTPS-Proxies

 
Vorteile "HTTPS-Proxy auf ALG"  Nachteile "HTTPS-Proxy auf ALG" 
  • Einfache Einrichtung, da in der Regel Konfigurationsoberflächen zur Verfügung stehen.
  • Gegenüber einem externen HTTPS-Proxy ergibt sich eine geringere Anzahl an Kommunikationsbeziehungen zwischen den an der SSL-Entschlüsselung und an der Inhaltefilterung beteiligten Modulen (da die Daten das ALG nicht verlassen müssen).
 
  • Die Komplexität von SSL begünstigt Fehler bei der Entwicklung der Proxy-Software, was zu Schwachstellen führen kann. Durch Fehler in der SSL-Implementierung kann dann möglicherweise das gesamte ALG übernommen werden.
  • Der maximale Datendurchsatz wird aufgrund der rechenintensiven Schlüsselverarbeitung und der daraus resultierenden verstärkten Auslastung des ALG verringert.
 

Tabelle: Vorteile und Nachteile von HTTPS-Proxy auf ALG

Falls das ALG keinen HTTPS-Proxy anbietet, ergibt sich der in der Abbildung dargestellte Aufbau. Der HTTPS-Proxy befindet sich hier in einer eigenen DMZ. In der Abbildung ist abweichend von der vorhergehenden Abbildung der Fall dargestellt, bei dem die Filterung von Schadinhalten vom ALG wahrgenommen wird.

 Integration eines externen HTTPS-Proxies

Abbildung: Integration eines externen HTTPS-Proxies

 
Vorteile "HTTPS-Proxy in DMZ"  Nachteile "HTTPS-Proxy in DMZ" 
  • Die Produktauswahl ist unabhängig vom ALG möglich.
  • Entlastung des ALGs, da die rechenintensive Schlüsselverwaltung auf einem eigenen Rechner stattfindet.
 
  • Auf dem ALG müssen mehrere Proxies eingerichtet werden.
  • Fehlkonfigurationen werden aufgrund der komplexen Kommunikationsbeziehungen der beteiligten Komponenten begünstigt.
  • Erhöhte Latenzzeiten gegenüber einem auf dem ALG integrierten HTTPS-Proxy beim Abruf von Daten, da mehrere TCP- bzw. UDP-Verbindungen zwischen den einzelnen Modulen aufgebaut werden müssen.
 

Tabelle: Vorteile und Nachteile von HTTPS-Proxy in DMZ

Die Stärke der Verschlüsselung innerhalb des vertrauenswürdigen Netzes könnte bei beiden vorgestellten Lösungen dem Schutzbedarf und der Vertrauenswürdigkeit der Teilnehmer angepasst werden, ggf. kann hier zur Steigerung der Performance auf eine Verschlüsselung im vertrauenswürdigen Netz verzichtet werden oder ein weniger rechenintensives, schwächeres Verschlüsselungsverfahren eingesetzt werden.

Caching-Proxy

Bei der Nutzung von Diensten könnte der Zugriff auf das nicht-vertrauenswürdige Netz auf bestimmte Proxies (z. B. Caching-Proxy für HTTP) beschränkt werden. Ein Client-Zugriff nach außen unter Umgehung des ("Zwangs-") Proxies ist dann nicht möglich, da die IP-Adresse des Clients vom Sicherheitsgateway abgewiesen wird (nur die IP-Adresse des Caching-Proxy wird vom Sicherheitsgateway akzeptiert).

 
Vorteile von ("Zwangs-") Caching-Proxies  Nachteile von ("Zwangs-") Caching-Proxies 
  • Umfangreiche Möglichkeiten zur Protokollierung des HTTP-Verkehrs, falls nur ein einstufiges Sicherheitsgateway verwendet wird (bestehend aus einem Paketfilter).
  • Erweiterte Filtermöglichkeiten, falls nur ein einstufiger Aufbau bestehend aus einem Paketfilter eingesetzt wird. Mit einem Caching-Proxy lassen sich beispielsweise filtern:
  • Cookies,
  • URLs,
  • HTTP-Referrer,
  • HTTP-Via und
  • HTTP-Server.
  • Reduzierung des übertragenen Datenvolumens aufgrund der Caching-Funktionalität.

Anmerkung: In der Regel werden Caching-Proxies nicht unter Sicherheitsaspekten entwickelt. Ein dedizierter Sicherheitsproxy sollte den Caching-Proxies nach Möglichkeit vorgezogen werden.

 
  • Kompletter Ausfall von HTTP/HTTPS bei Ausfall des Proxies. Eine vorübergehende Inbetriebnahme unter Verzicht auf den Proxy erfordert umfangreiche Konfigurationsarbeiten (die Sperrlisten auf dem Paketfilter müssen geändert werden und die Proxyeinstellungen der Clients müssen angepasst werden, falls der Caching-Proxy nicht transparent betrieben wurde). In der Regel ist deshalb eine redundante Auslegung des Proxies notwendig.
 

Tabelle: Vorteile und Nachteile von Zwangs-Caching-Proxies

Reverse Proxy

"Reverse Proxies" werden im Zusammenhang mit der Bereitstellung von (Web-) Servern auch zur Erreichung folgender Sicherheitsziele verwendet:

  1. Einschränkung der Kommunikationsverbindungen, die aus dem nicht-vertrauenswürdigen Netz kommend über einen Sicherheitsproxy geleitet werden müssen. Dadurch wird die Administration des Sicherheitsgateways erleichtert und die Wahrscheinlichkeit von Fehlkonfigurationen verringert.
  2. Verschleierung der Identität des Web-Servers (mehrere, zur Lastverteilung genutzte Web-Server erscheinen vom nicht-vertrauenswürdigen Netz aus gesehen unter einer IP-Adresse).
  3. Abfangen von Fehlermeldungen des Web-Servers, die einem Angreifer Hinweise zur Kompromittierung des Systems liefern könnten (eigentlich handelt es sich hierbei um einen Workaround, da der Web-Server dieses Problem selber abfangen sollte).
  4. Zusätzliche Abschottung des Web-Servers, d. h. ein Angreifer kann u. U. die Informationen einer Transaktion mitlesen, aber keinen Zugriff auf den Web-Server erlangen.
  5. Abkoppelung des IP-Stacks des Servers vom nicht-vertrauenswürdigen Netz.
  6. Filterung unerwünschter, aus dem nicht-vertrauenswürdigen Netz stammender Anfragen an den Web-Server.
  7. Erhöhung der Verfügbarkeit aufgrund von Lastverteilung und Lastminderung durch Caching.

In der folgenden Abbildung ist eine Situation dargestellt, in der zwei Server zum Zugriff aus dem nicht-vertrauenswürdigen Netz bereitgestellt werden. In dem abgebildeten Szenario müssen zwei Kommunikationsverbindungen über das ALG und den externen Paketfilter hinweg freigeschaltet werden.

Reverse Proxy zur Vermeidung vieler Kommunikationsbeziehungen über das ALG hinweg. Reverse Proxy und die Server stehen in einer DMZ.

Abbildung: Reverse Proxy zur Vermeidung vieler Kommunikationsbeziehungen über das ALG hinweg. Reverse Proxy und die Server stehen in einer DMZ.

Die in der vorigen Abbildung dargestellten Kommunikationsbeziehungen lassen sich mit Hilfe eines Reverse Proxy reduzieren. In Abbildung ist aus dem nicht-vertrauenswürdigen Netz nur der Zugriff auf den Reverse Proxy gestattet, Server 1 und 2 sind vor Zugriff gesperrt. Auf beide Server kann nur der Reverse Proxy zugreifen.

Reverse Proxy zur Vermeidung vieler Kommunikationsbeziehungen über das ALG hinweg

Abbildung: Reverse Proxy zur Vermeidung vieler Kommunikationsbeziehungen über das ALG hinweg. Reverse Proxy und die Server stehen in verschiedenen DMZ.

Zur Erhöhung der Serversicherheit können die Server auch in einer eigenen DMZ (oder auch im vertrauenswürdigen Netz) betrieben werden, wo sie durch einen Sicherheitsproxy vom Reverse Proxy getrennt werden. Die Übernahme eines Servers wird hierdurch zusätzlich erschwert, allerdings erhöht sich die Anzahl der Kommunikationsbeziehungen über das ALG.

Ergänzende Kontrollfragen: