Testen der Firewall

All das Wissen um die Paketfilter-Firewall nützt mir recht wenig, wenn ich mich nicht überzeugen kann, dass meine Kenntnisse zutreffen und meine damit getroffenen Einstellungen ihren Zweck erfüllen. Diesem Zweck dienen die Tests des Paketfilters.

Generell kann ich mich mit verschiedenen Arten von Tests an Firewalls herantasten:

• Penetrationstests,
• Tests der Firewall-Implementierung, das heisst, der Software, und
• Tests der Paketfilter-Regeln.

Mit Penetrationstests suche ich nach Sicherheitsproblemen in produktiven Netzwerken, indem ich diese attackiere. Der Paketfilter ist dabei nur ein Testobjekt unter mehreren. Probleme, die ich hierbei aufdecke, haben nicht notwendigerweise mit ihm zu tun. Da die untersuchten Netzwerke produktiv verwendet werden, muss ich besonders verantwortungsbewusst vorgehen und mir vor allem die Zustimmung des Besitzers der betroffenen Netzwerke holen. Das ist ganz bestimmt keine Arbeit für jemand, der sich erst in die Materie einarbeiten will.

Bei Tests der Firewall-Implementierung geht es um Fehler im Betriebssystem und der Paketfilter-Software. Probleme, die ich hierbei aufdecke, betreffen alle Paketfilter des betreffenden Typs, das heißt in unserem Fall OpenWrt in der getesteten Version. Dann ist es sinnvoll, eine Fehlermeldung in den Bug-Tracker zu stellen, damit das Problem für alle gelöst werden kann. Manchmal will ich mich auch direkt an die Entwickler wenden, wenn das entdeckte Problem sensible Bereiche betrifft.

Tests der Firewallregeln sollen nachweisen, dass die Paketfilter-Regeln die Sicherheitsrichtlinie korrekt umsetzen. Probleme, die ich hierbei aufdecke, betreffen den konkreten Paketfilter an dieser Stelle im Netz und die dafür geltende Sicherheitsrichtlinie.

In diesem Kapitel konzentriere ich mich auf Tests der Implementierung und der Regeln. Diese Tests kann ich abseits des produktiven Netzes in einer sicheren Testumgebung ausführen und muss mir keine Gedanken darüber machen, dass die Tests die Umgebung nicht stören dürfen beziehungsweise, dass letztere die Tests beeinflussen kann.

Testumgebung

Testmaschinen

Die Testumgebung besteht im einfachsten Fall aus dem zu testenden Paketfilter und je einem Rechner an jedem Anschluß dieses Paketfilters. Das heißt, ich benötige mindestens drei Geräte.

Mit einem X86-Image von OpenWrt kann ich alle Geräte als virtuelle, miteinander verbundene Maschinen betreiben. Dann kann ich die gesamte Testumgebung auf meiner Arbeitsstation vorhalten und benötige keine zusätzliche Hardware.

Will ich die mit der virtuellen Maschine gewonnenen Erkenntnisse auf ein OpenWrt-System mit anderer Hardware übertragen, benötige ich für einige Tests vielleicht trotzdem diese Hardware. Ein WLAN-Netzwerk, zum Beispiel, lässt sich nicht einfach simulieren.

Software

Neben den Testmaschinen benötige ich geeignete Software um die Testdaten zu erzeugen und die Datenpakete mitzuschneiden.

Zum Erzeugen von Datenpaketen stehen mir etliche Programme und Bibliotheken zur Verfügung, zum Beispiel:

• Nmap (Network Mapper) ist ein freies Werkzeug, um Netzwerke zu erkunden. Damit kann ich sehr einfach der Firewall Datagramme mit unterschiedlichen gesetzten Optionen senden.
• Hping ist dem Ping-Befehl ähnlich, unterstützt aber auch TCP, UDP, ICMP und andere IP-Protokolle, so dass ich die Reaktion des Paketfilters auf diese Datagramme testen kann.
• Tcpreplay erlaubt es, aufgezeichneten Datenverkehr erneut in das Netzwerk einzuspeisen. Damit kann ich zum Beispeil Datenverkehr aus dem Produktivnetz in das Testnetz einspielen und sehen, wie der Paketfilter reagiert.
• Network Expect ist ein Framework, das vom Programm Expect von Don Libes beeinflusst wurde. Damit kann ich “interaktive” Netzwerkprogramme mit Skripts schreiben, ohne zum Compiler greifen zu müssen.
• Mit libnet kann ich relativ einfach Anwendungen in C schreiben, die Datenpakete erzeugen. Diese verwende ich, wenn ich mit den anderen Werkzeugen nicht mehr weiterkomme.

Auch für das Mitschneiden des Datenverkehrs und die spätere Analyse kann ich unter verschiedenen Werkzeugen auswählen:

• Tcpdump ist weit verbreitet und für mich oft das Mittel der Wahl, um Datenverkehr mitzuschneiden.
• Snort basiert, wie tcpdump, auf der Bibliothek libpcap und kann als leichtgewichtiges IDS verwendet werden. Beim Testen von Firewalls kann es als Indikator dienen, ob bestimmte Datenpakete vorkommen. Das ist von Vorteil, wenn die mich interessierenden Daten in einer großen Menge anderer Datenpakete versteckt sind.
• Mit Libpcap kann ich wiederum eigene Werkzeuge in C programmieren, wenn ich kein geeignetes Werkzeug für meine Fragestellung finde.
• Libtrace ist eine Bibliothek wie libpcap. Ein Vorteil gegenüber letzterer ist, dass libtrace sehr viele Datenformate von fremden Paketsniffern lesen kann.
• Wireshark ist ein GUI-Programm zum Mitschneiden von Datenverkehr und zum bequemen Auswerten der Mitschnitte.

Vorgehen

Testplan

Spätestens, wenn ich mein Testsystem und die benötigte Software habe, wird es Zeit, einen Testplan aufzustellen. Dafür gibt es mindestens zwei Methoden: Ich kann nach einer Checkliste testen, oder ich erstelle meinen Testplan entsprechend dem Entwurf der Paketfilterregeln (entwurfsorientiert).

Tests nach Checkliste haben den Vorteil, dass ich sie schnell erstellen kann und nichts vergesse, was auf der Checkliste steht. Sie sind geeignet, wenn ich die Software der Firewall testen will, zum Beispiel zwischen zwei Versionen einer Firewall, als Regressionstest nach einer Fehlermeldung oder wenn ich ein Firewall-Produkt auswählen und vor dem Einsatz testen will, ob es überhaupt geeignet ist. Auch bei Tests von vorgegebenen Firewall-Regeln eignen sich Checklisten.

Was Tests nach Checkliste oft nicht berücksichtigen, sind die Beziehungen zwischen den Firewall-Regeln und der Sicherheitsrichtlinie.

Beim entwurfsorientierten Entwurf des Testplans gehe ich von der Sicherheitsrichtlinie aus. Ich überlege, wie eine Firewall-Konfiguration die Sicherheitsrichtlinie umsetzen könnte und entwickle daraus die Testfälle, die mir diese Überlegungen bestätigen oder widerlegen. Damit gelange ich zu Tests die relevant sind für den konkreten Paketfilter am Einsatzort.

Ein großes Problem beim entwurfsorientierten Entwurf der Tests ist, dass er schwierig ist. Schwieriger als der Entwurf von Firewall-Regeln für einen konkreten Paketfilter aus der Sicherheitsrichtlinie. Mit dem Entwurf der Paketfilter-Regeln stelle ich eine Behauptung auf: dass diese Paketfilter-Regeln die Sicherheitsrichtlinie erfüllen. Mit den Tests für die Überprüfung der Firewall versuche ich, diese Behauptung zu widerlegen.

Da es mir - und ich glaube den meisten Menschen - schwer fällt, eine eigene Behauptung zu widerlegen, ist es sinnvoll, wenn die Tests nicht von der gleichen Person entworfen werden, wie die Paketfilter-Regeln. Geht das nicht, hilft es, wenn ich die Regeln und die Tests im Abstand von einigen Tagen oder Wochen entwickle.

Tests durchführen

Neben den konzeptionellen Problemen beim Erstellen eines Testplans gibt es noch das Problem, dass ich bei seiner Umsetzung Fehler machen kann.

Das bedeutet, ich will nicht nur mit den Tests nachweisen, ob eine Filterregel korrekt ist oder nicht. Zusätzlich muss ich auch sicher sein können, dass die Tests wirklich funktionieren.

Dazu führe ich die Tests mindestens zweimal durch: einmal mit deaktivierten Regeln, die der Test prüfen soll und einmal mit aktiven Paketfilter-Regeln. Dabei sollte ich normalerweise in einem Fall die zugehörigen Datenpakete sehen und im anderen Fall nicht.

So kann ich sicher sein, dass die betrachteten Datenpakete durch die Firewall-Regeln blockiert werden und nicht auf Grund von anderen Phänomenen im Netz.

Neben der rein funktionalen Überprüfung des Paketfilters, ob die Regeln den Anforderungen der Sicherheitsrichtlinie für den konkreten Einsatzzweck genügen, steht als weiterer Aspekt die Leistungsfähigkeit des Paketfilters.

Diese hängt überwiegend von der eingesetzten Hardware und dem Betriebssystem ab, kann aber durch die Konfiguration des Paketfilters und der Regeln beeinflusst werden.

So kann durch zu großzügige Freigaben für ganze Netze die ARP-Tabelle bzw. der Neighbor-Cache des Paketfilters bei einem Netzwerk-Scan überlaufen, was dann zu erhöhtem Aufwand für reguläre Verbindungen führen kann, weil jedesmal eine neue ARP-Anfrage oder Neighbor-Detection nötig ist.

Auch können sich bestimmte Regel-Konfigurationen nachteilig auf die Performance des Paketfilters auswirken. Hier kann ich mit tcpreplay die Auswirkungen verschiedener Konfigurationen auf die Performance testen und anschließend mit einem funktionalen Test verifizieren, dass die performantere Konfiguration noch der Sicherheitsrichtlinie genügt.

Weitere Hinweise

Einen allgemeinen Einblick in die Vorgehensweise beim Test von Firewall-Paketfiltern gibt die Diplomarbeit von Gerhard Zaugg an der ETH Zürich von 2004. An den dort und in der referenzierten Literatur dargelegten Konzepten hat sich nichts Wesentliches geändert.

Für IPv6 verweise ich auf das Forschungsprojekt IPv6 Intrusion Detection im Rahmen dessen die Test-Suite ft6 entstanden ist.

Weitere Werkzeuge für IPv6 sind

• das IPv6-Angriffstoolkit thc-ipv6,
• die Testsuite zum Detektieren von Einbruchsversuchen
• das IPv6 Toolkit von Fernando Gont