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 tagquarantiney una regla que bloquea el DAGquarantinelo 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
quarantineoservidores-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
| Concepto | Qué es |
|---|---|
| Tag | Etiqueta con nombre (y color opcional) que se asigna a objetos, reglas, zonas o IPs |
| Static tag | Tag 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 Group | Grupo de direcciones cuyos miembros son las IPs (o objetos) que cumplen una condición de tags |
| Match criteria | Expresión con and / or entre tags (por ejemplo 'quarantine' or 'infectado') |
| Timeout | Tiempo 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
- Objects > Tags > Add > Name
quarantine, Color (ej.Red). - OK.
2. Crear el Dynamic Address Group
- Objects > Address Groups > Add.
- Name
Cuarentena, TypeDynamic. - Match: pulsa Add Match Criteria y elige
quarantine(puedes combinar tags conand/or). - OK.
set address-group Cuarentena dynamic filter "'quarantine'"
3. Usar el DAG en una regla
- Policies > Security > Add > Name
Bloquear cuarentena. - Source: Source Zone
inside, Source AddressCuarentena(o en Destination, según el caso). - Destination: Destination Zone
any. - Actions: Action
Deny. - Colócala arriba de las reglas de permiso.
- 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)
- Objects > Log Forwarding > Add (o edita el existente).
- Match List > Add: Name
threat-tag, Log Typethreat, Filter por ejemplo( severity geq high ). - Built-in Actions > Add: Name
tag-source, ActionTagging, TargetSource Address, ActionsAdd Tag, RegistrationLocal User-ID, Timeout60minutos, Tagsquarantine. - En la regla de Security Policy que permite ese tráfico: Actions > Log Forwarding: este perfil.
- Commit.
5. Asignar tags con la API XML
- Obtén una API key:
https://<IP-firewall>/api/?type=keygen&user=<usuario>&password=<contraseña>(guarda la key). - 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>'
- Para quitarlo, usa
<unregister>en vez de<register>con la misma estructura.
6. Tag directo en un objeto de dirección (estático)
- Objects > Addresses > Add (o edita) > Tags: elige el tag.
- 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 lugar | Qué debes ver | Si no lo ves |
|---|---|---|
show object registered-ip all | Las IPs registradas con sus tags | Si no aparece, el registro no llegó (API, log forwarding) |
show object registered-ip tag "quarantine" | Solo las IPs con ese tag | Compara el nombre del tag exacto |
Objects > Address Groups > fila del DAG > enlace more... en Addresses | La lista de miembros actuales | Si está vacía, revisa el match criteria |
| Policies > Security: hit count de la regla del DAG | Sube cuando el tráfico coincide | Si no sube, la IP no está en el grupo o la regla está debajo de otra que permite |
| Monitor > Logs > Traffic filtrado por la IP | Sesiones negadas por la regla del DAG | Si pasan, revisa el orden de las reglas |
| Monitor > Logs > System | Mensajes 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 ally 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 (
-klo 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.