"Eine Firewall ist immer nur so sicher wie das dazugehörige Ruleset, eine Firewall alleine nicht (richtig) konfiguriert bringt gar nichts, ausser das sie dem User falscher Sicherheit wiegt!"
Firewall ist NICHT gleich Firewall!
Firewall Router
Stärken- Hohe Geschwindigkeit durch Routing auf IP-Ebene
- Billig in der Anschaffung
- Anti spoofing Mechanismen
- Spoofing von Broadcasts für IPX, IP...
- PROXY ARP
Schwächen- Bieten keinen Schutz vor TCP Angriffen
- Zu viele offene Ports > 1024
- Keine Kenntnis von Protokollen
- Keine Zustandsinformationen über Verbindungen
- Keine Authentifizierung
- Keine Cluster möglich
- Hoher Wartungsaufwand in grossen Netzwerken
- Log-Server stets notwendig
- Unflexibel, nur einseitig einsetzbar
- Schwierig zu programmieren
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 ausserhalb 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. Die meisten der 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. Des Weiteren 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 äusseren Netzwerkadresse erkennen. Ein typischer Vertreter dieser Firewall-Router, der sich gut zu Studienzwecken eignet, ist z.B. LiNUX. Für die Kontrolle von grösseren Netzwerken eignet sich dieser Typ von Firewall-Router nicht mehr.
Stateful Paket Filter (SPF)
Stärken- Hohe Geschwindigkeit (teilweise)
- Keine offenen Ports
- Ausführliche LOG-Informationen
- Ausführliche Zustandsinformationen über alle Verbindungen
- Fähigkeit für Clustering
- Schutz gegen Scanner (counter intelligence)
- Einfache Wartung und Installation
- Einsetzbar in grossen Netzwerken
- Skalierbar
- Eigene Programmiersprache
- Vielseitig einsetzbar
Schwächen- Bieten wenig Schutz vor TCP-Angriffen
- Teilweise keinen eigenen TCP/IP-Stack
- Zu wenig Kenntnis von Protokollen, häufig kein echter Schutz
- Proxy nur für einige wenige Protokolle verfügbar
- Keine Authentifizierung, jedoch nachrüstbar
- Teuer in Anschaffung und Unterhaltung
- Einbruch der Performance bei Aktivierung aller Filter
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, dass hierbei einige wichtige Überprüfungen nicht stattfinden, um die Durchsatzgeschwindigkeit zu erhöhen.
Die Hersteller gehen davon aus, dass 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. .
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, dass z.B. User ohne Passwort 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.
Proxy-Firewalls
Stärken- Ausführliche Kenntnis über Protokolle und Dienste
- Umfangreiche Filtermöglichkeiten
- Schutz vor buffer overflows möglich
- Spezielle Proxies lieferbar (SQL)
- Für unbekannte Protokolle generische Proxy Dienste verfügbar
- Keine offenen Ports
- Ausführliche LOG-Informationen
- Ausführliche Zustandsinformationen über alle Verbindungen
- Vollständiger Schutz vor TCP/IP Angriffen
- Einfache Wartung und Installation
- Schutz vor Viren
- Schutz gegen feindliche Applets (Active-X, JAVA(Skript)
- Generische Proxies nachrüstbar (SOCK’s)
- Aufbau als dual homed proxy möglich (split DNS...)
- Eigener TCP/IP-Stack
Schwächen- 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, dass Anwendungsprogramme immer nur zum PROXY Kontakt aufnehmen. Für einen User innerhalb eines geschützen Netzwerkes scheinen alle Pakete ausschliesslich 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 SOCK’s. Beim Einsatz von SOCK’s werden alle Daten von einem Client, der SOCK’s unterstützen muss (Netscape), über den PROXY, auf dem ein SOCK’s-Dämon installiert sein muss, von und zu einem Internet-Server übertragen. SOCK’s 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, dass 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, meist werden diese auch als store-and-forward PROXY bezeichnet.
Vorsicht ist bei dem Begriff “PROXY” immer angebracht!
Der Kernel des Betriebssystems muss also für die Weiterleitung der Pakete zwischen den Netzwerk Interfaces sorgen, während der PROXY die Authentifizierung (telnet: login, SOCK’s) ü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 ausserhalb 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 also 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 extrem 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 äussere 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 äusserst 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, dass hier viele Sicherheitsabfragen fehlen und Squid auch in grosser 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.
Welches Firewall-Betriebssystem ?
Grundsätzlich kann man Firewalls so unterteilen- Firewalls auf DOS-Basis mit Winsock (WinPkt-Treiber) Diese kann man als völlig veraltet und überholt ansehen. Sie leiden gewöhnlich an fast allen DoS (Denial of Service) Krankheiten.
- Firewalls auf DOS-Basis mit eigenem TCP/IP-Stack Meist sind diese veraltet, es gibt aber auch Hersteller, die diese weiterentwickelt haben und supporten. Sie besitzen keinerlei Schutz vor Angriffen auf application level, es mangelt an Kenntnissen über Protokoll- Mechanismen und Diensten. In vielen Fällen sind DoS Angriffe auf den TCP/IP-Stack erfolgreich.
- Firewalls auf Windows Win9x/XP-Basis Diese leiden an allen DoS-Krankheiten, unter den auch Windows leidet, daher sind sie erfahrungsgemäss instabil. Es sind gravierende Fehlkonfigurationen möglich und schwer zu beheben. Sie bieten zumeist keinerlei Schutz gegen Angriffe auf application level. Das Angebot an PROXY´s ist gut, es sind aber zumeist generische Proxies, die keinerlei Spezialkenntnisse über die Dienste besitzen (SQL). Es fehlen oft Filter auf Anwendungsebene.
- Firewalls auf Windows Win9x/XP-Basis mit eigenem TCP/IP-Stack Diese können sehr gut geeignet sein, Arbeitsstationen im Netzwerk stabiler zu machen, und gegen Angriffe über ISDN abzusichern. Oft besitzen diese guten Schutz gegen DoS-Angriffe und solche auf application level. Die Kenntnisse von Protokollen und Diensten sind umfangreich.
- Firewalls auf NT4-Basis ohne eigenen Stack Sie laufen erfahrungsgemäss stabil, leiden aber unter DoS-Angriffen auf den TCP/IP-Stack von NT, die noch recht häufig auftreten. Es sind gravierende Fehlkonfigurationen möglich, die sich aber unter Anleitung gut beheben lassen. Sie bieten zumeist keinerlei Schutz gegen Angriffe auf application level, Kenntnisse über Protokollmechanismen sind eher selten (FTP). Das Angebot an PROXY´s ist gut.
- PROXY-Firewalls auf NT-Basis mit eigenem TCP/IP-Stack Diese laufen i.a. stabil und sind sehr zuverlässig, sind aber relativ teuer in Anschaffung und Support. Viele Firewalls, die auf Windows NT mit eigenem TCP/IP-Stack laufen, sind Portierungen von UNIX auf NT. Leider sind diese nicht so leistungsfähig, wie unter UNIX, obwohl die Software praktisch identisch ist. Der Grund liegt in dem effizienteren Memory-Konzept von UNIX und teilweise auch daran, dass der IP-Stack (nicht der TCP-Stack) von UNIX mit genutzt wird.
- Firewalls auf UNIX-Basis ohne eigenen Stack Sie laufen erfahrungsgemäss stabil und sind sicher. Fehlkonfigurationen treten häufig und fast nur bei LiNUX-Firewalls auf, die nach Anleitungen von Distributoren aus dem Internet, oder aus Zeitschriften (C´t) aufgebaut wurden. Firewalls, die auf BSD-Systemen oder Solaris aufsetzen, besitzen oft eine hohe Qualität und sind sehr sicher, auch gegen Bedienungsfehler.
- Firewalls auf UNIX-Basis mit eigenem TCP/IP-Stack Diese Firewalls sind oft identisch mit denen auf NT-Basis ohne eigenen TCP/IP-Stack. Sie arbeiten unter UNIX schneller.
- Firewalls mit eigenem Betriebssystem Viele dieser Firewalls benutzen FreeBSD (Borderware), BSDI (Borderware, Genua Wall), LiNUX (Astaro, Watchguard, TIS FWTK, GNATwall). Hinter einigen kommerziellen Firewalls steckt UNIX, weil es, wenn man es auf die wesentlich Funktionen reduziert, auf eine Diskette passt. Zu erwähnen ist noch CISCO PIX, welche auf IOS läuft, einer Eigenentwicklung von CISCO.
Da es viele Mischformen von Firewalls gibt, sollte man sich doch genauer informieren, welche der Eigenschaften den Anforderungen am meisten entgegenkommt.
mit freundlichen Grüssen
affa
