Access list extendidas:

Este artículo forma parte de una serie de varios artículos que tratan distintas tecnologías de seguridad en routers y switches para CCNA R&S, para ir al índice del curso tienes este link:

http://networkkings-es.blogspot.com.es/2013/07/curso-gratuito-ccna-200-120.html
 

Access list extendidas:

Se aplica todo lo que hemos visto para las listas de acceso standard, pero si antes teníamos unas ACL que filtraban el tráfico en base a la IP de origen de los paquetes ahora fitramos en base a:

• IP/red_origen
• IP/red_destino
• Protocolo(TCP/UDP/ICMP...)
• Puerto origen
• Puerto destino

Como os podéis imaginar, con las ACLextendidas si se puede filtrar dignamente, en realidad las ACL  standard son utilizadas para otros propósitos, aunque en un origen eran para filtrar tráfico.

Configuración:

access-list <100-199> permit <protocolo> <red_origen> <wildcard_origen> <eq/lt/gt> <puerto_origen> <red_destino> <wildcard_destino> <eq/lt/gt> <puerto_destino>

Es la misma idea que con las ACL estandar, pero se usa la numeración del 100 al 199, y tenemos que poner el orígen y el destino de los paquetes. Aquí también podemos filtrar a nivel de puerto, tanto de origen como de destino.

• <eq/lt/gt>: Eq significa que el puerto sea igual a, y un numero de puerto. Lt significa que el puerto sea menor a, y gt significa que el número de puerto sea mayor que.

Modificar ACL extendida:

R(config)#ip access-list extended<numero_ACL>

R(config-std-nacl)#<Numero_secuencia> <deny/permit> <red_origen> <wildcard_origen> <puerto> <red_destino> <wildcard_destino>

Protocolos soportados:

  ahp           Authentication Header Protocol
  eigrp         Cisco's EIGRP routing protocol
  esp           Encapsulation Security Payload
  gre           Cisco's GRE tunneling
  icmp          Internet Control Message Protocol
  igmp          Internet Gateway Message Protocol
  ip            Any Internet Protocol
  ipinip        IP in IP tunneling
  nos           KA9Q NOS compatible IP over IP tunneling
  ospf          OSPF routing protocol
  pcp           Payload Compression Protocol
  pim           Protocol Independent Multicast
  tcp           Transmission Control Protocol
  udp           User Datagram Protocol

El funcionamiento por lo demás es el mismo que el de las ACL standard.

Ejemplo:

  access-list 101 permit tcp host 192.168.1.1 host 80.80.80.80 eq 23
  access-list 101 permit tcp host 192.168.2.1 host 80.80.80.80 eq 23

Rack1R2(config)#do show ip access 101
Extended IP access list 101
    10 permit tcp host 192.168.1.1 host 80.80.80.80 eq telnet
    20 permit tcp host 192.168.2.1 host 80.80.80.80 eq telnet

Access list standard:

Este artículo forma parte de una serie de varios artículos que tratan distintas tecnologías de seguridad en routers y switches para CCNA R&S, para ir al índice del curso tienes este link:

http://networkkings-es.blogspot.com.es/2013/07/curso-gratuito-ccna-200-120.html

 

Access list standard:

Las access list o ACL son un mecanismo que permite controlar el tráfico que entra o sale por una interfaz. Su funcionamiento es algo bastante sencillo, simplemente se crea una lista con el tráfico que se quiere permitir dejar pasar, y con el tráfico que no se quiere dejar pasar.

Las access list se leen secuencialmente, y cuando un paquete cumple con una linea de una access list, la access list no se sigue leyendo para ese paquete, por ello es extremadamente importante el orden en el que se meten las entradas en una access list, así como asignar números de secuencia correctamente en las ACL.

Las access list solo hacen match con el tráfico que pasa por el router, pero no van a aplicar al tráfico generado desde el propio router, esto significa que si haces un ping desde un router ese tráfico no va a matchear en ninguna ACL del mismo router, pero podrá matchear en una ACL de cualquier otro router.

Todas las ACL por defecto llevan implícitamente aplicada una condición que deniega todo el tráfico en la última linea, esto no hace falta que lo configuremos, simplemente todas las ACL llevan implícito un DENY a todo el tráfico en la última linea.

Crear una ACL standard:

R(config)#access-list <numero_ACL> <permit/deny> <red_origen> <wildcard_origen>

• <numero_ACL>: Por narices las ACL standar tienen números en el rango 1-99, aunque hay un rango extendido entre el 1300 y el 1999 por si las moscas que también se puede usar.
• <permit/deny>: Si queremos dejar pasar ese tráfico, o si queremos no dejarlo pasar.
• <red_origen>: La red de origen de los paquetes que van a atravesar la interfaz.
• <wildcard_origen>: La wildcard que aplicamos.

Usando el mismo número de access list podemos añadir todas las lineas que queramos a una access list, teniendo en cuenta las reglas de las ACL que hemos comentado antes.

Ver una access list:

show ip access-list <numero_ACL>

Rack1R1#show ip access-list 33

Standard IP access list 33

10 permit 192.168.1.1

20 permit 192.168.2.1

30 deny 192.168.1.0, wildcard bits 0.0.0.255

Lo que aparece delante de cada permit o deny es el número de secuencia, y el router siempre va a leer y ordenar las ACL en base al número de secuencia hasta que haga match, y luego no seguirá leyendo.

Modificar una access list:

Hay dos maneras de modificar una access list, la primera es borrar la access list, e introducir la access list con las lineas que queramos, y la otra es un poco mas fina, pero un poco mas entretenida.

R(config)#ip access-list standard <numero_ACL>

R(config-std-nacl)#<Numero_secuencia> <deny/permit> <red_origen> <wildcard_origen>

Si quisieramos eliminar una linea en una ACL tan solo tendríamos que hacer:

R(config)#ip access-list standard <numero_ACL>

R(config-std-nacl)#no <Numero_secuencia>

Aplicar una ACL:

Las ACL no permiten o deniegan el tráfico alegremente, las ACL se aplican a interfaces, puedes aplicar una misma ACL a todas las interfaces que quieras de un router, pero solo se puede aplicar una ACL a cada interfaz, una para input y otra para output.

R#configure terminal

R(config)#int <interfaz>

Rack8R1(config-if)#ip access-group <numero_ACL> <in/out>

• <in/out>: Simplemente desde el punto de vista del router y mirando a la interfaz si la ACL aplica a los paquetes que entran al router por esa interfaz(in) o si salen por esa interfaz(out).

Ejemplo:

Creamos una ACL con cuatro entradas.

access-list 33 permit 192.168.1.1

access-list 33 permit 192.168.2.1

access-list 33 deny 192.168.1.0 0.0.0.255

access-list 33 permit any

Visualizamos la ACL:

Rack1R1#show ip access-list 33

Standard IP access list 33

10 permit 192.168.1.1

20 permit 192.168.2.1

30 deny 192.168.1.0, wildcard bits 0.0.0.255

Modificamos la ACL:

Rack1R1(config)#ip access-list standard 33

Rack1R1(config-std-nacl)#25 permit 192.168.1.0 0.0.0.255

Volvemos a ver la ACL:

Rack1R1#show ip access-lists 33

Standard IP access list 33

10 permit 192.168.1.1

20 permit 192.168.2.1

25 permit 192.168.1.0, wildcard bits 0.0.0.255

30 deny 192.168.1.0, wildcard bits 0.0.0.255

40 permit any

Aplicamos la ACL a una interfaz:

Rack1R1(config)#int e0/0

Rack1R1(config-if)#ip access-group 33 in

Por esa interfaz estaríamos permitiendo que entrase tráfico proveniente de las ip 192.168.1.1, 192.168.2.1 , de las 192.168.1.0 a 192.168.1.127, pero denegándolo a las 192.168.1.128-192.168.1.255, y permitiéndolo a todas las demás.

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

Access-list: Filtrado de paquetes fragmentados

Una cosa a tener en cuenta en el mundo del networking es, que no todos los medios nos ofrecen la misma MTU. MTU significa Maximum Uransmition Unit, y es el tamaño máximo de trama de nivel 2 que admite el medio de transmisión.

Por defecto Ethernet tiene una MTU de 1500bytes, en cambio hay medios ópticos que admiten 4000 o mas bytes, un servicio MPLS sobre Ethernet añade un cierto payload, por tanto tampoco pueden ofrecer 1500bytes, un túnel GRE como hemos visto en artículos anteriores ofrece una MTU sobre Ethernet de 1475bytes.

El caso es que si queremos transmitir un paquete que a nivel 3 tiene mas bytes, que la MTU que tiene el Medio a nivel 2, lo que se hace es fragmentar el paquete. Fragmentar consiste en enviar el paquete en “trocitos” de nivel 2 hasta el siguiente salto, estos trocitos no contienen toda la información de nivel 3, por tanto para poder determinar el siguiente  salto por defecto los routers deberán cachear los paquetes fragmentados, y después adaptar el paquete de nivel 3 a la MTU del camino que lleva al siguiente salto.

Ese proceso que conlleva el uso de fragmentación de paquetes supone un cierto stress extra para los routers, y también supone un cierto problema para algunos firewalls no muy avanzados ya que no son capaces de analizar ciertos paquetes.

En algunos entornos para evitar esto lo que se hace es denegar los paquetes fragmentados, algo que puede llegar a ser medio viable en algunas redes corporativas, pero no sería viable en ningún operador.
Estos paquetes fragmentados se pueden filtrar con Access list, no es algo demasiado complicado de hacer con una lista extendida.

Access-list extended SIN_FRAGMENTACION
 Deny ip any any fragments
 Permit ip any any

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.

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.

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.

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

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