Troubleshooting auf der Firewall: mit Palo Alto so einfach wie nie.

Verfasst von Kai Krebber am 30.10.20 09:37
Kai Krebber

Stellen Sie sich vor, Sie haben sich gut beraten lassen und sind nach intensivem Abwägen von Kosten und Nutzen zu der Entscheidung gelangt, für Ihr Unternehmen Palo Alto als Firewall einzuführen. Die Implementierung lief reibungslos und alle Kollegen sind glücklich.

Es gibt aber leider auch Ausnahmefälle, in denen es bei den Anwendern und/oder Systemadministratoren zu Störungsmeldungen kommt. Hier zeigt sich dann im Ent-Störungsprozess, wie gut der Werkzeugkasten ist, den die Firewall mitbringt. Bei Palo Alto helfen die umfangreichen und effizienten Bordmittel dabei, mit möglichst wenig Aufwand alle Fehler zu beheben – oftmals auch, wenn diese woanders liegen.

Sehen wir uns ein konkretes Beispiel an:

Betrachten wir zusammen folgendes Szenario: Ein Unternehmen führt ein neues ERP-System ein. Der Dienstleister, der die Software vor Ort konfiguriert teilt dem IT-Leiter währenddessen mit, dass die Software vor der Benutzung noch online lizensiert werden muss. Die Adresse des Lizenzservers sowie die verwendeten Ports und Protokolle werden an den Betreuer der Firewall weitergeleitet, damit dieser die erforderlichen Freigaben im Regelwerk einrichten kann.

Doch leider bleibt der Lizensierungsversuch des ERP-Systems auch nach dem Einrichten der Freigaben erfolglos. Auf der Suche nach dem Fehlerursprung, richtet sich der erste Verdacht gegen den Firewall-Admin: offenbar hat er die genannten Anforderungen nicht korrekt umgesetzt. Daraufhin überprüft er die angelegte Policy und bestätigt, dass er den Auftrag 1:1 erledigt hat. Wo liegt also das Problem?

Viele Ursachen sind möglich

Denkbar sind viele Auslöser für den Fehler. Wir möchten Ihnen exemplarisch drei Ursachen aufzeigen:

  1. Auf dem ERP-System wurde versehentlich das falsche (oder kein) Default-Gateway eingetragen.

  2. Der Fehler liegt doch auf der Firewall, z.B. wurde die neue Regel unter einer blockenden Regel angelegt, so dass die neue Regel nicht verwendet werden kann (Rule-Shadowing).

  3. Der Lizenzserver des Herstellers hat (temporär) ein Problem und kann aktuell keine Lizensierungsanfragen annehmen.

Wo liegt also die Fehlerursache?

Sofern die Firewall erlaubte und geblockte Zugriffe loggt, kann man mit dem Logfile die Fehlerquelle oft schon eingrenzen. Aber je nach Konstellation, kann auch damit nicht hinreichend geklärt werden,

- ob der Lizensierungsversuch des ERP-Systems überhaupt auf der Firewall ankommt,

- ob er zwar ankommt, von der Firewall aber nicht (korrekt) zum Lizensierungsserver weitergereicht wird,

- ob das Paket von der Firewall zum Server weitergeleitet wird, von diesem Server aber keine Antwort auf der Firewall sichtbar ist

- oder ob aus Sicht der Firewall eine erfolgreiche Bidirektionale Kommunikation stattgefunden hat, das ERP-System aber auf deren Basis trotzdem nicht die lokale Lizensierung durchführen kann.

Links, rechts oder mittendrin?

Etwas plakativ formuliert stellt sich also die Frage, ob die Ursache links von der Firewall, auf der Firewall selbst oder rechts von der Firewall zu suchen ist. Die Palo Alto Firewall bietet einen Packet Capture Mechanismus an, welcher genau diese Fragen:

  1. Kommt das erste Paket des Kommunikationsaufbaus vom Client zum Server überhaupt auf der Firewall an?

  2. Insofern es ankommt, wird es von der Firewall ggf. nicht (korrekt) zum Server weitergeleitet oder

  3. kommt das Paket an und wird auch sauber weitergeleitet.

beantwortet und auf 3 (genau genommen 4) sogenannte Stages abbildet:

Receive: Das Paket kommt an der Firewall an (oder ist hier schon nicht sichtbar) > Das Problem liegt im LAN / dem ERP-System. Also links der Firewall.

Drop: Das Paket wurde von der Firewall empfangen, aber von ihr verworfen. > Das Problem liegt auf der Firewall selbst, quasi mittendrin.

Transmit: Das Paket wurde empfangen, durch eine Security-Policy grundsätzlich zugelassen und für die weitere Verarbeitung intern zusätzlich analysiert.

Transmit: Das Paket wurde erfolgreich abschließend von der Firewall bearbeitet und auf seinen weiteren Weg zum Server gesendet. > Sofern hierauf keine Antwort (receive auf dem WAN Interface) zu sehen ist, liegt das Problem im WAN-Bereich. Somit rechts der Firewall.

BB_PaloAlto_Teil4_1bild

Pakete richtig analysieren

Ist ein Antwortpaket vom Server sichtbar, muss jetzt geprüft werden, ob dies sauber von der Firewall verarbeitet und zum Client (hier dem ERP-System) weitergeleitet wurde.

Für jede der 4 Stages, generiert die Palo Alto ein eigenes Capture File (sofern in der jeweiligen Stage mind. 1 Paket vorhanden ist). Diese Capture Files lassen sich entweder lokal auf der Firewall selbst oder nach Download auf z.B. den PC des Admins mittels dem de Facto-Standard für Paketanalysen Wireshark analysieren.

Die Pakete lassen sich auch bereits während des Erstellens der Capture Files nach den klassischen Kriterien (Interface, Quell-IP, Ziel-IP, Ports, Protokoll etc.) filtern. Nachfolgend ein Beispiel für zwei Filter, welche sowohl die (https-) Pakete vom Client zum Server, als auch die Antworten des Servers (über die geNATtete WAN-IP der Firewall) zurück zum Client aufzeichnen würden:

BB_PaloAlto_Teil4_2bild

Entsteht der Verdacht, dass die Angaben des Herstellers doch nicht passen, empfiehlt es sich, die Portangabe im Filter wegzulassen. Tauchen dann Pakete im drop-stage-file des Packet-Captures auf, hat man schon den Schuldigen gefunden.

Willkommen im Deep Dive

Zeigt der Packet-Capture, dass die Pakete in der Firewall hängen bleiben, bietet Palo Alto noch weitere Analysemöglichkeiten an. Insbesondere die Kommandozeile eröffnet hier umfangreiche Loggingmöglichkeiten während der Analyse und der Weiterverarbeitung der Pakete, durch die Firewall in den einzelnen Modulen. Hier kann man z.B. sehen, dass das Paket im Transmit zum WAN-Router vor der Firewall gesendet wird:

== 2020-08-12 10:32:15.424 +0200 ==
Packet received, tag 44202, type ATOMIC
Packet info: len 60 port 19 interface 282 vsys 1
wqe index 226090 packet 0x0x8000000315ae10ca, HA: 0
Packet decoded dump:
L2:  00:50:56:92:f3:79->c4:24:56:83:4a:13, VLAN 2 (0x8100 0x0002), type 0x0800
IP:  192.168.100.5->12.34.56.78, protocol 6
     version 4, ihl 5, tos 0x00, len 40,
     id 29498, frag_off 0x4000, ttl 64, checksum 40276(0x9d54)
TCP: sport 18947, dport 443, seq 510801893, ack 140743271,
     reserved 0, offset 5, window 65160, checksum 18986,
     flags 0x10 ( SYN), urgent data 0, l4 data len 0 TCP option: Flow fastpath, session 44202 (set work 0x800000030eef8900 exclude_video 0 from sp 0x80000002c2c2c180 exclude_video 0)
NAT session, run address/port translation
Forwarding lookup, ingress interface 282
L3 mode, virtual-router 2
Route lookup in virtual-router 2, IP 12.34.56.78
Route found, interface ethernet1/2, zone 5, nexthop 23.45.67.88
Resolve ARP for IP 23.45.67.88 on interface ethernet1/2
ARP entry found on interface 17

Diese debug-Dateien können dann von der Firewall geladen und dann entweder selbst analysiert oder dem Firewall-Herstellersupport zwecks Unterstützung bei der Fehlersuche überlassen werden.

Fazit

Es ist schön, wenn alles nach Plan läuft aber wenn nicht, sollte die Firewall nicht zur ‚Black Box‘ werden, sondern dem Admin die Möglichkeiten bieten, die Ursachen für eine fehlerhafte Kommunikation zu ermitteln. Eine Firewall von Palo Alto bietet diese Möglichkeiten.

Der Deep Dive ist jedoch nicht für jeden umsetzbar und/oder nicht ohne Hilfe anzuwenden. Wir stehen Ihnen auch hierbei als Lösungspartner zur Seite. Melden Sie sich einfach bei uns, gemeinsam schaffen wir das!

VEREINBAREN SIE EINEN TERMIN MIT UNS!

Themen: firewall, it-security, palo alto