<<< wie geht dem - übersicht - wie geht dem - sicherheits-checkliste >>>
firewalling - tücken und herausforderungen
Wenn mich keiner sieht bin ich doch sicher, oder?
Die aktuelle Version dieser Seite liegt unter http://verfaction.de/firewall.
Alle Copyrightrechte verbleiben beim Autor.
Vorbemerkungen
Was eine Firewall nicht ist
Ganz grundsätzlich sollten wir hier mal mit einem Mißverständnis aufräumen: So gut wie niemand sollte als Privatperson eine Firewall überhaupt brauchen. Eine Firewall ist das Eingeständnis, dass der Netzwerkadministrator nicht alle Rechner "sicher" konfiguriert hat. Entweder weil er dazu nicht in der Lage ist (z.B. weil Kunden ihre Rechner mit ins Netzwerk bringen), oder weil ihm die Konfigurationskomplexität über den Kopf gewachsen ist. In jedem Fall sollte hier an der Konfiguration dieser problematischen Endgeräte angefangen werden, nicht erst an der Firewall schrauben und dann feststellen, dass man ja immer noch ein Problem hat. Man kauft sich schliesslich auch für seine Privatwohnung keinen Türsteher, nur weil man eine Party im kleinen Rahmen mit ein paar Freunden feiert.
Was eine Firewall sein sollte
Nehmen wir also an, dass wir alle eigenen Rechner korrekt abgesichert haben. Diese lassen also nur zu, was wir explizit erlaubt haben. Jetzt kann man eine Firewall dazu benutzen, diese Konfiguration zu unterstützen und eine zusätzliche Absicherung durchzuführen oder gar gegenüber Dritten den Rechner oder Dienst ganz zu verstecken. Die sinnvolle Anwendung von Firewalling ist jedoch im großen Maßstab für ganze (Firmen-)Netzwerke. Also um eine ganze Gruppe von Rechnern zentral mit einer kontrollierten Anbindung zum Beipsiel ans Internet zu versehen. Gerade in Notfallsituationen kann dann an einer zentralen Stelle die Verbindung unterbrochen werden, um zum Beispiel Sicherheitsupdates einzuspielen, bevor man von der nächsten Wurm-Welle getroffen wird und ungewollt daran teilnimmt.
Die optimale Konfiguration sollte genau die Dienste zulassen, die für den erwünschten Betrieb benötigt werden und alle anderen Zugriffe komplett unterbinden. Der Effekt ist eine minimale Behinderung der legitimen Arbeiten und maximale Verhinderung aller sonstigen Zugriffe.
Was eine Firewall konzeptionell implementiert
Ein unsicherer Dienst bleibt auch hinter einer Firewall unsicher. Die Problematik wird dadurch nicht entschärft, dass man nur noch eingeschränkt darauf zugreifen kann. Bestenfalls sinkt die Wahrscheinlichkeit eines erfolgreichen Angriffs. Aber einen Dienst alleine durch Anbringen einer Firewall als "sicher" einzustufen, entbehrt jeder technischen Grundlage. Es sollte also die Ursache behoben werden, nicht die Wirkung. Wer viele Dienste betreiben will, muss sich bei der Installation darüber klar werden, dass diese Installation eine Pflege nach sich zieht. Auch und gerade mit Firewall sollte man sich dessen bewusst sein. Speziell die psychologisch beruhigende Komponente einer installierten Firewall verleitet zur Nachlässigkeit. Und verharmloste Sicherheitsproblematik suggeriert womöglich noch, dass es akzeptabel wäre auch nach Wochen oder Monaten nach der Offenlegung von Sicherheitslöchern diese ungestopft zu lassen. Darüberhinaus ist es eigentlich nicht der Sinn und Zweck einer Firewall Kenntnis von Protokollen zu haben und sicherzustellen, dass nur solche Protokolle auf den zugelassenen Verbindungen genutzt werden, die auch explizit erlaubt sind. Auch wenn es ganz grundsätzlich möglich ist.
Aspekte von Sicherheit
Sicherheitskonzept
Bevor man ein Netzwerk effektiv schützen kann, muss man seine Schwachstellen kennen. Dieser grundlegende Ansatz wird jedoch bei vielen Installationen völlig vernachlässigt. Es wird erst installiert, dann probier, dann noch mehr installiert und nacher dann direkt in den Produktivbetrieb gewechselt. Mit allen Testeinstellungen, die für die Einrichtung nötig waren. Aussen noch der "Never touch a running system"-Kleber drauf und fertig. Leider beinhaltet dieser Ansatz, dass weder bekannt ist, warum etwas tut, bzw. wie diese Installation wiederholt werden kann. Damit ist nicht nur die Pflege und Aktualisierung problematisch, auch die Migration eines Dienstes von einem kompromittierten System auf eine neue Hardware gestaltet sich äusserst kniffelig. Abgesehen von diesen ganz allgemeinen Administrationsproblemen kann wohl auch niemand dedizierte Einstellungen definieren, die zum Betrieb eines Dienstes benötigt werden. Für eine effiziente Firewall-Konfiguration ist es jedoch unerlässlich, dass genau diese Parameter bekannt sind. Bevor also über Art und Einstellung der Firewall nachgedacht werden kann, muss eine saubere Bestandsaufnahme aller Dienste und Rechner vorliegen, in der für jede Installation verzeichnet ist, was die minimale Angriffsfläche ist, die zugelassen werden muss. Dieser Prozeß ist überdies nicht einmalig, er sollte iterativ erfolgen und auch Veränderungen dazu nutzen, die bestehende Installation in Frage zu stellen und gegebenenfalls in optimierter Anordnung neu zu ordnen.
Netzwerk
"Vertrauen ist gut, Kontrolle ist besser". Dieser Spruch ist wohl jedem schon einmal begegnet. Für die Betrachtung von Rechnernetzen bedeutet das also, dass jedes Netzsegment, über das ich keine (physikalische) Kontrolle habe, einem Vertrauen unterliegt. Dieses Vertrauen kann mich dazu veranlassen, dass ich es als "sicher" und vertrauenswürdig einstufe, oder davon ausgehen muss, dass alle Daten, die über dieses Netzsegment gehen (zumindest potentiell) von Dritten mitgelesen werden. Durch eine Zugriffsregelung wie Firewalling kann man also eine bedingte Sicherung einziehen, die sicherstellt für welche Dienste aus welchen Quellen und für welche Ziele Verbindungen zugelassen werden. Die Firewall muss also mein vorher festgelegtes Sicherheitskonzept "einbetonieren".
Angriffsvektoren
Ein Problem kommt selten alleine. Insofern ist das auch nicht sinnvoll eine Firewall nur in eine Richtung arbeiten zu lassen. Es sind stets alle 4 Kombinationen relevant:
  • aussen <-> innen
  • innen <-> aussen
  • aussen <-> aussen
  • innen <-> innen
Gerade bei der Verwendung der TCP-Verbindungsnachverfolgung kann mit gezielten Paketen, die an die Firewall geschickt werden eine Verbindung erlaubt werden, die ursprünglich gar nicht erst zugelassen worden wäre, aber auf Grund der Tatsache "dass sie ja bereits existiert" dann doch gültig wird. Auch wenn sie nur für langsame Übertragungen geeignet sind, so sollten DNS-, ICMP- und SMTP-Tunnel unterbunden werden, wo nicht erwünscht. Speziell die Möglichkeit DNS-Anfragen auch ohne Authentifizierung aufzulösen wird häufig übersehen.
Sicherheit, Integrität, Authentizität
Um eine effiziente Zugriffregelung zu implementieren sind also 6 Faktoren pro Verbindung relevant: Quell-Adresse, Ziel-Adresse, Quell-Port, Ziel-Port, Eingangs-Interface, Ausgangs-Interface. Üblicherweise sollten die Adressen festliegen und sich nicht dynamisch ändern. Ebensowenig die Zuordnung von ein- und ausgehendem Interface. Was sich unglücklicherweise dynamisch verändern kann, sind die Ports. Bei TCP gibt es hierfür Verbindungsnummern, die einzelne Verbindungen in eine Gruppe zusammenfassen. Derartige Zuordnungen können jedoch auch gezielt gefälscht werden, um eine Zugehörigkeit vorzutäuschen. Man sollte sich also gut überlegen, bei welchen Regeln es Sinn macht diese Zugehörigkeit zum Erlauben weiterer Verbindungen heranzuziehen und wo nicht.
Bei der Annahme von Paketen aus einem Interface sollte vor allem mit dem Administrator des Fremdnetzes abgesprochen werden, welche Sicherheitsrichtlinien bei ihm Anwendung finden, so dass man Anfragen, die nicht legitim aus diesem Netz kommen dürfen gleich ablehnt. Gerade für an sich vertrauenswürdige, angeschlossene Netzwerksegmente sollte man sicher sein, dass nur diejenigen Verbindungen akzeptiert werden, die zu diesem Netz gehören.
Konzeptionelle Schwächen und Social Engineering
Ansonsten klingelt bei dem Namen "Tinkerbell" etwas? Nein? Dieser inzwischen medienberühmte Hund der Millionärstochter Paris Hilton hat auf der T-Mobil-Plattform Hackern im Frühjahr 2005 dazu verholfen die Passwort-vergessen-Frage zur Plattform zu beantworten: "Wie heisst mein Liebliengshaustier?". Da die Email-Plattform nur schlecht ein vergessenes Passwort per Email zuschicken kann, erhielten die Angreifer prompt Zugriff. Diese Funktion zeigt eindrucksvoll, dass Bequemlichkeit und Sicherheit nicht vereinbar sind. Gerade über "social engineering", also das Inerfahrungbringen von Informationen über das Umfeld einer Person schwächen gängige Passwort-vergessen-Systeme, die auf Alltäglichkeiten des Benutzers abzielen.
Mißbrauch von Infrastruktur
Bei der Betrachtung auf Basis von protokoll-spezifischen Ports fehlt jedoch ein nicht ganz uninteressanter Punkt: Wer garantiert, dass nur dieses Protokoll über den Port gesprochen wird? Kurze Antwort: Niemand. Zumindest bei der klassischen Firewall ist über ein binäre Entscheidung auf Basis der 6 genannten Faktoren keinerlei inhaltliche Aussage möglich. Und eine Analyse von dem inhaltlichen Protokoll ist in aller Regel aufwändig und benötigt mehr als nur ein Paket für die Beantwortung. Gerade also für Netzwerk-Router ist es also keine gute Idee hier eine künstliche Verknappung herbeizuführen, um mehrere Pakete erst mühsam zu inspizieren, bevor man sie weiterleitet. Der Ausweg, der auch industriell angewandt wird, ist ein Proxy. Dieser kann sowohl transparent zugeschaltet werden, als auch über die Firewall erzwungen werden (alle Rechner des Netzes haben keinen Zugriff auf den Dienst und können nur über den Proxy nach "draussen). Für eingehende Verbindungen gibt es sogenannte Reverse-Proxies, die speziell auch Lastverteilungsfunktionen übernehmen können.
Aktive Benutzermithilfe
"Jetzt sind wir doch sicher.", wird der eine oder andere jetzt denken. Tja, wären da nicht die Benutzer. Erwiesenermaßen gibt es genug Benutzer, die zum Beispiel Emails mit dem Titel "I love you" völlig unkritisch erst einmal öffnen und auch mitgelieferte Programme arglos ausführen. Die Ergündung überlassen wir an dieser Stelle zwar den Psychologen, aber wir stellen fest, dass so gut wie jedes Netzwerk nur so sicher ist, wie das schwächste Glied. Und je mehr Intelligenz in das Netzwerk-Setup wandert, um so schwächer werden relativ gesehen die durchschnittlichen Benutzer. Produktivität und Komfort sind und bleiben die Hauptfeinde von einer sicheren Konfiguration. Wer erst 3 komplexe Passwörter eingeben muss, um die Email "Besprechung um 12:00 statt um 14:00 Uhr." lesen zu können wird früher oder später aufhören Email als Kommunikationsmedium einzusetzen. An diesem Punkt wird dann die übliche Diskussion zwischen IT und Geschäftsführung in die nächste Runde gehen, welcher Aspekt schwerer wiegt.
Böswillige Angreifer
Angenommen wir haben sichere Netzwerke, leidensfähige und sicherheitsbewusste Anwender und glauben alles getan zu haben, um die Zugriffe nur für authorisierte Benutzer sicherzustellen. In der Informatik wird für handelsübliche Software zwischen 2% und 10% fehlerhafte Codezeilen angenommen, wenn der Code regulär "überprüft" wurde. Bei intensiv auditierter Sicherheitssoftware etwa bis 0,5%. Wenn wir also nun noch davon ausgehen, dass nicht alle Fehler automatisch auch von aussen ausnutzbar sind, bekommen wir immerhin eine Vorstellung davon, dass selbst mit der im Moment als "sicher" eingestuften Software locker einige bis ein paar 10 Fehler pro eingesetzte Applikation enthalten sind. Besonders sportlich ambitionierte Cracker sehen gerade dieses als Herausforderung an und werden danach suchen. Für den Administrator bedeutet dies allerdings, dass es keinen Zeitpunkt geben kann, an dem ein Server als "unhackbar" gelten kann. Man muss stets ein wachsames Auge dafür haben, ob im normalen Betrieb Anomalien in den Logfiles auftreten oder sich genrell Abweichungen vom Normalbetrieb zeigen. Gerade in der hochkomplexen IT von heute ist diese Anforderung jedoch ohne Helfer nicht zu lösen. Leider haben aber auch diese Helfer immer mal wieder wieder ihrerseits Fehler, die ausgenutzt werden können und werden.
Latentes Risiko durch Entwicklungsserver und zusätzliche Software
"Nichts hält länger als eine provisorische Lösung". Diesen Satz kennt wohl jeder und die meisten wissen aus eigener Erfahrung, dass er fast immer stimmt. Alle Pflege, Wartung und Fürsorge bei Installation und Betrieb bindet Personal und Geld. Speziell an den Orten, wo jedoch schnell Lösungen produziert werden müssen, steht in aller Regel kein Personal zur Verfügung um auch eine Nachbetreuung von Testinstallationen und Test-Servern gewissenhaft zu übernehmen. Dies führte bereits recht häufig zu gehackten Netzen in Forschung und Lehre. Aber ganz generell sollte man den Testbetrieb nach möglichkeit in einem gesicherten Netzsegment betreiben und erst in das öffentliche Internet migrieren, wenn sichergestellt werden kann, dass Zugriffsbeschränkungen korrekt funktionieren und offensichtliche Sicherheitslöcher gestopft sind. Aber dass sogar Firewall-Software ein zusätzliches angreifbares Element darstellt, hat der CCC Ulm bereits eindrucksvoll dokumentiert (http://ulm.ccc.de/chaos-seminar/personal-firewalls/). Aber auch die Windows-Firewall kann als Ziel angegriffen werden (http://habaneronetworks.com/viewArticle.php?ID=144). Speziell bei letzterem ist aber auch nicht ganz unerheblich, dass der Benutzer als Administrator generell ein schlechtes Sicherheitskonzept ist.
Roaming und dynamische Dienste
Zu allem Überfluß kommt aber inzwischen immer öfter ein Problem hinzu, das es im klassischen Internet so nicht gab. Benutzer wechseln mit ihrem Laptop recht volldynamisch Internetanbieter und sind sowohl auf der "hausinternen" als auch der "externen" Firewallseite zu finden. Dennoch soll unabhängig vom Aufenthaltsort die Funktionalität und Verfügbarkeit von zentralen Diensten gewährleistet sein. Realisieren lässt sich das praktisch nur, in dem man Laptops ganz kategorisch in ein abgeschottetes Netz verbannt (DMZ) und von dort per sehr feingranularer Zugriffsregelung auf die Dienste zugreifen lässt. Die DMZ-Anbindung kann entweder optional (nur von aussen) oder kategorisch (auch im Haus, speziell bei WLAN z.B.) per VPN erfolgen.
Diese mobilen Knoten bringen jedoch nicht nur von den Aufenthaltsorten eine Herausforderung mit sich, sondern es muss auch ganz besonders darauf geachtet werden, was die Mitarbeiter darauf zu Hause installieren können. Speziell durch infizierte Laptops (mit Viren oder Würmern) werden sonst auch die stärksten Firmen-Firewalls ausgehebelt. Zum Beispiel war der SQLSlammer seinerzeit auch im Netz von Microsoft zu finden. Nicht weil die öffentlichen Server anfällig gewesen wären, sondern weil einzelne Laptops den Wurm mitgebracht haben und dann über ungewartete Testsysteme sich ausgebreitet haben. Eine kategorische DMZ für Laptops hat also auch ganz pragmatische Vorteile.
Implementierungen
Halten wir also fest:
  • Eine Firewall ist eine Unterstützung, kein Allheilmittel
  • Die Firewall macht das Netz nur so sicher, wie der am schlechtesten administrierte Rechner im Netzwerk.
  • Eine Firewall braucht ein bestehendes Sicherheitskonzept, um zu berücksichtigen wo die zu schützenden Schwachstellen liegen. Wer einen Testserver mit öffentlicher IP womöglich noch ausserhalb der Firmenfirewall betreibt, um alle Dienste nutzen zu können muss im Sicherheitskonzept erst aufgenommen werden, bevor der Rechner erfasst ist.
  • Dienste, die nicht gestartet sind (am besten erst gar nicht installiert) brauchen nicht geschützt zu werden.
  • Eine Firewall kann keine unsicheren Dienste sicher machen, sie kann höchstens die öffentliche Verfügbarkeit beschränken.
  • Anwender müssen essentiell im Sicherheitskonzept berücksichtigt werden.
  • Netze mit unterschiedlicher Verwendung sollten möglichst physikalisch getrennt sein (z.B. Buchhaltung, Personalbüro, Sachbearbeiter, IT).
Für Microsoft Windows kann man prima das IPsec-Utility nutzen. Für Linux am ehesten netfilter/iptables als Paketfilter. Darüberhinaus sollte man aber beherzigen nur die benötigten Dienste zu fahren und auch diese entsprechend abzusichern. Für WindowsXP gibt es hierzu das ntsvcfg Script (mit Klickibunti-Oberfläche hier zu haben). Wer den Aufwand nicht scheut, kann auch seine Windows-CD mit dem sogenannten Slipstreaming bereits auf den aktuellen ServicePack-Level aktualisieren. Im Slipstreaming kann man sogar zusätzliche Treiber, Hotfixes, zusätzliche Programme und gar Scripte unterbringen. Eines dieser Scripte kann dann z.B. ntsvcfg sein und direkt die neue Windows-Installation noch bevor diese ans Internet angeschlossen wird absichern. Wer primär auf seine Anonymität achtet, dem sei auch XPAntiSpy ans Herz gelegt.
Für die Linuxianer hilfreich sind: SELinux, Hardening (z.B. debian-harden), Vserver/FreeVPS, GRSecurity, Tiger und Lire. Speziell Tiger ist eine sehr gute Unterstützung um eine einmal festgelegte Installation zu überwachen. Sämtliches Öffnen und Schliessen von Ports wird prompt mit einer Email dokumentiert. Zusammen mit der Logauswertung von lire hat man dann schoneinmal im Blick, was das System macht. Jetzt muss man nur noch die Sicherheitsupdates konsequent einpflegen.
Fazit
Zusammenfassend kann man also feststellen: eigentlich brauchen nur sehr wenige Leute wirklich Firewalls. Für die meisten ist es eine hilfreiche Unterstützung der implementierten Sicherheitsrichtlinie. Man sollte aber nicht vergessen, dass auch ein Portfilter eine zusätzliche Software ist und somit unter Umständen neue Probleme mit sich bringen kann. Und selbst mit Firewall sollte das primäre Augenmerk auf sicher konfigurierten Diensten liegen. Speziell bei komplexen Netzwerktopologien sind Firewalls sinnvoll um die einzelnen Bereiche voneinander zu trennen (und voreinander zu schützen).
und für alle, die schon immer die pragmatischen Beispiele bevorzugt haben...

#!/bin/bash
/sbin/modprobe ip_tables
/sbin/modprobe ip_conntrack
/sbin/modprobe ip_conntrack_ftp
/sbin/modprobe iptable_nat
/sbin/modprobe ipt_MASQUERADE
/sbin/modprobe ipt_state

/sbin/iptables -F
/sbin/iptables -t nat -F

/sbin/iptables -A FORWARD -i ppp0 -m state --state INVALID,NEW -j REJECT --reject-with icmp-port-unreachable
/sbin/iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE
echo 1 >/proc/sys/net/ipv4/ip_forward