Security Policy Fundamentals

Resumen

La Security Policy es el conjunto de reglas que decide qué tráfico se permite y cuál se bloquea. En Palo Alto las reglas se basan en zonas (de dónde viene el tráfico y a dónde va), no en interfaces, y cada regla puede coincidir también por dirección IP, usuario, aplicación (App-ID), servicio/puerto y categoría de URL. Las reglas se evalúan de arriba a abajo y gana la primera que coincide.
El firewall es stateful: si permites el primer paquete de una conexión, la respuesta vuelve sola; no hay que crear una regla de regreso. Por defecto el tráfico dentro de una misma zona se permite (intrazone) y el tráfico entre zonas distintas se niega (interzone), así que para que algo cruce de una zona a otra siempre hace falta una regla explícita. Esta nota cubre cómo crear reglas, objetos, tags y logging, y cómo se comportan las reglas por defecto.

Requisitos previos

• Interfaces de capa 3 con IP, Virtual Router y zona asignada (ver L3 Interfaces, Subinterfaces y DHCP)
• Ruteo funcionando hacia los destinos (ver Static Routing y Path Monitoring)
• Zonas definidas (por ejemplo inside, dmz, outside)
• Saber qué tráfico quieres permitir: zona origen, zona destino, aplicación y direcciones
• Objetos de dirección creados si quieres reglas legibles (ver más abajo)

Conceptos clave

Concepto	Qué significa
Zona	Grupo de interfaces con el mismo nivel de confianza (inside, dmz, outside)
Rule Type: universal	La regla aplica a tráfico dentro de la misma zona y entre zonas distintas (es el valor por defecto)
Rule Type: intrazone	Solo origen y destino en la misma zona
Rule Type: interzone	Solo entre zonas distintas
intrazone-default	Regla por defecto: permite tráfico dentro de la zona; no registra logs
interzone-default	Regla por defecto: niega tráfico entre zonas; no registra logs
Stateful	Se permite el flujo inicial; la respuesta se asocia a la session sin otra regla
Application	Aplicación identificada por App-ID (ver App-ID y Policy Optimization)
Service application-default	Solo los puertos estándar de esa aplicación
Tag	Etiqueta con color para identificar y agrupar reglas, zonas y objetos

Acciones de una regla.

• Allow: permite el tráfico.
• Deny: bloquea usando la acción de denegación de la aplicación (para muchas aplicaciones es drop-reset, que envía un reset al cliente).
• Drop: descarta en silencio, sin respuesta.
• Reset client / Reset server / Reset both: descarta y envía un reset TCP a quien elijas.

Cuando adjuntas un perfil (antivirus, URL, WildFire, etc.) a una regla, la acción de la regla debe ser Allow: el perfil decide después qué bloquear.

Reglas por defecto. No aparecen en la lista hasta que las ves en Policies > Security. Se pueden modificar con Override, pero solo lo que permite la GUI (Tags, Action, Profile Setting y Log Setting; no Name, Rule Type ni Description). La práctica común es activar Log at Session End en interzone-default para ver lo que se está negando.

Una sola regla para ambas direcciones

No crees una regla de regreso por cada flujo. Por ser stateful, con una regla que permita el inicio de la conexión es suficiente. La excepción típica es el tráfico que inicia el otro lado, como la oferta del servidor DHCP en un Virtual Wire (ver Virtual Wire).

Configuración (Ejemplo, Lab PCNSA y Lab PCNSE)

1. Objetos de dirección

1. Objects > Addresses > Add.
2. Name Subnet 10, Type IP Netmask, 10.10.0.0/24. Repite con Subnet 20 (10.20.0.0/24) y Srvr Private IP (10.30.0.100/32).
3. Para agruparlos: Objects > Address Groups > Add > Name User Subnets, Type Static, y marca Subnet 10 y Subnet 20.

set address Subnet_10 ip-netmask 10.10.0.0/24
set address Subnet_20 ip-netmask 10.20.0.0/24
set address-group User_Subnets static [ Subnet_10 Subnet_20 ]

2. Tags de color

1. Objects > Tags > Add > Name inside, Color Green.
2. Repite con dmz (Yellow) y outside (Red).
3. Asígnalos a objetos: Objects > Addresses > (objeto) > Tags. A zonas y reglas: Policies > Security > (regla) > Tags. Las zonas con el mismo nombre del tag aparecen coloreadas en la tabla de reglas.

3. Crear una regla

1. Policies > Security > Add.
2. General: Name inside_to_outside, Rule Type universal.
3. Source: Source Zone inside, Source Address User Subnets.
4. Destination: Destination Zone outside, Destination Address any.
5. Application: any (o aplicaciones específicas). Service/URL Category: application-default.
6. Actions: Action Allow, Log at Session End marcado.
7. OK y Commit.

set rulebase security rules inside_to_outside from inside to outside source User_Subnets destination any application any service application-default action allow log-end yes
commit

4. Regla con aplicación y destino específico

Permitir navegación web de los usuarios hacia un servidor en la dmz:

1. Policies > Security > Add > Name web-browse in2dmz.
2. Source Zone inside, Source Address User Subnets; Destination Zone dmz, Destination Address Srvr Private IP.
3. Application > Add: web-browsing. Service: application-default. Action Allow.

set rulebase security rules web-browse_in2dmz from inside to dmz source User_Subnets destination Srvr_Private_IP application web-browsing service application-default action allow log-end yes

Para ping, crea otra regla igual con la aplicación ping.

5. Orden de las reglas

Se evalúan de arriba a abajo. Mueve una regla con Policies > Security > selecciona la regla > Move (Top, Up, Down, Bottom). Pon las reglas específicas arriba y las generales abajo; una regla de bloqueo (Deny) que quede debajo de una de permiso que cubre el mismo tráfico nunca se aplicará (rule shadowing).

6. Logging en las reglas por defecto

1. Policies > Security > selecciona interzone-default > Override.
2. Actions > marca Log at Session End > OK.
3. El ícono de engranaje rojo indica que la regla por defecto fue modificada.

set rulebase default-security-rules rules interzone-default log-end yes

7. External Dynamic Lists (EDL)

Una EDL es una lista de IPs, dominios o URLs que el firewall descarga de un servidor web. Actualizas la lista en el servidor y el firewall la usa sin cambiar la configuración.

1. Objects > External Dynamic Lists > Add.
2. Name, Type (IP List, Domain List, URL List o Predefined IP List), Source (URL del archivo) y Check for updates (Five Minute, Hourly, Daily, Weekly).
3. Úsala en la regla como Source Address o Destination Address (IP List), o en un perfil de URL Filtering (URL List).
4. Commit.

request system external-list refresh type ip name <nombre-de-la-lista>

Verificación

Comando o lugar	Qué debes ver	Si no lo ves
test security-policy-match from inside to dmz source 10.20.0.105 destination 10.30.0.100 protocol 6 destination-port 80 application web-browsing	El nombre de la regla que coincide y su acción	Si coincide otra regla, revisa el orden
show running security-policy	Las reglas activas en orden	Falta commit si no aparece
Policies > Security > columna Hit Count	Sube al generar tráfico que coincide	Si queda en 0, esa regla no está siendo usada
show running rule-use rule-base security type unused vsys vsys1	Reglas que nunca se han usado	Útil para limpiar políticas
Monitor > Logs > Traffic	Sesiones con la regla, zona, aplicación y acción	Si no hay logs, mira “Errores comunes”
show session all filter source 10.20.0.105	La session activa con regla y estado	Si no hay session, el tráfico no llegó o fue bloqueado antes
Monitor > Logs > Traffic con ( rule eq 'interzone-default' )	Lo que se está negando por defecto	Requiere Log at Session End en esa regla

Errores comunes

El tráfico entre zonas no pasa

• Causa: no hay regla que lo permita; aplica interzone-default (deny).
• Revisa: test security-policy-match con el origen, destino, puerto y aplicación; y los logs con el filtro interzone-default.
• Solución: crea una regla con las zonas correctas y Allow, y haz commit.

Creé la regla pero la aplicación no funciona

• Causa: la aplicación que permitiste depende de otra (por ejemplo ssl o web-browsing) y esa no está permitida; o el servicio no es application-default y el puerto no coincide.
• Revisa: Monitor > Logs > Traffic y la aplicación que aparece.
• Solución: agrega las aplicaciones dependientes (ver App-ID y Policy Optimization).

Una regla de bloqueo no hace efecto

• Causa: una regla Allow más arriba cubre el mismo tráfico (rule shadowing).
• Revisa: el resultado del commit, pestaña Rule Shadow, y el orden.
• Solución: mueve la regla de bloqueo por encima de la de permiso.

No veo logs

• Causa: Log at Session End desactivado, la sesión no ha terminado, o el tráfico coincide con una regla por defecto sin logging.
• Solución: activa el logging en la regla correcta (ver Logging, Monitoring y SIEM).

Cambié una regla y el tráfico existente sigue pasando

• Causa: Rematch Sessions está desactivado en Device > Setup > Session > Session Settings (por defecto está activado), o el cambio fue en NAT, que no se reevalúa en sessions existentes.
• Solución: activa Rematch Sessions o ejecuta clear session all filter source <ip>.

La regla no coincide en un Destination NAT

• Causa: usaste la zona o IP incorrectas. En Security Policy, la zona destino es la zona real del servidor (post-NAT) y la IP destino es la pública original (pre-NAT).
• Solución: corrígelo siguiendo Destination NAT.

Una regla tiene Deny, pero con perfiles adjuntos no hace nada

• Causa: los perfiles se aplican solo cuando la acción es Allow.
• Solución: usa Allow en la regla y deja que el perfil bloquee.

Hay demasiadas reglas any y no sé qué se usa

• Causa: reglas amplias sin revisar.
• Solución: usa Hit Count y Policy Optimizer (ver App-ID y Policy Optimization) para reducir permisos a lo necesario.

Regla de acceso desde Internet a un servidor demasiado permisiva

• Causa: se permitió any aplicación o todos los puertos.
• Solución: permite solo lo necesario (la aplicación y la IP pública del servidor), con los perfiles de seguridad aplicados.