¿Cómo funcionan las ACLs?
Una lista de control de acceso o ACL (del inglés, access control list) es un concepto de seguridad informática usado para fomentar la separación de privilegios.
Las ACL permiten controlar el flujo del tráfico en equipos de redes, tales como enrutadores y conmutadores.
Un Sistema de Control de Accesos, administra el ingreso a áreas restringidas, y evita así que personas no autorizadas o indeseables tengan la libertad de acceder a la empresa. Así mismo con un Sistema de Control de Accesos se puede tener conocimiento de la asistencia del personal, horarios de ingreso y egreso, y también poder tener un control histórico de entradas de personas a todas las áreas (para poder tener en cuenta quienes podrían ser los posibles responsables de algún siniestro). Conceptos básicos
Hay 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
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.
Las ACL permiten controlar el flujo del tráfico en equipos de redes, tales como enrutadores y conmutadores.
Un Sistema de Control de Accesos, administra el ingreso a áreas restringidas, y evita así que personas no autorizadas o indeseables tengan la libertad de acceder a la empresa. Así mismo con un Sistema de Control de Accesos se puede tener conocimiento de la asistencia del personal, horarios de ingreso y egreso, y también poder tener un control histórico de entradas de personas a todas las áreas (para poder tener en cuenta quienes podrían ser los posibles responsables de algún siniestro). Conceptos básicos
Hay 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
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.
Comentarios
Publicar un comentario