Análisis del impacto del zone protection en enlaces con PBF en un firewall Palo Alto

Fecha: 10 de marzo del 2022

Escenario

Este es mi primer laboratorio con equipos Palo Alto, lo hice con este equipo ya que encontré esta curiosidad y/o

comportamiento particular en esta marca y decidí agregarla a mi colección de cosas raras.

Durante una implementación de varios enlaces de internet, se determinó que los enlaces pertenecientes a la zona

Outside (manera de trabajar similar a los firewalls por zonas basados en IOS (ZBF) que vimos en CCNA Security)

no traficaban por algún motivo.

El equipo esta confirgurado sin activarle la función ECMP (Equal Cost Multiple Path) para balanceo de carga y

múltiples rutas por defecto para dos enlaces, o sea, dos enlaces pero una sola ruta por defecto en ISP-1, y el otro

enlace con un PBF y un next-hop a la IP del router de ISP-2.

Los firewalls Palo Alto, al igual que los routers convertidos en ZBF, manejan el concepto de zonas, cada zona es

una agrupación de interfaces y politicas diferentes y deben crearse ciertos conectores o reglas para permitr el

tráfico entre una zona u otra, de lo contrario el tráfico entre zonas se deniega.

Inicialmente ambos ISP se encontraban en una única zona, pero al no poder activar el ZPP (Zone Protection Profile)

se separan en dos zonas difrentes para dejar una a protegida con ZPP (la que tiene la default route) y ver opciones

en la otra zona con ISP-2.

1.- Verificación inicial:

Podemos ver en esta sesión saliente que queda como incomplete, o sea que no termina de cerrar el saludo de

3 vias TCP al no poder verificar el origen cuando llega el tráfico de retorno y se inspecciona en el ZPP.

Incomplete in the application field:

Incomplete means that either the three-way TCP handshake did not complete OR the three-way TCP handshake

did complete but there was no enough data after the handshake to identify the application. In other words that traffic

being seen is not really an application.

One example is, if a client sends a server a SYN and the Palo Alto Networks device creates a session for that SYN,

but the server never sends a SYN ACK back to the client, then that session is incomplete.

Fuente: https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClibCAC

2.- Análisis:

El zone-protection profile (una función anti spoofing, anti port scan, anti DoS, etc...) no puede identificar el origen

del tráfico basado en reverse path forwarding (RPF) o sea que busca el origen (de la IP de origen) con una ruta,

aunque sea la ruta por defecto, de lo contrario dropea todo tráfico entrante o de retorno.

Se probó desactivando los posibles causales de la denegación pero sin exito.

Spoofed IP address:

Check that the source IP address of the ingress packet is routable and the routing interface is in the same

zone as the ingress interface. If either condition is not true, discard the packet.

Strict IP Address Check:

Check that both conditions are true:

- The source IP address is not the subnet broadcast IP address of the ingress interface.

- The source IP address is routable over the exact ingress interface.

- If either condition is not true, discard the packet.

Fuente: Palo Alto.com

4.- PBF policies:

Se evalúan las condiciones tales como IP source / destination, protocol / port, y se reenvían al next-hop

tal como se haría con una ACL y route-map en Cisco.

4.1.- Para ISP-1:

4.2.- Para ISP-2:

5.- Solución:

En Palo Alto puede habilitar ECMP para utilzar balanceo de rutas y varias rutas por defecto (esto pide un

reinicio del VR y corta el tráfico de firewall), con esto se pueden utilizar los zone-protection con el reverse

path forwarding ya que ahora existen rutas.

Luego se pueden crear políticas de PBF para forzar la salida por un enlace particular aunque exista la ruta,

ya que el PBF saltea la tabla de enrutamiento, solo estaría por el RPF.

(2022) Your route is my route...

Rosario, Argentina