El registro CVE utiliza el nombre de función moderno "Portal de Autenticación de User-ID". El esquema XML de PAN-OS, las opciones de CLI y las rutas de URL de documentación aún utilizan el vocabulario heredado captive-portal. Los operadores que auditan flotas con show config running | match authentication-portal pasarán por alto silenciosamente toda configuración porque esa cadena nunca aparece como elemento de configuración. Esta herramienta busca el nombre de elemento correcto según el esquema, independientemente de cuándo se creó la configuración.

El análisis completo de Tailwind sobre este detalle de nomenclatura se encuentra en TRG-SA-2026-003, "La huella heredada del Portal Cautivo".

Requisitos

• Python 3.10 o superior
• Solo biblioteca estándar — no se requiere pip install
• Una clave de API de PAN-OS con acceso de lectura al firewall (o, para el Nivel 2, a Panorama)
• Un certificado firmado por CA (o de confianza del operador) en la interfaz de gestión del firewall; se proporciona --insecure solo para auditorías de puesta en marcha puntuales

Nivel 1 — firewall único

Ejemplo de salida en tabla:

Otros formatos de salida: --output json o --output csv.

Otras opciones: --vsys <nombre> para auditoría de un solo vsys, --timeout/--retries para upstreams lentos, --debug para detalles de error detallados en stderr.

Nivel 2 — barrido de flota con Panorama

Cada fila del CSV es un dispositivo-vsys con estado del portal, host de redirección, modo, enlaces de interfaz y una clasificación de riesgo. El script utiliza el parámetro de API target=<serial> de Panorama, por lo que nunca se conecta directamente a los firewalls gestionados: una sola conexión a Panorama barre toda la flota.

Opciones destacadas:

• --workers N — hilos de auditoría concurrentes (predeterminado 8, máximo 32). Una flota de 1000 dispositivos se completa en minutos en lugar de la hora o más que tomaría un barrido en serie.
• --timeout, --retries — ajustes por llamada a la API. Los URLError transitorios y los HTTP 5xx se reintentan con retroceso acotado.
• --exclude-disconnected — de forma predeterminada, los dispositivos desconectados se incluyen con risk=DISCONNECTED para que sigan siendo visibles durante la ventana de parcheo. Use esta opción para eliminarlos.
• --min-expected-devices N — advierte (stderr) si Panorama devuelve menos dispositivos que N. Útil para detectar truncamiento de respuesta frente a un tamaño de flota conocido.
• --serial-filter '0007*' — filtra por glob según el número de serie para auditar un subconjunto.
• --debug — imprime detalles de error detallados por dispositivo en stderr (incluye cadenas reason del upstream; desactivado por defecto para evitar filtrar nombres de host en CSV orientados al cliente).

Clasificación de riesgo

La columna risk en la salida es una de las siguientes:

EXPOSED_LIKELY es una pista, no un veredicto: los nombres de zona son convenciones del operador, no una aplicación de seguridad. El script no puede reemplazar una revisión de política de seguridad; ordena la salida de la flota para indicar dónde debe centrarse la atención primero.

Qué hacen los scripts — y qué no hacen

Sí hacen:

• Consultar bloques <captive-portal> por vsys (el nombre del elemento de esquema es siempre captive-portal, independientemente del nombre en la interfaz o la versión de PAN-OS).
• Informar habilitado/deshabilitado, host de redirección, modo y enlaces de interfaz resueltos por zona.
• Clasificar el riesgo mediante heurística de nombres de zona para que las filas EXPOSED_LIKELY aparezcan primero en la salida de la flota.
• Enviar la clave de API mediante el encabezado X-PAN-KEY para que no aparezca en los registros de acceso de URL ni en los argumentos de proceso.
• Limitar el tamaño del cuerpo de respuesta (50 MB) para defenderse contra ataques de expansión de entidades en el analizador XML.
• Reintentar errores transitorios con retroceso acotado.

No hacen:

• Revisar la política de seguridad de forma exhaustiva. Si el portal es accesible desde una red no confiable depende de las reglas de política, NAT y enlaces de zona: el operador debe completar esa revisión a partir de la salida de la auditoría.
• Probar la accesibilidad mediante sondas de red. Solo auditoría de configuración pura.
• Modificar ninguna configuración. Todas las llamadas a la API son de solo lectura.

Generación de una clave de API de PAN-OS

La clave de API de PAN-OS hereda el rol y los permisos del usuario que la genera.

Advertencia importante: no existe una concesión de API XML de solo lectura en PAN-OS.

Los permisos de Rol de Administrador en la pestaña API XML son binarios Habilitar/Deshabilitar por categoría: Configuración, Solicitudes Operativas, Commit, Exportar, Importar, Informe, Registro, Agente User-ID. Habilitar Configuración para la API XML permite tanto show como acciones set/edit/delete/move/rename/clone. Habilitar Solicitudes Operativas permite operaciones <request> arbitrarias, incluido <request><restart>. Las pestañas de Web UI y API REST ofrecen Solo Lectura como opción; la pestaña de API XML no.

Un "usuario de auditoría" creado al habilitar estas categorías de API XML posee autoridad completa de escritura de API XML en el dispositivo. Trate la clave resultante como una credencial privilegiada: limite su vigencia a la ventana de auditoría, guárdela en un gestor de secretos y deshabilite al usuario cuando el trabajo esté completo.

Referencia canónica de PAN: Obtenga su clave de API (API XML de PAN-OS).

A través de la WebUI

En el firewall (o Panorama, si está usando audit_fleet.py):

1. Cree el Rol de Administrador. Navegue a Dispositivo > Roles de Administrador (o Panorama > Roles de Administrador). Haga clic en Agregar.

   • Asigne un nombre al rol, p. ej. audit-config-and-op.
   • En la pestaña Web UI, establezca todo en Ninguno (no se necesita acceso a la interfaz para el usuario de auditoría).
   • En la pestaña API XML, habilite Configuración y Solicitudes Operativas. Deje Commit, Exportar, Importar, Informe, Registro y Agente User-ID deshabilitados.
   • Haga clic en Aceptar. El rol resultante otorga autoridad completa de Configuración y Solicitudes Operativas de API XML — consulte la advertencia anterior.

2. Cree el usuario de auditoría. Navegue a Dispositivo > Administradores (o Panorama > Administradores). Haga clic en Agregar.

   • Nombre: p. ej. audit-cve-2026-0300.
   • Establezca una contraseña segura o vincúlelo a un Perfil de Autenticación.
   • Tipo de Administrador: Basado en Roles → seleccione audit-config-and-op.
   • Haga clic en Aceptar y luego Commit la configuración candidata.

3. Genere la clave de API con las credenciales del nuevo usuario. PAN-OS no expone un botón de "generar clave de API" en la WebUI: el endpoint de keygen es la ruta compatible. Use un cuerpo POST para que las credenciales no queden registradas en los registros de acceso de URL:

   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 lee la contraseña sin mostrarla en la terminal y sin incluirla en el historial del shell. El script lee la PAN_API_KEY resultante del entorno y la envía mediante el encabezado HTTP X-PAN-KEY: ni la contraseña ni la clave aparecen en los registros de acceso de URL ni en ps auxww mientras el script se ejecuta.

4. Deshabilite al usuario cuando el trabajo de auditoría esté completo. Navegue a Dispositivo > Administradores, localice audit-cve-2026-0300, haga clic en Eliminar (o deshabilite al usuario). Haga Commit. Esto invalida cualquier clave generada para ese usuario.

Notas de endurecimiento

• Mantenga la contraseña y la clave fuera del historial del shell. read -rs cubre la contraseña. Para la clave en PAN_API_KEY, prefiera configurarla de forma interactiva mediante el fragmento anterior en lugar de pegarla desde un archivo. Si debe cargarla desde un archivo, use set +o history para la sesión.
• Use un certificado firmado por CA en la interfaz de gestión del firewall. La opción --insecure en ambos scripts de auditoría deshabilita por completo la verificación del nombre de host TLS y la validación de certificados. Cualquier atacante en la ruta puede hacer MITM en la respuesta de auditoría e informar portal_enabled=False para un dispositivo comprometido. El script audit_fleet.py requiere --accept-mitm-risk junto con --insecure para barridos de flota porque el radio de explosión de una respuesta envenenada es de toda la flota.
• Rote la clave al finalizar. Deshabilitar o eliminar al usuario de auditoría invalida todas las claves generadas bajo ese usuario.

Códigos de salida

• 0 — ningún portal habilitado en ningún vsys auditado
• 2 — no se encontró ningún vsys (configuración transitoria o no compatible)
• 3 — portal habilitado en al menos un vsys (se requiere revisión)
• 4 — falló la llamada a la API (autenticación, TLS, red)

La salida no cero en "portal habilitado" es intencional: le permite conectar el script a canalizaciones de CI/barrido de flota que necesitan una señal clara.

Licencia

Licenciado bajo la Licencia Apache, Versión 2.0. Consulte LICENSE para conocer los términos completos.

Se permite el uso comercial; se requiere atribución (conservar el aviso de copyright y el archivo de licencia en obras derivadas).

Copyright 2026 Tailwind Resource Group.

Véase también

• TRG-SA-2026-003 — aviso de seguridad de Tailwind Resource Group para CVE-2026-0300
• PAN PSIRT — https://security.paloaltonetworks.com/CVE-2026-0300
• Mejores prácticas de PAN (restringir acceso al portal) — https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA14u000000CqbiCAC
• Tailwind Resource Group — https://tailwindrg.com