Mostrando entradas con la etiqueta firewalls. Mostrar todas las entradas
Mostrando entradas con la etiqueta firewalls. Mostrar todas las entradas

lunes, 9 de abril de 2012

VACLs: Filtrando tráfico a nivel 2

Alguna vez, resolviendo algún problema de conectividad en una red, en la que pasa lo típico de que un servidor no puede llegar a un sitio, pero si puede llegar a otro, aparece la típica persona de sistemas muy ajena al mundo de las redes y dice, "La culpa es del firewall, nos estais capando", entonces es cuando me toca decir la típica cosa que no es 100% cierta, pero que permite seguir resolviendo la incidencia sin buscar fantasmas.

¿Cual es esa mentijilla piadosa? 
Que los firewalls filtran tráfico entre equipos de diferentes vlanes, que no es posible filtrar tráfico de equipos en la misma VLAN. Es una mentirijilla porque existen firewalls transparentes, y porque si se puede filtrar a nivel de VLAN con VACL, pero me ha tocado decir esa mentirijilla varias veces en entornos que no usaban VACL, ni Firewalls en modo bridge.

¿Que es una VACL?
VACL simplemente es una ACL a nivel de vlan, permite filtrar el tráfico que pasa por una VLAN a nivel 2.

¿Que equipos permiten usar VACL?
Switches y routers basados en Asics, osea en switches y routers nuevecillos, por tanto lo de intentar probarlo en GNS3 va a ser que no.  :(

¿Como se configuran?
Primero se configura una ACL para seleccionar el trafico que queremos seleccionar, al estilo de un route-map.
ip access-list extended NO_NETBIOS
permit ip any any eq 139
Luego configuramos el vlan access-map.


vlan access-map filtro_NETBIOS_VLAN_100 10 
match ip address NO_NETBIOS <----seleccionamos el netbios y lo filtramos
 action drop
 vlan access-map filtro_NETBIOS_VLAN_100 20
  action forward<----el resto de tráfico sigue pasando sin problema

Y por último asignamos el filtro a las vlans que nos apetezca.

vlan filter filtro_NETBIOS_VLAN_100 vlan-list 100

Para los que sean un poco curiosos, se pueden hacer mas cosas con VACL, como por ejemplo denegar tráficos en base a la MAC, o incluso interferir en spanning tree filtrando BPDUs...etc, cuidado con esto último o podeis crear una tormenta de broadcast. :D


lunes, 13 de febrero de 2012

TCP Intercept:


TCP Intercept es una tecnología que permite interceptar las sesiones con origen o destino de un flujo(una ACL), estableciendose la sesión contra el router, que será el intermediario de la sesión.

Se usa particularmente para ataques de SYN flood, y en general para ataques de denegación de servicio basados en sesiones.


Tiene un monton de opciones a configurar, tiempo de inactividad, numero de conexiones con syn pero sin ACK...etc.



access-list 146 permit ip any 155.1.146.0 0.0.0.255  <---el trafico que interceptas
ip tcp intercept list 146 
ip tcp intercept connection-timeout 30 <----inactividad


lunes, 6 de febrero de 2012

Filtrado a nivel 7 con NBAR


NBAR es una tecnología que permite el reconocimiento de aplicaciones y protocolos a nivel de aplicación, sin trabajar tan solo a nivel de puerto como hace un firewall, lo que permite NBAR, es leer a nivel de cabeceras html...etc

Una funcionalidad de seguridad que se le puede dar a NBAR es descartar los paquetes de los protocolos no permitidos.

En este ejemplo vamos a descartar los paquetes de bittorrent, da igual que cambie de puerto el bittorrent, NBAR se basa en patrones de tráfico a nivel de aplicación, y descartará el tráfico.

Ejemplo:


class-map match-all TORRENTE
   match protocol bittorrent
policy-map ELIMINAR
  class TORRENTE
   drop
 
int fa0/0
    service-policy output ELIMINAR


Lo malo que tienen todo este tipo de trabajos de inspección a nivel 7, es que incurre en una mayor carga de trabajo para el router. Cosa aplicable a cualquier tecnología de este tipo, por lo que se recomienda hacerlo en equipos que no están demasiado justos de CPU y memoria.




lunes, 30 de enero de 2012

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.


lunes, 23 de enero de 2012

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.


lunes, 16 de enero de 2012

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. 

lunes, 9 de enero de 2012

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.





lunes, 2 de enero de 2012

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.

lunes, 26 de diciembre de 2011

Access list para ver si el tráfico está pasando


Una funcionalidad muy útil que se puede sacar a las accesss-list es la de comprobar si algún tráfico está atravesando el router, es algo parecido a activar un tcpdump en una maquina unix, pero bastante mas rudimentario.

Simplemente consiste en crear una access list en la que configurarmos un permit para el tipo de tráfico que estamos esperando encontrar, junto con la clausula log, y una segunda linea que ponga permit ip any. Lo que conseguimos con esto es, que si el tráfico que estamos buscando pasa por el router nos lo muestre en el log, pero en ningún caso vamos a cortar tráfico.



La verdad es que así contado quizá no se entienda bien, pero vamos a poner un ejemplo en el que se ve bastante claro.


access-list 10 permit 192.168.1.1 log <--- si entra tráfico de este origen meteme una entrada en el log y déjalo pasar
access-list 10 permit any <--- deja pasar el tráfico restante

Si hacemos un show access list vemos que el tráfico de la 192.168.1.1 está atravesando el router.
 Router#show access-lists 10
Standard IP access list 10
    10 permit 192.168.1.1 log(40 matches)
<----40 paquetes de origen 192.168.1.1 
    20 permit any(149407 matches) <---- el resto de paquetes viene de otros orígenes

Lo bueno que tiene esta práctica es que no tiene en principio impacto sobre el tráfico, ya que en realidad todo el tráfico está permitido. La cagada puede ser que se te olvide poner el permit any, pero bueno, son cosas que pasan :D .

Sobre el impacto en el router, para dispositivos con tarjetería con algo de inteligencia es nulo, ya que el router trabaja con las ACL a nivel de hardware. Para plataformas de routers de gama baja puede tener algo de impacto en la CPU del router, y si tienes la CPU al 98% no sería una buena idea aplicarlo, aunque claro, en un router con una CPU a ese nivel nada que no sea un upgrade de dispositivo es una buena idea.

Aquí os detallo una serie de links a otros artículos sobre ACL.


lunes, 19 de diciembre de 2011

Access list Standard y extendidas: Filtrando en un router/firewall cisco

Las ACL son posiblemente el mecanismo mas sencillo para filtrar tráfico del que disponemos en un equipo de red.

Este es el primero de una serie de artículos en los que se tratarán los diversos tipos de ACL, desde los tipos mas sencillos, hasta funciones mas avanzadas.

Una ACL simplemente es un filtro en el que se especificará una lista del tráfico que se deja pasar y se deniega en una serie de tarjetas. 



A la hora de crear access list lo primero que debemos tener en cuenta es, que tan solo se puede especificar una access list para entrada, y otra para salida en la misma interfaz, el numero de lineas de la ACL es ilimitado. De la mano de esto podemos decir que una misma ACL se puede aplicar a múltiples interfaces, no hace falta crear una ACL por interfaz.

También hay que tener en cuenta que las ACL se evalúan de manera secuencial, si un tráfico esta afectado por un permit o un deny en una ACL en la linea número 1, no seguirá leyendo la ACL, el tráficos será denegado o permitido. Por ello es importante en las ACL establecer las sentencias mas específicas al inicio de la ACL, y las secuencias mas generales al final de la ACL, sin olvidar que por defecto toda ACL lleva implícito un deniega todo el tráfico en la última linea.

Las máscaras que se utilizan en las ACL son máscaras de Wildcard, que son inversas a las máscaras de red, para leer un poco sobre wildcard dejo este enlace.

Por último, las listas de acceso están identificadas con un número de lista de acceso, según el número de  la lista, esta lista será de un tipo u otro, a continuación la tabla de rangos disponibles para cada tipo de ACL:

1 99 IP standard access lists
100 199 IP extended access lists
200 299 Protocol type-code access lists
300 399 DECnet standard access lists
400 499 XNS standard access lists
500 599 XNS extended access lists
600 699 AppleTalk cable range access lists
700 799 MAC address access lists
800 899 Novell IPX standard access lists
900 999 Novell IPX extended access lists
1000 1099 Novell IPX SAP access lists
1100 1199 MAC address access lists (extended range)
1200 1299 Novell IPX NLSP access lists
1300 1999 IP standard access lists (extended range)
2000 2699 IP extended access lists (extended range)

En este artículo en concreto vamos a tratar dos tipos de ACL , la standard y las extendidas, que son las identificadas por los dos primeros rangos, con el tiempo se añadieron los dos últimos rango ya que a veces podemos necesitar mas de 100 listas de acceso diferentes en un equipo.

Listas de acceso standard:

Las listas de acceso standard permiten filtrar el tráfico en función del origen del paquete.

access-list <Numero_de_ACL> <deny/permit> <red_origen> <mascara_origen>
Numero de ACL: Es el número que identifica a la ACL, y todas las lineas de ACL que incluyan ese número formaran parte de la ACL.

Permit/deny: como os podeis imaginar es si queremos dejar pasar el tráfico o lo queremos filtrar.

Red origen y mascará de origen: El tráfico que queremos filtar. Se puede utilizar la sentencia host si solo queremos afectar a una única IP, como veremos en el siguiente ejemplo.

access-list 10 permit host 192.168.1.1
access-list 10 deny 192.168.1.0 0.0.0.255
access-list 10 permit any

En este ejemplo permitiríamos el tráfico con origen de la ip 192.168.1.1, pero denegaríamos el de toda la subred a la que pertenece la 192.168.1.1. El resto del tráfico estaría permitido.

Para aplicar la access list a una interfaz:

router(config)# int fast0/0
router(config-if)#ip access-group 10 <in/out>
Listas de acceso extended:

Las listas de acceso extendidas son parecidas a las standard, pero permiten elegir origen, destino, puerto y protocolo, en el fondo los firewalls tradicionales se componen de listas de acceso extendidas, teniendo en cuenta las nuevas opciones de las ACL extendidas su funcionamiento es mayormente igual al de las listas de acceso standard.

access-list <Numero_ACL> <deny/permit>  <protocolo> <red_origen> <mascara_destino> <red_origen> <mascara_destino> <eq/gt/lt> <numero puerto>
Protocolo permite seleccionar el tipo de protocolo que queremos usar, ya sea tcp, udp, icmp...etc. Para seleccionar todos usaremos ip como protocolo.

Red de destino y máscara su nombre lo indica, en ellos también podemos especificar la sentencia host, o la sentencia any.

eq/gt/lt: Eq se utilizará para decir que un puerto igual a x. gt que el puerto sea mayor a x , y por último lt   para especifcar que puertos sea menor a x.

Ejemplo:

interface Ethernet0/1
ip address 172.16.1.2 255.255.255.0
ip access-group 101 in
access-list 101 deny icmp any 10.1.1.0 0.0.0.255
access-list 101 permit ip any 10.1.1.0 0.0.0.255
Un último dato importante para TODAS las ACL es, que el tráfico con origen desde el propio router nunca es evaluado en las ACL, las ACL solo funcionan cuando el tráfico entra al router y sale del router, NUNCA para el tráfico originado desde el propio router.

Comandos relacionados:

show access-list