Finalmente llegó la última entrada del tutorial sobre ACLs, los ejemplos de uso. Espero finalizar mostrando algunos ejemplos que se puedan verificar en la práctica y algunos usos adicionales de las ACLs que van más allá del currículo de CCNA. Disfrútenlo.
Siguiendo la serie de publicaciones sobre ACLs, voy a hacer ejemplos de configuración y funcionamiento del tema de cada una de las entradas anteriores, es decir, Conceptos, ACLs estándar, ACLs extendidas y ACLs complejas. Primero recordemos las bases de siempre.Conceptos básicosHay que recordar que las ACLs son fundamentalmente un mecanismo de selección de tráfico, generalmente, por medio de parámetros de los campos del encabezado IP o los encabezados TCP y UDP. En algunos casos, el protocolo de capa 4 puede establecer correspondencias con otros encabezados como los de EIGRP, OSPF, entre otros. Una vez que la selección se establece, se puede usar para múltiples finalidades, por ejemplo en CCNA se usa como mecanismo básico de seguridad, es decir, el tráfico seleccionado se puede bloquear o permitir según las necesidades de la organización. Otros usos son la definición de las direcciones que van a ser traducidas en un enrutador de borde que usa NAT entre otras muchas tecnologías que usan las ACLs para definir conjuntos de direcciones o flujos de tráfico seleccionados entre muchos otros. La selección de tráfico o direcciones en las ACLs consiste en definir un conjunto de reglas bajo un mismo identificador, sea numérico o alfanumérico, con la forma
- <id> <acción> <condición>
- <id> <acción2> <condición2>
- Comando: access-list <n> [permit|deny] <ref_origen> <wildcard_origen> [<ref_destino> <wilcard_destino>]
donde id es el nombre/número de la ACL, acción es permitir o denegar y en el comando id se corresponde con n , acción con permit|deny y la condición sería el resto del comando. La condición es lo que usualmente nos exige más cuidado, las condiciones se basan en direcciones origen en las ACLs estándar y origen/destino en las extendidas y nombradas extendidas. Las direcciones origen o destino se definen cada una mediante una dirección de referencia y una máscara wildcard y pueden definir arbitrariamente la selección, es decir, la dirección de referencia no tiene que corresponder exactamente con una subred sino con cualquier conjunto de direcciones, incluso de varias subredes o un subconjunto de IPs de una subred. Si la explicación anterior no es clara, por favor lea la entrada inicial de la serie: ¿Cómo funcionan las ACLs?: I Conceptos.
Topología de ejemplo
La siguiente va a ser nuestra topología de ejemplo. Infortunadamente el Packet Tracer no soporta las ACLs reflexivas ni dinámicas, así que si usted desea hacer el ejercicio completo debe hacerlo o bien con enrutadores reales o con GNS3. La topología consiste en 5 enrutadores interconectados por enlaces seriales, uno de ellos es el enrutador central que conecta con el servidor y el resto tienen sólo una subred conectada. Las direcciones de las LAN pertenecen al prefijo 172.16.0.0/12, asignandolas en orden de izquierda a derecha 172.16.0.0/24, 172.17.0.0/24, 172.18.0.0/24 (PC4) y 172.19.0.0/24 (PC5). El servidor tiene la dirección 10.1.1.1 y los enlaces entre enrutadores son 10.0.0.0/30, 10.0.0.4/30, 10.0.0.8/30, 10.0.0.12/30. El enrutamiento se lleva a cabo con eigrp de AS 1 sin autoresúmen por el hecho de haber redes discontiguas (10.0.0.0). La política (requerimientos) de seguridad de la organización son los siguientes:
- Estándar: Filtrar el acceso de la red del PC1 al servidor
- Extendidas: Filtrar el acceso del PC2 al servidor
- Dinámicas (No soportadas): Acceder al servidor desde PC5 sólo si se autentica previamente por telnet.
- Reflexivas (No soportadas): Permitir el tráfico de ICMP que se ogirine en PC4, pero no al revés
Un aspecto importante, antes de hacer cualquier cosa con ACLs es verificar que exista conectividad completa en la red objetivo. Si no comprobamos eso previamente, podríamos ignorar problemas actuales de conectividad en la red y podríamos creer que eso es efecto de la instalación de las acls. En esos casos el diagnóstico de un problema de esa naturaleza puede resultar muy difícil de diagnosticar y más dificil aun de solucionar. Otra consideración que hay que hacer es verificar que la instalación de una ACL afecta la red estrictamente como se espera y no genera efectos no previstos e indeseados. Lo anterior hay que hacerlo por cada acl y verificando la conectividad total -o la más importante si la red es muy grande-.
Listas de Control de Acceso Estándar
En el ejemplo, el requerimiento de filtrar la red del PC1 con ACL estándar nos enfrenta a la primera decisión: ¿dónde instalar la ACL?. La respuesta tiene dos sentidos, en qué enrutador y en qué interfaz de ese enrutador. Como las ACL estándar sólo filtran el tráfico con base en las direcciones IP origen, si la acl se instala en Router1, eso filtraría todo el tráfico de la red hacia todos los destinos, por lo tanto no es viable esa decisión. Una alternativa, si no es posible instalarla en otro enrutador, sería filtrar el tráfico proveniente del servidor en ese mismo enrutador lo que impidiría que las respuestas a tráfico que salió de la red de PC1 y PC3 regrese, lo cual sería un cumplimiento indirecto de la política de impedir conectividad entre esa red y el servidor.
Según lo anterior, la única alternativa es instalar la ACL estándar en Router0, y con eso se cumple la regla de oro de las acls estándar: instale lo más cerca posible del destino. En éste caso, en el que podemos configurar el enrutador más cercano al servidor, la instalamos en la interfaz por la que se conecta el servidor en la dirección de salida, filtrando efectivamente el tráfico cuyo origen es la red del PC1.
El resto es carpintería como decía un antiguo profesor que tuve:
- access-list 1 deny 172.16.0.0 0.0.0.255
- access-list 1 permit any
- interface FastEthernet0/0
- ip address 10.0.0.1 255.255.0.0
- ip access-group 1 out
Una vez que se instala esta acl, los paquetes originados en cualquier pc de la red del PC1 no llegarán al servidor pero sí a cualquier otro pc de la red. La conectividad con el resto de las redes de la topología sigue intacta.
ACL extendidas
El segundo requerimiento es filtrar el tráfico desde el PC2 hasta el Servidor. Evidentemente no se puede hacer un filtrado así con una sola acl estándar, por ejemplo, si ponemos una ACL estandar en router0 que filtre el tráfico cuya IP es la de PC2 en la fa 0/0 de salida, éste quedará sin conectividad con cualquier PC de la red del servidor, no sólo el servidor. Si, por otro lado, la ponemos de entrada la situación es peor: el servidor no se podrá comunicar. Otra alternativa sería instalarla en la interfaz LAN que pertenece a la red de PC2 (en Router1) y éste no se podrá comunicar con ninguna otra red.
La solución es una ACL extendida, que por norma se instala lo más cercano al origen posible. El razonamiento es que haciendolo de ésta manera evitamos que tráfico innecesario corra por la red ocupando ancho de banda y procesamiento en los dispositivos.
- access-list 101 deny ip host 172.17.0.3 host 10.0.0.5
- access-list 101 permit ip any any
- interface FastEthernet0/0
- ip address 172.17.0.1 255.255.0.0
- ip access-group 101 in
Lo anterior en el enrutador Router1, donde se conecta el host que se quiere filtrar. De nuevo, hay que verificar que otros PCs no quedan afectados por la acl, eso lo verificamos enviando y recibiendo paquetes exitosamente desde el PC6 al servidor. La conectividad del resto de las redes de la topología sigue inalterada, eso incluye la conectividad de otras redes al pc2.
ACLs dinámicas y reflexivas
Infortunadamente el PT 5.1 no soporta ninguno de estos tipos de acls. Para poder hacer el ejercicio habría que usar gns3, netlab o enrutadores reales. De todas formas ilustraré cómo sería la configuración correspondiente en esta topología.
Recordemos que las dinámicas son, entre otras cosas, un mecanismo de autenticación simple. Lo primero que haremos será crear un nombre de usuario y contraseña para autenticar al PC 5, luego crearemos la acl que incluya la palabra reservada dynamic, cuidando que la misma acl permita el tráfico de telnet desde el pc en cuestión, instalamos la acl y luego en la configuración de las vty agregamos el comando que vincula estas dos instrucciones.
- username cesarcabrera password cecab123
- access-list 101 permit ip any host 172.19.0.1 eq telnet
- access-list 101 dynamic testlist timeout 15 permit ip host 172.19.0.3 host 10.0.0.5
- interface fa 0/0
- ip access-group 101 in
Lo anterior, una vez instalado en el enrutador Router2, sólo permitirá el acceso del PC5 al servidor si primero se intenta hacer un telnet al enrutador y se autentica exitosamente al mismo.
El requerimiento de acl reflexiva se debe instalar en el último enrutador, Router3, usando una acl nombrada extendida -no numerada- y con dos palabras clave adicionales: reflect/evaluate. En la dirección de salida se permite el tráfico pero se establece que se creen las acls necesarias para el tráfico de retorno con reflect y de entrada se le indica a la acl que evalúe las entradas dinámicas creadas por la acl de salida.
- ip access-list extended SALIDA
- permit icmp 172.18.0.0.0.0.0.255 any reflect TICMP
- ip access-list extended ENTRADA
- evaluate TICMP
- interface ser 0/0/0
- ip access-group SALIDA out
- ip access-group ENTRADA in
Note que una vez que se instalan estos comandos en el último enrutador, lo único que se puede hacer desde la red 172.18.0.0n es enviar exitosamente pings, pero no serán exitosos si se originan en otras redes hacia ésta última.
Otros usos de las ACLs
Finalmente, como les he venido mencionando en otras entradas, las acls son un mecanismo de clasificación de tráfico y por eso son útiles en otros contextos. Voy a citar dos, uno de ccna y otro de ccnp, particularmente de BSCI. En el último semestre de CCNA se estudia el tema de NAT, NAT se usa para tener una red con direccionamiento privado arbitrariamente grande conectada a una red pública usando sólo un pequeño conjunto de direcciones públicas. El mecanismo consiste en examinar los paquetes provenientes de la red privada y cambiar las direcciones IP y puertos TCP/UDP del encabezado por las direcciones públicas disponibles. De ese proceso se guarda en memoria una registro de qué puertos origen han sido asignados a qué dirección privada, de tal manera que cuando se recibe la respuesta de la red pública con IP destino pública (o global como dice el currículo), el puerto TCP/UDP destino determina la dirección IP de host local al que hay que cambiar la dirección IP para enviar el paquete al interior de nuestra red (en otra ocasión escribo más en detalle el proceso).
NAT debe especificar dos conjuntos de direcciones: las direcciones privadas a traducir a direcciones públicas y el conjunto de direcciones públicas. El conjunto de direcciones públicas es un rango de direcciones arbitrarias que dificilmente corresponderán con una regla tipo acl, pero las direcciones privadas sí deben tener un patrón que se corresponda con una acl estándar, en la que las direcciones a las que se aplique la acción permit serán las direcciones que hay que traducir a direcciones públicas (o globales). En otras palabras, para crear una regla de traducción de direcciones, se especifica por medio de una acl qué direcciones privadas (o locales) deben ser traducidas.
En BSCI (uno de los exámenes de ccnp) se habla de un mecanismo de manipulación de tráfico llamado mapas de ruta (route-map). Los mapas de ruta permiten manipular la forma en que se realiza el enrutamiento por ejemplo yo podría arbitrariamente y sin contar con la tabla de enrutamiento, decir que el tráfico de cierta red debe usar siempre un enlace en particular de salida. Ése es el ejemplo más simple de un mapa de ruta, pero los mapas de ruta permiten muchas cosas más, por ejemplo cambiar parámetros de enrutamiento como métricas o filtrar actualizaciones de enrutamiento que provengan de otro enrutador. El mecanismo básico por el que se especifica qué tráfico será afectado por las reglas del mapa de ruta son las acl extendidas.
Conclusiones
|
|
Espero que después de toda esta secuencia sobre listas de control de acceso, hayan quedado claros muchos conceptos y formas de usar las acls y sobre todo, ver que éstas son un mecanismo muy potente y muy importante en el mundo de la configuración de equipos de red, en especial de Cisco. Les dejo también la topología de ejemplo con los requerimientos para que ensayen en sus casas -si tienen el Packet Tracer-, la conectividad básica y el enrutamiento ya están configurados, sólo faltan las acls. Espero que hayan disfrutado la lectura y que les haya resultado de alguna utilidad.
Recuerde que ésta es la última entrada en una serie sobre acls, acá les dejo el listado completo para que lo lean en caso de no haberlo hecho antes:
Gracias por tu explicación y por compartir tus conocimientos
Hola Hermes,
gracias por el comentario y espero que sigas atento a mis publicaciones y por supuesto que las recomiendes cuando haya lugar.
Hasta pronto.
muy buena la explicacion quisiera saber como poner estas access-list tengo tres router y tengo una maquina en cada uno pero yo quiero que dos host de esos no tenga acceso al que queda pero que ese si pueda tener acceso a esos dos si alguien me puede ayudar le agradeceria por favor
Hola Oscar,
gracias por el comentario. Simplifica la topología del ejemplo a la tuya y aplica las ACLs según tus direcciones a ver cómo te va.
Gracias y hasta pronto.
hola oscar,
se pueden aplicar las listas de acceso en redes wimax???
gracias y hasta pronto
este blog esta demasiado bueno felicidades
Gracias, muy útil tu explicación…
viejo esa explicacion estubo solo bueno segui publicando
Gracias por tu ejemplo, sólo una duda, si queres denegar el acceso de la red 172.16.0.0 hacia el servidor, ¿porqué es una sentencia «out», no podría ser «in», ya que el acceso que no permites es para que entre el tráfico, no?
Si alguien sabe porqué, agradezco la ayuda.
(Un saludo)
hola de nuevo, ¿podría ser porque el «out» hace referencia a la dirección en la que se aplica de la sentencia (es decir hacia afuera) y no hace referencia al tipo de tráfico. Uf, vaya lío, pero con estos ejemplos se va aprendiendo mucho, gracias por tomarte tiempo y compartir tu conocimiento.
Saludos, desde madrid
Hola Raspa,
gracias por el comentario. Efectivamente in/out hacen referencia a si el tráfico sale o entra a la interfaz en la que se aplica.
Me alegro que te sirva lo que escribo. Hasta pronto.
cesar, te pido tu apoyo… en lo siguiente:
tengo instaladas 4 tarjetas fastethernet en un router y un FW en la red, necesito que el trafico hacia la misma red se quede en la red y el trafico que no tenga como destino la red se vaya por el FW.
Gracias de antemano…
Hola Julio,
eso se puede hacer con enrutamiento basado en políticas o PBR por sus siglas en inglés. Busca en Cisco sobre ese tema y encontrarás un ejemplo igualito al caso que me propones.
Gracias y hasta pronto.
si, lo hice con pbr, pero cunado los paquetes van de una tajeta a otra, como quiera se van al fw…
access-list 120 permit ip 192.168.0.0 0.0.31.255 any
route-map FW permit 10
match ip addess 120
set ip next-hop 192.168.0.1
en cada interface x/x
ip policy route-map FW
***************************
inarface 0/1 ip adress 192.168.10.2 y 192.168.11.2 secondary
inarface 0/2 ip adress 192.168.12.2 y 192.168.13.2 secondary
inarface 0/3 ip adress 192.168.14.2 y 192.168.15.2 secondary
inarface 0/4 ip adress 192.168.16.2 y 192.168.17.2 secondary
pudes mandarme el link donde esta el ejemplo sobre PBR de cisco, para darle una checada….
Gracias cesar..
Hola Julio,
lo que tú pones parece bien, míra el ejemplo de Cisco:
Understanging Policy-based routing.
Gracias y hasta pronto.
listo cesar, para resolver mi bronca, genere otra PBR con un acl conorigen y destino al mismo segmento y hice un match a esa acl, con un set interface fastethernet 0, que mi primera interface del router y con eso tubo para repartir el trafico en todas las iterfaces del router.
Mil Gracias por tu apoyo..
Ok, Julio, me alegro. ¿Es un ejercicio académico o algo que necesitabas de tu trabajo?
Cesar, que tal… necesito ayuda con lo sig…
tengo una LAN, con varios segmentos de red, dentro de la red hay conectados 3 router cisco, en las pcs pongo como gateway el router por el que quiero se vaya el trafico y no hay ningun problema, pero cuando quiero que desde un router redirigir el trafico hacia otro router, no lo hace, porque un router no puede ver al otro… como le hago para que se vean entre si…. te recurdo que estan conectados por ethernet y switches…. gracias…
Hola Julio,
la verdad me faltan detalles, si están conectados mediante un switch deben estar todos en la misma subred, adicionalmente, si no hay tráfico permanente entre ellos es posible que el caché arp esté expirando y algunas comunicaciones se rompan por la pérdida del primer paquete.
Finalmente, también es posible que falten rutas. Si los PCs están en una subred y el switch que comunica los enrutadores no hace parte de ese segmento, los enrutadores del segundo salto deben tener rutas al segmento de origen.
Gracias y hasta pronto.
ok, mira la red esta conformada por varios sw’s 3com y catalyst, y los 3 routers estan conectados dentro de esos sw’s, primer router tiene el segmento 10.5.113.0/24, el segundo 10.135.0.0/24 y el tercer router 172.10.10.0/24, a todas las pc’s tienen ip de estos segmentos y el trafico de las pc’s salen por la puerta de enlace segun el router(10.5.113.1, 10.135.0.1 y 172.10.10.1) hasta aqui no hay bronca. el problema es cuando el trafico que llega al router 172.10.10.1 con destino del segmento 10.135.0.0/24 redirigr el trafico al router 10.135.0.1, esto lo aplique en unas acl(como me explicaste en otra ocasion), pero no se realiza porque el router 172.10.10.1 no alcanza al router 10.135.0.1, el detalle es como puedo hacerle para que estos dos routers se vean…. de antemano mil gracias…
Ahi les dejo el link para que descarguen el ejemplo, para practicar en el packet tracert 5.3, Espero les sirva. http://www.megaupload.com/?d=IFSNGHNB
Buenas amigo, observando el ejemplo de la configuración estandar. Me parece que colocas todo bien hasta llegar a configurar la ACL en la interface de salida del router 0, no entiendo porque colocas la ip 10.0.0.1 255.255.0.0 si es la de salida del router 0 no debería se por ejemplo 10.1.1.2 y la mascara dependiendo del prefijo de la subred del servidor. Gracias en lo que puedas aclarar esta duda.
Hola Omar,
buena observación, has descubierto una inconsistencia en mi publicación. En realidad la configuración no está mala, si te fijas bien, en ninguna otra parte aparece la dirección 10.1.1.1, eso es porque no existe: el servidor en realidad tiene la dirección 10.0.0.5.
Gracias por el comentario. En unos días lo corrijo (para que puedes releerlo como está).
Gracias por la aclaratoria. 🙂
Buenas, primero lo felicito por la importancia y utilidad de sus aportes, segundo es para consultarle como se restringe la entrada y salida de correo electronico de un solo pc en una red(estamos en el simulador packet tracer). de antemano muchas gracias.
Hola Julián,
esa consulta parece tarea, te invito a que busques cuál es el puerto que usa el correo electrónico (SMTP/POP/IMAP, seguramente te solicitan el primero) y hagas una ACL que bloquee ese puerto. El resto está en el tutorial, termina de leerlo.
Gracias y hasta pronto.
Soy administrador de red en una escuela. Tenemos un switch cisco sg 300 que permite acl, he intentado permitir solo navegacion web en la red (192.168.1.0/24) creando una acl que permita solo paquetes con puerto origen o destino 80 pero no logro hacerlo funcionar. me puedes dar una idea de cmo hacerlo.
Desde ya muchas gracias y muy buena tu explicacion.
Hola Claudio,
no conozco el modelo que me citas, te sugiero que intentes permitir el tráfico que me dices en una sola dirección (de entrada o de salida) y bloquees el resto explícitamente.
Gracias y hasta pronto.
Hola Cesar, en la escuela donde trabajo tenemos un switch cisco sg 300 que permite acl. La intencion es permitir a nuestros alumnos solo navegacion web(para evitar programas cmo el ares, etc.) He intentado crear una acl donde permita slo el trafico de paquetes a y desde el puerto tcp 80 y lo mismo para udp 53(dns), sin embargo no funciona porque las maquinas dejan de navegar. Me podras hechar una mano.
SOIS LA OSTIA TIO!!!!
Infinitas gracias por tu material!!!
La verdad, no pude llegar a la clase donde realizaron pruebas de ACL y ahorita estoy haciendo una tarea gruesa, pero gracias a tu ayuda, ya la estoy resolviendo de maravillas!!!, muy bien explicado, los tips son realmente importantes, ahora le entiendo a éstas cosas «ACL», Excelente aporte. Felicidades por tu actitud. El conocimiento no tiene dueño, pero el que tiene conocimiento y lo comparte, se hace más sabio y eso le da poder. Bendiciones, saludos desde El Salvador.
Caramba Castellanos,
¡qué comentario tan alentador!. Gracias a tí por dejarme semejante mensaje, me hace muy feliz saber que les gusta y que les sirve, eso nunca queda claro hasta que alguien como tú se toma el tiempo de escribirlo.
Gracias y hasta pronto.
Muy bueno tu articulo César, pero dejame expresarte unas dudas sobres tu razonamiento (soy novato en esto de las ACLs, pero me interesa aprender). En las razones que exponés sobre donde poner la ACL extendida, decís que si la ponés de salida en la interface f0/0 de Router0, este, el enrutador supongo, quedará sin conectividad con cualquier PC de la red del servidor y no solo el servidor, pero se puede mencionar específicamente el host denegando el paso y luego permitiendo el paso a todos los demás incluso la red del servidor, como explicaste en un ejemplo que expusiste en el articulo II ACL estándard. DE todas formas te agradecemos tu tiempo e interés de enseñar. Un abrazo.
Muchas gracias amigo! me has salvado de seguir estresandome con un proyecto de la carrera! Ahora ya sé hacer bloqueos bien hechos!
Saludos 🙂