URPF: Unicast Reverse Path Forwarding

Unicast Reverse Path Forwarding, consiste en un mecanismo por el cual se comprueba que la interfaz por la que se recibe unos paquetes sea la interfaz por la que según la tabla de rutas puedo alcanzar esa red. En caso contrario deniego los paquetes.

Esto sirve para evitar ataques basados en spoofing, según los cuales recibo peticiones para que responda a una red interna, y me dedico a “bombardear” esa red interna, sin comprobar que los paquetes no me estan viniendo desde dentro.

Como se puede ver en el gráfico, un router tiene varias LAN consideradas internas, y una conexión a intenet, desde internet se lanzan paquetes contra el router con una dirección ip de destino 10.0.0.33, y con dirección de origen 192.168.1.34. El caso es que según los filtros del router/firewall el tráfico entre esas dos redes esta permitido, por lo que los paquetes pasan, y el resultao de todo esto es que los equipos de la LAN 1, y la LAN 2 estarán constantemente mandándose paquetes de SYN ACK y RESET con el correspondiente aumento de CPU, que llegado el caso puede causar una denegación de servicio.

En el segundo gráfico el router/firewall usa URPF, y como el tráfico viene de un origen que no corresponde a lo que tenemos en la tabla de rutas se deniega el tráfico.

Router(config-if)#ip verify unicast source reachable-via rx <----configura uRPF en una interfaz

Si además quiero que me guarde en el log los paquetes denegados, debería hacer una ACL con log y asignarla al uRPF.

access-list 127 deny ip any any log
Router(config-if)#ip verify unicast source reachable-via rx 127 <---- El 127 es la ACL de arriba

La parte "mala" de URPF es que no permite tráficos asimétricos, por lo que si las tablas de routing de los equipos no coinciden para la ida y la vuelta del tráfico, es posible que haya tráfico que se deniegue.

Filtrando tráfico con route maps

Quizá el filtrado de tráfico como si fuese una ACL no sea uno de los usos mas habituales para los route maps, pero es que hay que reconocer que los route maps sirven para todo.

El método consiste en crear una ACL ¿WTF? Si, utilidad real tampoco hay mucha, pero estas son las cosas raras que te toca pensar cuando te enfrentas a un examen como el CCIE. Repetimos, creas una ACL en la que estableces el tráfico que quieres descartar, y esa ACL se la pones como clausula match para el route-map, luego como clausula set del route map redireccionas el tráfico a Null0, y aquí paz y después gloria. Probablemente sea un recurso que no vas a usar en tu vida, pero bueno, cosas que pasan .

Este ejemplo es facil, todo el tráfico udp que entra o sale por la interfaz queda denegado, ya que se envía a NULL0.

ip access-list extended NO_QUIERO_UDP
    permit udp any any
 
route-map UDP_TRASH permit 10
 match ip address NO_QUIERO_UDP
 set interface Null0
interface FastEthernet 0/0
  ip policy route-map UDP_TRASH

Ojo, existe una posible pifia que he visto cometer, y es que como en los route maps que se aplican en BGP hay que añadir una sentencia permit x para que el resto de rutas se anuncien, en ocasiones cuando los route maps se usan para filtrar, o para PBR se añade esta sentencia, que no es necesaria, ni tampoco recomendada. Si añadimos una sentencia route map UDP_TRASH 20 permit,  lo que pasaría es que todo el tráfico de la interfaz fa0/0 subiría a procesadora, y en caso de los equipos grandes como un 7600/6500 no estaríamos aprovechando la funcionalidad que ofrece la tarjeta. El efecto práctico sería una subida enorme del consumo de CPU como esa tarjeta tenga bastante tráfico.

Access list dinámicas: Lock and Key ACL

Las ACL Dinámicas, también conocidas como Lock and Key ACL son ACL que solo permiten el paso de tráfico una vez que el usuarios se ha autenticado. Para autenticarse el usuario deberá hacer un telnet al router, se le facilitará usuario y contraseña, y si se autentica correctamente a partir de ese momento, y con un timeout establecido, podrá acojerse a las cláusulas permit de la ACL, en caso contrario no podrá cursar tráfico.

Un ejemplo vale mas que mil palabras:

username HOMER password SIMPSON <-----Creamos un usuario local, que será el que luego utilizaremos para conectarnos por telnet al router

line vty 0 4
    login local <----¿No te apetece probar esto mismo con un TACACS+? Pronto un articulo sore autenticación con TACACS+
    autocommand access-enable host timeout 10 <----Timeout del telnet

Una vez creado el acceso por telnet, la siguiente parte es crear la ACL dinámica. La primera linea, que pueden ser todas las que se quieran, mientras que lleven dynamic, y la lista de acceso dinámica que queremos que se cree, es lo que se le va a aplicar a los usuarios una vez autenticados por telnet.

La segunda linea de la ACL es una linea “normal”, y sirve para permitir el acceso por telnet a nuestro router, para que la gente se pueda autenticar.

access-list 110 dynamic DINAMICA timeout 10 permit ip any any  <-----Lo que se aplica a los usuarios ya conectados
access-list 110 permit tcp any host 1.1.1.1 eq telnet <-----Permitimos que los usuarios se conecten por telnet, sino va a ser complicado :D

Un ejemplo que ponen en la propia web de cisco:

This is a basic example of lock and key.

username test password 0 test 
!--- Ten (minutes) is the idle timeout.username test autocommand access-enable host timeout 10 


interface Ethernet0/0 
  ip address 10.1.1.1 255.255.255.0 
  ip access-group 101 in 

access-list 101 permit tcp any host 10.1.1.1 eq telnet !--- 15 (minutes) is the absolute timeout.access-list 101 dynamic testlist timeout 15 permit ip 10.1.1.0 0.0.0.255        
172.16.1.0 0.0.0.255


line vty 0 4  

login local 


El link a las access list dinámicas de la pagina de Cisco. 

Reflexive access list

Las ACL reflexivas son un concepto de ACL que permiten que todo tráfico de vuelta a un tráfico que fué originado en el interior sea permitido. No se trata del caso de established, que busca simplemente un bit ACK en los paquetes, las ACL reflexivas mantienen en memoria una tabla con las conexiones originadas desde el interior, y cuando entra al router tráfico de vuelta se compara con esa tabla, si concuerda se permite el tráfico, y si no concuerda se deniega el tráfico. Una cosa importante a tener en cuenta sobre las ACL reflexivas es el hecho de que no hace falta que sea tráfico TCP, son capaces de mantener en memoria “sesiones” de tráfico UDP, ICMP...

Estas ACL siempre deben ser configuradas como ACL extendidas con nombre.

Para configurarlas hay que configurar dos ACL, pero en realidad es como si se creasen tres:

• Una ACL de salida, en la que permitirás todo lo que quieres que salga, y lo reflectamos contra la ACL que va a mantener en memoria la sesión pemitida, en este caso vamos a nuestra ACL de salida la vamos a llamar SALIDA, vamos a permitir todo el tráfico desde un host hacia fuera, y lo vamos a reflectar contra una ACL llamada ESPEJO.

ip access-list extended SALIDA
    permit ip host 192.168.1.2 any reflect ESPEJO

• Una ACL de entrada, en la cual a parte de lo que se quiera permitir específicamente como en una ACL normal, se añadirá una cláusula evaluate, con el nombre de la ACL donde se reflectaban las peticiones de salida, y si el tráfico es de vuelta a una conexión originada desde el interior, el tráfico se permitirá. En nuestro ejemplo simplemente pondremos evaluate ESPEJO.

ip access-list extended ENTRADA
   evaluate ESPEJO 

• La ACL ESPEJO es generada dinámicamente, y se puede consultar haciendo un show ip access-list ESPEJO, donde se nos mostraría lo que esta permitido en estos momentos.

show ip access-list ESPEJO

Aquí podemos ver un ejemplo de la propia página de cisco, para el tema de reflexive ACL;

This is an example of the permit of ICMP outbound and inbound traffic, while only permitting TCP traffic that has initiated from inside, other traffic is denied.

ip reflexive-list timeout 120 
    
interface Ethernet0/1
 ip address 172.16.1.2 255.255.255.0
 ip access-group inboundfilters in
 ip access-group outboundfilters out 

ip access-list extended inboundfilters
permit icmp 172.16.1.0 0.0.0.255 10.1.1.0 0.0.0.255
evaluate tcptraffic !--- This ties the reflexive ACL part of the outboundfilters ACL,
!--- called tcptraffic, to the inboundfilters ACL.ip access-list extended outboundfilters
permit icmp 10.1.1.0 0.0.0.255 172.16.1.0 0.0.0.255 
permit tcp 10.1.1.0 0.0.0.255 172.16.1.0 0.0.0.255 reflect tcptraffic

Link a la guia de configuración de ACL de cisco.

Access list established: Haciendo tu vida un poco mas facil

Una cosa que se puede configurar en las listas de acceso extendidas y que resulta muy útil, es las listas de acceso con clausula established. Cuando se añade una linea a la lista de acceso, y lleva al final la palabra established, los paquetes de vuelta de la sesión quedan permitidos automáticamente siempre y cuando vengan marcados con el bit ACK.

Pongamos un ejemplo:

access-list 120 permit tcp host 192.168.1.1 any established
access-list 120 deny ip any any

Esta lista de acceso la configuramos de salida en una interfaz, permitiría las conexiones TCP desde la 192.168.1.1 con destino a cualquier sitio, y los paquetes que respondan a una conversación TCP originada por el host 192.168.1.1, sin embargo, si la conexión se intenta comenzar desde fuera, el tráfico estaría denegado.

Algo importante a tener en cuenta es que realmente no se realiza trabajo de deep packet inspection respecto a la conversación TCP, con lo que en principio nos evitamos los problemas de los firewall de capa 7, y por el lado negativo tampoco estamos haciendo inspección de paquetes.