Firewall Rule #1: DENY ALL Marc Ruef | 27.04.2009 Seit vielen Jahren führe ich sogenannte Firewall Rule Reviews durch. Bei diesen wird das Regelwerk eines Firewall-Systems exportiert und auf etwaige Schwächen hin untersucht. Nach dem Export findet als erstes eine Normalisierung statt. Dabei werden die Attribute der Regelsätze auseinandergenommen und vereinheitlicht. Üblicherweise sind dort Quellsystem, Quellport, Zielsystem, Zielport, Protokoll und Aktion von Interesse (moderne Firewall-Systeme erlauben zusätzliche Attribute wie Gültigkeitsdauer, VPN-Einstellungen, Logging, Client-Authentisierung, etc.). Nachdem das Regelwerk in derartiger Weise dissektiert wurde, werden die einzelnen Attribute auf ihre Richtigkeit hin geprüft. Dabei wird das Ziel verfolgt, jede Abweichung von der optimalen Sicherheit - diese entspricht minimalen Zugriffsmöglichkeiten - als solche zu erkennen. Wird zum Beispiel bei einem Zugriff auf einen File-Server im internen Netzwerk als Quelladresse ANY - also jedermann - zugelassen, ist dies ein offensichtliches Problem: Entweder lassen sich die Quelladressen einschränken oder der Fileserver sollte anstatt im internen LAN in eine DMZ gestellt werden. (Die empfohlene Gegenmassnahme muss die Topologie des Netzwerks, das applizierte Routing, die bereitgestellten Daten auf dem Server sowie die vorgesehenen Benutzergruppen berücksichtigen.) Um eine solche Analyse durchführen zu können, muss uns der Kunde das Regelwerk der zu untersuchenden Firewall-Komponente zur Verfügung stellen. Am liebste natürlich in einem wohl geformten Format wie XML oder CSV. Manche Produkte erlauben ebenfalls den Export als HTML- oder PDF-Dokument. Ist dies nicht möglich, kann - gerade bei webbasierten Interfaces (z.B. Astaro und kleinere Appliances) - mit simplem Copy & Paste gearbeitet werden. Und versagt selbst dies, dann bleiben immernoch Screenshots, die sich zum Beispiel mit Tools wie Snagit32 sehr gut automatisieren lassen. Im Rahmen eines grösseren Projekts sollte ich mitunter das Regelwerk einer Checkpoint Firewall-1 untersuchen. Die ebenfalls begutachteten Cisco PIX Firewall und Alteon Switches wiesen kleinere Mängel auf, die spätestens durch die Checkpoint-Lösung hätten abgefangen werden müssen. Wie es das Projekt vorsah, habe ich dem Chief Security Officer (CSO) des Unternehmens mitgeteilt, dass wir für die Durchführung des Tests das Regelwerk benötigen würden. Er versicherte mir, dass er sich darum kümmern würde. Checkpoint Firewall-1 ist ein kommerzielles Produkt, das gerade in grösseren Netzwerken bevorzugt wird. Der israelische Hersteller ist deshalb darum bemüht, die Administrationsoberfläche weitestgehend ergonomisch und intuitiv zu gestalten. Sodann muss man sich mit einem proprietären Client auf das System verbinden, um das Regelwerk einsehen und anpassen zu können. Die Firewall-Administratoren des Kunden lieferten sodann auch Screenshots dieser Oberfläche. Dabei haben sie jedoch nur die Regeln als solche extrahiert. Checkpoint erlaubt eine individuelle Erstellung und Zuweisung von eigenen Gruppennamen. So können zum Beispiel die Systeme mit der IP-Adresse 192.168.0.11 und 192.168.0.12 in der Gruppe Grp_Webservers_Intern zusammengefasst werden. Anstelle der jeweiligen IP-Adressen (private Adressen nach RFC1918) wird also dann auch dieser Gruppenname im Regelwerk benutzt. Solcherlei kaskadierte Informationen können in den meisten Fällen keiner echten Firewall Rule Review unterzogen werden. Schliesslich fehlen die essentiellen Details, welche Systeme bzw. IP-Adressen nun effektiv Zugriff haben. Ob sich nun in der Gruppe Grp_Webservers_Intern ebenfalls eine öffentliche IP-Adresse findet oder nicht - dies wäre ein ernstzunehmendes Risiko - kann anhand des Gruppennamens alleine nicht gesehen werden. Die Grunddaten müssen also ungeschönt eingesehen werden können. Aus diesem Grund haben wir zusätzlich die Informationen zu den Objekt-Gruppen angefordert. Auf der Administrationsoberfläche können diese sehr einfach mit drei Klicks erreicht werden. Ein Export ist ebenfalls als HTML möglich. Noch einfacher ist es jedoch, wenn man uns einfach den Inhalt des Unterordners /conf schickt, der sämtliche Dateien des Regelwerks enthält. Mit einem Parser lassen sich die jeweiligen Informationen extrahieren. Mehrere Tage vergingen und wir haben nichts mehr von den Firewall-Administratoren gehört. Dies ist sehr ärgerlich, denn ich habe mir die Zeit für das Projekt reserviert und hätte mich direkt darauf schon wieder um ein neues Projekt - eine Source Code Analyse einer in Java geschriebenen Banking-Anwendung - kümmern sollen. Der Chief Security Officer des Kunden hakte bei seinen Leuten nach und wollte wissen, wo die restlichen Daten bleiben. Das Firewall-Team reagierte sichtlich genervt und verwies darauf, dass "sie mit operativen Problemen beschäftigt seien und sich keine Zeit für derlei 'sinnlose' Audit-Aktivitäten nehmen könnten. Wir sollen das Regelwerk gefälligst selber exportieren." Die zuständigen Stellen applizieren hier scheinbar eine DENY ALL Regel. Zwei Dinge fallen an dieser Situation auf: (1) Der Chief Security Officer scheint nicht genügend Kompetenzen haben, um die Leute im operativen Betrieb zu sicherheitstechnischer Zusammenarbeit bewegen zu können. Dies ist ein organisatorisches bzw. strukturelles, in manchen Firmen aber auch ein persönliches bzw. soziales Problem. (2) Ich als Auditor soll direkten Einfluss auf ein zu prüfendes Objekt ausüben, wodurch ich jenachdem die Integrität der zu prüfenden Daten untergrabe. Sowohl als Auditor als auch als Forensiker nehme ich bewusst möglichst keine Änderungen an Systemen vor. Ich habe meinem Kunden den Sachverhalt erklärt und mit Nachdruck darauf hingewiesen, dass ich ohne die Herausgabe des kompletten Regelwerks meine Aufgabe nicht wahrnehmen kann. Und dieses Regelwerk sei durch den Object Owner, also die Firewall-Administratoren, bereitzustellen. Es vergingen zwei weitere Tage, doch irgendwann erhielt ich auch die restlichen Screenshots. Schade, denn eigentlich ist so ein Kopieren von Dateien ja gar nicht so schwierig. Die Daten der Screenshots müssen übrigens zwecks Normalisierung abgeschrieben werden. Zum Glück kann man das mit OCR weitestgehend automatisieren.