Hallo Zusammen,
Bei den letzten Updates der Netzwerk-Management Module unserer Orion
Plattform haben wir erweiterten Support für Palo Alto Firewalls implementiert, ein Feature, welches seit 2017 auf euren Wunschlisten stand.
Ich muss kurz ausholen: Das Feature selbst heißt „Network Insight für Palo Alto“, und es gibt bereits einige Network Insight sowie App-Insights innerhalb von Orion.
Wir nennen es „Insight,“ wenn wir bei komplexen Themen mehr Unterstützung bringen, als es mit gewöhnlichen Methoden möglich ist.
Mit den Insights haben wir es uns zur Aufgabe gemacht, komplizierte Technologien, die im Detail oft Spezialwissen erfordern, für den Allrounder (IT Generalist) zugänglich zu machen.
Im Bereich von Network Insight gibt es bereits Support für F5 Loadbalancer, Cisco Nexus sowie ASA.
Für den Support der ASAs haben wir von euch viel Lob erhalten, also lag der Schritt nahe, sich mit einer weiteren Firewall zu befassen.
Und wieder kamt ihr ins Spiel – kein Anbieter wurde von euch so oft vorgeschlagen wie PA.
Verwalten von Security Policies
Die Effektivität einer Firewall wird durch die Policies bzw. Regeln definiert. Idealerweise sichern die Regeln den Netzwerkverkehr ab ohne negativen Einfluss auf die Geschäftsprozesse.
Wenn es jedoch zu Flüchtigkeitsfehlern oder grober Fehlkonfiguration kommt, entstehen Probleme auf verschiedenen Ebenen. Für den Administrator reicht es an dieser Stelle nicht mehr aus, lediglich die Performance der Firewall zu beobachten.
Unglücklicherweise ist das Einpflegen von Regeln keine einmalige Aktion, sondern eine dynamische Angelegenheit.
Die Infrastruktur ändert sich ebenso wie Geschäftsprozesse und Anwendungen, und Regeln müssen ständig angepasst werden.
Network Configuration Manager (NCM) stellt die folgenden Features zur Verfügung:
- Komplette Übersicht über alle Regeln
- Details zu einzelnen Regeln sowie deren Änderungen
- Die Benutzung von Regeln über mehrere PA Knoten
- Das Vergleichen von Ausschnitten der Konfiguration
- Interface Konfigurationen
- Information zu Anwendungen, Adressen und Diensten innerhalb von Regeln
Nach dem ersten Einlesen der Konfiguration wird NCM automatisch die Regeln sowie die dazugehörigen Elemente anzeigen.
Die im Bild angezeigte Seite erlaubt das schnelle Auffinden von Regeln durch Such- und Filterfunktionen.
Ein Klick auf eine Regel zeigt Details der Konfiguration inklusive der Objekte und Objektgruppen, die von der Regel betroffen sind.
Manche Regeln werden über mehrere Firewalls hinweg eingesetzt. Wir zeigen dies automatisch an, um Situationen vorzubeugen, bei denen ein Administrator eine Änderung versehentlich auf allen Geräten gleichzeitig replizieren lässt.
Ebenso lässt sich sofort feststellen, ob eine neue Regel korrekt angewandt worden ist.
Was bei der Überwachung von jeglichen Konfigurationen wichtig ist, trifft um so mehr zu bei Firewalls; ein Audit über Veränderungen. Compliance erfordert ein Log, und wir zeigen direkt an wann und was verändert wurde.
VPN Tunnel Überwachung
Als wir mit der Planung des Network Insights begonnen hatten, haben wir in UX Diskussionen gefragt, wie ihr zur Zeit VPN Tunnel überwacht.
Die häufigste Antwort war „Ich pinge die Gegenstelle.“
Leider ist das nicht wirklich ausreichend. In vielen Konfigurationen hat das andere Ende des Tunnels keine direkte IP Adresse, oder es gibt verschiedene je nach Datenverkehr, also wird meist irgendwas am anderen Ende angepingt.
Das wiederum kann mit der Herausforderung kommen, dass die Gegenstelle aus Sicherheitsgründen nicht auf Ping antwortet.
Oder, noch schlimmer, wenn Pakete plötzlich nicht mehr zurück geliefert werden – das kann oft ein Problem mit der antwortenden Maschine anstatt dem Tunnel sein.
Das ist eine ganze Menge Arbeit, erfordert manuelles Nachforschen, ist nicht präzise und, vor allem, bringt nicht viel. Es zeigt lediglich den Status (up/down) an, aber keinerlei Grund, warum etwas gerade nicht aktiv ist.
Wenn der Tunnel down ist, wo muss sich ansetzen?
Wann hat es zuletzt funktioniert?
Wenn der Tunnel läuft, wieviel Datenverkehr wird gerade generiert?
Wenn man bedenkt, dass VPN Tunnel mit WAN Verbindungen gleichzusetzen sind – es werden Standorte verknüpft, oder aber Clouds – wird klar, dass die Tunnel als kritisch anzusehen sind, und Probleme so schnell wie möglich beseitigt werden müssen.
Nachdem Network Insight für Palo Alto aktiviert worden ist, wird Network Performance Monitor (NPM) automatisch die VPN Tunnel erkennen und anzeigen.
Das Site-to-site Element zeigt Details zu jedem Tunnel an:
Ein paar Dinge sollte man sich genauer anschauen.
Alle Tunnel zeigen Quell- und Ziel-IP. Wenn die Ziel IP bzw. das Gerät schon überwacht wird, vielleicht eine andere PA oder ASA, wird direkt auf den Knoten verlinkt, wie bei der 192.168.100.10 auf dem Screenshot.
Ebenso wird der Name des Tunnels angezeigt, sofern einer vorhanden ist.
Es werden unterschiedliche Informationen für Tunnel je nach Status angezeigt. Wenn ein Tunnel down ist, sieht man Zeit/Datum der Statusänderung. In den meisten Fällen sieht man auch, in welcher Phase der Tunnel gescheitert ist.
Das ist typischerweise die erste Information, die man für das Troubleshooting benötigt.
Bei aktiven Tunneln wird Zeit/Datum des Verbindungsaufbaus angezeigt und welche Verschlüsslung in Benutzung ist, inklusive des Hashs.
Die letzten zwei Spalten sind von besonderem Interesse – sie zeigen die Bandbreite an.
Bandbreite kann, durch die Verschlüsslung, ein Problem darstellen. Mit einem Tool zur Datenverkehrsanalyse kann die Bandbreite anhand der beiden kommunizierenden IP Adressen nach der Verschlüsslung identifiziert werden. Das ist ein bisschen Arbeit und zeigt nur die Gesamtanzahl übertragener Pakete bzw. Bytes an. Man hat keine Einsicht in die Anwendungen oder die tatsächlichen Endpunkte.
Wenn man sich Flows vor dem Verschlüsseln anschaut, sieht man zwar die direkten Endpunkte, aber das Filtern nach Anwendungen wird schwierig, und letzten Endes weiss man nicht, was genau es durch den Tunnel geschafft hat. Der Overhead durch die Einkapselung wird ignoriert.
Und das Ganze vor dem Hintergrund, dass VPN Tunnel über die WAN Verbindung laufen, was häufig ein sehr hoher Kostenfaktor ist.
Network Insight für Palo Alto zeigt die tatsächliche Bandbreite jedes einzelnen Tunnels an. Die Datensätze sind normalisiert und erlauben somit das Erstellen von Berichten für die Kapazität/Auslastung, sowie die Alarmierung für den Fall, dass sich etwas verabschiedet.
Aber wir wären nicht SolarWinds, wenn wir die Daten nicht auch im PerfStack Dashboard der Plattform bereit stellen würden:
GlobalProtect VPN Überwachung
Ich stelle eine Behauptung auf:
Wenn jemand ein Problem mit einer Endpunkt-VPN Verbindung hat, ist es meistens jemand aus der Führungsetage.
Würdet ihr zustimmen?
Das beim Troubleshooting von Endpunkt-VPNs ist, dass man meisten nicht wirklich viele Daten hat, bis man den Laptop tatsächlich in den Händen hält, und eine Antwort wie „Keine Ahnung was da los ist“ lässt Zweifel an der Kompetenz aufkommen.
Network Insight für Palo Alto überwacht GlobalProtect und erstellt einen Eintrag für jede einzelne Verbindung:
Dadurch kann man auf einige Probleme schließen. Wenn z.B. der gleiche User permanent Verbindungsprobleme hat, liegen lokale Probleme vor. Vielleicht einfach nur ein falsches Passwort.
Wenn jedoch keiner mehr Verbinden kann, liegt ein Problem mit der Firewall vor oder der Verbindung zum System für die Authentifizierung.
Datenverkehr nach Regel
Sogar Netflow Traffic Analyzer (NTA) trägt zum Network Insight bei. Wir haben Teile von NTA mit NCM integriert, und wenn beide Module vorhanden sind, kann man den Flow anhand einzelnen Policies einsehen.
Das beantwortet viele Fragen, wie z.B. „Wer oder was mag von einer Regeländerung beeinflusst werden?“ aber vereinfacht natürlich auch retrospektives Troubleshooting.
Es gibt verschiedene Wege, um die Daten anzusehen, hier starten wir auf der Detailseite des Knotens und klicken links auf Policies:
Dort wählen wir eine Regel von der Übersicht aus:
Und schließlich öffnen sich die Policy-Details:
Auf der linken Seite sieht man ein paar Daten zur Regel sowie die exakte Konfiguration.
Die Übersicht auf der rechten Seite ist nicht wie üblich nach Knoten oder Interface gefiltert, sondern tatsächlich nach der Policy, die den Datenfluss regelt.
Die angezeigten Endpunkte befinden sich in einer der konfigurierten Firewall-Zonen und die die Konversationen selbst definieren sich über die Application-IDs die in den Regeln gefunden werden.
Das sind wertvolle Informationen für jeden, der Regeln plant oder ändert, da hier grafisch aufbereitet wird, welchen Einfluss eine Änderung auf den Produktiv-Betrieb haben kann.
Für diese Ansicht werden sowohl NCM als auch NTA benötigt und NTA hat NPM als Voraussetzung.
Da kommt noch was – User Device Tracker
In den meisten Fällen benötigt User Device Tracker (UDT) lediglich SNMP Zugangsdaten, um Informationen über Ports und verbundene Endpunkte zu sammeln.
Bei manchen Geräten jedoch werden diese Informationen nicht oder nur limitiert über SNMP bereitgestellt, z.B. Cisco Nexus 5K, 7K und 9K, und Palo Alto! Hier wird die CLI benutzt.
Der CLI Zugriff kann entweder per Gerät oder im Bulk eingerichtet werden.
Nachdem die Auswahl der Geräte getroffen wurde, werden die Eigenschaften editiert:
Etwas weiter unten befinden sich die CLI Einstellungen:
Es ist wichtig, L3 Polling zu aktivieren:
Danach wird UDT die Endpunkte anzeigen, hier ein Bild von einem NX-7K:
Viel Spass mit dem neuen Network Insight!
