Der CVE-Eintrag verwendet den modernen Feature-Namen „User-ID Authentication Portal". Das PAN-OS-XML-Schema, die CLI-Optionen und die Dokumentations-URL-Pfade verwenden weiterhin die veraltete captive-portal-Terminologie. Administratoren, die Flotten mit show config running | match authentication-portal prüfen, übersehen stillschweigend jede Konfiguration, da diese Zeichenfolge niemals als Konfigurationselement erscheint. Dieses Tooling durchsucht den schemakorrekten Elementnamen, unabhängig davon, wann die Konfiguration erstellt wurde.

Die vollständige Tailwind-Analyse zu dieser Namensfalle finden Sie in TRG-SA-2026-003, „Captive Portal's legacy footprint".

Anforderungen

• Python 3.10 oder neuer
• Nur Standardbibliothek — kein pip install erforderlich
• Ein PAN-OS-API-Schlüssel mit Lesezugriff auf die Firewall (oder, für Stufe 2, auf Panorama)
• Ein CA-signiertes (oder vom Betreiber vertrauenswürdiges) Zertifikat auf der Verwaltungsschnittstelle der Firewall; --insecure ist nur für einmalige Bring-up-Audits vorgesehen

Stufe 1 — einzelne Firewall

Beispiel für Tabellenausgabe:

Weitere Ausgabeformate: --output json oder --output csv.

Weitere Flags: --vsys <name> für das Audit eines einzelnen vsys, --timeout/--retries für langsame Upstreams, --debug für ausführliche Fehlerdetails auf stderr.

Stufe 2 — Panorama-Fleet-Sweep

Jede Zeile in der CSV ist ein Gerät-vsys mit Portalstatus, Redirect-Host, Modus, Schnittstellenbindungen und einer Risikoklassifizierung. Das Skript verwendet den Panorama-API-Parameter target=<serial>, sodass es niemals direkt eine Verbindung zu verwalteten Firewalls herstellt — eine Verbindung zu Panorama durchsucht die gesamte Flotte.

Bemerkenswerte Flags:

• --workers N — parallele Audit-Threads (Standard 8, max. 32). Eine Flotte mit 1000 Geräten wird in Minuten statt in über einer Stunde abgeschlossen, die ein serieller Sweep benötigen würde.
• --timeout, --retries — Einstellungen pro API-Aufruf. Vorübergehende URLError- und HTTP-5xx-Fehler werden mit begrenztem Backoff erneut versucht.
• --exclude-disconnected — standardmäßig werden getrennte Geräte mit risk=DISCONNECTED einbezogen, damit sie während des Patch-Fensters sichtbar bleiben. Verwenden Sie dieses Flag, um sie auszuschließen.
• --min-expected-devices N — Warnung (stderr), wenn Panorama weniger Geräte als N zurückgibt. Nützlich, um eine Antwortkürzung bei bekannter Flottengröße zu erkennen.
• --serial-filter '0007*' — Glob-Filter nach Seriennummer, um eine Teilmenge zu prüfen.
• --debug — ausführliche Fehlerdetails pro Gerät auf stderr ausgeben (enthält Upstream-reason-Zeichenfolgen; standardmäßig deaktiviert, um zu vermeiden, dass Hostnamen in kundenorientierte CSVs gelangen).

Risikoklassifizierung

Die Spalte risk in der Ausgabe ist eine der folgenden:

EXPOSED_LIKELY ist ein Hinweis, kein Urteil — Zonennamen sind Betreiberkonventionen, keine Durchsetzung. Das Skript kann eine Sicherheitsrichtlinien-Prüfung nicht ersetzen; es sortiert eine Flottenausgabe so, dass zuerst dort Aufmerksamkeit entsteht, wo sie nötig ist.

Was die Skripte tun — und was nicht

Tun:

• <captive-portal>-Blöcke pro vsys abfragen (der Schem-Elementname ist immer captive-portal, unabhängig von der UI-Benennung oder der PAN-OS-Version).
• Aktiviert/deaktiviert, Redirect-Host, Modus und zonenaufgelöste Schnittstellenbindungen melden.
• Risiko nach Zonennamen-Heuristik klassifizieren, sodass EXPOSED_LIKELY-Zeilen zuerst in der Flottenausgabe erscheinen.
• Den API-Schlüssel über den X-PAN-KEY-Header senden, damit er nicht in URL-Zugriffsprotokollen und Prozessargumenten auftaucht.
• Antwortkörpergröße begrenzen (50 MB), um sich gegen Entity-Expansion-Angriffe auf den XML-Parser zu verteidigen.
• Vorübergehende Fehler mit begrenztem Backoff erneut versuchen.

Tun nicht:

• Sicherheitsrichtlinie umfassend prüfen. Ob das Portal von einem ungeschützten Netzwerk aus erreichbar ist, hängt von Richtlinienregeln, NAT und Zonenbindungen ab — der Betreiber muss diese Prüfung anhand der Audit-Ausgabe durchführen.
• Erreichbarkeit durch Netzwerkprobe testen. Nur reine Konfigurationsprüfung.
• Konfiguration ändern. Alle API-Aufrufe sind schreibgeschützt.

Generieren eines PAN-OS-API-Schlüssels

Der PAN-OS-API-Schlüssel erbt die Rolle und Berechtigungen des Benutzers, der ihn generiert.

Wichtiger Hinweis: Es gibt keine schreibgeschützte XML-API-Berechtigung in PAN-OS.

Die Berechtigungen der Admin-Rolle auf der Registerkarte XML-API sind binär Aktivieren/Deaktivieren pro Kategorie — Konfiguration, Betriebsanfragen, Commit, Export, Import, Report, Log, User-ID-Agent. Das Aktivieren von Konfiguration für die XML-API erlaubt sowohl show- als auch set/edit/delete/move/rename/clone-Aktionen. Das Aktivieren von Betriebsanfragen erlaubt beliebige <request>-Operationen, einschließlich <request><restart>. Die Registerkarten Web-UI und REST-API bieten „Nur Lesen" als Option an; die Registerkarte XML-API nicht.

Ein „Audit-Benutzer", der durch Aktivieren dieser XML-API-Kategorien erstellt wird, besitzt volle XML-API-Schreibberechtigung auf dem Gerät. Behandeln Sie den resultierenden Schlüssel als privilegierte Anmeldeinformation: Begrenzen Sie seine Lebensdauer auf das Audit-Fenster, speichern Sie ihn in einem Secrets-Manager und deaktivieren Sie den Benutzer, wenn die Arbeit abgeschlossen ist.

Kanonische PAN-Referenz: Get Your API Key (PAN-OS XML API).

Über die WebUI

Auf der Firewall (oder Panorama, wenn Sie audit_fleet.py verwenden):

1. Admin-Rolle erstellen. Navigieren Sie zu Device > Admin Roles (oder Panorama > Admin Roles). Klicken Sie auf Add.

   • Benennen Sie die Rolle z. B. audit-config-and-op.
   • Setzen Sie auf der Registerkarte Web UI alles auf None (kein UI-Zugriff für den Audit-Benutzer erforderlich).
   • Aktivieren Sie auf der Registerkarte XML API Configuration und Operational Requests. Lassen Sie Commit, Export, Import, Report, Log und User-ID Agent deaktiviert.
   • Klicken Sie auf OK. Die resultierende Rolle gewährt volle XML-API-Konfigurations- und Betriebsanfragen-Berechtigung — siehe Hinweis oben.

2. Audit-Benutzer erstellen. Navigieren Sie zu Device > Administrators (oder Panorama > Administrators). Klicken Sie auf Add.

   • Name: z. B. audit-cve-2026-0300.
   • Legen Sie ein starkes Passwort fest oder binden Sie es an ein Authentifizierungsprofil.
   • Administrator-Typ: Role Based → wählen Sie audit-config-and-op.
   • Klicken Sie auf OK, dann Commit Sie die Kandidatenkonfiguration.

3. API-Schlüssel generieren mit den Anmeldeinformationen des neuen Benutzers. PAN-OS bietet keine Schaltfläche „API-Schlüssel generieren" in der WebUI — der Keygen-Endpunkt ist der unterstützte Weg. Verwenden Sie einen POST-Body, damit Anmeldeinformationen nicht in URL-Zugriffsprotokollen protokolliert werden:

   root@kitploit:~

   read -rs AUDIT_PW; echo
   export PAN_API_KEY="$(curl -ksX POST "https://fw1.example.com/api/" \
     --data-urlencode "type=keygen" \
     --data-urlencode "user=audit-cve-2026-0300" \
     --data-urlencode "password=$AUDIT_PW" \
     | grep -oE '<key>[^<]+' | cut -c6-)"
   unset AUDIT_PW
   

   read -rs liest das Passwort, ohne es auf dem Terminal anzuzeigen und ohne es in den Shell-Verlauf aufzunehmen. Das Skript liest den resultierenden PAN_API_KEY aus der Umgebung und sendet ihn über den HTTP-Header X-PAN-KEY — weder das Passwort noch der Schlüssel erscheinen in URL-Zugriffsprotokollen oder in ps auxww, während das Skript läuft.

4. Benutzer deaktivieren, wenn die Audit-Arbeit abgeschlossen ist. Navigieren Sie zu Device > Administrators, suchen Sie audit-cve-2026-0300, klicken Sie auf Delete (oder deaktivieren Sie den Benutzer). Commit. Dies invalidiert alle für diesen Benutzer generierten Schlüssel.

Härtungshinweise

• Passwort und Schlüssel aus dem Shell-Verlauf heraushalten. read -rs deckt das Passwort ab. Für den Schlüssel in PAN_API_KEY bevorzugen Sie die interaktive Festlegung über das obige Snippet, anstatt aus einer Datei einzufügen. Wenn Sie ihn aus einer Datei laden müssen, verwenden Sie set +o history für die Sitzung.
• Ein CA-signiertes Zertifikat auf der Verwaltungsschnittstelle der Firewall verwenden. Das Flag --insecure in beiden Audit-Skripten deaktiviert die TLS-Hostnamenprüfung und Zertifikatsvalidierung vollständig. Jeder Angreifer auf dem Pfad kann die Audit-Antwort per MITM abfangen und portal_enabled=False für ein kompromittiertes Gerät melden. Das Skript audit_fleet.py erfordert --accept-mitm-risk zusammen mit --insecure für Fleet-Sweeps, da der Schadensradius einer vergifteten Antwort flottenweit ist.
• Schlüssel nach Abschluss rotieren. Das Deaktivieren oder Löschen des Audit-Benutzers invalidiert alle unter diesem Benutzer generierten Schlüssel.

Exit-Codes

• 0 — kein Portal auf einem geprüften vsys aktiviert
• 2 — kein vsys gefunden (vorübergehend oder nicht unterstützte Konfiguration)
• 3 — Portal auf mindestens einem vsys aktiviert (Überprüfung erforderlich)
• 4 — API-Aufruf fehlgeschlagen (Auth, TLS, Netzwerk)

Der Nicht-Null-Exit bei „Portal aktiviert" ist beabsichtigt — er ermöglicht es Ihnen, das Skript in CI-/Fleet-Sweep-Pipelines einzubinden, die ein klares Signal benötigen.

Lizenz

Lizenziert unter der Apache License, Version 2.0. Siehe LICENSE für die vollständigen Bedingungen.

Kommerzielle Nutzung ist gestattet; Namensnennung ist erforderlich (Copyright-Hinweis und Lizenzdatei in abgeleiteten Werken beibehalten).

Copyright 2026 Tailwind Resource Group.

Siehe auch

• TRG-SA-2026-003 — Sicherheitsadvisory der Tailwind Resource Group für CVE-2026-0300
• PAN PSIRT — https://security.paloaltonetworks.com/CVE-2026-0300
• PAN Best-Practice (Portalzugriff einschränken) — https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA14u000000CqbiCAC
• Tailwind Resource Group — https://tailwindrg.com