![[Inhalt]](toc.gif)
|
|
Online Suche im Handbuch | LITTLE-IDIOT NETWORKING |
Die hier nur kurz vorgestellten Firewall-Architekturen besitzen jeweils ihre eigenen Schwächen. Diese werden in späteren Abschnitten genauer erläutert. Hier seien also nur in kurzen Stichpunken deren Stärken und Schwächen erwähnt.
Der Begriff Firewall ist nicht genau definiert oder geschützt, daher werden fälschlicherweise oft Paketfilter als Firewall bezeichnet, was die korrekte Einschätzung des Wertes, also des Kosten-Nutzen Verhältnisses erschwert.
Stärken
Schwächen
Als Firewall Router werden häufig Router mit Filtereigenschaften bezeichnet. Besser wäre die Bezeichnung Paketfilter. Wenn man den Werbeaussagen der Hersteller glauben darf, dann sind deren Eigenschaften inzwischen recht umfangreich, sie beherrschen das Filtern nach IP - Nummern, Ports, Protokollen, bieten Schutz gegen spoofing und DoS-Angriffe, die auf den TCP/IP-Stack zielen, bieten NAT oder Masquerading an. Anscheinend gibt es kaum noch Unterschiede zu echten Firewalls. Weit gefehlt! In der Praxis reichen solche Filter nicht mehr aus, insbesondere beim Einsatz von komplexeren Protokollen, wie FTP, RPC, NFS, NIS, SMB, SQL u.s.w.. Den Firewall-Routern fehlen fast immer Kenntnisse über die Protokollmechanismen und somit sind sie auch nicht in der Lage, die Inhalte von wichtigen Protokollen zu interpretieren
So ist der Administrator gezwungen, fast alle Ports oberhalb der privilegierten Ports (> 1024) und evtl. auch einige unterhalb (111, RPC-Portmapper für PDC oder RPC) freizuschalten. Dieses ermöglicht dann direkte, vielfältige Angriffe auf Server hinter dem Firewall-Router, angefangen von DoS-Angriffen, bis hin zu Tricks, die ein wenig in die Protokollmechanismen eingreifen, z.B. FTP PORT-Umleitung auf einen Telnet-Zugang (Siehe PASV-Mechanismus). Firewall-Router besitzen keinerlei Statusinformationen über die benutzten Ports, z.B. von welchem Rechner diese initiiert wurden, welche Protokolle zu den Ports gehören und warum (NFS, RPC).
Für viele Protokolle müssen Ports oberhalb von 1024 für Zugriffe von außerhalb freigegeben werden, was zu unzähligen Sicherheitslöchern führt. Es gibt zahlreiche Tricks, die Fehler in Betriebssystemen hinter dem Firewall-Router ausnutzen, um diesen durchtunneln zu können. Weiterhin besitzen diese Firewall-Router keine User-Authentifizierungsmechanismen.
Firewall-Router besitzen keinen vollständigen TCP/IP-Stack. Sie sind nur in der Lage, auf IP-Ebene Pakete weiterzuleiten. Daher überprüfen sie einige Dinge bei der Weiterleitung auf andere Netzwerkinterfaces nicht.
Das sind z.B. IP-Fragmentierung, TCP-Prüfsummen, Offsets bei Sequenznummern, Flags in IP- und TCP-Headern (Näheres siehe: Angriffsvarianten auf TCP/IP-Stacks). Die meisten der o.a. Angriffsvarianten auf einen Server hinter dem Firewall-Router werden nicht abgefangen. So haben sich einige Hersteller aus Gründen des Marketings kurz damit beholfen, indem sie die Bytefolge (Signatur) von bekannten Angriffen aufgezeichnet haben, und diese dann aus dem Datenstrom herausfiltern. Mit Werkzeugen, wie Ballista oder IPSEND, ist es einem Angreifer leicht möglich, Signaturen zu erzeugen, die noch nicht erkannt werden. Desweiteren sind Firewall-Router anfällig gegen spoofing-Angriffe von einem benachbarten Arbeitsplatzrechner, der einen session hijacking Angriff ausführt.
Offiziell besitzen Firewall-Router Mechanismen gegen spoofing, sie können aber, da sie keine Statusinformationen über Details einer Verbindung besitzen, spoofing - Angriffe nur zwischen der inneren und äußeren Netzwerkadresse erkennen. Ein typischer Vertreter dieser Firewall-Router, der sich gut zu Studienzwecken eignet, ist z.B. LINUX. Für die Kontrolle von größeren Netzwerken eignet sich dieser Typ von Firewall-Router nicht mehr.
Stärken
Schwächen
Stateful Paket Filter sind als besonders schnelle Filter bekannt. In Geschwindigkeitstests schneiden sie stets hervorragend ab, und eignen sich scheinbar besonders für den Einsatz bei ISP´s zum Schutz von Servern oder Netzwerken mit Hochgeschwindigkeitsanbindung (>100 MBit). Diese Eigenschaften lassen vermuten, daß hierbei einige wichtige Überprüfungen nicht stattfinden, um die Durchsatzgeschwindigkeit zu erhöhen. Die Hersteller gehen davon aus, daß der TCP/IP-Stack der Server hinter der Firewall diese Untersuchungen sowieso durchführt. Das hat in der jüngsten Vergangenheit zu zahlreichen Angriffen auf TCP/IP-Stacks hinter SPF-Firewalls geführt, insbesondere bei Internet-Dienstleistern. Stateful Paket Filter verfügen gegenüber Firewall-Routern zusätzlich über einen Mechanismus, der, sobald eine Verbindung geöffnet wird, in die Pakete hineinschaut (Inspektion), den Status (Herkunft, Ziel, belegte Ports, MAC-Adresse, Sequenznummern, Offsets, Protokolle, Befehle) speichert und überwacht. Sie erkennen Zusammenhänge zwischen TCP- und UDP-Paketen (RPC, NFS) u.s.w.. Durch die Überwachung des Status und die Inspektion werden viele Angriffe unmöglich, die bei Firewall-Routern noch funktionieren. Angriffe auf TCP/IP-Stacks können sie nur zum Teil abwehren, im allgemeinen funktionieren viele DoS-Angriffe auf TCP/IP-Stacks hinter SPF-Firewalls recht gut, sehr zum Leidwesen einiger ISP´s. Aus diesen Gründen haben führende Hersteller zusätzlich zu den SPF-Filtern noch PROXY-Eigenschaften für spezielle Dienste, also auch noch eigene TCP/IP-Stacks den Firewalls hinzufügen müssen. Aktiviert man aber alle Schutzmechanismen und nutzt viele PROXY-Eigenschaften, sowie Filter für protokollspezifische Befehle (HTTP: PUT, GET, POST) und die Erkennung für Angriffssignaturen, so bricht die Performance dieser Filter dramatisch ein. SPF´s eignen sich aufgrund ihres Designs hervorragend, eine Programmiersprache hinzuzufügen, die somit nicht implementierte PROXY-Mechanismen für neue Protokolle simulieren kann. Da auch kombinierte Protokolle aus TCP und UDP (NFS, NIS+, RPC...) hiermit kontrolliert werden können, entsteht so schnell der Eindruck von Sicherheit, wo effektiv keine ist. Beispiel aus dem Handbuch von Checkpoint:
Instructions for adding Sybase SQL server support to FireWall-1: Sybase SQL uses TCP ports above 1024. The port used is defined in the configuration of the Sybase server. To configure FireWall-1 for use with Sybase SQL: 1. From the GUI, add a TCP service called Sybase SQL Server. Define this port as using the port defined in the SQL serverconfiguration. 2. Accept this service in the Rulebase. Instructions for adding Microsoft NetMeeting support to FireWall-1: .... Add TCP port 1503 in GUI.
Es gibt keine Anzeichen bei der Installation eines SQL Dienstes bei der Firewall-1, daß diese Firewall irgendwelche Kenntnisse darüber hat, was sie schützen soll, und wie sie es schützen kann. Wer also beispielsweise einen SQL Server sicher betreiben will, der sollte sich den Original SQL-Proxy von ORACLE einmal genauer ansehen. Andernfalls dürften die Überraschungen groß sein.
Die Zahl der offenen Ports reduziert sich gegenüber derjenigen bei Firewall-Routern dramatisch, da nur noch diejenigen Ports geöffnet werden, die auch wirklich gebraucht werden. Es müssen also nicht mehr pauschal alle Ports >1024 freigeschaltet werden. Es verbleiben aber noch einige Risiken, da es externen Hosts immer noch gestattet wird, auf interne Server oder Clients zuzugreifen. Es werden zwar laut Handbuch PROXY-Dienste hierfür angeboten, jedoch beschränkt sich tatsächlich die Funktion nur auf die Freischaltung der benötigten Ports. Es findet keinerlei inhaltliche Überprüfung statt.
SPF´s mangelt es oft an der wichtigen User-Authentifizierung. Diese verhindert, daß z.B. User ohne Paßwort - Anmeldung auf der Firewall eine Verbindung in das Internet öffnen können. Dies ist ein wirksamer Schutz gegen trojanische Pferde, die als Hintergrundprozesse vollautomatisch Verbindungen zu Servern im Internet aufbauen.
Stärken
Schwächen
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 lokalen Festplatte beherrschen. Im Falle des SQUID und Netscape-PROXY ist dieser sogar in der Lage, mit benachbarten Systemen Daten auszutauschen. Das macht sie äußerst anfällig gegen DoS-Angriffe und buffer overflows. Bisher hat sich nur kein Angreifer dafür interessiert, da auf diesen Servern ohnehin frei zugängliche Informationen lagern. Deswegen sind auch keine Sicherheitsprobleme bekannt. Wer sich aber etwas genauer mit den Quellcodes beschäftigt, der wird sehen, daß hier viele Sicherheitsabfragen fehlen und Squid auch in großer Zahl Gebrauch von den Bibliotheken des Betriebssystems macht. Die Sicherheit von Squid und Netscape Proxy hängt auch entscheidend von der Qualität des Servers ab, doch hierzu mehr später.
Wenn also von PROXY-Firewalls die Rede ist, dann sind sicherlich nicht solche Konstruktionen gemeint.
PROXY-Firewalls gehören zu den langsamsten Firewalls, aber auch zu den solidesten. Sie besitzen einen eigenen, vom Kernel unabhängigen, im allgemeinen solide programmierten TCP/IP-Stack und umfangreiche Filtermöglichkeiten auf Anwendungsebene, sowie genaue Kenntnisse der Protokollmechanismen und Dienste. Sie besitzen keine derjenigen Schwächen, die Firewall-Router oder SPF für Angreifer attraktiv machen. Trotzdem sind auch diese gewöhnlich relativ einfach zu überwinden. Schwachpunkt sind die Arbeitsstationen bzw. Server in der DMZ hinter der Firewall. Aus praktischen Erwägungen können Anhänge an E-Mails und JAVA(Skript)/Active-X stets ungehindert die Firewall überwinden, nur in den wenigsten Fällen wird dies unterbunden. Angreifer konzentrieren sich daher immer auf diese Schwachstelle, da sie am einfachsten auszunutzen ist.
Zu den typischen Vertretern der PROXY-Firewalls gehört z.B. TIS Gauntlet. Das TIS FWTK unter LINUX oder BSD-UNIX dient der Anschauung, da es im Quellcode veröffentlicht wurde. Das Toolkit bietet guten Schutz, aber es fehlt eine Unterstützung für moderne Protokolle. Es existiert ein allgemein einsetzbarer PROXY, ein Schutz vor komplexeren Angriffen bietet dieser aber auch nicht.
Grundsätzlich kann man Firewalls so unterteilen
Da es viele Mischformen von Firewalls gibt, sollte man sich doch genauer informieren, welche der Eigenschaften den Anforderungen am meisten entgegenkommt.
|
|
Online Suche im Handbuch | LITTLE-IDIOT NETWORKING |