8.3.3. Anwendungs-Gateways (Proxies)

Die auch als Forwarder, Proxy-Server oder kurz nur als Proxies bezeichneten Anwendungs-Gateways stellen die zweite Gruppe von Grundelementen eines Firewalls dar. Sie wirken im Gegensatz zu den Paket-Filtern auf der Anwendungsebene und werden meist als normale Applikationen (Programme) auf einem Firewall-Rechner betrieben.

Bei den Firewall-Rechnern handelt es sich in der Regel um gewöhnliche Mehrnutzer-Systeme. Meist sind es UNIX-Maschinen, wobei zunehmend auch Windows NT eingesetzt wird. Da diese Computer vom Internet aus erreichbar und damit direkt attackierbar sind, müssen sie besonders gut gesichert sein und permanent sehr aufmerksam überwacht werden, um evtl. Einbrüche so schnell wie möglich erkennen und bekämpfen zu können.

Deshalb dürfen auf ihnen nur Dämonen betrieben werden, die als sehr stabil bekannt sind und sich durch eine hohe Resistenz gegen Angriffe auszeichnen. Da mit der zunehmenden Komplexität von Systemen in der Regel auch deren Anfälligkeit gegen Fehlfunktionen und gezielte Attacken deutlich steigt, sollten die eingesetzten Programme so einfach wie möglich gehalten werden, um ihre Zuverlässigkeit relativ leicht überprüfen und damit sicherstellen zu können.

Wie so oft im Bereich der Sicherheit ist man also gut beraten, dem Prinzip KISS zu folgen: "Keep It Simple, Stupid". Aus diesem Grunde empfiehlt es sich auch, alle nicht wirklich benötigten Server, Programme und Dateien abzuschalten bzw. zu entfernen, um deren evtl. möglichen versehentlichen oder absichtlichen Mißbrauch von vornherein auszuschließen.

Derartig geschützte ("hardened") Firewall-Computer bezeichnet man vielfach als Bastionen oder bastion hosts. Auf sie konzentrieren sich in der Regel die Hauptanstrengungen der Firewall-Administratoren.

Bastionen können verschiedene Aufgaben erfüllen. Die wichtigsten Funktionen sind die Bereitstellung der Proxies sowie das Logging. Daneben besteht prinzipiell die Möglichkeit, Applikations-Server auf ihnen zu betreiben, z.B. einen Mail-Dämon. Dabei sollte man allerdings überlegen, ob möglicherweise die Sicherheit sowie die Performance der Bastion darunter leiden und ob es daher nicht sinnvoller ist, den Dienst nur indirekt über einen Proxy zugänglich zu machen.

In manchen Installationen gestattet man Anwendern, sich auf der Bastion anzumelden und von dort aus Netzdienste über lokal bereitgestellte Klienten zu nutzen. Im Sinne der Sicherheit empfiehlt sich dieses Vorgehen generell nicht. Auf dem Bastion Host sollten lediglich Accounts für die Administratoren, aber keine für normale Nutzer existieren.

Damit läßt sich verhindern, daß die Sicherheitsmechanismen der Bastion von innen her untergraben werden, z.B. durch Starten eines speziellen Servers, der Zugriffe auf Bereiche des privaten Netzes gestattet, die gemäß der Sicherheitspolitik unzulässig und durch den Firewall zu unterbinden sind. Verschiedene Schwächen von Systemen kann man nur dann ausnutzen, wenn man sich auf der betreffenden Maschine befindet. Der Administrator sollte in diesem Zusammenhang nie vergessen, daß die Bastion auch ein potentielles Ziel für Angriffe aus dem internen Netz darstellt und daß man sie dagegen ebenfalls sehr sorgfältig schützen muß.

Bei den auf den Bastionen betriebenen Anwendungs-Gateways wird das Proxy-Konzept genutzt, das Ihnen bereits an anderen Stellen (z.B. bei der Diskussion von HTTP) begegnet ist und das im konkreten Fall dazu dient, eine indirekte Kommunikation zwischen zwei Partnern zu ermöglichen, die sich auf verschiedenen Seiten des Firewalls befinden und sich auf der Netzwerk-Ebene nicht erreichen können, da ihre IP-Pakete vom Firewall nicht durchgelassen werden. Durch entsprechende Konfigurationsdateien legt der Administrator fest, welche Kommunikation zulässig und welche nicht statthaft ist. Dazu kann es notwendig sein, daß sich der Nutzer gegenüber dem Proxy geeignet authentifiziert.

Ein Beispiel soll das Prinzip verdeutlichen:

Nehmen wir an, ein Anwender möchte vom internen Netz aus per Telnet auf eine Maschine im Internet zugreifen. Dann wendet er sich mit Hilfe seines Klienten an den Proxy und beauftragt diesen, die Verbindung zum gewünschten Telnet-Server herzustellen. Sofern dem seitens der Sicherheitspolitik nichts entgegensteht, wird der Proxy den Auftrag nach Möglichkeit ausführen und anschließend alle im Rahmen der Kommunikationsbeziehung auszutauschenden Daten vom jeweiligen Sender entgegennehmen und an den Empfänger weiterleiten, so daß beide Partner über den Firewall hinweg miteinander kommunizieren können. Gegenüber dem Telnet-Klienten erscheint der Proxy als Telnet-Server, und gegenüber diesem Server fungiert er als Klient. Da alle Daten der Anwendung den Proxy passieren müssen, ist dieser in der Lage, ein umfangreiches Logging zu realisieren.

Proxy-Server werden meist in zwei Gruppen unterteilt:

  1. application-level gateways: Diese sind anwendungsspezifisch und unterstützen häufig nur genau ein Protokoll, z.B. Telnet oder FTP. Daraus folgt, daß für jeden weiteren zu unterstützenden Dienst ein neuer Proxy-Server benötigt wird.

  2. circuit-level gateways: Hierbei handelt es sich um allgemeine, d.h. nicht anwendungsspezifische Proxies, die beliebige TCP-Verbindungen und evtl. auch UDP-Kommunikationsbeziehungen weiterleiten.

Das relativ bekannte und für nichtkommerzielle Zwecke konstenfrei nutzbare TIS Internet Firewall Toolkit (TIS FWTK) bietet eine Sammlung anwendungsspezifischer Proxies, u.a. für FTP, HTTP, rlogin, Telnet, SMTP und X11. Nähere Informationen dazu sowie zu dem von der Firma TIS (Trusted Information Systems) angebotenen kommerziellen Firewall-Produkt Gauntlet Internet Firewall finden Sie unter http://www.tis.com/research/software/fwtk/.

Beim TIS FWTK können die Anwendungs-Gateways mit ganz normalen, d.h. nicht speziell angepaßten Klienten genutzt werden, da man den Server, zu dem eine Verbindung hergestellt werden soll, manuell durch entsprechende Kommandos bzw. Argumente angibt. Daraus folgt, daß der Firewall für den Anwender nicht transparent ist.

Die allgemeinen Proxies behandeln die zu übertragenden Daten als Bytestrom, dessen Interpretation sie nicht selbst vornehmen, sondern dem jeweiligen Klienten und Server überlassen. Als allgemeine Proxies werden in der Praxis häufig SOCKS-Server verwendet. SOCKS ist der Name eines Protokolls, das in den Socks FAQ [http://www.socks.nec.com/socksfaq.html] folgendermaßen charakterisiert wird:

SOCKS is a networking proxy protocol that enables hosts on one side of SOCKS server to gain full access to hosts on the other side of the SOCKS server without requiring direct IP reachability. SOCKS redirects connection requests from hosts on opposite sides of a SOCKS server. The SOCKS server authenticates and authorizes the requests, establishes a proxy connection, and relays data.

SOCKS is commonly used as a network firewall that enables hosts behind a SOCKS server to gain full access to the Internet, while preventing unauthorized access from the Internet to the internal hosts.

There are two major versions of SOCKS: SOCKS V4 and SOCKS V5. David Koblas is the original author.

Der RFC 1928 enthält eine Spezifikation der Version 5 des SOCKS-Protokolls.

Von der Firma NEC wird eine sehr leistungsfähige SOCKS-Implementierung gepflegt und kostenfrei zur Verfügung gestellt: http://www.socks.nec.com/. Dort finden Sie neben der Software auch eine Vielzahl von Informationen zur Thematik SOCKS.

Um den SOCKS-Server nutzen zu können, sind die Klienten zu modifizieren (man hat eigens dafür das Verb SOCKSify geprägt), da sie dem Proxy zu Beginn jeder Sitzung unter Verwendung des SOCKS-Protokolls u.a. mitteilen müssen, wo sich derjenige Server befindet, zu dem eine Kommunikationsbeziehung aufgebaut werden soll. Dadurch ist allerdings der Firewall für den Anwender in der Regel transparent, da er den Klienten in gewohnter Weise nutzt und (anders als beim TIS FWTK) keine separaten Schritte unternehmen muß, um die Verbindung zum Server aufzubauen.

Ein weiteres Beispiel für einen allgemeinen Proxy finden wir bei der Secure Shell, die uns später noch genauer beschäftigen wird. Sie unterstützt die Weiterleitung beliebiger TCP-Verbindungen über einen kryptographisch gesicherten Kanal, wobei die Konfiguration der Quell- und Zieladressen einschließlich der Ports vorab durch entsprechende Optionen erfolgt, so daß hier kein spezielles Protokoll (wie z.B. SOCKS) zur Kommunikation mit dem Proxy benötigt wird. Dadurch ist diese Lösung zwar weniger flexibel, dafür entfällt aber die Notwendigkeit der Modifikation der Klienten.

Proxies weisen gegenüber Paket-Filtern u.a. folgende Vorteile auf:


© Holger Trapp, 30.6.1999