Konkrete Kritik an CVSS4
Marc Ruef
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.
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.
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:
$ruleid
wird die zuvor erklärte ID angegeben.$type
wird der Typ der Konfigurationseinstellung angegeben. Dieser kann beispielsweise policy
(Firewall-Regel), zoneObj
(Zonen-Objekt), addrObj
(Adress-Objekt) oder svcObj
(Service-Objekt) lauten).$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:
2
= ALLOW)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:
ID | Action | SrcZone | DstZone | SrcNet | DstNet | DstSvc |
---|---|---|---|---|---|---|
1 | 2 | LAN | LAN | All LAN Management IP | HTTPS Management | |
2 | 2 | LAN | LAN | All LAN Management IP | HTTP Management | |
3 | 2 | WAN | DMZ | Webserver | HTTP | |
4 | 2 | LAN | WAN | Workstations | HTTP | |
5 | 2 | LAN | DMZ | Administrators | Webserver | SSH |
… |
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.
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:
ID | Id | IdDisp | Type | Zone | Properties | Ip1 | Ip2 |
---|---|---|---|---|---|---|---|
1 | ALL LAN Management IP | All X0 Management IP | 8 | 793 | 0.0.0.0 | 0.0.0.0 | |
2 | Webserver | Webserver | 1 | DMZ | 14 | 192.168.0.10 | 255.255.255.255 |
3 | Workstations | Workstations | 8 | 14 | 0.0.0.0 | 0.0.0.0 | |
4 | Administrators | Administrators | 8 | 14 | 0.0.0.0 | 0.0.0.0 | |
… |
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:
ID | atomToGrp | grpToGrp |
---|---|---|
… | ||
5 | ZRHXP001 | Workstations |
6 | ZRHXP002 | Workstations |
7 | ZRHXP003 | Workstations |
8 | ZRHXP004 | Workstations |
… |
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:
ID | Id | IdDisp | Type | Zone | Properties | Ip1 | Ip2 |
---|---|---|---|---|---|---|---|
… | |||||||
5 | ZRHXP001 | ZRHXP001 | 1 | LAN | 14 | 172.16.0.1 | 255.255.255.255 |
6 | ZRHXP002 | ZRHXP002 | 1 | LAN | 14 | 172.16.0.2 | 255.255.255.255 |
7 | ZRHXP003 | ZRHXP003 | 1 | LAN | 14 | 172.16.0.3 | 255.255.255.255 |
8 | ZRHXP004 | ZRHXP004 | 1 | LAN | 14 | 172.16.0.4 | 255.255.255.255 |
… |
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:
ID | Action | SrcZone | DstZone | SrcNet | DstNet | DstSvc | Comment |
---|---|---|---|---|---|---|---|
… | |||||||
4 | ALLOW | LAN | WAN | 172.16.0.1-4 | ANY | TCP/80 | Workstations to WWW |
… |
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.
Unsere Spezialisten kontaktieren Sie gern!
Marc Ruef
Marc Ruef
Marc Ruef
Marc Ruef
Unsere Spezialisten kontaktieren Sie gern!