Firewall Rule Review - Ansatz und Möglichkeiten

Firewall Rule Review

Ansatz und Möglichkeiten

Marc Ruef
Marc Ruef
Rocco Gagliardi
Rocco Gagliardi
Lesezeit: 20 Minuten

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

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

zu identifizieren, die

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.

Produkt Ansatz Vorgehen
iptables View/Export /usr/sbin/iptables-save
Astaro Export (full) /usr/local/bin/backup.plx
Export (iptables) /usr/sbin/iptables-save
Backup Webadmin / Management / Backup/Restore
Checkpoint FW1 Backup copy files in %FWDIR%/conf/ (objects_5.C, rulebase.fws, *.W)
Export Tools: cpdb2html/cpdb2web
Cisco IOS/PIX/ASA View/Export show mem, show conf
Citrix Netscaler Backup copy file /nsconfig/ns.conf (via SCP)
Juniper Backup (Webadmin) Admin / Update / Config / Copy&Paste
Backup (FTP) request system configuration rescue save (via FTP)
McAfee Web Gateway Backup Configuration / File Management / Configuration Data / Download Configuration Backup
Microsoft Windows 7 Firewall Export (GUI) Actions / Export List
Export (Shell) netsh advfirewall export [filename]
Sidewinder G2 Export (ACL) cf acl export
Export (IP Filter) cf ipfilter export
Export (Proxy Settings) cf proxy export
Export (Application Filter) cf appfilter export
StoneSoft StoneGate Firewall Export Configuration / File / Export / Export Elements

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.

Produkt Apache Array CLI INI CSV XML
Apache Reverse Proxy x
USP Secure Entry Server x
Astaro (backup.plx) x
Checkpoint Firewall-1 x
Fortigate x
iptables x
Cisco IOS/PIX/ASA x
Citrix Netscaler x
McAfee Web Gateway x
SonicWALL x
Microsoft Windows 7 Firewall x
StoneSoft StoneGate Firewall x
Airlock x
Clearswift MIMEsweeper x
StoneSoft StoneGate Firewall x
Totemo Trustmail x

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:

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:

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.

Src Host Src Port Dst Host Dst Port Protocol Action
    >1023 192.168.0.10/32 80 (http) TCP ALLOW
    10.0.0.0/8 >1023
      80 (http) TCP ALLOW

      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

      Unsichere Rules

      Unnötige Rules

      Dokumentation fehlt

      Lockdown fehlt

      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.

      Src Host Src Port Dst Host Dst Port Protocol Action
        >1023 192.168.0.10/32 80 TCP ALLOW

          [ANY Rule]
          192.168.0.10/32 23
          [Insecure]
          TCP ALLOW
          10.0.0.0/8 >1023
            80 TCP ALLOW
            192.168.0.10/24 1024-50000
            [Inadequate]
            10.0.0.0/8 22,902,8443
            [Mashup]
            TCP ALLOW

            [ANY Rule]

            [ANY Rule]
            192.168.0.10/24 3389 TCP ALLOW
            10.0.0.0/8 0
            [ANY Rule]
            0,8 ICMP
            [Insecure]
            ALLOW

            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.

            ID Einstellung Wert Empfehlung Risiko
            1427 CheckFileSignatures 0 1 (=enabled) Medium
            1428 ChecksumMismatchWeb ‘Replace and Quarantine’ ‘Replace and Quarantine’ Passed
            1429 EmbdJavaAppletWeb ‘Allow’ ‘Block’ Medium
            1430 ExpiredContentWeb ‘Block’ ‘Block’ Passed
            1431 JavaScriptWeb ‘Allow’ ‘Block’ Low
            1432 MacroWeb ‘Replace and Quarantine’ ‘Block Document’ (strict) Passed
            1433 UnsignedEXEWeb ‘Allow’ ‘Block’ High

            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:

            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.

            Beschreibung Src Dst Srv AV AC Au CI II AI Score
            Extern Web zu öffent. Webserver Inet DMZ t80 N L N N C C 9.4
            Extern Web für interne Clients (in) LAN Inet t80 N M N C C C 9.3
            Extern Web zu Kundenseite Inet DMZ t443 N L S C C C 9.0
            Extern Mail zu öffent. Webserver Inet DMZ t110 N M S C C C 8.5
            Extern Fernzugriff zu Server Inet DMZ t22 N M S C C C 8.5
            Intern zu Nameserver LAN DMZ u53 L L N C C C 7.2
            Intern Intranet für Clients LAN DMZ t80 L L N P C C 6.8
            Extern Web für interne Clients (out) LAN Inet t80 L L S C C C 6.8
            Intern Fernzugriff für Clients LAN DMZ t3389 L M S P C P 5.5
            Intern ICMP Echo für Server DMZ Inet i0,8 L M S P P C 5.5

            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.

            Firewall Rule Review Findings

            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:

            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.

            Über die Autoren

            Marc Ruef

            Marc Ruef ist seit Ende der 1990er Jahre im Cybersecurity-Bereich aktiv. Er hat vor allem im deutschsprachigen Raum aufgrund der Vielzahl durch ihn veröffentlichten Fachpublikationen und Bücher – dazu gehört besonders Die Kunst des Penetration Testing – Bekanntheit erlangt. Er ist Dozent an verschiedenen Fakultäten, darunter ETH, HWZ, HSLU und IKF. (ORCID 0000-0002-1328-6357)

            Rocco Gagliardi

            Rocco Gagliardi ist seit den 1980er Jahren im Bereich der Informationstechnologie tätig. In den 1990er Jahren hat er sich ganz der Informationssicherheit verschrieben. Die Schwerpunkte seiner Arbeit liegen im Bereich Security Frameworks, Routing, Firewalling und Log Management.

            Links

            Sie wollen eine KI evaluieren oder entwickeln?

            Unsere Spezialisten kontaktieren Sie gern!

            ×
            Konkrete Kritik an CVSSv4

            Konkrete Kritik an CVSSv4

            Marc Ruef

            Übergang zu OpenSearch

            Übergang zu OpenSearch

            Rocco Gagliardi

            scip Cybersecurity Forecast

            scip Cybersecurity Forecast

            Marc Ruef

            Voice Authentisierung

            Voice Authentisierung

            Marc Ruef

            Sie wollen mehr?

            Weitere Artikel im Archiv

            Sie brauchen Unterstützung bei einem solchen Projekt?

            Unsere Spezialisten kontaktieren Sie gern!

            Sie wollen mehr?

            Weitere Artikel im Archiv