Es sind etwa 6 Jahre vergangen seit dem von mir und Gabriele Gerbino organisierten Event Automate IT². Während des Events präsentierte Xavier Homes einen Fall, der mich fasziniert hatte. Heute könnten wir es als Firewall as Code bezeichnen.

Mein Interesse galt nicht nur der Eleganz der Lösung, sondern auch den praktischen Auswirkungen auf Betrieb und Sicherheit.

Jahrelang habe ich Firewalls verwaltet und sehe nun als Berater die Implementierungen vieler Kunden. Alle Installationen, die ich sehe, haben die gleichen Probleme:

• Hunderte von Regeln;
• Jede Regel wird nach dem Empfinden des jeweiligen Operators erstellt;
• Keine genaue Kenntnis, außer einer kurzen Beschreibung, über den Ursprung und die Entwicklung der Regel;
• Wahrscheinlich veraltete Regeln bleiben bestehen, da niemand sicher sagen kann, ob sie notwendig sind;
• Regeln beziehen sich auf stillgelegte oder wiederverwendete Systeme und eröffnen somit undefinierte Risiken;
• Regeln werden zusammengefasst und vereinfacht, nur um den Betrieb zu erleichtern (ohne Sicherheitsbewertung);
• Ständige Anfragen, neue Regeln hinzuzufügen, ohne genau zu wissen, was eine Anwendung tun sollte oder nicht;
• Unmöglichkeit einer Überprüfung aus den oben genannten Gründen und auch weil sich die Regeln ständig ändern;
• Enorme Betriebszeit zur Verwaltung der Firewalls;
• Niemand kann sagen, ob die Richtlinien irgendeiner Sicherheitsrichtlinie entsprechen, die das Unternehmen haben sollte.

Obwohl es Software gibt, die diese Probleme lösen soll, sind diese oft:

• Ein weiteres Pflaster für schlecht gestaltete Prozesse;
• Schwierig zu bedienen;
• So teuer, dass sie für die meisten Unternehmen wirtschaftlich nicht tragbar sind.

Wir beginnen von vorne und entwerfen einen Prozess, der uns ermöglicht, die oben beschriebenen Probleme zu lösen, und daraus (nicht umgekehrt) eine Technologie abzuleiten, die uns die Verwaltung unserer Firewalls ermöglicht.

Im gezeigten Beispiel habe ich Firewalls von Palo Alto Networks verwendet. Die Gründe für diese Wahl sind:

• Ich kenne sie ziemlich gut;
• Ihre Konfiguration kann vollständig im Textformat (insbesondere XML) exportiert werden;
• Ich kann die Konfigurationsdatei bearbeiten und später vollständig anwenden (Commit).

Der Ansatz sollte auf alle Firewalls anwendbar sein, die diese drei Eigenschaften erfüllen.

Der Prozess

Der Prozess, den ich entwerfen möchte, ist sehr einfach:

1. Die Anwendungsbeauftragten definieren die Funktionsregeln ihrer Anwendungen in Bezug auf die notwendigen Verkehrsflüsse;
2. Die Sicherheitsbeauftragten definieren auf hoher Ebene die Verkehrsrichtlinien zwischen den verschiedenen Sicherheitszonen basierend auf einer Risikobewertung;
3. Die Sicherheitsarchitekten entwerfen, implementieren und überwachen die Firewall-Lösungen;
4. Die Automatisierung übernimmt die Anforderungen aus (1), wendet die in (2) definierten Einschränkungen an, generiert die Regelbasis und wendet sie auf die Firewalls an. Die operative Tätigkeit der Sicherheitsarchitekten beschränkt sich auf das in (3) definierte.

Konkret müssen die Anwendungsbeauftragten die Netzwerkanforderungen mittels Dateien definieren und diese zusammen mit dem Code oder der Dokumentation der Anwendung verfügbar machen (Git wäre ein gutes Werkzeug, aber nicht das einzige). Täglich oder auf Anfrage aktualisiert die Automatisierung die Richtlinien.

Das Modell

Wie immer erfordert die Modellierungsphase die meiste Zeit. Im Beispiel habe ich vorgesehen, dass:

• Die Definition der Dienste in Bezug auf Protokoll/Port/Anwendung zentralisiert und von den Sicherheitsarchitekten verwaltet wird. Der Grund ist, dass die Wahl der Anwendung, die mit einem bestimmten Port verknüpft wird, spezifisches Wissen über die Firewall-Lösung erfordert.
• Die Definition der Sicherheitszonen und deren Beziehung zu den Netzwerken zentralisiert und von den Sicherheitsarchitekten verwaltet wird. Der Grund ist, dass das Konzept der Sicherheitszone mit dem Netzwerkdesign verbunden ist.
• Einstellungen wie Logging und Sicherheitsprofile von den Sicherheitsarchitekten verwaltet werden.
• Die Definition jeder Anwendung erfolgt über zwei Dateien: networks.yml und rules.yml. Die Pflege beider Dateien obliegt dem Anwendungsbeauftragten.

Hier ein Beispiel:

# networks.yml
networks:
  WWW:
    - 10.20.1.7/32
  APP:
    - 10.20.2.15/32
  DB:
    - 10.20.2.23/32

Die obige Datei definiert drei Objekte: WWW, APP, DB.

rules:
  - destination-address: WWW
    service: HTTP
    description: |
      Allow HTTP external traffic to exposed web server.      
  - destination-address: WWW
    service: HTTPS
    description: |
      Allow HTTPS external traffic to exposed web server.      
  - source-address: WWW
    destination-address: APP
    service: HTTPS_8443
    description: |
      Allow traffic from exposed web server to application server.      
  - source-address: APP
    destination-address: DB
    service: MYSQL
    description: |
      Allow traffic from application server to database server.      

Die obige Datei definiert die Regeln einer spezifischen Anwendung. Die Dienste sind in der zentralisierten Datei services.yml definiert:

services:
  HTTP:
    applications: web-browsing
  HTTPS:
    applications: ssl
  HTTPS_8443:
    protocol: tcp
    port: 8443
    applications: ssl
  MYSQL:
    applications: mysql

Die Sicherheitszonen werden basierend auf den im network-zone_mapping.yml definierten Regeln zugeordnet:

zones:
  servers:
    type: internal
    networks:
      - 10.20.2.0/24
  dmz:
    type: internal
    networks:
      - 10.20.1.0/24
  # Internet (catch all)
  internet:
    type: external
    networks:
      - 0.0.0.0/0

Implementierungsansatz

Zusammenfassend die wesentlichen Punkte des Ansatzes:

• Die Sicherheitsarchitekten müssen die Firewalls detailliert konfigurieren können, und es ist undenkbar, eine Schnittstelle mit allen notwendigen Einstellungen nachzubilden;
• Die Anwendungsbeauftragten müssen in der Lage sein, die Verkehrsregeln abstrakt zu definieren.

Der praktischste Ansatz besteht daher darin:

1. Die aktualisierte Konfiguration von der Firewall zu lesen;
2. Alle Verkehrsregeln und zugehörigen Objekte zu löschen;
3. Aus den oben beschriebenen Dateien Regeln und Objekte neu zu generieren und zur bereinigten Konfiguration hinzuzufügen;
4. Die Konfiguration zu validieren;
5. Die Konfiguration anzuwenden.

Der Vorteil dieses Ansatzes ist offensichtlich: Ich muss nie überprüfen, ob ein Objekt existiert, ob es korrekt ist oder an der richtigen Stelle steht. Dies vereinfacht die Implementierung erheblich.

Es gibt natürlich auch Nachteile bzw. Einschränkungen:

• Die Regeln müssen so geschrieben sein, dass die Reihenfolge nicht wichtig ist;
• Alle Regeln müssen in den oben beschriebenen Dateien definiert sein.

Ausnahmen können natürlich vorgesehen werden, aber jeder besondere Fall wird die Implementierung komplizieren.

Werkzeuge

Nachdem das Modell definiert ist, muss das Werkzeug gewählt werden, das das Modell in eine tatsächliche Konfiguration umsetzt. Bei der Bewertung habe ich mich auf folgende Werkzeuge konzentriert:

• Aerleon (ehemals Google Carpica)
• pan-os-python: offizielle Bibliotheken entwickelt von Palo Alto Networks
• pan-python: privat entwickelte Bibliotheken, auf denen pan-os-python basiert (interessant, nicht wahr?)
• PAN-OS XML API
• PAN-OS CLI

Nach einigen Versuchen mit der offiziellen Bibliothek (pan-os-python) entschied ich mich, einen anderen Weg zu gehen, da die Bibliothek vorsieht, die Firewall-Objekte einzeln zu konfigurieren, während mein Ansatz die Manipulation der gesamten Konfigurationsdatei erforderte.

Ich begann daher, pan-python zu erkunden, das alles zu tun schien, was benötigt wurde. Aufgrund der schlechten Dokumentation musste ich jedoch vieles durch Versuch und Irrtum herausfinden. Ich war fast soweit, meine eigene Bibliothek zu schreiben, die direkt die nativen APIs aufruft.

Aerleon ist eine sehr interessante Lösung, erreichte aber nicht das Detaillierungsniveau, das ich benötigte. Die Verwendung der CLI war nicht notwendig, da die Palo Alto Networks Firewalls vollständig über native APIs verwaltet werden können.

Implementierung

Derzeit ist die Automatisierung in einer einzigen Python-Datei implementiert, die:

1. Die Konfiguration im XML-Format von der Firewall liest;
2. Die UUID und den Wert des Trefferzählers für jede Regel liest;
3. Objekte und Regeln löscht;
4. Neue Objekte und Regeln generiert, dabei die UUID beibehält, und diese zum XML hinzufügt;
5. Einige Konformitätsprüfungen durchführt;
6. Die Regeln nach der am häufigsten verwendeten Regel sortiert;
7. Die Konfiguration auf die Firewall lädt;
8. Die Konfiguration anwendet.

Die Integration könnte in eine CI/CD-Pipeline aufgenommen und an die Bedürfnisse angepasst werden.

Es bleiben einige Dinge zu verwalten:

• Regeln, die eine spezifische Reihenfolge haben müssen;
• Sicherheitsprofile;
• Unterstützung für Benutzergruppen;
• Spezifische Anpassungen, die jemand sicher benötigen wird.

Schlussfolgerungen

Die Entwicklung dieser Automatisierung hat etwa drei Arbeitstage in Anspruch genommen. Natürlich ist das Ergebnis nicht produktionsreif, aber es ist ein guter Ausgangspunkt.

Die Vorteile dieses Ansatzes sind objektiv:

• Enorm reduzierte Betriebskosten;
• Verantwortung für die Regeln liegt bei denen, die die Anwendung kennen;
• Saubere Konfiguration;
• Möglichkeit, kontinuierliche Überprüfungen der formalen Richtigkeit der Richtlinie durchzuführen;
• Verbesserte Leistung dank der Möglichkeit, die Regeln nach Nutzung zu ordnen.

Falls Sie denken, dass dieser Ansatz zukunftsweisend ist, muss ich Ihnen verraten, dass Xavier’s Vortrag auf einer realen Installation bei einem ziemlich großen internationalen Kunden basierte.

Referenzen

• Automate IT²
• Aerleon
• Google Carpica
• pan-os-python
• pan-python
• PAN-OS XML API
• PAN-OS CLI