MANRS Guía de Implementación
- Introducción
- Coordinación
- Global de Validación
- Anti-Spoofing
- Filtrado
- Resumen y listas de verificación
- información Adicional
4.3. Anti-Spoofing-prevención del tráfico con direcciones IP de origen falsificadas
acciones esperadas de Manrs relevantes:
- El operador de red implementa un sistema que habilita la validación de direcciones de origen para al menos redes de clientes stub de un solo hogar, sus propios usuarios finales e infraestructura., El operador de red implementa el filtrado anti-spoofing para evitar que los paquetes con dirección IP de origen incorrecta entren y salgan de la red.
la suplantación de direcciones IP es la práctica de originar datagramas IP con direcciones de origen distintas a las asignadas al host de origen. En términos simples, el anfitrión pretende ser otro host. Esto se puede explotar de varias maneras, sobre todo para ejecutar ataques de amplificación de reflexión de denegación de Servicio (DoS) que causan que un host reflector envíe tráfico a la dirección falsificada.,
Hay muchas recomendaciones para evitar la suplantación de IP mediante el filtrado de entrada, por ejemplo, verificar las direcciones de origen de los datagramas IP cerca del borde de la red. La mayoría de los proveedores de equipos admiten el filtrado de entrada de alguna forma. Desde 2005, el despliegue de técnicas anti-spoofing no ha sido una limitación del rendimiento del equipo. Ha sido una limitación del deseo y la voluntad de desplegar y mantener la configuración anti-spoofing.
irónicamente, los ataques de amplificación de DoS significativos pueden ser costosos para los proveedores de servicios., Los costos perjudican a la marca, dañan las operaciones de los clientes y tienen un impacto colateral operativo/de costos en otros clientes. Estos ataques de amplificación de DoS son prevenibles. Sería imposible sin spoofing.
esto demuestra que el filtrado de entrada definitivamente no está suficientemente desplegado. Desafortunadamente, no hay beneficios para un proveedor de servicios (SP) que implementa filtrado de ingreso. También existe la creencia generalizada de que el filtrado de ingresos solo ayuda cuando se implementa universalmente.,
los enfoques comunes para este problema han involucrado características de software como SAV (validación de dirección de origen) en redes de cable-módem o validación estricta uRPF (unicast Reverse-Path Forwarding) en redes de enrutadores. Estos métodos pueden aliviar la sobrecarga de la administración en casos donde el enrutamiento y la topología son relativamente dinámicos. Otro enfoque podría ser utilizar la información del filtro de prefijo entrante para crear un filtro de paquetes, que solo permitiría paquetes con direcciones IP de origen para las que la red podría anunciar legítimamente la accesibilidad.,
para la mayoría de las arquitecturas de red más pequeñas y simples, la forma más fácil de evitar la suplantación es mediante el uso de unicast RPF (uRPF) en modo estricto. Para filtrar las direcciones de origen utilizadas por los dispositivos en un dominio de capa 2, se pueden utilizar las mejoras de validación de direcciones de origen (SAVI). En equipos donde las funciones de filtrado automático no están disponibles, puede usar listas de control de acceso (ACL) para implementar manualmente un filtrado equivalente. Todas estas tecnologías se explican a continuación.
4.3.1., Principios rectores para arquitecturas Anti-Spoofing
para ser lo más eficaz posible, las técnicas anti-spoofing deben aplicarse lo más cerca posible de la fuente. En las redes empresariales, las direcciones de origen utilizadas por cada dispositivo a menudo se controlan y aplican para que las auditorías de seguridad puedan identificar exactamente qué dispositivo envió Qué paquete.
para una implementación exitosa de MANRS, tal granularidad fina a nivel de dispositivo no es necesaria, ya que MANRS se centra en la seguridad de enrutamiento y anti-spoofing a nivel de red., Por lo tanto, las arquitecturas anti-spoofing comunes se centran en asegurarse de que los clientes no envíen paquetes con las direcciones de origen incorrectas.
imponer el uso de direcciones de origen válidas a nivel de cliente tiene la ventaja de que los clientes no pueden falsificar las direcciones de los demás, lo que evita que causen problemas entre sí que sean difíciles de depurar.
si por alguna razón no es posible imponer el uso de direcciones de origen por cliente, entonces una alternativa es hacerlo en puntos de agregación para que los clientes estén al menos limitados en qué direcciones pueden falsificar., Como mínimo, debe haber anti-spoofing a nivel de ISP para que los clientes no puedan falsificar direcciones de otras organizaciones y causar problemas a escala de Internet.
4.3.2. Unicast RPF
BCP38 uRPF Strict Mode with RFC1998++ style of multihoming (a bcp for multihoming) is an approach that works in symmetrical (single homed) and asymmetrical (multihomed BGP) configurations, and was first operationally deployed in 2002. Sí, hay muchos que piensan que «uRPF no funciona debido a la asimetría de enrutamiento», pero esto no es cierto., La documentación de 2001, el documento técnico de ISP Essentials (Google para la versión 2.9) y el libro de ISP Essentials (ISBN 1587050412) junto con las implementaciones en varios SPs principales han demostrado que el modo estricto de uRPF es una técnica viable.
Hay cuatro algoritmos para uRPF: modo estricto (verificar IP de origen y adyacencia), modo suelto (verificar Solo IP de origen), ruta factible (verificar IP de origen con las alternativas de la FIB) y modo VRF (permitir/denegar verificación de origen en una tabla separada de la FIB)., Cada una de estas opciones de uRPF está diseñada para funciones específicas de «anti-spoofing» en diferentes partes de la red.
- uRPF Strict Mode-BCP38 en el borde del cliente-SP. Cada paquete entrante se prueba contra la FIB y si la interfaz entrante no es la mejor ruta inversa, el paquete se elimina.
- uRPF Loose Mode-sRTBH en cualquier lugar de la red – pero solo verifique si la ruta está en la FIB. Si no en la fibrilación, entonces caer. Si está en la fibrilación, entonces pase. Bueno para sRTBH y mitigar un poco de tráfico falsificado en el borde de peering.,
- uRPF ruta factible-sRTBH en cualquier lugar de la red y BCP38 para clientes multihomed y rutas asimétricas. En el modo factible, el FIB mantiene rutas alternativas a una dirección IP dada. Si la interfaz entrante coincide con cualquiera de las rutas asociadas con la dirección IP, entonces el paquete se reenvía. De lo contrario, el paquete se deja caer.
- uRPF VRF Mode-aplicación de políticas de emparejamiento basadas en BGP o sRTBH más granular (nota: el modo VRF puede usarse como BCP38, pero no se ha probado operativamente)
uRPF puede ser útil en muchos lugares de la red., Se utiliza con mayor frecuencia en los bordes de las redes donde los clientes, servidores y / o clientes están conectados porque el modo estricto funciona bien allí. Los operadores de red dudan en usar uRPF en el núcleo de sus redes debido al temor de dejar caer accidentalmente el tráfico válido que ha tomado un camino inesperado a través de su red. uRPF Feasible Path mode debería resolver estos problemas.
tanto Cisco como Juniper implementan tanto el modo estricto como el modo suelto. Mostramos cómo usar el modo estricto., Configurar uRPF Modo Estricto en las interfaces hacia los clientes con:
Cisco:
ip verify unicast source reachable-via rx ipv6 verify unicast source reachable-via rxJuniper:
family inet { rpf-check; } family inet6 { rpf-check; }Que asegurarse de que el cliente sólo podrá utilizar las direcciones IP que usted ruta. En situaciones en las que usted es cliente de otro ISP donde tiene una ruta predeterminada que apunta a ese ISP, debe usar:
Cisco:
ip verify unicast source reachable-via rx allow-default ipv6 verify unicast source reachable-via rx allow-defaultJuniper:
Los routers Juniper adaptan automáticamente su filtrado uRPF en función de hacia dónde apuntan las rutas predeterminadas. Simplemente use los mismos comandos que los anteriores.,
la opción allow-default es necesaria porque de forma predeterminada las direcciones de origen solo se compararán con rutas específicas, ignorando la ruta predeterminada. Si bien hacer coincidir la ruta predeterminada parece ser lo mismo que permitir cualquier cosa, no lo es. se asegura de que su fuente no le envíe tráfico para el que tiene otras rutas más específicas que apuntan en una dirección diferente, como sus propias redes y las redes de sus clientes. Esto lo protegerá contra el tráfico falsificado de otros.
4.3.3., Lista de acceso dinámico (Radius & Diameter)
la forma estándar de establecer listas de acceso para los usuarios autenticados por Radius es a través del atributo Radius 11 (Filter-Id). Con este atributo puede decirle al enrutador que aplique una lista de acceso preexistente a la conexión del usuario. Sin embargo, esto requiere un método fuera de banda para aprovisionar todos los enrutadores con las listas de acceso correctas.
algunos proveedores tienen opciones adicionales de Radius que se pueden usar para aprovisionar dinámicamente la propia lista de acceso a través de Radius., Cisco, por ejemplo, proporciona funcionalidad adicional a través de los atributos cisco-avpair:
cisco-avpair = "ip:inacl#5=permit ip 192.0.2.0 0.0.0.255 any" cisco-avpair = "ip:inacl#99=deny ip any any"esto solo permitiría paquetes del cliente que tengan una dirección de origen en el rango 192.0.2.0/24.
4.3.4. SAVI
SAVI es el nombre del grupo de trabajo de IETF que trabaja en las mejoras de validación de direcciones de origen. Para la validación de la dirección de origen de un cliente, se utiliza comúnmente la solución SAVI para DHCP en RFC 7513., Esta versión de SAVI realiza un seguimiento de todas las direcciones IP que se han asignado a cada dispositivo husmeando en los intercambios de mensajes DHCPv4 y DHCPv6 en el conmutador de red al que está conectado el cliente. Si un cliente utiliza una dirección de origen no autorizada, el conmutador eliminará el paquete.
Los proveedores a menudo usan su propia terminología para describir las características de SAVI. En los dispositivos Cisco, estas características se denominan DHCP Snooping, Source Guard y Prefix Guard.
4.3.5., IP Verify Source
Las redes Ethernet son dominios de difusión y, de forma predeterminada, no hay validación de quién puede enviar paquetes con qué direcciones. Para configurar los switches de Cisco para verificar las direcciones de origen utilizadas por los dispositivos conectados, se puede usar la configuración «IP verify source».,
Hay tres variantes de esta característica:
● ip verify source
● ip verify source port-security
● ip verify source tracking port-security
La primera variante comprueba la dirección IP de origen, la segunda variante, también se verifica la dirección MAC de origen y la tercera variante pistas de los enlaces entre la dirección IP y la dirección MAC. Para evitar que los clientes utilicen la dirección MAC de otro cliente, se recomienda la última variante. Todos estos basan su decisión en datos DHCP fisgoneados.,
antes de poder verificar las direcciones de origen, el conmutador debe configurarse para espiar el tráfico DHCP para recopilar datos en los que basar sus decisiones con ip dhcp snooping. Para realizar un seguimiento de qué puerto ethernet se conecta a cada cliente DHCP, use la opción DHCP 82 con ip dhcp snooping information option. Esto es necesario porque con verify port-security el conmutador no aprenderá las direcciones MAC hasta que el servidor DHCP haya asignado una dirección IP al dispositivo conectado. Por lo tanto, la opción 82 es necesaria para recordar al conmutador dónde estaba conectado el cliente.,
Hay varios pasos necesarios para habilitar el seguimiento seguro de los dispositivos y verificar sus direcciones de origen. El primer paso es habilitar el» seguimiento de dispositivos ip » globalmente en el switch. Esto asegura que el conmutador pueda rastrear qué dirección IP pertenece a qué dirección MAC. Luego, en cada interfaz, defina el número de dispositivos que pueden conectarse con ip device tracking maximum num donde num puede ser un número de 1 a 10. Ahora habilite switchport port-security en cada interfaz para asegurarse de que solo se utilicen las direcciones MAC permitidas., Y, finalmente, habilite la función de verificación que vincula todos estos con ip verify source tracking port-security.
ahora el switch tiene toda la información que necesita para espiar el tráfico DHCP, vincular las direcciones IP a las direcciones MAC y verificar que todos los paquetes enviados a través del switch se ajustan al estado recopilado que se basa en las respuestas del servidor DHCP. Los paquetes que no se ajusten a lo que el servidor DHCP ha asignado serán eliminados.
4.3.6. Fuente de Cable: verifique
las redes de módem de Cable son en muchos sentidos similares a las redes ethernet., A menos que se configure de otra manera, los usuarios pueden falsificar direcciones de origen o robar las direcciones de otros usuarios de la red de cable. La función Cisco cable source-verify permite al operador CMTS limitar qué direcciones de origen puede usar un usuario.
Hay dos variantes de esta característica:
● cable source-verify
● cable source-verify dhcp
Ambas variantes afectan a la cual aborda desde el cable de red de la subred están autorizados a utilizar. La primera variante solo evita que los usuarios roben las direcciones de los demás y, por lo tanto, no es suficiente para MANRS., Veremos la segunda variante.
configurar cable source-verify dhcp indica a los CMTS que todas las direcciones de origen deben verificarse con los arrendamientos DHCP que los CMTS hayan visto. Si se envía un paquete con una fuente diferente, el CMTS lo soltará. Esto evitará que los usuarios utilicen direcciones no asignadas a ellos a través de DHCP .
Pueden producirse problemas cuando se recarga el CMTS. En tal caso, los CMTS no conocerán todos los arrendamientos DHCP de sus usuarios y podrían eliminar el tráfico legítimo. Para resolver esto, el CMTS se puede configurar para usar el protocolo DHCP LeaseQuery., Esto permite a los CMTS preguntar al servidor DHCP sobre los arrendamientos para el tráfico que está viendo. Una vez que el servidor DHCP confirme que hay un arrendamiento legítimo para esa dirección, el CMTS la agregará a su caché y permitirá que pase el tráfico.
para configurar el CMTS para que no confíe en ARP en la red de cable, configúrelo con no cable arp. Esto asegurará que solo la información aprendida de DHCP y LeaseQuery sea confiable al verificar las direcciones de origen.
la función cable source-verify solo protege la subred de la propia red de cable., Para evitar que los usuarios suplanten otras direcciones y para permitir el tráfico de clientes que tienen una subred enrutada que pueden usar, configure también ip verify unicast source reachable-via rx para habilitar el modo estricto uRPF en la red de cable. Eso comprobará todas las direcciones de origen que no están directamente en la red de cable y permitirá validar contra, por ejemplo, rutas estáticas para subredes enrutadas hacia clientes.
4.3.7., Lista de control de acceso (ACL)
las ACL se implementan comúnmente en el límite entre el borde del proveedor (PE) y el borde del cliente (CE), pero también son muy útiles en otros lugares, como en el servidor del proveedor, el cliente y las redes de infraestructura para evitar que los dispositivos se comporten mal. La estrategia optimizada de ACL sería colocar un filtro de permisos explícito en la interfaz del cliente. Los filtros de permisos explícitos permiten rangos de direcciones específicos y luego niegan todo lo demás. Por ejemplo, si al cliente del operador se le asigna 192.0.2.0/24, la ACL BCP 38 permitiría todas las direcciones de origen de 192.0.2.,0/24 y luego denegar todos los paquetes cuya dirección de origen no sea 192.0.2.0 / 24.
en las interfaces descendentes del ISP, debe haber filtros que verifiquen las direcciones de origen utilizadas por sus clientes. Si uRPF no se puede utilizar, entonces las ACLs manuales son necesarias. Vamos a tomar el primer cliente del ejemplo anterior diagrama:
Cisco:
Juniper:
4.3.7.1., Puntos de agregación
cuando las ACLs en el límite PE-CE no son posibles, por ejemplo, porque varios clientes están conectados a una sola red de capa 2 y los dispositivos de capa 2 no tienen las características para filtrar la información de la capa 3, filtrar en un punto de agregación es la segunda mejor solución.
en este ejemplo (por alguna razón no especificada) no es posible filtrar en el /24 para cada cliente. En ese caso filtrado en 192.0.2.0 / 23 y 198.51.100.,0/23 (y de manera similar para IPv6) en un punto de agregación cerca de las conexiones del cliente al menos limitaría las posibilidades de suplantación para ese grupo de clientes a un pequeño rango de direcciones.
la configuración se realiza de la misma manera que se muestra en la sección anterior, excepto que ahora se realiza en un enrutador diferente en una ubicación más central en la red.
4.3.8. Carrier Grade NAT – ¿es NAT una herramienta anti-falsificación?
por defecto muchas implementaciones NAT no filtran la dirección de origen de los clientes., Tome por ejemplo una configuración NAT simple en un router Cisco como:
ip nat inside source list INSIDE pool OUTSIDE overloadEsta regla NAT traducirá paquetes con una dirección de origen en la lista de acceso Dentro y cambiará la dirección de origen a una dirección en el grupo exterior. Sin embargo, los paquetes que tienen una dirección de origen falsificada que no está incluida en la lista de acceso interior serán reenviados sin ninguna traducción, lo que resulta en paquetes falsificados en Internet., Cuando un paquete falsificado coincide con la lista de acceso, se traducirá utilizando el pool especificado, por lo que el mundo exterior no verá una dirección de origen falsificada, pero será imposible para el operador NAT rastrear los paquetes falsificados hasta su originador.
esto muestra que NAT no es una herramienta anti-spoofing. Incluso cuando se utiliza NAT, las direcciones de origen utilizadas por los clientes deben verificarse lo más cerca posible del cliente, al igual que en los casos sin NAT mostrados anteriormente en este capítulo. Solo entonces se puede evitar que los paquetes falsificados y/o no rastreables lleguen a Internet.