Dynamic Address Groups y Tagging

Contenido complementario

Este tema no está en las notas de tus cursos que tengo; está completado con conocimiento general de PAN-OS. Compáralo con lo que viste en la lección y corrígelo si difiere.

Resumen

Un Address Group normal (estático) es una lista fija de direcciones que tú editas a mano. Un Dynamic Address Group (DAG) es un grupo cuyos miembros se calculan solos: no listas direcciones, defines una condición basada en tags (por ejemplo “todo lo que tenga el tag quarantine”), y el firewall incluye las IPs que tengan esa etiqueta en ese momento. Cuando a una IP se le agrega o quita el tag, entra o sale del grupo sin que tengas que editar ni hacer commit de la regla que lo usa.
Esto permite automatizar respuestas: un host que dispara una alerta de amenaza recibe el tag quarantine y una regla que bloquea el DAG quarantine lo aísla en segundos. También permite que sistemas externos (scripts, VMware, nube, el agente User-ID) registren IPs con tags usando la API. Esta nota explica los tags, cómo crear un DAG, cómo asignar tags y cómo comprobar quién está en el grupo.

Requisitos previos

  • Saber qué condición quieres usar (por ejemplo el tag quarantine o servidores-web)
  • Un mecanismo para asignar tags a IPs: Log Forwarding Profile con acción Tagging, la API XML, un script, o el tag directo en un objeto de dirección
  • Una regla de Security Policy que use el DAG como origen o destino
  • Si usas la API: una API key y una cuenta con permiso para User-ID (rol XML API)
  • Si lo automatizas desde logs: un Log Forwarding Profile aplicado a la regla que genera el log (ver Logging, Monitoring y SIEM)

Conceptos clave

ConceptoQué es
TagEtiqueta con nombre (y color opcional) que se asigna a objetos, reglas, zonas o IPs
Static tagTag asignado a un objeto de dirección en la configuración; requiere commit para cambiarlo
Dynamic tag (registered IP)Tag asociado a una IP en memoria, registrado por API, User-ID o log forwarding; no requiere commit
Dynamic Address GroupGrupo de direcciones cuyos miembros son las IPs (o objetos) que cumplen una condición de tags
Match criteriaExpresión con and / or entre tags (por ejemplo 'quarantine' or 'infectado')
TimeoutTiempo en minutos que dura un tag registrado; al vencer, la IP sale del grupo

Las asignaciones de tags dinámicos se guardan en memoria. Si el firewall se reinicia, hay que volver a registrarlas (por eso conviene usar timeout y un sistema que las vuelva a enviar).

graph LR
    A["Host 10.10.0.105<br/>genera log de amenaza"] --> B["Log Forwarding Profile<br/>acción Tagging"]
    B --> C["La IP recibe el tag<br/>'quarantine' (timeout 60 min)"]
    C --> D["DAG 'Cuarentena'<br/>criterio: 'quarantine'"]
    D --> E["Regla de Security Policy<br/>origen = DAG, Action Deny"]

Configuración

1. Crear el tag

  1. Objects > Tags > Add > Name quarantine, Color (ej. Red).
  2. OK.

2. Crear el Dynamic Address Group

  1. Objects > Address Groups > Add.
  2. Name Cuarentena, Type Dynamic.
  3. Match: pulsa Add Match Criteria y elige quarantine (puedes combinar tags con and / or).
  4. OK.
set address-group Cuarentena dynamic filter "'quarantine'"

3. Usar el DAG en una regla

  1. Policies > Security > Add > Name Bloquear cuarentena.
  2. Source: Source Zone inside, Source Address Cuarentena (o en Destination, según el caso).
  3. Destination: Destination Zone any.
  4. Actions: Action Deny.
  5. Colócala arriba de las reglas de permiso.
  6. Commit. Esta es la última vez que haces commit para ese comportamiento: después los miembros cambian solos.

4. Asignar tags automáticamente desde un log (acción Tagging)

  1. Objects > Log Forwarding > Add (o edita el existente).
  2. Match List > Add: Name threat-tag, Log Type threat, Filter por ejemplo ( severity geq high ).
  3. Built-in Actions > Add: Name tag-source, Action Tagging, Target Source Address, Actions Add Tag, Registration Local User-ID, Timeout 60 minutos, Tags quarantine.
  4. En la regla de Security Policy que permite ese tráfico: Actions > Log Forwarding: este perfil.
  5. Commit.

5. Asignar tags con la API XML

  1. Obtén una API key: https://<IP-firewall>/api/?type=keygen&user=<usuario>&password=<contraseña> (guarda la key).
  2. Registra una IP con un tag:
curl -k -X POST "https://192.168.1.51/api/?type=user-id&key=<API-KEY>" --data-urlencode 'cmd=<uid-message><version>2.0</version><type>update</type><payload><register><entry ip="10.10.0.105"><tag><member>quarantine</member></tag></entry></register></payload></uid-message>'
  1. Para quitarlo, usa <unregister> en vez de <register> con la misma estructura.

6. Tag directo en un objeto de dirección (estático)

  1. Objects > Addresses > Add (o edita) > Tags: elige el tag.
  2. Los objetos con ese tag entran al DAG tras el commit.

7. Dynamic User Groups (complemento)

Un Dynamic User Group (DUG) funciona igual, pero agrupa usuarios por tags en lugar de IPs: Objects > Dynamic User Groups. Se usa como Source User en una regla.

Verificación

Comando o lugarQué debes verSi no lo ves
show object registered-ip allLas IPs registradas con sus tagsSi no aparece, el registro no llegó (API, log forwarding)
show object registered-ip tag "quarantine"Solo las IPs con ese tagCompara el nombre del tag exacto
Objects > Address Groups > fila del DAG > enlace more... en AddressesLa lista de miembros actualesSi está vacía, revisa el match criteria
Policies > Security: hit count de la regla del DAGSube cuando el tráfico coincideSi no sube, la IP no está en el grupo o la regla está debajo de otra que permite
Monitor > Logs > Traffic filtrado por la IPSesiones negadas por la regla del DAGSi pasan, revisa el orden de las reglas
Monitor > Logs > SystemMensajes de tags registrados o expirados (según versión)Útil para ver cuándo salió la IP del grupo

Errores comunes

El DAG está vacío

  • Causa: ninguna IP tiene el tag, el nombre del tag no coincide exactamente (mayúsculas, comillas) o el criterio está mal escrito.
  • Revisa: show object registered-ip all y el Match del DAG.
  • Solución: corrige el nombre del tag o registra la IP.

La IP tiene el tag pero la regla no se aplica

  • Causa: la regla del DAG está por debajo de una regla Allow que coincide primero.
  • Solución: mueve la regla de bloqueo arriba.

La acción de Tagging por log no funciona

  • Causa: el Log Forwarding Profile no está aplicado a la regla que genera el log, el filtro no coincide con el log, o falta commit.
  • Revisa: Actions de la regla (Log Forwarding), y que el filtro del Match List coincida con los campos del log.
  • Solución: aplica el perfil a la regla correcta y verifica el filtro con un log real.

La API responde error

  • Causa: API key inválida o sin permiso, XML mal formado, o certificado no confiable (-k lo ignora en pruebas).
  • Solución: genera una nueva key, valida el XML y asegúrate de que la cuenta tenga el rol XML API con permiso de User-ID.

Los tags desaparecen

  • Causa: el timeout venció o el firewall se reinició.
  • Solución: usa un timeout adecuado, o que el sistema externo reenvíe los registros periódicamente. En HA, los registros se sincronizan al peer.

Quiero que un host quede aislado pero sigue accediendo

  • Causa: la regla de aislamiento solo cubre el origen; el tráfico entrante hacia ese host sigue permitido.
  • Solución: crea también una regla con el DAG como destino.

No puedo editar el miembro de un DAG a mano

  • Causa: los miembros son dinámicos por diseño.
  • Solución: cambia el tag del objeto o de la IP; no se agregan miembros directamente al grupo.