scip AG

Labs: Firewall Rule Review - Ansatz und Möglichkeiten

at Thursday, 7. June 2012
by Marc Ruef | G+ und Rocco Gagliardi | G+

Durch Firewall-Systeme wird die Grundsicherheit in Netzwerken gewährleistet. Bei einer Firewall Rule Review wird das Regelwerk einer solchen Sicherheitskomponente auf etwaige Fehler und Schwächen hin untersucht. Dieser Beitrag fasst die Grundlagen einer solchen Analyse zusammen.

• Einführung
• Export
• Dissection
• Review
• Einstellungen
• Bewertung
• Gründe
• Zusammenfassung

Einführung

Das grundlegende Ziel einer Firewall Rule Analyse ist das Identifizieren von Schwachstellen und Unschönheiten in einem Firewall-Regelwerk. Dabei geht es darum

• Regeln,
• Objekte,
• und Relationen

zu identifizieren, die

• unsicher,
• falsch,
• ineffizient
• oder unnötig

sind. Zu diesem Zweck wird das Regelwerk einer Firewall mit all seinen Details und Abhängigkeiten betrachtet.

Export

Als erstes gilt es Zugriff auf das Regelwerk zu erhalten. Man unterscheidet hier zwischen onsite Analysen, bei denen online auf der Firewall bzw. der Management-Schnittstelle dieser gearbeitet wird. Und einer offline Analyse, bei der das Regelwerk extrahiert und unabhängig von der produktiven Umgebung untersucht wird.

Früher wurden Onsite-Analysen vorgezogen, da sich diese schnell und unkompiziert angehen lassen. Man kann sich direkt an die Firewall setzen und mit der Begutachtung beginnen. Aus Gründen der Professionalität versuchen wir jedoch darauf zu verzichten. Eine Offline-Analyse bietet wichtige Vorteile, wie Unabhängigkeit von der produktiven Umgebung. Zudem lassen sich, wie wir in einem späteren Schritt sehen werden, computergestützte Analysen vorantreiben.

Viele Firewall-Systeme bieten eine Export- oder Backup-Funktion, mit der das Regelwerk extrahiert werden kann. Entweder sind es spezifische Kommandoeingaben oder Funktionen auf der grafischen Oberfläche, die zu diesem Ziel führen können. Die folgende Tabelle fasst einige bekannte Firewall-Systeme und ihre Exportfunktionalität für Rulsets und Configs zusammen.

Grundsätzlich ist jedes Datenformat, welches die erforderlichen Grunddaten enthält, willkommen. Sollten keine Exportfunktionen vorgesehen sein, kann versucht werden mittels Copy&Paste (vor allem in Webfrontends) oder Screenshots zu arbeiten.

Dissection

Nachdem das Regelwerk mittels Export- oder Backup-Funktionen extrahiert wurde, gilt es dieses in ein Format zu konvertieren, mit dem die Analyse möglichst effizient vorangetrieben werden kann. Hierzu wird das Parsing der jeweiligen Dateien erforderlich.

Im Beitrag Firewall Rule Parsing am Beispiel von SonicWALL haben wir gezeigt, wie ein solches Parsing bei einer SonicWALL aussehen kann. Das Parsing ist sehr stark von der Struktur der vorliegenden Daten abhängig. So kann zwischen verschiedenen Datentypen der jeweiligen Produkte unterschieden werden, wie die folgende Tabelle zeigt.

Das Parsing hat in der Regel zum Ziel, die einzelnen Regeln und ihre Attribute identifizieren und dediziert auf sie zugreifen zu können. Normalerweise wird das Regelwerk, welches komplexe Relationen und Verschachtelungen aufweisen kann, in eine tabellare Form gebracht. Als minimale Informationen eines Firewall-Regelwerks gelten:

• Quelle (Host/Netz)
• Ziel (Host/Netz)
• Dienst (Protokoll/Port)
• Aktion [Allow, Deny/Drop]

Viele Produkte bieten aber noch ein mehr an Attributen an, die sich einer Firewall-Regel oder den einzelnen Objekten zuordnen lassen. Dazu können gehören:

• ID
• Aktiv
• Timeframe
• Benutzer
• Logging
• Priorität/QoS
• ...

Ein normalisiertes Firewall-Regelwerk wird nachfolgend abgebildet, wobei sich sowohl in Bezug auf bei der Anzahl der eingebrachten Regeln als auch der berücksichtigten Attribute auf ein Minimum abgestützt wird.

Hierbei handelt es sich um die beiden typischen Outbound- und Inbound-Rules für Webkommunikationen über Port tcp/80. Im ersten Fall wird der Zugriff aus dem Internet in die DMZ erlaubt und im zweiten Fall werden den Clients im Klasse C-Netzwerk der Zugriff ins Internet gewährt und im zweiten .

Review

Nachdem eine Umformung und Normalisierung des Regelwerks vorgenommen werden konnte, kann sich um die eigentliche Analyse bemüht werden. Hierbei wird nach Schwachstellen Ausschau gehalten, die da sein können:

Erweiterte Zugriffsrechte

• ANY Rules: Regelsatz enthält bei einem Attribut den Wert ANY, der als Wirdcard verstanden wird und den Zugriff für alle erlaubt.
• Bidirektionale Rules: Innerhalb eines Regelsatzes wird eine hohe Deckungsgleichheit bei Quelle und Ziel vorgefunden.
• Breitflächige Definition von Zonen/Ports: Aufgrund einer schlechten Eingränzung von Attributen (Gruppen oder Bereichen) werden ein Mehr an Zugriffen erlaubt, weder nötig sind.
• Blacklisting: Es wird ein Blacklisting-Mechanismus eingesetzt, der naturgemäss zu False-Negatives beim Unterbinden von Zugriffen neigt.
• DROP ALL Rule fehlt: Manche Firewall-Produkte erwarten explizit eine DROP ALL Rule, wodurch sämtlicher verbleibender nicht erlaubter Verkehr unterbunden wird.

Unsichere Rules

• Unsichere Protokolle (z.B. telnet, ftp, snmp): Es werden als unsicher geltende Protokolle zugelassen. Dies ist nicht direkt ein Fehler innerhalb des Firewall-Setups. Viel mehr ist es ein Indikator, dass konzeptionell etwas verbessert werden kann.
• Mash-up von Objekten: Es werden Objekte unterschiedlicher Kategorisierung und Klassen in einer Objektgruppe oder in einem Attribut zusammengefasst.
• Überlappende Objekte: Es werden verschiedene Objekte genutzt, sich teilweise überlappen. Dies tritt in erster Linie bei Adressbereichen, Netzen und logischen Gruppen auf.
• Verkapselte Objekte: Es werden Objektgruppen in anderen Gruppen verkapselt, wodurch die Übersichtlichkeit und Nachvollziehbarkeit des Regelwerks massiv leidet.

Unnötige Rules

• Inaktive Objekte: Es werden Objekte verwaltet, die aber nirgends als Attribut in einem Regelsatz vorkommen.
• Temporäre Rules: Es werden Regeln betrieben, die als temporäre Regeln gedacht und eingerichtet wurden. Manchmal haben diese Regeln schlichtweg nicht die Transition in feste Regeln geschafft – Oder es handelt sich um vergessene Überbleibsel.
• Test Rules: Ähnlich wie temporäre Regeln können erweiterte und vergessene Test Rules ein Risiko darstellen.
• Unnötige Rules: Unnötige Regeln, die keinen Nutzen erfüllen, stellen sowohl organisatorisch als auch technisch eine Gefahr dar. Dies kann zum Beispiel der Fall sein, wenn für längst deaktivierte oder verschobene Systeme noch immer die alten Regeln bestehen.

Dokumentation fehlt

• Kein Comment/Description: Aufgrund fehlender Kommentare oder Beschreibungen ist die Funktionsweise einer Regel oder deren technischen, organisatorischen bzw. politischen Hintergründe nicht nachvollziehbar. Neben betrieblicher Reibung wird damit ebenfalls die gesamte Analyse als solche erschwert.
• Whitelisting ohne Begründung: Es werden Whitelisting-Mechanismen angewendet, die nicht dokumentiert und damit auch nicht begründet sind. Deren Legitimität lässt sich nicht mehr nachvollziehen.
• Logging nicht aktiviert: Es werden Regeln verwendet, die kein Logging aktivieren. Ein solches ist aber sowohl für eine Fehlersuche als auch für eine forensische Untersuchung erforderlich.

Lockdown fehlt

• Lockdown Rules nicht vorhanden: Das Firewall-System selbst schützt sich nicht durch Angriffe, wodurch die Integrität dessen mittels direkten Attacken beeinträchtigt werden könnte.
• Stealth Rules nicht vorhanden: Das Firewall-System setzt keine Mechanismen ein, um seine Existenz zu verschleiern. Zum Beispiel, indem auf das Dekrementieren des TTL-Werts im IP-Header verzichtet wird.
• DENY anstatt DROP: Die für das Unterbinden von Kommunikationen angesetzten Regeln benutzen DENY und informieren deshalb über die Restriktion. Stattdessen kann ein stillschweigendes Verwerfen mittels DROP zum Einsatz kommen.

Sodann wird es möglich, dass im bestehenden Regelwerk die jeweiligen Schwächen markiert und dokumentiert werden. Ein Beispiel der Identifikation solcher Schwachstellen zeigt die nachfolgende Tabelle. Hierbei werden die in Ungnade gefallenen Attribute farblich markiert, um das Risiko (Low, Medium, High) anzeigen zu können. Hinter dem Attribut wird in eckigen Klammern das Stichwort der Schwachstelle festgehalten. Eine weiterführende Dokumentation mit zusätzlichen Details zu Risiken und Massnahmen kann daraus abgeleitet werden.

Im Rahmen verschiedener Projekte pflegen wir ein eigens entwickeltes Framework zur computergestützten Umsetzung von Firewall Rule Reviews einzusetzen. Nachfolgendes Video zeigt den Import und die Analyse eines umfassenden Checkpoint-Regelwerks. Die Regeln und ihre Attribute werden anhand der bisher beschriebenen Betrachtungen auf etwaige Schwächen hin untersucht.

Zusätzliche Einstellungen

Viele Firewall-Systeme bieten abseits des zentralen Regelwerks globale oder zusätzliche Funktionen an. Vor allem Application Gateways nutzen systemweite Einstellungen für die jeweiligen Proxies. Diese sind bei einer umfangreichen Firewall-Analyse ebenso zu berücksichtigen. Nachfolgende Tabelle zeigt einen kleinen Ausschnitt der globalen Einstellungen einer McAfee Web Gateway Installation.

Hierbei wird ähnlich verfahren, wie bei der zugrundeliegenden Firewall Rule Analyse. So werden die einzelnen Einstellungen identifiziert und ihre gegenwärtigen Werte ausgemacht. Diese werden mit den sicherheitstechnischen Empfehlungen verglichen und bei Abweichungen ein Risiko ausgewiesen.

Es gibt zwei grundsätzliche Schwierigkeiten, die bei einer solchen Betrachtung aufstossen koennen. Einerseits wird bei einer detaillierten Betrachtung oftmals in Bereiche vorgestossen, die nicht oder nur ungenügend Dokumentiert sind. So kann es durchaus sein, dass Einstellungen vorgefunden werden, deren genaue Funktionsweise nicht bekannt ist. Wenn selbst das Handbuch des Produkts nicht weiterhelfen kann, kann versucht werden sich mit dem Hersteller in Verbindung zu setzen und um interne Details zu beten. Solche Anfragen werden aber relativ selten berücksichtigt. Dann können nur eine vage Ableitung oder konkrete Experimente helfen, die Funktionsweise der einzelnen Settings determinieren zu können. Eine absolute Deckungsgleichheit innert nützlicher Frist zu erreichen, ist oftmals unmöglich.

Andererseits können gerade im Rahmen von dateibasierten Analysen Konfigurationsmöglichkeiten aufgedeckt werden, die innerhalb der normalen Nutzung des Produkts nicht gesehen oder verändert werden können. Gerade wenn das Produkt normalerweise über eine grafische Oberfläche betreut wird, kann es zu Problemen und Missverständnissen bei der genauen Betrachtung kommen. Es wird sodann schwierig herauszufinden, welche Option in welcher Form auf der grafischen Oberfläche ausgewiesen wird und ob sie sich überhaupt innerhalb des üblichen Prozesses anpassen lässt. Dieser Nachteil kann aber auch zum Vorteil werden, wenn denn plötzlich versteckte Funktionen entdeckt werden, aus denen sich in unmittelbarer Weise ein Vorteil erschliessen lässt.

Bewertung bestehender Regelsätze

Nachdem das Regelwerk optimiert wurde, indem unsichere Einstellungen entfernt, ersetzt oder verbessert wurden, kann das bestehende Regelwerk bewertet werden. Hierbei geht es darum zwei Dinge zu bestimmen:

• Welches Restrisiko verbleibt nach den Optimierungen?
• Und welche Kommunikationsbeziehungen bergen das grösste Risiko?

Wir und andere Institute (z.B. ETH Zürich) forschen seit über 10 Jahren in diesem Bereich. Bis heute gibt es keine etablierten Mechanismen, um eine umfangreiche Bewertung von Kommunikationsbeziehungen durchzuführen.

Das nachfolgend gezeigte Beispiel orientiert sich am Common Vulnerability Scoring System (CVSS). Hierbei handelt es sich um ein System, welches zur Bewertung von Verwundbarkeiten verwendet wird. Einer Verwundbarkeit werden verschiedene Eigenschaften zugewiesen, die sich wiederum auf die als Score ausgedrückte Bewertung auswirkt. Doch anstelle von Verwundbarkeiten wird CVSS zur Bewertung der in der Firewall-Umgebung abgebildeten Kommunikationsbeziehungen verwendet.

Als erste Attribute für das Base Score werden Access Vector (AV), Access Complexity (AC) und Authentication (Au) verwendet. Damit wird definiert, welche Voraussetzungen gegeben sein müssen, um eine Schwachstelle ausnutzen zu können. Die nächsten Attribute sind Confidentiality Impact (CI), Integrity Impact (II) und Availability Impact (AI). Diese geben an, welche Auswirkungen ein erfolger Angriff nach sich führen wird.

Diese sechs Attribute erlauben laut CVSSv2 jeweils drei unterschiedliche Abstufungen. Diesen Abstufungen werden Werte zugewiesen, die sich zum Schluss in der Berechnung verwenden lassen. Auf der Webseite von NIST findet sich eine umfangreiche Dokumentation zu diesem System.

Ohne auf die Beweggründe der Attributisierung der jeweiligen Kommunikationsmechanismen eingehen zu wollen, lässt sich anhand dieser Liste die kritischen Beziehungen ausmachen. In einem weiteren Schritt sieht man sich dank dieser Daten in der Lage, flankierende Massnahmen zur Mitigierung der Risiken anzustreben. Dabei handelt es sich aber in der Regel nicht mehr um Massnahmen, die sich in der Firewall-Umgebung anwenden lassen. Viel mehr müssen oftmals weitreichende technologische, architektonische/topologische, konzeptionelle oder organisatorische Massnahmen angestrebt werden.

Gründe für Fehler

Eine statistische Auswertung der letzten Projekte hat verschiedene Dinge aufzeigen können. Einerseits kann gesagt werden, dass gewisse Probleme einen Grossteil der Installationen betreffen. So finden sich immermal wieder ANY-Rules, temporäre Rules oder ein deaktiviertes Logging.

Andererseits gibts aber auch Probleme, die an einzelne Kunden gebunden scheinen und bei diesen besonders häufig auftreten. So haben wir schon Regelwerke gesehen, bei denen konsequenz auf ein Logging verzichtet wird, sämtliche Dienste mit ANY-Rules betrieben werden oder gänzlich auf ein Logging verzichtet wird. Hierbei scheint es sich entweder um alteingesessene oder eingelebte Fehler zu handeln. Diese sind zwar oftmals mit unmittelbaren Massnahmen zu lösen, jedoch müssen diese Massnahmen mit viel Aufwand und Geduld in die bestehende Arbeitsphilosophie eingeflochten werden.

Im Rahmen einer statistischen Auswertung haben wir ebenfalls versucht herauszufinden, welches die Gründe für unsichere Firewall-Regelwerke sind. Diese lassen sich grob in die folgenden sechs Kategorien einteilen:

• Fehler (falscher Klick, falsches Copy&Paste, ...)
• Vergessen/Faulheit (“Ich werde das später noch optimieren…”)
• Fehlinformationen (der Hersteller empfiehlt Ports 10000-50000)
• Missverständnis (technisch, konzeptionell)
• Unbekannte Funktionalität (versteckte Einstellungen)
• Technische Fehler (z.B. fehlerhafter Backup-Import)

Diese Fehler lassen sich in der Regel mit dem Durchsetzen eines Vier-Augen-Prinzips verhindern. Ob dieses nun durch eine interne Peer-Review oder durch ein externes Beratungsunternehmen (z.B. im Rahmen eines Audits) geschaffen wird, ist zweitrangig. Hauptsache ist, dass subtil eingeschlichene Fehler möglichst früh erkannt und eliminiert werden können. Dadurch lässt sich das Zeitfenster für erfolgreiche Angriffe minimieren.

Zusammenfassung

Auch wenn vereinzelte Stimmen laut werden, dass Firewall-Systeme ausgedient haben, spielt Firewalling seit vielen Jahren eine zentrale Rolle im Bereich der modernen Informationssicherheit. Sie regulieren massgeblich den Datenfluss in einem Netzwerk, sind damit Dreh und Angelpunkt der angewandten Netzwerksicherheit.

Netzwerke und Netzwerkapplikationen weisen heutzutage eine gewisse Komplexität auf, der auch innerhalb des Firewallings Rechnung getragen werden muss. Da mit Komplexität stets das Risiko von Fehlern mitgeführt wird, ist es besonders wichtig, dass Firewalling mit äusserster Sorgfalt betrieben wird. Um Schwächen in einer Firewall-Installation frühstmöglich entdecken zu können, kann eine Firewall Rule Review angestrebt werden.

Als erstes wird das Firewall-Regelwerk extrahiert. Daraus werden die einzelnen Regeln, ihre Attribute und Relationen herausgelöst und normalisiert. Dadurch wird es möglich, sowohl einzelne Objekte als auch ganze Regeln auf ihre Korrektheit hin zu prüfen. Dabei sollten ebenfalls globale Einstellungen, die besonders bei Proxy-Systemen mitgeführt werden, berücksichtigt werden.

Unsichere und unschöne Regeln können optimiert werden. Das verbleibende Regelwerk lässt sich sodann bewerten, um risikoreiche Kommunikationskanäle ausfindig machen zu können. Diese können dann ausserhalb des Firewallings mit flankierenden Massnahmen – oftmals ist ein Mehr an Aufwand erforderlich – geschützt werden.

(3062 words)

Links:

• http://beauwoods.blogspot.com/2012/05/firewalls-and-anti-virus-arent-dead.html
• http://isc.sans.edu/diary.html?storyid=13240
• http://nvd.nist.gov/cvsseq2.htm
• http://www.first.org/cvss/cvss-guide.html
• http://www.infosecisland.com/blogview/20734-Why-We-Still-Need-Firewalls-and-AV.html
• http://www.infoworld.com/d/security/the-firestorm-over-firewalls-193409
• http://www.infoworld.com/d/security/why-you-dont-need-firewall-193153
• http://www.networkworld.com/news/2005/070405perimeter.html
• http://youtu.be/P62Z4vqX5nA

Tags: Apple, Astaro, Backup, Buch, Checkpoint, Cisco, Citrix, Dienstleistung, EBK, Firewall, ICMP, Javascript, Mail, Microsoft, Proxy, Risiko, Webseite, Windows, XML, YouTube, iOS, iptables

Labs Overview

• Latest Postings
  • Computer Forensik – Ein Überblick
  • Vortrag zu Security Testing an SGRP Veranstaltung
  • Staatstrojaner – Kritik am neuen Bundesgesetz
  • Overview of Microsoft’s security toolkit EMET
  • Blog Digest April 2013
  • Wie statisch sollten Sicherheitsrichtlinien sein?
  • Timing für effiziente unentdeckte Portscans
  • Interpreting a Logfile with Grok
  • Spamhaus DDoS mit DNS Amplification
  • Blog Digest März 2013
• Archive
  • 2013 | 2012 | 2011 | 2010 | 2009 |

• Blog Digest

• Blogroll
  • abuse.ch
  • c22.cc
  • computec.ch
  • darkreading.com
  • infosecisland.com
  • krebsonsecurity
  • metasploit.com
  • schneier.com
  • securiteam.com
  • stfn.ch
  • zeltser.com
  • 5e4n.ch
• Syndication
  • RSS
  • Twitter