Firewalling
Unter Firewalling ist die Umsetzung einer Firewall für ein Netzwerk zu verstehen.
Aber was ist eine Firewall?
Eine Firewall ist ein Konzept um die Zugriffsrechte auf Systeme und Dienste die in einem Netzwerk verfügbar sind zu regeln. Oftmals wird auch von einer Firewall gesprochen und damit das Gerät gemeint, welches die Zugriffsrechte in einem Netzwerk primär regelt, aber sachlich ist dies eigentlich falsch. Um zu verstehen wie und warum eine Firewall arbeitet sollte man die Grundlagen des TCP/IP Protokolls kennen.
Doch warum braucht man eine Firewall?
Eine Firewall regelt i.d.R. drei grundlegende Dinge in einem Netzwerk:
Sie stellt eine zentrale Instanz zur Umsetzung einer Sicherheitspolitik in einem Netzwerk dar.
Sie sichert Server und Workstations eines Netzwerkes vor Unbefugtem Zugriff durch nicht autorisierte Systeme.
Sie ist in der Lage das Gefahrenpotential zu verringern.
Was kann eine Firewall nicht?
Wenngleich eine Firewall ein zentrales Element einer Sicherheitspolitik in Datennetzen darstellt (oder es zumindest sollte), so gibt es Dinge für die sie sich nicht eignet:
Sie kann keinen Schutz vor Angriffen von 'innen' heraus gewähren. (Sollte ein Angreifer als Vertrauenswürdig eingestuft worden sein, so wird kein Firewallsystem daran was ändern)
Sie kann die Privatsphäre nicht schützen. (Datenverkehr unter TCP/IP läuft normalerweise unverschlüsselt)
Sie kann einen Administrator nicht vor Problemen auf den Endgeräten schützen.
Das Konzept Firewall
Sicherheitsrichtlinien
Um das Konzept Firewall umzusetzen, muss man sich erst einmal klar werden wie man dies realisieren kann. Hierzu geht man am besten so vor, das man sich erst mal überlegt was man erlauben und verbieten will. Hierbei ist zu berücksichtigen, dass verschiedene Teilnehmer eines Netzwerkes verschiedene Dienste benötigen. So wird die Einkaufsabteilung eines Unternehmens u.U. ?nur? die Dienste Email oder WorldWideWeb brauchen. Die Entwicklungsabteilung braucht evtl. noch zusätzlich FTP und der Vorstand will möglicherweise Videokonferenzen durchführen können. Je nach Situation kann es also recht schnell sehr Komplex werden zu überschauen wer welche Dienste im Netz benötigt. Ergo braucht man einen sinnvollen Ansatz wie man das mit dem Erlauben und Verbieten realisieren soll. In der Praxis haben sich zwei Ansätze als praktikabel herauskristallisiert:
Man erlaubt erst mal alle Dienste und sperrt dann nach und nach diejenigen Dienste, die nicht benötigt werden.
Man verbietet erst mal alle Dienste und erlaubt dann genau die Dienste, die benötigt werden.
Beide Ansätze haben Vor- und Nachteile. Der Vorteil von Methode 1 liegt darin, dass schnell alles ans Laufen gebracht werden kann. Allerdings besteht die Gefahr, dass beim Sperren der Dienste etwas übersehen werden kann. Außerdem besteht die Gefahr, dass ein Cracker das System kompromittiert ehe es durch den/die Administratoren gesichert werden konnte. Daher empfehle ich persönlich den zweiten Ansatz. Dessen großer Nachteil besteht darin, dass Dienste erst nachdem sie explizit freigeschaltet worden sind verfügbar sind. Gerade wenn ein Netzwerk komplett neu aufgebaut wird kann dies zu erheblichen Störungen des Betriebs führen. Andererseits läuft man nicht Gefahr, dass Dienste bei der Konfiguration nicht berücksichtigt werden, die dann zu einer Kompromittierung durch einen Cracker führen können. Zu beachten ist, dass die Wahl eines Ansatzes mit dem/den Vorgesetzen abgesprochen werden muss.
Wer jetzt der Meinung ist beide Ansätze quasi Mischen zu können sollte sich klar machen was dies bedeutet:
Man verliert die Glaubwürdigkeit gegenüber den Nutzern des Netzwerkes. Dies sorgt nicht nur für Unmut bei den Kollegen, sondern führt auch dazu, dass sich weiterführende Sicherheitsrichtlinien wenn überhaupt, dann nur schwer Umsetzen lassen.
Man verliert die Übersicht. Man muss genau nachhalten wann man was wie umgesetzt hat. Sollte man hierbei einen Fehler machen ist die Übersicht futsch.
Man erhöht den Arbeits- und Zeitaufwand den man zur Umsetzung braucht. Da jede Sicherheitsrichtlinie mit den Vorgesetzten abgesprochen werden muss würde dieses Vorgehen zu permanenten Diskussionen mit diesen führen.
Bedrohungsanalyse
Als nächstes muss eine Bedrohungsanalyse durchgeführt werden. Hierzu sollte man sich klar machen welche Daten man im Netz vorhält und welcher Schaden dadurch entstehen kann wenn diese Daten in falsche Hände fallen. (Ein Beispiel hierzu: Ein eCommerce-Unternehmen hat einen Onlineshopping Server. Auf diesem müssen Kundendaten verfügbar sein. Hierzu gehören in diesem Beispiel auch Kreditkartennummern. Wie groß ist der Schaden wenn diese Daten in die falschen Finger geraten?) Aber auch die Frage wie teuer der Ausfall eines Dienstes kommt ist für eine Bedrohungsanalyse vonnöten.
Sobald die Bedrohungsanalyse abgeschlossen ist, muss überlegt werden, welche Sicherungsmaßnahmen (Paketfilter, Intrusion Detection Systeme, Anti-Viren-Systeme o.ä.) eingesetzt werden sollen und was dies kostet. Hierbei ist wichtig die Kosten in ein sinnvolles Verhältnis zum möglichen Schaden zu setzen.
Hierzu ist es wichtig sich erst einmal eine Übersicht der am Markt befindlichen Sicherheitsprodukte zu verschaffen. Dabei muss berücksichtigt werden, dass bestimmte Sicherheitsprodukte andere Produkte voraussetzen. (So braucht ein auf Linuxbasis arbeitender Paketfilter die entsprechende Hardware, ein für die Windowsplattform programmiertes Anti-Viren-Paket braucht eine bestimmte Windowsversion etc.)
Paketfilter
Soweit so gut. Nachdem man sich also klargemacht hat was man schützen will und wie viel man dafür ausgeben darf/kann, muss man nun noch überlegen wie man den Schutz realisieren will.
Heutzutage sind sog. Paketfilter zur Umsetzung der Firewallrichtlinien üblich. Hierbei gibt es drei verschiedene Arten:
Zustandslose Paketfilter (z.B. ipchains, Linux Kernel 2.2.x, div. Cisco Router)
Zustandsbehaftete Paketfilter (z.B. Checkpoint FW-1)
Applikationsproxies (Selten, da teuer und mit Detailfehlern im Design)
Es gibt noch eine weiter Form von Paketfiltern die in diesem Zusammenhang nicht weiter betrachtet werden sollen. Die sog. Personal Firewalls, als da wären ZoneAlarm, o.ä. Diese sind für einen wirkungsvollen Schutz aufgrund diverser Designfehler ungeeignet.
Aber was soll der Paketfilter nun filtern? Es gibt 3 verschiedene wichtige Protokolle im Internet:
ICMP
.Da dies ein Message Control Protokoll ist wird hier nach Messagetypen unterschieden. Eine Paketfilter sollte auf jeden Fall den Typ 5 (Redirect) filtern, da ein Angreifer hierdurch in die Lage versetzt wird den Datenverkehr auf ein bestimmtes System umzulenken. Der Messagetyp 0 (Echo Reply) ist ein eher umstrittener Messagetyp. Viele Experten gehen davon aus, dass man diesen Typen nicht filtern sollte, da man ihn eh nicht brauchen kann um einen Angriff zu starten. Meiner Meinung nach sollte man aber bei allen an das Internet angeschlossenen Systemen, die keine Dienste für die Öffentlichkeit bereitstellen (z.B. Proxies für das LAN) diesen Echo Reply filtern. Hierdurch schaltet man einen solchen Rechner in eine Art Stealth-Modus. Der Angreifer wird ihn nicht mehr sehen und hat ein Angriffsziel weniger zur Verfügung
UDP
.Hierbei handelt es sich um ein statusloses Protokoll. Da einige Dienste (traceroute, dns, etc.) dieses Protokoll benötigen, muss ein Paketfilter dieses Protokoll berücksichtigen. Hierbei muss sich ein Administrator klar machen welcher Dienst auf welche Maschine zugelassen werden muss. So empfehle ich für ein traceroute dasselbe, was ich für ein Ping empfehle. Bei anderen UDP Paketen ist i.d.R. klar welcher Zielrechner diese benötigt. Ansonsten gilt: was nicht gebraucht wird sollte gesperrt werden.
TCP
.Auch hier gilt: Alles sperren, was nicht gebraucht wird. Protokolle die benötigt werden nur zu den Zielrechnern zulassen, die diese auch verarbeiten können. (www nur zum Webserver zulassen, ftp nur zum FTP-Server, etc.)
Eine Anmerkung zum Sperren. Eben war die Rede davon den Ping Echo Reply oder den traceroute für Rechner die im WAN keine Dienste anbieten zu sperren. Hiermit ist ein ersatzloses Wegwerfen der für diese Systeme gedachten Pakete gedacht.
Bei den anderen Systemen (Webserver, Fileserver etc.) sollte hingegen das Sperren als zurückweisen aufzufassen sein. Da diese Rechner eh öffentlich bekannt sind führt ein Wegwerfen der Pakete nur dazu, dass ein evtl. auftauchender Fehler nicht mehr nachvollzogen werden kann. Wird das Paket hingegen zurückgewiesen, kann man anhand der zurückgewiesenen Paketen u.U. erkennen woher der Fehler kommt.
Verschlüsselung der Dienste
Eine Anmerkung noch zur Überlegung welche Dienste gebraucht werden. Ein Netzwerkadministrator sollte bestrebt sein, Dienste wenn möglich durch ein verschlüsseltes Pendant zu ersetzen. So kann der TELNET Dienst z.B. durch die SecureShell ersetzt werden, der FTP-Dienst durch das SFTP.
Multimediadienste wie z.B. Netmeeting sollten nach Möglichkeit nicht über das Internet genutzt werden, da sie dermaßen viele Ports brauchen. (?hierbei verwandeln sich Firewalls in Schweizer Käse?; Zitat: Lutz Donnerhacke). Sollte man sie dennoch über das Internet nutzen wollen/müssen, so sollte man nach Möglichkeit einen anderen Adressbereich hierfür nutzen als für die WAN-Anbindung.
Da eine Firewall ein Konzept ist, sind wir mit der reinen Paketfilterung noch nicht am Ende.
Logging
Eine weitere Forderung an ein Firewallkonzept ist, dass mitprotokolliert wird. Das bedeutet, dass man penibel über alle Aktivitäten Buch führt. Hierbei ist es sinnvoll, wenn möglich direkt eine Trennung zwischen normalen/erlaubten Aktivitäten und unnormalen/verbotenen Aktivitäten zu machen. Auf diese Art erhöht sich die Lesbarkeit der Logfiles. Eine weitere Überlegung die sich bei der Forderung nach einem Logging stellt ist die Frage warum geloggt werden soll und was man mit den Logfiles macht. Zum einen kann durch das Logging schnell herausgefunden werden was mit dem System passiert. Neben der schnelleren Fehlerfindung kann auf diese Art auch ein Einbruchsversuch erkannt werden. Allerdings muss auch jmd. da sein, der diese Logfiles liest. Daher ist zu überlegen die Logfiles durch Hilfsprogramme in eine leichter lesbare Form zu bringen.
Schutz der Server
Alle o.g. Maßnahmen bringen aber nichts, wenn die Server als solches nicht ausreichend geschützt sind. Daraus ergeben sich folgende Forderungen:
Ein Server sollte ausschließlich zu dem einen Zweck genutzt werden, nämlich Dienste zur Verfügung zu stellen. (D.h.: Man arbeitet oder spielt nicht auf einem Server)
Ein Server sollte nach Möglichkeit nur einen Dienst anbieten. Sollte man einen weiteren Dienst anbieten wollen, so sollte man nach Möglichkeit einen weiteren Server aufbauen.
Die Administration sollte nach Möglichkeit nicht über das Netz gemacht werden. Da diese Forderung in dem meisten Fällen eher eine Idealforderung ist, sollte man bei einer Remoteadministration zumindest verschlüsselte Dienste (z.B. SecureShell) nutzen und den Adressbereich der administrieren darf einschränken.
Ein Server sollte nicht in der Lage sein mit anderen Servern zu kommunizieren. Dies regelt man am besten dadurch, dass die Serversysteme nicht an einen Switch/Hub angeschlossen sind, sondern direkt am Paketfilter
Ein Server sollte Up to Date sein. Dies erreicht man durch das Hardening.
