Sicherheit in Netzen

Prof. Jürgen Plate
Dipl.-Ing. Jörg Holzmann

4 Firewall-Rechner

4.1 Einführung

Als Firewall wird heute jedes System bezeichnet, welches den Datenverkehr zwischen zwei Netzwerken kontrolliert. Im einfachsten Fall ist dies ein Router. Ein Firewallsystem kann auch aus mehreren zusammenarbeitenden Komponenten, z. B. zwei Routern und einem Rechner, bestehen. Heutige Firewall-Rechner besitzen meistens zwei oder drei Netzwerkanschlüsse, und lassen sich je nach Anforderung in verschiedene Topologien einbinden.
Ein Firewall kanalisiert die Kommunikation, indem alle Daten von und nach außen über dieses System laufen müssen. Die Kanalisierung erhöht zudem die Chancen, einen Einbruchversuch anhand ausführlicher Protokoll-Dateien zu erkennen, da der Eindringling erst den Firewall passieren muß.
Mit einem Firewall läßt sich die Wahrscheinlichkeit erheblich verringern, daß Angreifer von außen in inneren Systeme und Netze eindringen können. Zudem kann das System interne Benutzer davon abhalten, sicherheitsrelevante Informationen, wie unverschlüsselte Paßwörter oder vertrauliche Daten, nach außen geben.
Ein Firewall kann aus einer einzelnen Maschine oder aus einer mehrstufigen Anordnung bestehen. Eine mehrstufige Anordnung ist vor allem dann sinnvoll, wenn man bestimmte Dienste der Öffentlichkeit zur Verfügung stellen will, etwa einen WWW- oder ftp-Server. Die entsprechenden Hosts können dann in einem Zwischennetz isoliert werden.
Die Kontrolle des Datenverkehrs kann auf verschiedenen Ebenen erfolgen. Für die Kontrolle der Ebenen 1 bis 4 des ISO-Modells kann ein Router ausreichend sein, für die höheren Ebenen ist ein Rechner notwendig. Der Router kann mit Access-Listen versehen werden. Diese Access-Listen erlauben die Kontrolle des Datentransfers auf Netzwerkebene, d.h. daß eine Kontrolle des Dateninhalts und auf Applikationsebene nicht möglich ist. Jedes Datenpaket wird für sich betrachtet, unabhängig von anderen Paketen. Der Router kann nicht erkennen, ob ein bestimmtes Paket zu einem Datenpaket gehört, welches schon vorher vermittelt wurde.

Zur Umgehung dieses Problems versucht man, den Firewall-Rechner so auszulegen, daß der Rechner mitverfolgt, welche Pakete schon geschickt wurden. Jegliche Kommunikation wird nach sogenannten Protokollen abgewickelt. Sind die Regeln solch eines Protokolls dem Firewall-Rechner bekannt, kann er verfolgen, ob die Pakete der im Protokoll vorgegeben Reihenfolge und Richtung entsprechen. Dieses Verfahren wird als 'statefull inspection' bezeichnet. Eine Kontrolle des Dateninhalts kann mit diesem Verfahren immer noch nicht stattfinden.

Ein 'application-level' Firewall erlaubt die Inhalts-Kontrolle. Bei diesem Firewall-Typ muß für jedes durch den Firewall vermitteltet Protokoll ein spezielles Programm, ein sog. Proxy, vorhanden sein. Der Proxy vermittelt zwischen den beiden Seiten des Firewalls. Das Proxy-Programm verhält sich genau so wie das Originalprogramm des jeweiligen Protokolls, z.B. wie ein FTP-Server. Mit einem Proxy ist es möglich, auf allen Ebenen der Kommunikation den Datenstrom zu Filtern und zu Beeinflussen.

Die heutigen Firewall-Produkte sind meist eine Kombination der obigen Techniken. Je nach nach Produkt sind die einzelnen Funktionen unterschiedlich stark ausgeprägt.

Firewallsysteme sind für einen vollautomatischen Betrieb ausgelegt. Allerdings mag dies täuschen, da je nach Firewall-Typ u.U. Statistiken, Logdaten, Alarme usw. generiert werden. Diese Botschaften benötigen einen Adressaten, einen kompetenten und verantwortlichen Menschen, der die Nachrichten des Firewalls bewertet und entsprechend handelt. Zur Definition dieser Aktionen ist zusammen mit, oder besser noch vor der Installation des Firewalls festzulegen, was der Firewall wie schützen soll. Es ist festzulegen, was in bestimmten Situationen zu tun ist, und wer dies tut. Der Betrieb eines Firewallsystems kann mehr Personalresourcen fordern als der Betrieb eines LAN-Servers.

Nachfolgend sollen einige gängige Firewall-Architekturen vorgestellt werden.

4.2 Architektur mit Dualhomed-Host

Eine Architektur mit Dualhomed-Host wird um einen Host herum aufgebaut, der über mindestens zwei Netzwerkschnittstellen verfügt. Ein solcher Host ist als Router zwischen den Netzen einsetzbar, die an die Schnittstellen angeschlossen sind. Er kann dann IP-Pakete von Netz zu Netz routen. Für diese Firewall-Architektur muß diese Routingfunktion jedoch deaktiviert werden. IP-Pakete werden somit nicht direkt von dem einen Netz (dem Internet) in das andere Netz (das interne, geschützte Netz) geroutet. Systeme innerhalb der Firewall und Systeme außerhalb (im Internet) können jeweils mit dem Dualhomed-Host, aber nicht direkt miteinander kommunizieren. Der IP-Verkehr zwischen ihnen wird vollständig blockiert. Die Netzarchitektur für eine Firewall mit Dualhomed-Host ist denkbar einfach: der Dualhomed-Host sitzt in der Mitte, wobei er mit dem Internet und dem internen Netz verbunden ist.


Ein Dualhomed-Host kann Dienste nur anbieten, indem er entsprechende Proxies (Stellvertreter) oder Gateways einsetzt. Es ist jedoch auch möglich, direkte Nutzerzugriffe zu gestatten (Sicherheitsrisiko).

4.3 Architektur mit überwachtem Host

Die "screened host architecture" bietet Dienste von einem Rechner an, der nur an das interne Netz direkt angeschlossen ist, wobei ein getrennter Router verwendet wird. Der Bastion-Host befindet sich im inneren Netz. Auf diesem Router verhindern Paketfilter das Umgehen des Bastion-Host.

Die Paketfilterung auf dem Sicherheitsrouter muß so konfiguriert werden, daß der Bastion-Host das einzige System im internen Netz darstellt, zu dem Rechner aus dem Internet Verbindungen aufbauen können (das einzige "nach außen sichtbare" System). Zusätzlich sind nur gewisse Dienste zugelassen. Alle externen Systeme, die auf interne Systeme zugreifen wollen, und auch alle internen Systeme, die externe Dienste wahrnehmen wollen, müssen sich mit diesem Rechner verbinden. Daraus ergibt sich ein besonderes Schutzbedürfnis für diesen Bastion-Host. Der Vorteil bei dieser Konstruktion ist die Tatsache, daß ein Router leichter zu verteidigen ist. Dies liegt u. a. daran, daß auf ihm keine Dienste angeboten werden. Nachteilig wirkt sich aus, daß bei einer eventuellen Erstürmung des Bastion-Host das interne Netz vollkommen schutzlos ist.

4.4 Architektur mit überwachtem Teilnetz

Die "screened subnet architecture" erweitert die Architektur mit überwachtem Host um eine Art Pufferzone, die als Grenznetz das interne Netz vom Internet isoliert. Diese Isolierzone wird auch "Demilitarisierte Zone" (DMZ) genannt.

Bastion-Hosts sind von ihrer Art her die gefährdetsten Rechner in einer Firewallkonstruktion. Auch wenn sie in der Regel mit allen Mitteln geschützt sind, werden sie doch am häufigsten angegriffen. Die Ursache liegt darin, daß ein Bastion-Host als einziges System Kontakt zur Außenwelt unterhält.

4.5 Firewall-Software

Zur Software-Konfiguration eines Firewall existieren zwei Grundstrategien:

Es gibt drei Arten von Firewall-Softwareebenen:

Besser als ein einzelner Paketfilter oder Application-Level-Gateway ist ein mehrstufiger Aufbau, bestehend aus der Hintereinanderschaltung eines Paketfilters, eines Application-Level-Gateways und eines weiteren Paketfilters (im Folgenden mit "P-A-P-Aufbau" bezeichnet).

Vorteil des mehrstufigen Aufbaus gegenüber der einstufigen Struktur sind die sich daraus ergebenden erheblich größeren Steuer- und Protokollierungsmöglichkeiten. Obwohl ein ALG implizit bereits grundlegende Paketfilterfunktionalität bietet, sollte auf die beiden Paketfilter nicht verzichtet werden, da diese u. a. den TCP/IP-Stack des ALG schützen und etwaige Fehlkonfigurationen der in der Regel sehr komplexen ALG kompensieren können. Zudem können sie das ALG bei der Filterung von unerwünschtem Datenverkehr (z. B. durch Internet-Würmer) unterstützen und eine völlige Auslastung des ALG zumindest hinauszögern.

Der Einsatz von Firewalls bietet sich auch innerhalb einer Organisation an, um Bereiche unterschiedlicher Sensitivität von einander abzugrenzen. Firewalls bieten jedoch niemals hundertprozentige Sicherheit! Sie schützen nicht vor dem Fehlverhalten eines authorisierten Anwenders und können, etwa durch eine zusätzliche Modem-Verbindung, umgangen werden.

Ein Firewall nach dem heutigen Stand der Technik kann nur gegen bereits bekannte Angriffs-Methoden schützen. Er kann möglichst viele Ereignisse protokollieren, um im Fall des Falles den Vorgang möglichst lückenlos rekonstruieren zu können. Nur, was soll man protokollieren? Die Datenmengen können pro Tag auf hunderte von Megabytes anwachsen. Wer wertet dies aus, und sucht darin die Nadel im Heuhaufen?

Neueste Ansätze beruhen darauf, daß man ein Firewallsystem durch ein zusätzliches System ergänzt, welches den Verkehr auf dem Netzwerk überwacht. Dieses System ist vom Firewall völlig unabhängig, und es greift nicht aktiv in den Datenverkehr des Netzes ein. Dieses System hat die Aufgabe eines unparteiischen 'Flugschreibers' (der Name 'Network Flight Recorder' wurde von Marcus Ranum, dem Entwickler des TIS Firewall Toolkit, geprägt). Dieses System kann den Bedürfnissen entsprechend programmiert werden. Mit Hilfe dieses Systems kann man zwar einen Einbruch in das Netz nicht aktiv unterbinden, man kann ihn aber leichter erkennen und verfolgen. Das System kann, genauso wie ein Firewall, Alarme bei suspekten Ereignissen auslösen, z. B. wenn plötzlich DNS-Anfragen von einem System beantwortet werden, welches kein DNS-Server ist (DNS-Spoofing).

Modulare Erweiterungen der Basisstruktur

Dem Firewallaufbau können weitere Module mit speziellen Sicherheitsfunktionen hinzugefügt werden. Beispiele hierfür sind: Die meisten dieser Module können auf verschiedene Weise platziert werden, also z. B. vor oder hinter dem Application-Level-Gateway oder in der demilitarisierten Zone ("DMZ") des ALG.

Verbleibende Risiken

Auch nach der Installation eines Sicherheitsgateways mit restriktiven Sicherheitseinstellungen verbleiben nit technisch lösbare Risiken. Beispiele hierfür sind:

Viele der verbleibenden Risiken können verringert werden, indem die Mitarbeiter geschult und darüber aufgeklärt werden, wie wichtig die Einhaltung von Sicherheitsrichtlinien für die Sicherheit des organisationsinternen Netzes ist. Vollständige Sicherheit ist jedoch unmöglich.

4.6 Firewall-Management

Werden in einem Unternehmen mehrere Firewalls betrieben, so ergeben sich zusätzliche Komplikationen beim Management der Systeme. Mehrere Firewalls sind notwendig bei räumlicher Trennung mehrerer Niederlassungen mit eigenen Internetzugängen oder bei geschäftsprozeßbedingte Kopplung zu den Netzen verschiedener Partnerfirmen (Extranet). Die Konfiguration eines Firewallsystem ist immer einmalig auf den jeweiligen Standort und die Netzwerktopologie zugeschnitten. Es gibt keine Firewall-Konfiguration 'von der Stange'.

In den wenigsten Fällen ist es möglich, einen Firewall direkt an der Konsole des Rechners zu managen. Selten wird der Firewallrechner am Schreibtisch des Administrators stehen. Manche Firewalls erlauben ein remote Management nur über dedizierte Leitungen (seriell, eigenes LAN). Die Kenntnis der internen Konfiguration oder das Mithören der Passwörter beim remote login über das interne LAN erleichtern einen Einbruch-Versuch. Daher muß beim direkten Login in den Firewall-Rechner immer eine verschlüsselte Verbindungen benutzt werden. Liefert der Hersteller keine ausreichenden Tools zum Remote-Management von Firewallsystemen, so kann man durch den den Einsatz von frei verfügbaren Tools die Situation wesentlich verbessern. Programme wie Secure Shell (ssh, fü remote login), PGP (zum Signieren von Konfigurationsdateien) und rsync (zum Datentransfer und Datei-Synchronisation über ssh) bilden schon eine sehr gute Basis. Hat man viele Systeme zu betreuen, mag die Installation eines eigenen Firewall-Management-Rechners vorteilhaft sein. Dieser zentrale Management-Rechner kann dann die Meldungen aller Firewalls auswerten und archivieren, und kann seinerseits einen abgesicherten WWW-Server bereitstellen (Apache-SSL), über den Management-Funktionen zentral für mehrere Firewallsysteme und Statusabfragen abgewickelt werden können.

4.7 Alternativen zu Firewalls

Routing-Kontrolle über statische Routingtabellen

Beim IP-Routing müssen alle an einer Verbindung beteiligten Rechner die Route zu ihren Partnern kennen, d.h. im einfachen Fall einer Verbindung von zwei Rechnern, daß Host A den Weg zu Host B und umgekehrt auch Host B den Weg zu Host A bekannt sein muß, um eine Kommunikation zu ermöglichen. Aus diesem Grund kann ein empfindlicher Rechner schon dadurch besser abgesichert werden, daß er nur die Routen zu genau definierten Partnern kennt und solche Pakete mit ihm unbekannten Wegen nicht an einen Gateway oder Router zum Weiterversand weiterleitet. D.h. ein mit derart gesicherter Rechner kennt keinen default Gateway und ist mit einer statischen Routingtabelle konfiguriert.

Zugriffskontrolle

Rechner und Router prüfen die Zugriffe auf das Netz bzw. auf das System anhand von Zugriffskontroll-Listen (Access Control Lists, ACL) Das kann bei Routern mit dem sogenannten Screening geschehen, wobei dem für unerlaubte Dienste der jeweilige Port gesperrt, für zugelassene Dienste der jeweilige Port offen ist. Weiterhin kann das Screening auch noch über Tabellen auf der Basis von IP-Adressen konfiguriert werden, um nur bestimmten Rechnern den Zugang zu gestatten bzw. zu unterbinden. Ein wesentlicher Nachteil diesen Verfahrens ist, daß es nicht immer ganz einfach ist, alle zu sperrenden oder zu gestattenden Dienste/Ports zu ermitteln. Weiterhin kann der Router mit der Zugangskontrolle so start belastet sein, daß es zu Performanceeinbrüchen kommen kann.

Neben der Zugriffskontrolle bei Routern kann der Zugriff auch hostbasiert für viele Serverdiensten mittels sog. Wrapper-Implementierungen kontrolliert werden. Hierbei wird bei einer Dienstanforderung nicht der eigentliche Daemon gestartet, sondern zunächst ein Wrapper, der anhand von Listen den Zugang prüft und die Anforderung abweist bzw. den eigentlichen Daemon startet. Bsp.: statt den FINGER-Dienst direkt über den inetd zu starten

finger ----->  inetd  ----->  fingerd
       79/tcp

wird zunächst ein Wrapper wie tcpd gestartet, der anhand von ACLs die Zugangsberechtigung prüft und ggfs. dann den fingerd aufruft

finger ----->  inetd  ----->  tcpd  ----->  fingerd
       79/tcp                 ACLs

Die ACLs sind meist einfache Tabellen (/etc/hosts.allow, /etc/hosts.deny), in denen festgelegt wird, für welche Hosts bzw. Subnetze welche Dienste zugelassen oder gesperrt sind.

Das Problem bei Wrappern ist, daß alle Dienste derart gewrappt werden müssen, um den Rechner zu sichern, d.h. auch Dienste mit dynamischer Portzuweisung wie NFS.

4.8 WWW-Server Sicherheit

Grundsätzlich kann ein WWW-Server vor oder hinter (extern oder intern) einem Firewall angeordnet werden. In beiden Fällen ist der Rechner des WWW-Servers so gut wie möglich abzusichern. Auch die Position hinter dem Firewall (aus der Sicht des Internet) schützt nicht gegen Angriffe über das HTTP-Protokoll, z.B. CGI-Attacken.

Die Position des WWW-Servers wird von mehreren Faktoren bestimmt. Dies sind zum einen funktionelle Faktoren, wie z.B. der Zugriff auf firmeninterne Datenbanken oder Platformabhängikeiten der Web-Anwendung. Andere Faktoren sind die erwartete Serverlast (bestimmt die Belastung des Firewalls bei interner Serverposition) und die Schutzwürdigkeit der auf dem Server zugänglichen Daten. Ebenso wichtig ist der leichte aber sichere Zugriff des Webmaster zu seinen Daten auf dem Server.

Eine mögliche Konfiguration eines WWW-Server besteht darin, daß der Haupt-Server mit den statischen Daten außerhalb des Firewalls steht, also aus dem Internet voll zugänglich ist. Über einen vorgeschalteten Router kann man den Zugriff für bestimmte Ports frei schalten. Der WWW-Server wird so konfiguriert, daß Anfragen an bestimmte URLs von diesem über den Firewall an einen internen WWW-Server weitergeleitet werden (Proxy-Funktion). Dieser interne Server generiert hauptsächlich dynamische HTML-Seiten, z. B. aus Abfragen einer internen Datenbank.

Eine andere Variante besteht darin, außerhalb des Firewalls einen Cache-Server aufzustellen, der die HTML-Anfragen an den eigentlichen, innerhalb des Firewalls stehenden, WWW-Server weiterleitet. Diese Konfiguration hat den Vorteil, daß sich der außerhalb stehende Cache dem Internet als WWW-Server präsentiert. Auf dem Firewall muß nur die Verbindung zwischen dem Cache und dem internen WWW-Server freigeschaltet werden, der interne Server tritt niemals direkt mit einem der Clients am Internet in Kontakt.

4.9 Intrusion Detection

Intrusion Detection Systeme (IDS) und Intrusion Response Systeme (IRS) gewinnen in einem größeren Netzwerk immer mehr an Bedeutung. Mit den IDS-Systemen können Angriffsmuster erkannt werden, wodurch Angriffe, die normalerweise unbemerkt geblieben wären, detailliert verfolgt werden können. Sie eignen sich beispielsweise zum Aufbau einen Honeypot/Honeynet - wobei Server (die teilweise ganz bewusst Sicherheitsmängel aufweisen) als Köder ins Internet gestellt werden, dabei aber akribisch überwacht werden.

Vornehmlich Firmen-Netzwerke sind vielen Angriffs-Versuchen sowohl von innen als auch von außen ausgesetzt. Ein PacketSniffer kann hier Abhilfe schaffen, indem er den gesamten Netzwerk-Verkehr protokolliert. Aber es kann nicht die Aufgabe des System- bzw. Netzwerk-Administrators sein, den Tag mit der Analyse der protokollierten Daten zu verbringen und etwaige Angriffe zu erkennen, zumal er dafür auch noch die spezifischen Merkmale der Unmengen möglicher Angriffe zur Hand oder besser im Kopf haben müsste. Hier helfen sogenannte Intrusion Detection Systeme weiter, die den Netzwerkverkehr mittlerweile in Echtzeit analysieren und anhand bestimmter Regeln etwaige Angriffe erkennen und bei Bedarf Aktionen ausführen, um den Angriff abzuwenden, ihn zu protokollieren oder den Administrator zu benachrichtigen.

Hier stellt sich aber zuerst die Frage, was eine Intrusion überhaupt ist. Heberlein, Levitt und Mukherjee von der University of California, Davis haben sie 1991 wie folgt definiert: Eine Menge von Handlungen, deren Ziel es ist, die Integrität, die Verfügbarkeit oder die Vertraulichkeit eines Betriebsmittels zu kompromittieren. Allgemeiner gefasst kann man eine Intrusion als eine Verletzung der Sicherheitsmassnahmen eines Systemes verstehen. Intrusion Detection ist noch ein sehr junges Gebiet der IT-Sicherheit und ist im allgemeinen der Versuch, Methoden zu entwickeln, mit denen Angriffe auf Rechnersysteme erkennbar sind. Frühe Intrusion Detection Systeme versuchten dies anhand der Analyse der vom Betriebssystem zur Verfügung gestellten Protokolldateien, den sogenannten Auditdaten, die dem Administrator meistens auch zur Verfügung stehen. Eine andere Möglichkeit ist die Überprüfung der Integrität von Dateien mit Hilfe von Programmen wie Tripwire, um sicherzustellen, daß Dateien nicht verändert wurden. Heutzutage kommt es nicht nur auf die Analyse von Protokolldaten eines Hosts an, sondern auf die effektive Analyse von teilweise sehr grossem Netzwerkaufkommen.

Sollte nun ein Angreifer versuchen, in einen Computer oder ein Netzwerk einzudringen, auf dem ein solcher PacketAnalyser installiert ist, so schlägt dieser Alarm, protokolliert den Angriff und kann ihn eventuell abwehren. Letzteres zählt aber eher zur Aufgabe von Intrusion Response Systemen. Generell kann man ein Intrusion Detection System als eine Art Alarmanlage ansehen. Sollte ein Einbruch vom System entdeckt werden, wird der Administrator benachrichtigt (über Pager, SMS, eMail, WinPopup-Message, etc.) und kann dann entscheiden, wie er mit dem Problem umgeht. Im Extremfall wird er sich entscheiden, das System herunterzufahren oder in den Single-User-Mode bringen, um es keinem weiteren Missbrauch auszusetzen und sich ungestört der Behebung des ausgenutzten Fehlers widmen zu können.

Die Konfiguration solcher Systeme ist sehr vielfältig und kann je nach Ausführung auch sehr umfangreich werden. Die grössten Unterschiede liegen wohl darin, ob man ein solches IDS für einen einzelnen Rechner einsetzen möchte oder ein ganzes Netz absichern will. Bei der Konfiguration ist es wichtig, dass die Integrität der Konfigurationsdaten gesichert ist und das im Falle eine Einbruchsmeldung diese auch garantiert wird, dass es sich also um einen echten Angriff handelt und nicht etwa um einen Fehlalarm, der als Folge einer Fehlkonfiguration entstand.

Auch eine nicht der Sicherheits-Policy entsprechende Benutzeraktion kann und soll von einem Intrusion Detection System angezeigt werden. Daraus resultiert auch die Notwendigkeit, dass ein IDS in die Sicherheits-Policy eines Unternehmens integriert wird und Eskalationspläne für die möglichen Angriffe festgelegt sind. Laut dem ISO (International Standards Organisation) Workingdraft 15947 soll ein Intrusion Detection System die folgenden Sicherheiten bieten:

Die Reaktion auf einen vom IDS ausgelösten Alarm muss dann innerhalb des Unternehmens durch eine Eskalationsprozedur bestimmt werden.

Die Angriffe werden bei Intrusion Detection Systemen in zwei Kategorien unterteilt. Als Erstes sind die Angriffe über das Netzwerk zu nennen. Hierzu zählen alle Angriffe auf den unteren vier Protokollschichten des OSI-Models. Als zweite Klasse werden die Angriffe auf den Server oder Host des Netzwerkes betrachtet. Die Komplexität und Vielzahl der Softwarepakete, die auf einem Server läuft, birgt eine große Anzahl an Fehlermöglichkeiten. Programme, die eine Sicherheitslücke ausnutzen, um dem Angreifer Zugang zum System zu verschaffen, werden als "Exploits" bezeichnet. Wegen der Vielzahl der Angriffsmöglichkeiten besteht ein Intrusion Detection System aus einer großen Sammlung von Komponenten, die verschiedene Ereignisse, Eingaben und Datenverhalten überwachen und gegebenenfalls einen Alarm auslösen.

Im Allgemeinen erledigt ein IDS seine Arbeit in drei Schritten:

Informationen zum Thema IDS:

Links zum Thema IDS:

Zum vorhergehenden Abschnitt Zum Inhaltsverzeichnis Zum nächsten Abschnitt


Copyright © FH München, FB 04, Prof. Jürgen Plate