Firewall Regeln Beispiel Essay

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 (). Dadurch wird eine Datei mit der Erweiterung 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 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 wird die zuvor erklärte ID angegeben.
  • Mit wird der Typ der Konfigurationseinstellung angegeben. Dieser kann beispielsweise (Firewall-Regel), (Zonen-Objekt), (Adress-Objekt) oder (Service-Objekt) lauten).
  • Danach folgt mit der Name des Objekts selber. Dies sind zum Beispiel , , , , oder .
function extract_object($ruleset, $ruleid, $type, $object){ preg_match('/'.$type.$object.'_'.$ruleid.'\=(.*?)&/s', $ruleset, $matches); return $matches[1]; }

Mit dem Funktionsaufruf wird also der Eintrag 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 von Interesse, denn dieser definiert die eigentlichen Firewall-Regeln (Rule-Policies, bei Cisco PIX/ASA werden sie genannt). Typischerweise sind die folgenden Objekte hierbei von Interesse:

  • ID – Interne Identifikation
  • Action – Verfahren mit der Kommunikation (z.B. = 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:

ID Action SrcZone DstZone SrcNet DstNet DstSvc
1 2 LANLAN   All LAN Management IP HTTPS Management
2 2 LANLAN   All LAN Management IP HTTP Management
3 2 WANDMZ   Webserver HTTP
4 2 LANWAN Workstations   HTTP
5 2 LANDMZ 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.

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 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 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 , für Adress-Objekte und für Dienst-Objekte ausgelesen werden. Eine Auflösung der bisher gesehenen Adress-Objekte sieht sodann wie folgt aus:

ID Id IdDisp Type Zone Properties Ip1 Ip2
1 ALLLAN 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 (Adress-Objekte) und (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 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 ALLOWLANWAN 172.16.0.1-4 ANYTCP/80 Workstations to WWW

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 der Fall, der sporadisch bei langen Konfigurationseinstellungen mit abgekürzt wird. Oder die Tatsache, dass Zeitangaben bei normalerweise einen Buchstaben für Tage verwenden, Donnerstag () und Sonntag () hingegen zwei Buchstaben nutzen.

Links

Security Development Lifecycle

Marc Ruef

Personalisiertes Phishing

Marc Ruef

Malware Entwicklung

Marc Ruef

Anti-Fraud bei Online-Diensten

Marc Ruef

Sie wollen mehr?

Weitere Artikel im Archiv

Sie haben Fragen zum Thema?

Unsere Spezialisten kontaktieren Sie gern!

Eine Firewall dient dazu, den Datenverkehr zwischen unterschiedlichen Netzwerken zu regeln. Die Erstellung verschiedener Regeln in einer Firewall ermöglicht den Zugriff auf das Internet.

Transkript

Die Seite kann nicht angezeigt werden. Ja ganz offensichtlich haben wir hier im Browser gerade ein Verbindungsproblem, und ob wir das gelöst bekommen, das wollen wir uns in diesem Video anschauen. Ja, die Seite kann nicht angezeigt werden, warum denn nicht? Sie sollte eigentlich angezeigt werden können denn netzwerktechnisch ist soweit alles OK. Das heißt, wir haben hier verbundene Interfaces, wir haben hier ein Routing das funktioniert, auch ein DNS-Server ist da, es geht hier um das so genannte "Firewalling". Für diese Verbindung gibt es keine Regeln. Ein, zwei Worte zum Thema Firewalling, was ist Firewalling? Mit Hilfe von Firewalls kann ich Datenverkehr zwischen unterschiedlichen Netzwerken regeln und steuern. Und wir kennen zwei unterschiedliche Ansätze, und zwar einmal die Netzwerk-Firewall, die steht also dann in der Mitte irgendwo im Netzwerk und regelt den Datenverkehr zwischen unterschiedlichen Netzwerken, und die so genannte "Personal Firewall", die sitzt dann direkt auf dem Host von dem aus dann der Traffic gesteuert werden soll, und beide Konzepte haben Vor- und Nachteile. Wir behandeln jetzt hier nur die Netzwerk-Firewall. Dort ist der Vorteil natürlich, dass diejenigen, die den Traffic verursachen, das Regelwerk auf dieser Firewall nicht beeinflussen können. Wenn man einen Nachteil konstruieren möchte, dann kann man sagen, dass Angriffe aus dem Segment, aus einem eigenen Segment, auf den Host dies kann natürlich von der Netzwerk-Firewall nicht verhindert werden, denn die sieht den Traffic gar nicht. Also, wenn der Angriff aus dem eigenen Segment kommt, dann kann eine Netzwerk-Firewall natürlich nichts machen. Bevor wir loslegen, möchte ich ganz kurz das Netz hier vorstellen, in dem wir arbeiten. Wir haben hier auf der linken Seite ein LAN, das steckt in der 192.168.100.0/24, und wir haben auf der rechten Seite hier ein Wan, das ist ein simuliertes WAN, das habe ich mal mit der 1.1.1.0/8 bezeichnet, und in der Mitte steht eine Firewall, das ist hier die Monowall, ist ein FreeBSD-basiertes Produkt, und das wollen wir jetzt hier mal verwenden. Diese Monowall, die steht mit einem Beinchen hier, also links im LAN mit der IP 254 hinten dran, und mit dem anderen Beinchen steht sie hier im simulierten Internet, wir haben also hier die IP 1.1.1.11. Diese DMZ hier unten, die wollen wir in diesem Video nicht betrachten. Schauen wir mal rein in diese Firewall, ich habe sie hier schon mal geöffnet, browser-basiert, und es ist jetzt so, dass ich bei der Monowall hier nicht noch ein explizites NAT einrichten muss. Ich muss im Vorfeld ein LAN- und ein WAN-Interface definieren, und auf dem WAN-Interface ist dann das NAT automatisch aktiviert. Ich muss hier also explizit nichts machen. Ein Stück weiter unten haben wir hier die Firewall-Regeln. Wir beschränken uns jetzt hier mal auf Firewall-Regeln für IPv4, und wir sehen, es gibt hier tatsächlich überhaupt keine Regeln. Die Firewall funktioniert jetzt hier so, dass wir die einzelnen Regeln festlegen können, und zwar von dem Interface, von dem der Traffic dann kommt. Also wenn ich jetzt hier auf dem Registerreiter LAN bin, dann regle ich den Traffic, der jetzt tatsächlich auf diesem Interface auch ankommt. Was hier auf dem WAN ist, das interessiert ihn dann auf diesem Registerreiter eben nicht. Es gibt ein Regelwerk, das wird dann eben von oben nach unten abgearbeitet, und wie man sieht, wenn keine Regeln definiert sind, dann greift eine so genannte Standardregel, Das ist hier eine Regel, die sagt: "Nee, dann passiert eben nichts. Dann wird das Paket verworfen." Wenn eine Regel greift, dann wird die Aktion ausgeführt, die ich eben hinterlegt habe. Wenn das Regelwerk von oben nach unten abgearbeitet wird und eine Bedingung innerhalb der Regel greift, dann passiert die Aktion, die in der Regel hinterlegt ist. Wollen wir mal so eine Regel bauen. Ich drücke hier auf das Plus-Zeichen. Hier oben habe ich dann auch gleich die Aktion. Für uns soll das natürlich jetzt ein "Zulassen" sein. Ich habe hier noch "Block" und "Reject". Beim Reject kommt noch eine ICMP-Meldung zurück, beim Block wird's einfach sang- und klanglos vom Netz genommen. Ich habe das Interface, das passt soweit. Ja, und hier sieht man schon, ich muss also tatsächlich die Protokolle, die ich verwenden will, die muss ich kennen, ich muss wissen um was es geht. Was wollen wir jetzt hier machen? Wir wollen ja mit dem Browser später eben auf das Internet zugreifen und das ist entweder HTTP oder HTTPS und das basiert tatsächlich auf TCP, auf dem Transmission Control Protocol. Können wir hier die einzelnen Protokolle auswählen, ich lasse jetzt hier TCP. So, dann haben wir hier eine Quelle, und die Quelle, die könnten wir jetzt natürlich auch direkt eintragen, die Monowall ist hier aber so nett und hat an den Interfaces schon die entsprechenden Adressen hier drin abgebildet, das heißt wenn ich jetzt hier mein LAN-Subnet verwende, dann habe ich automatisch die 192.168.100.0 in diese Regel eingetragen als Quelle. Dann haben wir eine Quellport-Range, die wir hier eintragen müssen. Welche Quellports stehen also in dem Paket drin? Beim Browser ist es ja so, dass ich den Zielport mit 80 adressiere, den Quellport kann ich aber im Vorfeld nicht bestimmen, weil den der Browser automatisch auswählt. Das ist irgendwo was über 1024. Dann nehme ich hier jetzt mal "any to any". Das Ziel? Ja, ich kann noch nicht wissen, wo der Webserver steht, welches Ziel das ist, keine Ahnung, deswegen muss ich beim Ziel tatsächlich hier auch "any" lassen. Und beim Zielport, da kann ich jetzt ziemlich genau bestimmen was ich haben möchte, ich möchte hier HTTP haben, könnte aber natürlich auch "Port 80" eintragen. Wunderbar, und wir speichern das Ganze ab und registrieren die Änderungen. Schauen wir mal, ob's klappt. Ich aktualisiere den Browser. Nee, passiert immer noch nichts. Warum? Weil so ein Browser-Abruf hier natürlich nicht nur auf dem HTTP-Protokoll basiert, sondern ich brauche auch noch eine Namensauflösung. Wie man sieht, man muss also die Netzwerkkommunikation schon im Kopf haben, wenn man ein eigenes Firewall-Regelwerk entwickeln möchte, Also machen wir eine zweite Regel hinzu und sagen jetzt, also: Es soll durchgelassen werden am Interface WAN das DNS-Protokoll, und DNS basiert aber nicht auf TCP, sondern es ist ein statusloses Protokoll auf UDP. Zumindest die Standard-Lookups basieren auf UDP. So, auch hier wieder: Die Quelle wird also mein LAN. Quellport kann ich nicht definieren. Zielport ist aber DNS, sprich Port 53. So, speichern wir das Ganze ab. OK, und dann schauen wir mal ob's funktioniert. Und tatsächlich: Die Verbindung funktioniert. Ja, und wie man hier ganz gut sehen kann, jetzt funktionieren genau zwei Regeln, nämlich HTTP und DNS, sobald ich aber auf eine Webseite draufkomme, die mich zwingend auf HTTPS umroutet, dann würde das Regelwerk hier schon wieder schief gehen und ich muss es erweitern. Deswegen muss ich mir im Vorfeld Gedanken machen, welche Protokolle denn raus dürfen und welche nicht, und in kleineren Unternehmen ist es dann tatsächlich häufig so, dass man sagt, also, es darf dann alles raus, ich mache also eine Regel, die sagt: Es darf alles raus. Rein darf ja standardmäßig sowieso nichts, sondern nur die Antworten dürfen rein, und dort macht man dann eben eine Regel, die dann besagt: Also, alles von intern nach extern ist erlaubt. Dann kommt jeder Client mit jedem Protokoll raus. Das müssen Sie aber im Netzwerkdesign dann für sich selber entscheiden.

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *