Im Rahmen von Sicherheitsüberprüfungen führen wir immerwieder sogenannte Firewall Rule Reviews durch. Bei diesen wird das Regelwerk einer Firewall einer formalen, strukturellen und logischen Analyse unterzogen. Dadurch sollen ineffiziente, fehlerhafte und fehlende Regelsätze identifiziert werden. Diese Aufgabe führen wir computergestützt durch, wodurch wir ein Mehr an Effizienz und Zuverlässigkeit erreichen können.

Dabei wird das jeweilige Firewall-Regelwerk exportiert und für einen Import in unser Analysesystem vorbereitet. Hierzu wird es erforderlich, dass ein Parsing des Regelwerks vorgenommen werden kann. Durch diese Normalisierung wird die Weiterverarbeitung vereinfacht, da die Eigenschaften der unterschiedlichen Produkte nicht mehr (im Detail) berücksichtigt werden müssen.

Einführung

Nachfolgend soll exemplarisch an SonicWALL aufgezeigt werden, wie ein solches Firewall Rule Parsing aussehen kann. Als erstes wir auf dem jeweiligen SonicWALL-Gerät ein Export der Konfiguration vorgenommen (System/Settings/Export Settings). Dadurch wird eine Datei mit der Erweiterung .exp angelegt. Hierbei handelt es sich um einen mit Base64 codierten String, der relativ einfach wieder decodiert werden kann:

$file_content_raw = file_get_contents('sonicwall_ruleset.exp');
$fw_ruleset_text = base64_decode($file_content_raw);

Dadurch wird der Klartext-Zugriff auf das Firewall-Regelwerk und zusätzliche Konfigurationseinstellungen möglich. SonicWALL benutzt ein Format, bei dem die unterschiedlichen Einstellungen durch das Zeichen & voneinander getrennt werden. Jede Einstellung besitzt einen Namen und einen Wert, der durch das Gleichheitszeichen = zugewiesen wird (Auszug, manuell umgebrochen):

checksumVersion=1&zoneObjId_0=LAN&zoneObjProperties_0=1821&
zoneObjCflProfile_0=0&zoneObjZoneType_0=1&zoneObjIntraZoneCom_0=1&
zoneObjAvProfile_0=0&zoneObjASProfile_0=0&zoneObjGavProfile_0=0&
zoneObjGscProfile_0=0&zoneObjGroupVpn_0=1&zoneObjMyIDPProfile_0=0&
zoneObjEnforceWiFi_0=0&zoneObjEnforceSslvpn_0=0&zoneObjSslvpnIp_0=&
zoneObjSslvpnPort_0=&zoneObjWiFiException_0=0&
zoneObjWiFiExceptionHandle_0=&zoneObjRestrictVpnTrav_0=0&
zoneObjAllowWPA_0=0&zoneObjSonicPointProfHandle_0=&
zoneObjSonicPointOnly_0 (...)

Zusammengehörige Einstellungen werden durch eine eindeutige Identifikationsnummer ausgewiesen. Abgesehen von der ersten Einstellung gehören alle nachfolgenden Einstellungen zu einem Zonen-Objekt mit der ID 0. Diese wird durch _0 am Ende des Einstellungsnamens ausgewiesen. Diese ID ist besonders wichtig, um Zusammenhänge erkennen zu können.

Extrahierung einzelner Einstellungen

Mit der nachfolgenden Funktion werden nun die einzelnen Einstellungen extrahiert. Hierzu kommt ein dynamischer regulärer Ausdruck zum Zug, der drei dynamische Elemente enthält:

• Durch $ruleid wird die zuvor erklärte ID angegeben.
• Mit $type wird der Typ der Konfigurationseinstellung angegeben. Dieser kann beispielsweise policy (Firewall-Regel), zoneObj (Zonen-Objekt), addrObj (Adress-Objekt) oder svcObj (Service-Objekt) lauten).
• Danach folgt mit $object der Name des Objekts selber. Dies sind zum Beispiel Action, SrcZone, DstZone, SrcNet, DstNet oder DstSvc.

function extract_object($ruleset, $ruleid, $type, $object){
   preg_match('/'.$type.$object.'_'.$ruleid.'\=(.*?)&/s', $ruleset, $matches);
   return $matches[1];
}

Mit dem Funktionsaufruf extract_object($fw_ruleset_text, 23, 'addrObj', 'Ip1') wird also der Eintrag addrObjIp1_23 angezeigt. Hier handelt es sich um die IP-Adresse der Adress-Objekts mit der ID 23. Mit einer Iteration durch das Regelwerk kann nun eine Umformulierung dessen stattfinden. Dabei sind ist vor allem der Typ policy von Interesse, denn dieser definiert die eigentlichen Firewall-Regeln (Rule-Policies, bei Cisco PIX/ASA werden sie access-list genannt). Typischerweise sind die folgenden Objekte hierbei von Interesse:

• ID – Interne Identifikation
• Action – Verfahren mit der Kommunikation (z.B. 2 = ALLOW)
• SrcZone – Quellzone
• DstZone – Zielzone
• SrcNet – Quellsystem
• DstNet – Zielsystem
• DstSvc – Dienst
• Comment – Optionale Kommentare

Eine naheliegende Umformung des Regelwerks ist die tabellare Darstellung, zum Beispiel in einer CSV-Datei. Die Regeln werden auf einzelne Zeilen geschrieben, wobei die gleichwertigen Definitionen in der gleichen Spalte geführt werden. Ein sehr simples SonicWALL-Regelwerk sieht umgeformt so aus:

Die ersten beiden Regeln werden standardmässig durch die SonicWALL angelegt, um die interne Administration des Geräts über das Webfrontend gewährleisten zu können. Die Regel 3 wurde manuell erstellt und lässt externe Zugriffe über HTTP auf den Webserver in der DMZ zu. Regel 4 wird genutzt, damit die internen Clients per HTTP auf das World Wide Web zugreifen können. Und Regel 5 wird verwendet, damit interne Administratoren per SSH den Webserver in der DMZ verwalten können. Leer gelassene Felder werden als ANY-Definitionen verstanden.

Auflösung von Objekt-Gruppen

Anhand dieses Beispiels sieht man ein klassisches Problem beim Parsing von Firewall-Regelwerken: Bei modernen Systeme werden (verschachtelte) Objekte verwendet. Zum Beispiel ist anhand des Namens Webserver nicht ersichtlich, welche IP-Adresse eben dieses Objekt zugewiesen bekommen hat. Gleiches gilt für die restlichen Systeme, Netzwerke und Dienste (z.B. ein Dienst mit dem Namen SSH muss nicht zwingend über tcp/22 betrieben werden).

Das Regelwerk von SonicWALL ist relativ komfortabel, denn die Objekte sind ebenfalls darin enthalten (im Gegensatz zu CheckPoint, die ihrerseits eine separate Objects-Datei verwenden). Für Zonen-Objekte muss der Typ zoneObj, für Adress-Objekte addrObj und für Dienst-Objekte svcObj ausgelesen werden. Eine Auflösung der bisher gesehenen Adress-Objekte sieht sodann wie folgt aus:

In diesem Fall ist nur ein System effektiv spezifiziert (alle anderen Objekte stellen Netze dar). Hierbei handelt es sich um die ID 2, bei dem der Webserver mit einer eindeutigen IP-Adresse und einer eindeutigen Zonen-Zuordnung definiert wird. Alle anderen Adress-Objekte sind undefiniert; sowohl in Bezug auf die Zone als auch auf die IP-Adressierung. Der Grund dafür ist, dass es sich hier um Objekt-Gruppen handelt. Die zu einer Gruppe gehörigen Objekte werden weiterführend in addro_ (Adress-Objekte) und so_ (Service-Objekte) dokumentiert:

Mit der der durch diese Zwischentabelle zusammengetragenen IDs kann nun die effektive Konfiguration des jeweiligen Objekts ausgemacht werden. Hierzu wird erneut auf addrObj zugegriffen, in diesem Fall aber nur auf die Elemente des Adress-Objekts mit den IDs 5-8:

Mit dieser erfolgreichen Auflösung kann nun die Normalisierung des Regelwerks vorangetrieben werden. Die Regel 4 (Zugriff von Workstatsions auf das Web) kann nun wie folgt aufgelöst und ausformuliert werden:

Fazit

Das Parsing eines Firewall-Regelwerks ist wichtig, um eine formale Analyse dessen durchführen zu können. Hierzu muss eine Umwandlung der jeweiligen Elemente stattfinden, wobei die interne Logik des Produkts berücksichtigt werden muss.

Die Export-Dateien von SonicWALL sind dabei relativ einfach gehalten und beinhalten alle Informationen, die zur Konfiguration des Geräts erforderlich sind. Durch verschiedene Lookup-Prozesse wird es möglich, das Firewall-Regelwerk mit all seinen Abhängigkeiten und Verschachtelungen zu verstehen.

Nur an wenigen Punkten sind die einzelnen Einstellungen schwierig verständlich oder das Parsing mit Problemen behaftet. Letzteres ist zum Beispiel beim Suffix iface der Fall, der sporadisch bei langen Konfigurationseinstellungen mit if_ abgekürzt wird. Oder die Tatsache, dass Zeitangaben bei schedObjId normalerweise einen Buchstaben für Tage verwenden, Donnerstag (TH) und Sonntag (SU) hingegen zwei Buchstaben nutzen.

About the Author

Marc Ruef has been working in information security since the late 1990s. He is well-known for his many publications and books. The last one called The Art of Penetration Testing is discussing security testing in detail. He is a lecturer at several faculties, like ETH, HWZ, HSLU and IKF. (ORCID 0000-0002-1328-6357)

Links

• http://it-blog.timk.de/it-blog/page/how-to-show-sonicwall-configuration-in-plain-text.htm
• http://www.cisco.com/en/US/products/hw/vpndevc/ps2030/products_tech_note09186a0080094aad.shtml
• http://www.sonicwall.com