Listas de control de acceso de tránsito: filtrado en el perímetro

Introducción

Este documento incluye pautas y técnicas de instrumentación recomendadas para filtrar el tránsito y limitar el tráfico en sus puntos de ingreso a la red. Las listas de control de acceso de tránsito (ACL) se utilizan para aumentar la seguridad de la red permitiendo explícitamente únicamente el tráfico requerido en la red o redes.

Filtros de tránsito

Configuración típica

En la mayoría de los entornos de red perimetral, como un punto de presencia típico de Internet de una red empresarial, se debe utilizar el filtrado de entrada para descartar el tráfico no autorizado en el perímetro de la red. En determinadas implementaciones de proveedores de servicios, esta forma de filtrado de tráfico perimetral o de tránsito también se puede utilizar de forma eficaz para limitar el flujo de tráfico de tránsito hacia y desde los clientes únicamente a protocolos permitidos específicos. Este documento se centra sobre un modelo de instrumentación para empresas.

En este ejemplo se muestra un diseño típico de conectividad a Internet empresarial. Dos routers periféricos, IR1 e IR2, proporcionan conectividad directa a Internet. Detrás de estos dos routers, un par de firewalls (Cisco PIX en este ejemplo) proporciona capacidades de inspección con estado y acceso tanto a la red interna como a la zona desmilitarizada (DMZ). La DMZ contiene servicios de acceso público como DNS y web; es la única red accesible directamente desde la Internet pública. Nunca se debe obtener acceso a la red interna directamente por Internet, pero el tráfico de origen de la red interna debe poder llegar a los sitios de Internet.

Los routers de borde deberían estar configurados para ofrecer un primer nivel de seguridad a través del uso de los ACL de entrada. Las ACL solo permiten el tráfico específicamente permitido a la DMZ y permiten el tráfico de retorno para los usuarios internos que acceden a Internet. Todo el tráfico no autorizado debe descartarse en las interfaces de ingreso.

Secciones ACL de tránsito

En general, una ACL de tránsito se compone de cuatro secciones.

• Entradas de antisimulación y dirección de uso especial que impiden que fuentes ilegítimas y paquetes con direcciones de origen que pertenecen a su red ingresen a la red desde una fuente externa

  

  Nota: RFC 1918 define el espacio de direcciones reservadas que no es una dirección de origen válida en Internet. RFC 3330 define direcciones de uso especial que pueden requerir filtrado. RFC 2827 proporciona directrices para evitar la suplantación de identidad.

• Tráfico de retorno permitido explícitamente para conexiones internas a Internet

• Tráfico de origen externo explícitamente permitido destinado a direcciones internas protegidas

• Explícito deny enunciado

  

  Nota: Aunque todas las ACL contienen un deny , Cisco recomienda el uso de una deny , por ejemplo, deny ip any any. En la mayoría de las plataformas, estas sentencias mantienen un conteo del número de paquetes denegados que se pueden mostrar mediante el comando show access-list comando.

Cómo desarrollar una ACL de tránsito

El primer paso en el desarrollo de una ACL de tránsito es determinar los protocolos requeridos dentro de sus redes. Aunque cada sitio tiene requisitos específicos, ciertos protocolos y aplicaciones se utilizan ampliamente y se permiten con mayor frecuencia. Por ejemplo, si el segmento DMZ proporciona conectividad para un servidor web de acceso público, se requiere TCP desde Internet a las direcciones del servidor DMZ en el puerto 80. De manera similar, las conexiones internas a Internet requieren que la ACL permita la devolución del tráfico TCP establecido: tráfico que tiene configurado el bit de reconocimiento (ACK).

Identificar protocolos requeridos

El desarrollo de esta lista de protocolos requeridos puede ser una tarea desalentadora, pero hay varias técnicas que se pueden utilizar, según sea necesario, para ayudar a identificar el tráfico requerido.

• Revise su política de seguridad / política de servicios

  Su política de sitio local debería proporcionar una línea de base de los servicios permitidos y denegados.

• Revise/audite su configuración de escudo de protección.

  La configuración actual del firewall debe contener permit para los servicios permitidos. En muchos casos, puede traducir esta configuración al formato ACL y utilizarlo para crear la mayor parte de las entradas ACL.

  

  Nota: Los firewalls con monitorización de estado no suelen tener reglas explícitas para el tráfico de retorno a conexiones autorizadas. Debido a que las ACL de los routers no poseen estado, el tráfico de retorno debe ser permitido de manera explícita.

• Revisión/auditoría de sus aplicaciones.

  Las aplicaciones alojadas en la DMZ y las utilizadas internamente pueden ayudar a determinar los requisitos de filtrado. Revise los requisitos de la aplicación para proporcionar detalles esenciales sobre el diseño del filtrado.

• Use una ACL de clasificación.

  Una ACL de clasificación se compone de permit para los diversos protocolos que podrían destinarse a la red interna. (Consulte el Apéndice A para obtener una lista de los protocolos y aplicaciones más utilizados.) Use el comando show access-list para mostrar un recuento de aciertos de entrada de control de acceso (ACE) para identificar los protocolos necesarios. Investigue y comprenda cualquier resultado sospechoso o sorprendente antes de crear una permit para protocolos inesperados.

• Utilice la característica conmutación Netflow.

  Netflow es una función de switching que, si está activada, proporciona información detallada sobre el flujo. Si Netflow está activado en los routers periféricos, el show ip cache flow proporciona una lista de protocolos registrados por Netflow. Netflow no puede identificar todos los protocolos, por lo que esta técnica debe utilizarse junto con otros.

Identificar tráfico no válido

Además de la protección directa, la ACL de tránsito también debe proporcionar una primera línea de defensa contra ciertos tipos de tráfico no válido en Internet.

• Denegar espacio RFC 1918.

• Denegar paquetes con una dirección de origen que caiga bajo un espacio de dirección de uso especial, como se define en RFC 3330.

• Aplique filtros anti-simulación, de acuerdo con RFC 2827; su espacio de dirección nunca debe ser el origen de paquetes desde fuera de su sistema autónomo (AS).

Otros tipos de tráfico que se deben tener en cuenta son:

• Protocolos externos y direcciones IP que necesitan comunicarse con el router de borde

  • ICMP de direcciones IP del proveedor de servicios

  • Protocolos de ruteo

  • VPN IPSec, si se utiliza un router de extremo como terminación

• Tráfico de retorno permitido explícitamente para conexiones internas a Internet

  • Tipos específicos de Protocolo de mensaje de control de Internet (ICMP).

  • Respuestas a consultas del Sistema de nombres de dominio (DNS) salientes

  • TCP establecido

  • Tráfico de retorno del protocolo de datagramas de usuario (UDP)

  • conexiones de datos FTP

  • conexiones de datos TFTP

  • Conexiones multimedia

• Tráfico de origen externo explícitamente permitido destinado a direcciones internas protegidas

  • Tráfico VPN

    • Asociación de seguridad de Internet y protocolo de administración de claves (ISAKMP)

    • Traducción de direcciones de red (NAT) transversal

    • Encapsulación patentada

    • Carga de seguridad de encapsulación (ESP)

    • Encabezado de autenticación (AH)

  • HTTP a servidores web

  • Secure Socket Layer (SSL) a servidores web

  • FTP a servidores FTP

  • Conexiones de datos FTP entrantes

  • Conexiones de datos FTP pasivo (pasv) de entrada

  • Protocolo Simple Mail Transfer (SMTP)

  • Otras aplicaciones y servidores

  • Consultas DNS entrantes

  • Transferencias de zona DNS entrante

Aplique ACL

La ACL recientemente construida debería aplicarse al tráfico entrante en todas las interfaces orientadas a Internet de los routers de borde. En el ejemplo ilustrado en la sección Configuración Típica, la ACL se aplica en las interfaces de cara a Internet en IR1 e IR2.

Vea las secciones sobre pautas de implementación y ejemplo de implementación para obtener más detalles.

Ejemplo de ACL

Esta lista de acceso proporciona un ejemplo simple pero realista de entradas típicas requeridas en una ACL de tránsito. Es necesario personalizar esta ACL básica con los detalles de configuración locales específicos del sitio.

!--- Add anti-spoofing entries.
!--- Deny special-use address sources.
!--- Refer to RFC 3330 for additional special use addresses.

access-list 110 deny ip 127.0.0.0 0.255.255.255 any
access-list 110 deny ip 192.0.2.0 0.0.0.255 any
access-list 110 deny ip 224.0.0.0 31.255.255.255 any
access-list 110 deny ip host 255.255.255.255 any

!--- The deny statement should not be configured
!--- on Dynamic Host Configuration Protocol (DHCP) relays.

access-list 110 deny ip host 0.0.0.0 any

!--- Filter RFC 1918 space.

access-list 110 deny ip 10.0.0.0 0.255.255.255 any
access-list 110 deny ip 172.16.0.0 0.15.255.255 any
access-list 110 deny ip 192.168.0.0 0.0.255.255 any

!--- Permit Border Gateway Protocol (BGP) to the edge router.

access-list 110 permit tcp host bgp_peer gt 1023 host router_ip eq bgp
access-list 110 permit tcp host bgp_peer eq bgp host router_ip gt 1023

!--- Deny your space as source (as noted in RFC 2827).

access-list 110 deny ip your Internet-routable subnet any

!--- Explicitly permit return traffic.
!--- Allow specific ICMP types.

access-list 110 permit icmp any any echo-reply
access-list 110 permit icmp any any unreachable
access-list 110 permit icmp any any time-exceeded
access-list 110 deny   icmp any any

!--- These are outgoing DNS queries.

access-list 110 permit udp any eq 53  host primary DNS server gt 1023

!--- Permit older DNS queries and replies to primary DNS server.

access-list 110 permit udp any eq 53  host primary DNS server eq 53

!--- Permit legitimate business traffic.

access-list 110 permit tcp any Internet-routable subnet established
access-list 110 permit udp any range 1 1023 Internet-routable subnet gt 1023

!--- Allow ftp data connections.

access-list 110 permit tcp any eq 20 Internet-routable subnet gt 1023

!--- Allow tftp data and multimedia connections.

access-list 110 permit udp any gt 1023 Internet-routable subnet gt 1023

!--- Explicitly permit externally sourced traffic.
!--- These are incoming DNS queries.


access-list 110 permit udp any gt 1023 host <primary DNS server> eq 53

!-- These are zone transfer DNS queries to primary DNS server.

access-list 110 permit tcp host secondary DNS server gt 1023 host primary DNS server eq 53

!--- Permit older DNS zone transfers.

access-list 110 permit tcp host secondary DNS server eq 53  host primary DNS server eq 53

!--- Deny all other DNS traffic.

access-list 110 deny udp any any eq 53
access-list 110 deny tcp any any eq 53

!--- Allow IPSec VPN traffic.

access-list 110 permit udp any host IPSec headend device eq 500
access-list 110 permit udp any host IPSec headend device eq 4500
access-list 110 permit 50 any host IPSec headend device
access-list 110 permit 51 any host IPSec headend device
access-list 110 deny   ip any host IPSec headend device

!--- These are Internet-sourced connections to
!--- publicly accessible servers.

access-list 110 permit tcp any host public web server eq 80
access-list 110 permit tcp any host public web server eq 443
access-list 110 permit tcp any host public FTP server eq 21

!--- Data connections to the FTP server are allowed
!--- by the permit established ACE.
!--- Allow PASV data connections to the FTP server.

access-list 110 permit tcp any gt 1023 host public FTP server gt 1023
access-list 110 permit tcp any host public SMTP server eq 25

!--- Explicitly deny all other traffic.

access-list 101 deny ip any any 

• log se puede utilizar para proporcionar detalles adicionales sobre el origen y los destinos de un protocolo determinado. Aunque esta palabra clave proporciona información valiosa sobre los detalles de los aciertos de ACL, los aciertos excesivos a una entrada de ACL que utiliza el log aumenta la utilización de la CPU. El impacto del rendimiento asociado con el registro varía de acuerdo a la plataforma.

• Los mensajes ICMP inalcanzables se generan para los paquetes que una ACL niega administrativamente. Esto podría afectar el rendimiento del router y del link. Considere el uso de la no ip unreachables para inhabilitar los IP inalcanzables en la interfaz donde se implementa la ACL de tránsito (borde).

• Esta ACL se puede implementar inicialmente con todos los permit para garantizar que el tráfico legítimo de la empresa no sea denegado. Una vez que se haya identificado y contabilizado el tráfico legítimo de la empresa, el deny se pueden configurar.

ACL y paquetes fragmentados

Las ACL tienen un fragments que permite un comportamiento especializado de gestión de paquetes fragmentados. En general, los fragmentos no iniciales que coinciden con las sentencias de la Capa 3 (protocolo, dirección de origen y dirección de destino), independientemente de la información de la Capa 4 en una ACL, se ven afectados por el permit or deny de la entrada coincidente. Tenga en cuenta que el uso de la fragments puede forzar a las ACL a denegar o permitir fragmentos no iniciales con más granularidad.

El filtrado de fragmentos agrega una capa adicional de protección contra un ataque de denegación de servicio (DoS) que utiliza sólo fragmentos no iniciales (como FO > 0). El uso de un deny para los fragmentos no iniciales al principio de la ACL impide que todos los fragmentos no iniciales accedan al router. En raras circunstancias, una sesión válida podría requerir fragmentación y, por lo tanto, filtrarse si un deny fragment existe en la ACL. Entre las condiciones que podrían provocar la fragmentación se incluyen el uso de certificados digitales para la autenticación ISAKMP y el uso de NAT Traversal IPSec.

Por ejemplo, considere la ACL parcial que se muestra aquí.

access-list 110 deny tcp any Internet routable subnet fragments
access-list 110 deny udp any Internet routable subnet fragments
access-list 110 deny icmp any Internet routable subnet fragments
<rest of ACL>

Al agregar estas entradas al principio de una ACL, se deniega el acceso a la red a cualquier fragmento no inicial, mientras que los paquetes no fragmentados o los fragmentos iniciales pasan a las líneas siguientes de la ACL no afectadas por la deny fragment declaraciones. El fragmento de ACL anterior también facilita la clasificación del ataque, ya que cada protocolo (UDP, TCP e ICMP) incrementa contadores independientes en la ACL.

Dado que muchos ataques dependen de la inundación de paquetes fragmentados, el filtrado de fragmentos entrantes en la red interna proporciona una medida adicional de protección y ayuda a garantizar que un ataque no pueda inyectar fragmentos simplemente haciendo coincidir las reglas de la capa 3 en la ACL de tránsito.

Refiérase a Listas de Control de Acceso y Fragmentos IP para obtener una descripción detallada de las opciones.

Evaluación de riesgo

Cuando implemente ACL de protección del tráfico de tránsito, considere dos áreas clave de riesgo.

• Asegúrese de que el permit/deny ya se han establecido. Para que la ACL sea efectiva, debe permitir todos los protocolos requeridos.

• El rendimiento de ACL varía de una plataforma a otra. Antes de implementar las ACL, revise las características de rendimiento del hardware.

Cisco recomienda probar este diseño en el laboratorio antes de la implementación.

Apéndices

Protocolos y aplicaciones de uso común

Nombres de puertos TCP

Esta lista de nombres de puerto TCP se puede utilizar en lugar de números de puerto cuando configura la ACL en Cisco IOS^® Software. Consulte el RFC del número asignado actual para encontrar una referencia a estos protocolos. Los números de puerto que corresponden a estos protocolos también pueden ser encontrados por mientras usted configura la ACL ingresando un ? en lugar de un número de puerto.

bgp	kshell
chargen	login
cmd	lpd
daytime	nntp
discard	pim
domain	pop2
echo	pop3
exec	smtp
finger	sunrpc
ftp	syslog
ftp-data	tacacstalk
gopher	telnet
hostname	time
ident	uucp
irc	whois
klogin	www

Nombres de puertos UDP

Esta lista de nombres de puerto UDP se puede utilizar en lugar de números de puerto cuando configura la ACL en Cisco IOS Software. Consulte el RFC del número asignado actual para encontrar una referencia a estos protocolos. Los números de puerto que corresponden a estos protocolos también pueden ser encontrados por mientras usted configura la ACL ingresando un ? en lugar de un número de puerto.

biff	ntp
bootpc	pim-auto-rp
bootps	rip
discard	snmp
dnsix	snmptrap
domain	sunrpc
echo	syslog
isakmp	tacacs
mobile-ip	talk
nameserver	tftp
netbios-dgm	time
netbios-ns	who
netbios-ss	xdmcp

Directrices de implementación

Cisco recomienda prácticas de implementación conservadoras. Debe tener una comprensión clara de los protocolos requeridos para implementar satisfactoriamente las ACL de tránsito. Estas directrices describen un método muy conservador para la implementación de ACL de protección que utilizan un enfoque iterativo.

1. Identifique los protocolos utilizados en la red con una ACL de clasificación.

   Implemente una ACL que permita todos los protocolos conocidos que se utilizan en la red. Esta detección o clasificación ACL debe tener una dirección de origen de any y un destino de una dirección IP o de toda la subred IP enrutable de Internet. Configure una última entrada que permita ip any any log para ayudarle a identificar los protocolos adicionales que debe permitir.

   El objetivo es determinar todos los protocolos requeridos que están en uso en la red. Utilice el registro para el análisis para determinar qué más podría comunicarse con el router.

   

   Nota: aunque el log proporciona información valiosa sobre los detalles de los aciertos de ACL, los aciertos excesivos a una entrada de ACL que utiliza esta palabra clave pueden resultar en un número abrumador de entradas de registro y posiblemente un uso elevado de la CPU del router. Use el comando log durante breves períodos de tiempo y solo cuando sea necesario para ayudar a clasificar el tráfico.

   Tenga en cuenta que la red está en riesgo de sufrir un ataque mientras que una ACL consta de todas las permit se encuentra en su lugar. Realice el proceso de clasificación lo antes posible para que se puedan establecer los controles de acceso adecuados.

2. Revise los paquetes identificados y comience a filtrar el acceso a la red interna.

   Una vez identificados y revisados los paquetes filtrados por ACL en el paso 1, actualice la clasificación ACL para que contabilice los nuevos protocolos y direcciones IP identificadas. Agregue entradas de ACL para evitar la suplantación de identidad. Según sea necesario, sustituya determinadas deny entradas para permit en la ACL de clasificación. Puede utilizar el show access-list comando para supervisar deny las entradas se pueden supervisar para el recuento de aciertos. Proporciona información sobre los intentos de acceso de red prohibidos sin tener que habilitar el inicio de sesión en entradas ACL. La última línea de la ACL debe ser un deny ip any any. Una vez más, el recuento de aciertos de esta última entrada puede proporcionar información sobre los intentos de acceso prohibidos.

3. Supervise y actualice la ACL.

   Supervise la ACL completa para asegurarse de que los protocolos requeridos recientemente introducidos se agregan de una manera controlada. Si monitorea la ACL, también proporciona información sobre los intentos de acceso a la red prohibidos que podrían proporcionar información sobre ataques inminentes.

Ejemplo de implementación

Este ejemplo muestra una ACL de tránsito que protege una red basada en este direccionamiento.

• La dirección IP del router del ISP es 10.1.1.1.

  La dirección IP de cara a Internet del router de extremo es 10.1.1.2.

  La subred con capacidad de ruteo de Internet es 192.168.201.0 255.255.255.0.

  La cabecera de VPN es 192.168.201.100.

  El servidor web es 192.168.201.101.

  El servidor FTP es 192.168.201.102.

  El servidor SMTP es 192.168.201.103.

  El servidor DNS principal es 192.168.201.104.

  El servidor DNS secundario es 172.16.201.50.

La ACL de protección de tránsito se desarrolló en base a esta información. La ACL permite el peering eBGP al router ISP, proporciona filtros anti-simulación, permite el tráfico de retorno específico, permite el tráfico entrante específico y niega explícitamente todo el otro tráfico.

no access-list 110

!--- Phase 1 – Add anti-spoofing entries.
!--- Deny special-use address sources.
!--- See RFC 3330 for additional special-use addresses.

access-list 110 deny   ip 127.0.0.0 0.255.255.255 any
access-list 110 deny   ip 192.0.2.0 0.0.0.255 any
access-list 110 deny   ip 224.0.0.0 31.255.255.255 any
access-list 110 deny   ip host 255.255.255.255 any

!--- This deny statement should not be configured 
!--- on Dynamic Host Configuration Protocol (DHCP) relays.

access-list 110 deny   ip host 0.0.0.0 any

!--- Filter RFC 1918 space.

access-list 110 deny   ip 10.0.0.0 0.255.255.255 any
access-list 110 deny   ip 172.16.0.0 0.15.255.255 any
access-list 110 deny   ip 192.168.0.0 0.0.255.255 any

!--- Permit BGP to the edge router.

access-list 110 permit tcp host 10.1.1.1 gt 1023 host 10.1.1.2 eq bgp
access-list 110 permit tcp host 10.1.1.1 eq bgp host 10.1.1.2 gt 1023

!--- Deny your space as source (as noted in RFC 2827).

access-list 110 deny   ip 192.168.201.0 0.0.0.255 any

!--- Phase 2 – Explicitly permit return traffic.
!--- Allow specific ICMP types.

access-list 110 permit icmp any any echo-reply
access-list 110 permit icmp any any unreachable
access-list 110 permit icmp any any time-exceeded
access-list 110 deny   icmp any any

!--- These are outgoing DNS queries.

access-list 110 permit udp any eq domain host 192.168.201.104 gt 1023

!--- Permit older DNS queries and replies to primary DNS server.

access-list 110 permit udp any eq domain host 192.168.201.104 eq domain

!--- Permit legitimate business traffic.

access-list 110 permit tcp any 192.168.201.0 0.0.0.255 established
access-list 110 permit udp any range 1 1023 192.168.201.0 0.0.0.255 gt 1023

!--- Allow FTP data connections.

access-list 110 permit tcp any eq ftp-data 192.168.201.0 0.0.0.255 gt 1023

!--- Allow TFTP data and multimedia connections.

access-list 110 permit udp any gt 1023 192.168.201.0 0.0.0.255 gt 1023

!--- Phase 3 – Explicitly permit externally sourced traffic.
!--- These are incoming DNS queries.

access-list 110 permit udp any gt 1023 host 192.168.201.104 eq domain

!--- Zone transfer DNS queries to primary DNS server.

access-list 110 permit tcp host 172.16.201.50 gt 1023 host 192.168.201.104 eq domain

!--- Permit older DNS zone transfers.

access-list 110 permit tcp host 172.16.201.50 eq domain host 192.168.201.104 eq domain

!--- Deny all other DNS traffic.

access-list 110 deny   udp any any eq domain
access-list 110 deny   tcp any any eq domain

!--- Allow IPSec VPN traffic.

access-list 110 permit udp any host 192.168.201.100 eq isakmp
access-list 110 permit udp any host 192.168.201.100 eq non500-isakmp
access-list 110 permit esp any host 192.168.201.100
access-list 110 permit ahp any host 192.168.201.100
access-list 110 deny   ip any host 192.168.201.100


!--- These are Internet-sourced connections to
!--- publicly accessible servers.

access-list 110 permit tcp any host 192.168.201.101 eq www
access-list 110 permit tcp any host 192.168.201.101 eq 443
access-list 110 permit tcp any host 192.168.201.102 eq ftp



!--- Data connections to the FTP server are allowed 
!--- by the permit established ACE in Phase 3.
!--- Allow PASV data connections to the FTP server.

access-list 110 permit tcp any gt 1023 host 192.168.201.102 gt 1023
access-list 110 permit tcp any host 192.168.201.103 eq smtp

!--- Phase 4 – Add explicit deny statement.

access-list 110 deny   ip any any

Edge-router(config)#interface serial 2/0
Edge-router(config-if)#ip access-group 110 in

Información Relacionada

• Solicitudes de Comentarios (RFC)
• Soporte Técnico y Documentación - Cisco Systems