Firewall Handbuch für LINUX 2.0 und 2.2 - zurück

• Relativ langsam
• Proxy nur für die wichtigsten Protokolle verfügbar
• Generische Proxies vorhanden jedoch sind diese unsicher
• Ausführliche Authentifizierung
• Clustering schwer möglich
• Keine eigene Programmiersprache möglich
• Nicht für Hispeed LAN´s geeignet
• Teuer in Anschaffung und Unterhaltung
PROXY-Firewalls sind grundsätzlich in zwei Varianten zu unterteilen: circuit level proxy,
was einem generischen Proxy nahekommt, und einem application level proxy, der
aufgrund seiner Kenntnisse der Protokollmechanismen auch als dedicated proxy
bezeichnet wird.
Ihnen gemeinsam ist, daß Anwendungsprogramme immer nur zum PROXY Kontakt
aufnehmen. Für einen User innerhalb eines geschützen Netzwerkes scheinen alle Pakete
ausschließlich vom PROXY zu stammen, daher auch die Bezeichnung PROXY
(Stellvertreter). Als einfachen PROXY könnte man auch einen völlig ungesicherten UNIX-
Server definieren, in den sich ein Anwender aus dem geschützten Netzwerk via TELNET
einloggt, um sich dann von diesem zu einem beliebigen Server im Internet weiter
verbinden zu lassen. Damit dieser Vorgang automatisch ablaufen kann, werden
verschiedene Mechanismen eingesetzt. Einer davon ist SOCKS. Beim Einsatz von
SOCKS werden alle Daten von einem Client, der SOCKS unterstützen muß (Netscape),
über den PROXY, auf dem ein SOCKS-Dämon installiert sein muß, von und zu einem
Internet-Server übertragen. SOCKS verfügt über keinerlei Fähigkeit, in Pakete hinein zu
schauen, er leitet sie nur weiter. Falls also der Client gegenüber buffer overflows
verletzbar ist, so ist er es stets auch hinter dem PROXY. Einzige Ausnahme sind Angriffe,
die auf den TCP/IP-Stack zielen. Diese werden vom PROXY abgefangen.
Es dürfte klar sein, daß bei dieser Konstruktion nicht von Sicherheit gesprochen werden
kann. Im Grunde kann man auch einen E-Mail-Dämon oder auch einen DNS-Server als
PROXY bezeichnen, sie werden auch als store-and-forward PROXY bezeichnet.
Vorsicht bei dem Begriff PROXY ist immer angebracht.
Der Kernel des Betriebssystems muß also für die Weiterleitung der Pakete zwischen den
Netzwerk - Interfaces sorgen, während der PROXY die Authentifizierung (telnet: login,
SOCKS) übernimmt.
Gelingt es dem Angreifer, die PROXY-Software durch einen DoS-Angriff stillzulegen, so ist
der Weg in das innere Netzwerk offen, da der Kernel stets Datenpakete forwarded. Mit
Hilfe von gespooften, source routing pakets gelingt es einem Angreifer dann, von
außerhalb hosts im inneren Netzwerk zu erreichen. Unter dieser Sicherheitslücke leiden
sehr viele Systeme - DoS dient hier nicht der Deaktivierung eines hosts, sondern eher der
Reaktivierung unterdrückter Qualitäten. Wenn also von PROXY´s, wie z.B. SQUID,
CERN-HTTPD oder WWWOFFLE die Rede ist, kann von Sicherheit also keine Rede sein.
Wer eine S.u.S.E. LINUX Firewall mit SQUID als PROXY installiert hat, einen SUN
SOLARIS host mit Netscape-PROXY betreibt, oder Windows 98/NT z.B. mit einem
Microsoft Proxy betreibt, dessen Sicherheit liegt mit hoher Wahrscheinlichkeit völlig blank.
Bei der gewöhnlichen Standardinstallation bindet sich der PROXY an einen Port auf der
internen Netzwerkkarte, und übergibt die weiterzuleitenden Informationen an den Kernel,
der diese dann an die äußere Netzwerkkarte weiterleitet. Hierzu ist forwarding notwendig.
Korrekt wäre der PROXY installiert, wenn er auch ohne forwarding die Daten
transportieren würde. Dies erfordert genaue Kenntnisse und Konfigurationsänderungen
bei Host und PROXY. Es besteht zudem stets die Gefahr eines buffer overflows.
SQUID, CERN-HTTPD gehören schon zu der Gattung der application level proxy, die
genaue Kenntnisse über das Protokoll besitzen. Genaugenommen sind es sogar
intelligente Proxies, da sie über spezielle Mechanismen des Caching von Files auf der
Erstellt von Doc Gonzo - http://kickme.to/plugins