CCNP/JNCIS EN ESPAÑOL: 10: Firewall Filters

Firewall Filter es lo que Cisco llama access list (ACL). Estos filtros se tienen que poner tanto en entrada como en salida (stateless) ya que no traza las sesiones tcp.

Se suelen usar para permitir o denegar tráfico.

Se configuran como las routing policy, con term, from y then:

- Si todas las condiciones se cumplen, se ejecuta la acción

- Si no hay ninguna condición en from todas las rutas se seleccionan

Opciones de from. Si no hay from, se selecciona todo el tráfico

Un firewall filter siempre llevará un term por defecto que ejecutará la acción de descartar (discard)

Cuando encuentra un then con una "terminating action" (accept, discard o reject) ejecuta y no sigue leyendo.

Podemos configurar una "terminating action" o un "flow control" (next term) que nos permite pasar al siguiente term. También podemos configurar un policer que llamaría a otra policy. Otra opción son class-forwarding y loss-priority que se utilizan para las clases de servicio (CoS).

Si configuramos un "action modifier" pero no definimos un "terminating action", el tráfico se acepta.

Si aplicamos un filtro de firewall y no especificamos ningún tráfico en ningún term, se descartará.

Para configurar un filtro de firewall:

1. Lo definimos

2. Aplicamos el filtro en la interface

Es de gran utilidad utilizar el comando commit confirmed para evitar que los cambios aplicados en el filtro de firewall nos dejen sin conexión.

Configuraremos filtros en el laboratorio JNCIA.

POLICING

Policing sirve para limitar la cantidad de tráfico que entra o sale de una interface. En el from podemos especificar protocolos, rutas, puertos.

Este filtro se aplica en las interfaces (units) o en los protocolos.

Para configurar el policing limitamos dos objetos:

- Bandwidth-Limit: ancho de banda en bits por segundo

- Burst-Size-Limit: límite del tamaño de ráfaga en bytes por segundo

Para calcular el Burst Size Limit usamos la siguiente fórmula:

Burst Size = ancho de banda X tiempo permitido de ráfaga en milisegundos

El resultado lo dividimos entre 8 para que nos salga en bytes.

Ejemplo:

Queremos configurar una ráfaga de 5 milisegundos en una interface Ethernet:

Ethernet: 10.000.000 bps

Burst: 5/1000 segundos

El resultado es de 6250 bytes.

Configuraremos un policing en el laboratorio JNCIA.

uRPF (Universe Reverse Path-Forwarding)

Esta opción de Junos OS sirve para validar el tráfico que entra en las interfaces es de un origen especifico permitido y el next hop que nos lo envía es el correcto (antispoofing).

Tenemos dos modos:

- Strict - Por defecto. Chequea origen y next hop válidos

- Loose - Chequea solo origen válido

URPF chequea por defecto solo las rutas activas, por lo que en escenario con más de una ruta hacia origen-destino con peso asimétrico (con mismo peso debería funcionar bien), puede causar problemas. Para evitarlo usamos el atributo feasible-paths.

Se puede configurar en cualquier equipo pero lo común es habilitarlo en todas las interfaces del router frontera, el que se conecta a Internet.

Cuando un paquete falla el chequeo de uRPF se descarta por defecto. Este comportamiento lo podemos modificar. Son los llamados Fail-Filters. Son especialmente útiles para permitir el tráfico DHCP o BOOTP. Estos protocolo lanzan un broadcast con origen 0.0.0.0 y destino 255.255.255.255. Esto hay que permitirlo porque si no, el uRPF descartará el tráfico.

Para configurar uRPF:

#set routing-options forwarding-table unicast-reverse-path active-path -> strict mode

#set routing-options forwarding-table unicast-reverse-path feasible-path -> loose mode

#set interface X family inet rpf-check

Ejemplo de uRPF con Fail Filter para DHCP: