Contenido incluido
en el temario de
CCNA 200-301
Las iACLs deben ser pensadas como la primera línea de defensa contra amenazas externas, por este motivo deben implementarse en los puntos de entrada de la red para proteger la infraestructura de diferentes riesgos potenciales, tanto accidentales como maliciosos.
Las iACLs son listas de acceso extendidas que restringen el acceso externo al espacio de direcciones de la infraestructura corporativa. Permiten que solo los dispositivos autorizados se comuniquen con elementos que integran la infraestructura como son los routers y switches, al mismo tiempo que permiten que el tráfico de tránsito fluya libremente.
Por ejemplo, las iACLs implementadas en un punto de entrada a la red desde Internet deben considerar implementar las recomendaciones de los RFCs 1918 y 3330, y la inclusión del filtrado anti-spoofing.
Al diseñar una iACL se debe analizar cuáles son los protocolos cuyo funcionamiento es requerido por la infraestructura. Aunque cada red tiene requisitos diferentesy específicos ciertos protocolos son de implementación habitual y por lo tanto deben ser considerados. Por ejemplo, las conexiones BGP externas a dispositivos externos (del proveedor de servicio, por ejemplo) deben permitirse explícitamente. También se debe permitir explícitamente cualquier otro protocolo que requiera acceso directo a los routers de infraestructura. Por ejemplo, si finaliza un túnel GRE en un router de infraestructura central, entonces el protocolo 47 (GRE) debe permitirse explícitamente.
Además de los protocolos requeridos para la operación de la infraestructura es necesario identificar también el espacio de direcciones que se utilizan en la infraestructura, ya que este es el espacio de direcciones que debe proteger la iACL. El espacio de direcciones de la infraestructura incluye todas las direcciones que se utilizan para la red interna y a las que rara vez acceden fuentes externas, como es el caso de las interfaces de los routers, el direccionamiento de los enlaces punto a punto y de servicios de infraestructura crítica. Dado que estas direcciones se utilizan para identificar el destino del tráfico en las iACL, la sumarización es fundamental. Siempre que sea posible, estas direcciones deben agruparse, de ser posible, en bloques CIDR.
Dado que muchos ataques se basan en inundar los routers con paquetes fragmentados, el filtrado de fragmentos entrantes a la infraestructura es otro elemento que se debe considerar y que proporciona una medida adicional de protección al mismo tiempo que ayuda a garantizar que un atacante no pueda inyectar fragmentos simplemente haciendo coincidir las reglas de Capa 3 en la iACL. Para esto las sentencias correspondientes que se incorporan en la iACL deben utilizar la keyword fragments que obliga a la sentencia a denegar o permitir fragmentos no iniciales con mayor granularidad.
Además de los protocolos requeridos para la operación de la infraestructura es necesario identificar también el espacio de direcciones que se utilizan en la infraestructura, ya que este es el espacio de direcciones que debe proteger la iACL. El espacio de direcciones de la infraestructura incluye todas las direcciones que se utilizan para la red interna y a las que rara vez acceden fuentes externas, como es el caso de las interfaces de los routers, el direccionamiento de los enlaces punto a punto y de servicios de infraestructura crítica. Dado que estas direcciones se utilizan para identificar el destino del tráfico en las iACL, la sumarización es fundamental. Siempre que sea posible, estas direcciones deben agruparse, de ser posible, en bloques CIDR.
Dado que muchos ataques se basan en inundar los routers con paquetes fragmentados, el filtrado de fragmentos entrantes a la infraestructura es otro elemento que se debe considerar y que proporciona una medida adicional de protección al mismo tiempo que ayuda a garantizar que un atacante no pueda inyectar fragmentos simplemente haciendo coincidir las reglas de Capa 3 en la iACL. Para esto las sentencias correspondientes que se incorporan en la iACL deben utilizar la keyword fragments que obliga a la sentencia a denegar o permitir fragmentos no iniciales con mayor granularidad.
El uso de una sentencia de denegación (deny) para los fragmentos no iniciales al inicio de la iACL bloquea todos los fragmentos no iniciales evitando que accedan al router. Son raras las circunstancias en las que una sesión válida puede requerir fragmentación.
En consecuencia. Las iACLs deben incluir 3 tipos de sentencias:
- Sentencias que bloquean los paquetes IP fragmentados.
- Sentencias que filtran el ingreso desde la red externa (Internet) de tráfico con una dirección IP privada como dirección de origen.
- Sentencias que filtran tráfico de protocolos requeridos por la infraestructura de la red, según dirección IP de origen.
Un ejemplo de estas iACL podría ser el siguiente:
Rtr(config)#access-list 101 deny tcp any 209.165.200.224 0.0.0.31 fragments
Rtr(config)#access-list 101 deny udp any 209.165.200.224 0.0.0.31 fragments
Rtr(config)#access-list 101 deny icmp any 209.165.200.224 0.0.0.31 fragments
- Filtrado de fragmentos de tráfico IP que tiene como destino el espacio de direccionamiento IP público que implementa la red corporativa (209.165.200.224/27 en este ejemplo).
- Se genera una sentencia para cada protocolo (TCP, UDP, ICMP) para tener contadores del tráfico que coincidan con cada sentencia por separado.
Rtr(config)#access-list 101 deny ip 10.0.0.0 0.255.255.255 any
Rtr(config)#access-list 101 deny ip 172.16.0.0 0.15.255.255 any
Rtr(config)#access-list 101 deny ip 192.168.0.0 0.0.255.255 any
- Bloquea todo el tráfico que tiene como dirección de origen los bloques de direcciones IP privadas definidas en el RFC 1918.
Rtr(config)#access-list 101 deny ip host 0.0.0.0 any
Rtr(config)#access-list 101 deny ip 127.0.0.0 0.255.255.255 any
Rtr(config)#Rtr(config)#access-list 101 deny ip 192.0.2.0 0.0.0.255 any
Rtr(config)#access-list 101 deny ip 224.0.0.0 31.255.255.255 any
- Bloquea tráfico que tiene como dirección de origen direcciones IPv4 especiales que no debieran aparecen como origen de tráfico.
- Son las direcciones incluidas en el RFC 3330.
Rtr(config)#access-list 101 permit tcp host 209.165.201.2 host 209.165.201.1 eq bgp
Rtr(config)#access-list 101 permit tcp host 209.165.201.2 eq bgp host 209.165.201.1
- Se deben permitir los protocolos requeridos para la operación de la infraestructura y cuya dirección IP destino coincide con esa misma infraestructura. En estos casos la buena práctica sugiere que además la dirección IP de origen sea conocida para autorizar explícitamente esa dirección y hacer más granular el permiso.
- En este ejemplo se está permitiendo el tráfico BGP que se genera en el dispositivo peer con el que se intercambia información de ruteo con ese protocolo.
Rtr(config)#access-list 101 deny ip 209.165.200.224 0.0.0.31 any
- Bloquea el tráfico IP que tiene como dirección IP de origen el bloque de direcciones públicas asignado a la red corporativa. Esto previene ataques que hagan spoofing de IP utilizando ese bloque de direcciones.
Rtr(config)#access-list 101 permit ip any any
- Finalmente se permite todo otro tráfico IPv4.
- Esto permite todo tráfico IP que tiene un destino diferente que la infraestructura protegida y deja el filtrado de ese tráfico a otro dispositivo como puede ser un firewall.
Estás invitado a participar de nuestro grupo en Facebook:
https://www.facebook.com/groups/librosnetworking/
podés participar de nuestro grupo en VKontakte
https://vk.com/libros.networking
o seguir las principales novedades en el grupo de Telegram:
https://t.me/LibrosNetworking
Las abreviaturas y siglas utilizadas en este post puede encontrarlas desarrolladas en
que está disponible en la Librería en Línea de EduBooks.
No hay comentarios.:
Publicar un comentario
Gracias por tu comentario.
En este blog los comentarios están moderados, por lo que su publicación está pendiente hasta la revisión del mismo.