Runbooks

Resumen

Un runbook es una receta paso a paso para una tarea operativa que se repite o que ocurre en momentos de presión: abrir un acceso nuevo, bloquear una IP de emergencia, revertir un cambio que rompió algo, reemplazar un firewall averiado. Su valor está en que, cuando algo falla a las tres de la madrugada, no tienes que pensar cómo se hace: sigues una lista probada, en orden, con la verificación al final de cada paso y la forma de volver atrás.
Esta nota reúne los runbooks más comunes de un firewall Palo Alto en la vida real. Cada uno tiene: cuándo usarlo, qué necesitas antes, los pasos (con GUI y CLI), cómo verificar que quedó bien y cómo revertir. Son procedimientos propios, pensados para trabajo diario, y remiten a las demás notas del vault para el detalle de cada función. Adáptalos a tu empresa (ventanas de cambio, aprobaciones, nombres de reglas) y guárdalos donde tu equipo los encuentre.

Requisitos previos

• Acceso administrativo con el rol adecuado (ver Admin Authentication y RBAC) y acceso alternativo por consola (ver Initial Setup y Management Plane)
• Respaldos recientes de la configuración (ver CLI y Config Management)
• Logging activo y un lugar donde revisar los resultados (ver Logging, Monitoring y SIEM)
• Un proceso de cambios (ticket, aprobación, ventana) acordado con tu equipo
• Un entorno de laboratorio para ensayar los procedimientos de riesgo

Regla general para todos los cambios

graph LR
    A["1. Respaldo"] --> B["2. Cambio en candidata"]
    B --> C["3. Validar y revisar<br/>(Preview Changes)"]
    C --> D["4. Commit"]
    D --> E["5. Verificar"]
    E --> F{"¿OK?"}
    F -- Sí --> G["6. Documentar"]
    F -- No --> H["Revertir"]

1. Respaldo: Device > Setup > Operations > Save named configuration snapshot (con el número de ticket en el nombre).
2. Cambio: en la candidata.
3. Revisión: Commit > Preview Changes (o run show config diff en modo configuración, o show config diff en modo operativo; verificar con Tab o ?) para ver exactamente qué cambia.
4. Commit.
5. Verificación: logs, test ...-match, prueba real desde un cliente.
6. Documenta: qué se cambió, quién y por qué (usa el campo Description y Tags de las reglas).

Runbook 1: Abrir un acceso nuevo (regla de Security Policy)

Cuándo: una aplicación o usuario necesita llegar a un destino que hoy está bloqueado.

1. Reúne: origen (IP/usuario/grupo), destino, aplicación o puerto, protocolo, justificación y vigencia.
2. Comprueba si ya existe una regla que lo cubre: test security-policy-match from inside to outside source <IP> destination <IP> destination-port <p> protocol 6 application <app>.
3. Crea objetos si hacen falta (Objects > Addresses; ver Security Policy Fundamentals).
4. Policies > Security > Add: Name con el ticket (por ejemplo CHG1234-app-contabilidad), Source/Destination Zone y Address, Source User, Application (no any), Service application-default, Action Allow, Profile Setting con el grupo de perfiles estándar, Log at Session End, Description y Tag con la fecha de revisión.
5. Colócala en el lugar correcto (más específica arriba, antes de reglas generales o de deny).
6. Commit con Description.
7. Verifica: test security-policy-match ahora devuelve la regla; la prueba real funciona; Monitor > Logs > Traffic muestra la sesión con la regla nueva.
8. Revertir: desactiva la regla (clic derecho > Disable) y haz commit; o carga el snapshot.

Runbook 2: Publicar un servidor (NAT de destino)

Cuándo: un servidor interno debe ser accesible desde Internet.

1. Datos: IP pública, IP privada del servidor, puerto(s), zona del servidor.
2. Crea la regla de Destination NAT (ver Destination NAT): zonas pre-NAT, destino la IP pública, servicio con el puerto original, traducción a la IP privada (y puerto si cambia).
3. Crea la regla de Security Policy con destino la IP pública (original) y zona de destino la real (dmz), con perfiles de seguridad (ver Security Profiles y Profile Groups).
4. Si hay HTTPS y quieres inspeccionar, añade Inbound Inspection (ver SSL Inbound Inspection).
5. Commit.
6. Verifica: test nat-policy-match, test security-policy-match, prueba desde fuera, show session id (traducción en s2c), y Threat logs (ver Troubleshooting NAT).
7. Revertir: deshabilita ambas reglas y haz commit.

Runbook 3: Bloqueo de emergencia de una IP o dominio

Cuándo: una IP está atacando o un host interno está comprometido.

1. Rápido sin commit (si ya tienes un DAG): registra la IP con el tag de cuarentena por API (ver Dynamic Address Groups y Tagging y Automatización y API).
2. Por regla: crea un objeto con la IP; una regla de Deny arriba de todo (origen o destino según el caso), con logging; commit.
3. Por lista dinámica: agrega la IP, URL o dominio a la External Dynamic List y fuerza el refresco: request system external-list refresh type <ip|url|domain> name <nombre> (ver URL Filtering y DNS Security).
4. Borra las sesiones activas de esa IP: clear session all filter source <IP> y clear session all filter destination <IP>.
5. Verifica: Monitor > Logs > Traffic muestra las sesiones nuevas denegadas por la regla; el hit count sube.
6. Revertir / seguimiento: deja una fecha de revisión; cuando termine el incidente, elimina el bloqueo y documenta.

Runbook 4: Revertir un commit que rompió algo

Cuándo: después de un cambio hay pérdida de conectividad.

1. Si aún tienes acceso: Device > Setup > Operations > Load named configuration snapshot (el de antes del cambio) o Load configuration version (una versión anterior), luego Commit.
2. Por CLI:

configure
load config version <n>
commit

o load config from <nombre-de-snapshot> y commit.
3. Si no tienes acceso por la GUI: entra por consola o SSH, revierte con los comandos de arriba.
4. En Panorama: carga la versión anterior en Panorama y haz push, o usa el commit recovery del firewall (si estaba activo, el firewall revierte solo si pierde conexión con Panorama).
5. Verifica: la conectividad afectada y los logs System.
6. Después: analiza la causa con Preview Changes y Config logs antes de reintentar.

Runbook 5: Failover manual de HA (mantenimiento)

Cuándo: necesitas trabajar en el firewall activo sin cortar el servicio.

1. Verifica el estado: show high-availability state (Local active, Peer passive), Running Config Synchronized y versiones Match (ver High Availability).
2. En el activo: Device > High Availability > Operational Commands > Suspend local device (o request high-availability state suspend).
3. El pasivo pasa a activo; comprueba con un ping continuo y show high-availability state en el otro.
4. Haz el mantenimiento en el firewall suspendido.
5. Vuelve a ponerlo funcional: Make local device functional (request high-availability state functional).
6. Verifica: ambos estados, sincronización y sesiones. Si Preempt está activo, el rol puede volver solo.

Runbook 6: Actualizar PAN-OS en un par HA

Cuándo: hay que subir de versión (ver Updates y Upgrades para la ruta correcta).

1. Revisa notas de la versión, ruta de actualización (imágenes base) y compatibilidad; si usas Panorama, actualízalo primero (Panorama debe ser igual o superior a los firewalls).
2. Respaldo: snapshot y export de la configuración, y Device State.
3. Descarga la versión en ambos firewalls (Device > Software > Download).
4. Suspende el pasivo (request high-availability state suspend), instala la versión y reinicia; espera a que vuelva y compruebe HA.
5. Haz failover (suspende el activo para que el actualizado tome el control), valida el tráfico.
6. Actualiza el otro firewall y reinícialo.
7. Vuelve al reparto original si procede (preempt o failover manual).
8. Verifica: versiones iguales (Match), HA sincronizado, aplicaciones y logs normales, y contenido (App/Threat) al día.
9. Plan de reversa: conserva la imagen anterior (Device > Software > Install de la anterior) y el snapshot.

Runbook 7: Reemplazar un firewall averiado (RMA)

Cuándo: un firewall de un par HA o autónomo falla en hardware.

1. En HA: el otro firewall ya está activo; verifica show high-availability state.
2. Solicita el reemplazo (RMA) con el número de serie.
3. Con el equipo nuevo: instala la misma versión de PAN-OS (y contenido) que el par, y migra las licencias (ver Licensing y Subscriptions).
4. Configura solo lo local: IP de gestión, hostname, el Master Key idéntico al del par (Device > Master Key and Diagnostics) y los enlaces HA con los valores cruzados (ver High Availability).
5. Conéctalo y habilita HA: la configuración se sincroniza desde el activo.
6. Si es un equipo autónomo: importa el archivo de configuración y el Device State (certificados) del último respaldo; si estaba en Panorama, registra el nuevo serial y empuja la configuración (ver Panorama Fundamentals).
7. Verifica: HA Synchronized, versiones Match, interfaces y tráfico.

Runbook 8: Nueva sucursal

Cuándo: se abre un sitio nuevo con firewall y VPN al central.

1. Reserva direccionamiento único para la sucursal (sin solapamiento).
2. Si hay Panorama o Strata Cloud Manager: define template/stack o carpeta y variables, registra el serial (ZTP si aplica; ver Zero Touch Provisioning).
3. Configura interfaces, zonas, rutas y NAT (ver L3 Interfaces, Subinterfaces y DHCP).
4. Crea el túnel hacia el central (ver Site-to-Site VPN Estático) y las rutas.
5. Aplica el grupo de perfiles de seguridad estándar y las reglas del sitio (Device Group o carpeta).
6. Envía logs al SIEM (ver Logging, Monitoring y SIEM).
7. Verifica: túnel arriba, ping entre sitios, salida a Internet, logs llegando, In Sync en Panorama.

Runbook 9: Perdí el acceso de administrador

Cuándo: la contraseña de admin se perdió o el login centralizado falla.

1. Si el login centralizado falla: entra con la cuenta local de emergencia (ver Admin Authentication y RBAC).
2. Si tienes otro superusuario: restablece la contraseña desde Device > Administrators.
3. Si no tienes ninguna cuenta: usa la consola y el procedimiento de recuperación de Palo Alto (modo de mantenimiento) para restablecer la contraseña; este procedimiento puede requerir reiniciar y, en algunos casos, restaurar la configuración: revisa la documentación oficial de tu versión antes de hacerlo.
4. Tras recuperar, revisa los logs de Config y System para ver si hubo accesos o cambios no autorizados, y cambia las credenciales relacionadas (ver Hardening del Management Plane).

Runbook 10: Revisión periódica (mensual o trimestral)

1. Reglas sin uso: Policies > Security > Policy Optimizer > Rule Usage (filtro Unused) y Hit Count y Hit Count; deshabilita y luego elimina.
2. Reglas con any en aplicación: Policy Optimizer > Rules Without App Controls; conviértelas en específicas (ver App-ID y Policy Optimization).
3. Objetos sin usar: Objects > (tipo) > Unused; revisa y elimina.
4. Licencias y certificados próximos a vencer (Device > Licenses, Device > Certificate Management).
5. Versión de PAN-OS y contenido: estado de soporte y vulnerabilidades (ver Updates y Upgrades).
6. Respaldos: verifica que existen y que se pueden restaurar (prueba en laboratorio).
7. Administradores: elimina cuentas que ya no se usan y revisa los roles.
8. Logs y alertas: revisa que llegan al SIEM y que las alertas siguen siendo útiles.

Verificación

Comando o lugar	Qué debes ver	Si no lo ves
Commit > Preview Changes antes de cada commit	Solo los cambios que esperabas	Si hay cambios ajenos, revisa quién más modificó la candidata
Device > Setup > Operations	Snapshots con el ticket en el nombre	Si no hay, haz respaldo antes de continuar
show jobs all	Commit en FIN / OK	Si FAIL, lee el detalle
test security-policy-match / test nat-policy-match	Resultado esperado tras el cambio	Si no coincide, revisa orden, zonas y direcciones
Monitor > Logs > Traffic / Config / System	Cambios y sesiones coherentes con el procedimiento	Si no, investiga antes de cerrar el cambio
show high-availability state	Estados correctos en el par	Si no, no continúes con el siguiente paso
Prueba real desde un cliente	La función afectada opera	Si no, usa la reversa

Errores comunes

Un runbook se ejecutó a medias

• Causa: se interrumpió el procedimiento o se saltó un paso.
• Solución: vuelve al respaldo inicial, o reanuda desde el último paso verificado; no continúes sin saber en qué punto estás.

No había respaldo para revertir

• Causa: no se guardó el snapshot antes.
• Solución: usa las versiones de configuración automáticas (Device > Setup > Operations > Load configuration version) y haz del respaldo previo un paso obligatorio.

El commit incluyó cambios de otra persona

• Causa: la configuración candidata es compartida.
• Solución: coordina los cambios, usa config lock o commit parcial por administrador.

La regla creada no se aplica

• Causa: está debajo de otra regla que coincide, o la zona/IP/aplicación no son las correctas.
• Solución: usa test security-policy-match y revisa el orden (ver Security Policy Fundamentals).

El failover no fue transparente

• Causa: HA2 sin sincronización de sesiones o versiones distintas entre el par.
• Solución: revisa High Availability antes de cualquier ventana de mantenimiento y haz una prueba controlada.

Un bloqueo de emergencia se quedó para siempre

• Causa: no hubo fecha de revisión.
• Solución: toda regla de emergencia lleva descripción, ticket y fecha de revisión; inclúyela en la revisión periódica.