¿Por qué se reemplaza ARP por NDP en IPv6?


49

ARP fue reemplazado por el NDP (Neighbour Discovery Protocol). Pero no sé la razón exacta de esto.

  • ¿Hay algún problema de seguridad en ARP?
  • ¿Por qué ARP es reemplazado por NDP?
  • ¿Cuáles son las ventajas de ARP?

¿Alguien puede explicar esto en términos simples?

Respuestas:


67

¿Hay algún problema de seguridad en ARP?

Si. Aquí están algunos:

  • ARP Spoofing.

    Los mensajes ARP falsos se envían a través de una LAN, lo que resulta en la vinculación de la dirección MAC de un atacante con la dirección IP de una computadora o servidor legítimo en la red.

    Consulte a continuación para obtener más información sobre ARP Spoofing / Poisoning.

  • Inundaciones MAC.

    La tabla de traducción que rastrea qué direcciones MAC están en qué puertos físicos tiene una cantidad limitada de memoria. Esto permite explotar un interruptor inundando la tabla de traducción. Los conmutadores primitivos, sin saber cómo manejar el exceso de datos, se abrirán por error y transmitirán todas las tramas de red a todos los puertos.

  • Duplicación de MAC.

    En un ataque de duplicación de MAC, un conmutador se confunde al pensar que dos puertos tienen la misma dirección MAC. Dado que los datos se reenviarán a ambos puertos, no es necesario reenviar IP.

Seguridad de origen del protocolo de resolución de direcciones TCP / IP (ARP)


¿Por qué se reemplazó ARP por NDP?

Proporciona mejoras y características adicionales para IPv6.

Consulte a continuación una comparación de NDP y los protocolos Protocolo de resolución de direcciones [ARP], ICMP Router Discovery [RDISC] e ICMP Redirect [ICMPv4].


¿Cómo se defiende el NDP contra la suplantación / envenenamiento por ARP?

Utiliza el protocolo Secure Neighbor Discovery (SEND). Las direcciones generadas criptográficamente aseguran que la fuente reclamada de un mensaje NDP sea el propietario de la dirección reclamada.

Una de las funciones del Protocolo de descubrimiento de vecinos (NDP) IPv6 es resolver las direcciones de la capa de red (IP) para vincular las direcciones de la capa (por ejemplo, Ethernet), una función realizada en IPv4 por el Protocolo de resolución de direcciones (ARP). El protocolo Secure Neighbor Discovery (SEND) evita que un atacante que tiene acceso al segmento de difusión abuse de NDP o ARP para engañar a los hosts para que envíen el tráfico del atacante destinado a otra persona, una técnica conocida como envenenamiento por ARP.

Para protegerse contra el envenenamiento por ARP y otros ataques contra las funciones de NDP, SEND debe implementarse donde no sea posible impedir el acceso al segmento de transmisión.

SEND utiliza pares de claves RSA para producir direcciones generadas criptográficamente, como se define en RFC 3972, Direcciones generadas criptográficamente (CGA). Esto garantiza que la fuente reclamada de un mensaje NDP sea el propietario de la dirección reclamada.

Fuente Configuración de descubrimiento de vecino IPv6 seguro


¿Cómo funciona ARP Spoofing?

ARP Spoofing también se conoce como ARP Poison Routing (APR) o ARP Cache Poisoning.

La falsificación de ARP es un tipo de ataque en el que un actor malicioso envía mensajes ARP (Protocolo de resolución de direcciones) falsificados a través de una red de área local. Esto da como resultado la vinculación de la dirección MAC de un atacante con la dirección IP de una computadora o servidor legítimo en la red.

Una vez que la dirección MAC del atacante está conectada a una dirección IP auténtica, el atacante comenzará a recibir los datos destinados a esa dirección IP.

La falsificación de ARP puede permitir que las partes maliciosas intercepten, modifiquen o incluso detengan los datos en tránsito. Los ataques de falsificación de ARP solo pueden ocurrir en redes de área local que utilizan el Protocolo de resolución de direcciones.

Fuente Veracode ARP Spoofing


¿Cómo funciona un ataque ARP Spoofing Attack?

Los pasos para un ataque de suplantación de ARP generalmente incluyen:

  1. El atacante abre una herramienta de falsificación de ARP y establece la dirección IP de la herramienta para que coincida con la subred IP de un objetivo. Los ejemplos de software de suplantación de identidad de ARP populares incluyen Arpspoof, Cain & Abel, Arpoison y Ettercap.

  2. El atacante usa la herramienta ARP spoofing para buscar las direcciones IP y MAC de los hosts en la subred del objetivo.

  3. El atacante elige su objetivo y comienza a enviar paquetes ARP a través de la LAN que contienen la dirección MAC del atacante y la dirección IP del objetivo.

  4. Como otros hosts en la LAN almacenan en caché los paquetes ARP falsificados, los datos que esos hosts envían a la víctima irán al atacante. Desde aquí, el atacante puede robar datos o lanzar un ataque de seguimiento más sofisticado.

Fuente Veracode ARP Spoofing

El atacante puede optar por inspeccionar los paquetes (espiar), mientras reenvía el tráfico a la puerta de enlace predeterminada real para evitar el descubrimiento, modificar los datos antes de reenviarlos (ataque de hombre en el medio) o lanzar una denegación de servicio ataque causando que algunos o todos los paquetes en la red sean descartados.

Fuente Wikipedia ARP spoofing


Comparación [de NDP] con IPv4

El protocolo IPv6 Neighbour Discovery corresponde a una combinación de los protocolos IPv4 Protocolo de resolución de direcciones [ARP], ICMP Router Discovery [RDISC] e ICMP Redirect [ICMPv4].

En IPv4 no existe un protocolo o mecanismo generalmente acordado para la Detección de Inalcanzabilidad de Vecino, aunque el documento de Requisitos de Hosts [HR-CL] especifica algunos algoritmos posibles para la Detección de Puerta Muerta (un subconjunto de los problemas que aborda la Detección de Inalcanzabilidad de Vecino).

El protocolo de Descubrimiento de Vecinos proporciona una multitud de mejoras sobre el conjunto de protocolos IPv4:

  • Router Discovery es parte del conjunto de protocolos base; no es necesario que los hosts "husmeen" los protocolos de enrutamiento.

  • Los anuncios de enrutador llevan direcciones de capa de enlace; no se necesita un intercambio de paquetes adicional para resolver la dirección de la capa de enlace del enrutador.

  • Los anuncios de enrutador llevan prefijos para un enlace; no es necesario tener un mecanismo separado para configurar la "máscara de red".

  • Los anuncios de enrutador habilitan la configuración automática de direcciones.

  • Los enrutadores pueden anunciar una MTU para que los hosts la usen en el enlace, asegurando que todos los nodos usen el mismo valor de MTU en enlaces que carecen de una MTU bien definida.

  • Las multidifusiones de resolución de direcciones se "distribuyen" en más de 16 millones (2 ^ 24) de direcciones de multidifusión, lo que reduce en gran medida las interrupciones relacionadas con la resolución de direcciones en nodos distintos del destino. Además, las máquinas que no son IPv6 no deben interrumpirse en absoluto.

  • Los redireccionamientos contienen la dirección de la capa de enlace del nuevo primer salto; no se necesita una resolución de dirección separada al recibir una redirección.

  • Se pueden asociar múltiples prefijos con el mismo enlace. De forma predeterminada, los hosts aprenden todos los prefijos en enlace de los anuncios de enrutador. Sin embargo, los enrutadores pueden configurarse para omitir algunos o todos los prefijos de los anuncios de enrutador. En tales casos, los hosts suponen que los destinos están fuera de enlace y envían tráfico a los enrutadores. Un enrutador puede emitir redireccionamientos según corresponda.

  • A diferencia de IPv4, el destinatario de una redirección de IPv6 supone que el nuevo siguiente salto está en enlace. En IPv4, un host ignora los redireccionamientos que especifican un siguiente salto que no está en el enlace de acuerdo con la máscara de red del enlace. El mecanismo de redireccionamiento IPv6 es análogo al recurso XRedirect especificado en [SH-MEDIA]. Se espera que sea útil en enlaces de medios compartidos y sin difusión en los que no es deseable o no es posible que los nodos conozcan todos los prefijos para destinos en enlace.

  • La detección de inalcanzabilidad vecina es parte de la base, lo que mejora significativamente la solidez de la entrega de paquetes en presencia de enrutadores defectuosos, enlaces parcialmente defectuosos o particionados, o nodos que cambian sus direcciones de capa de enlace. Por ejemplo, los nodos móviles pueden moverse fuera de enlace sin perder ninguna conectividad debido a cachés ARP obsoletos.

  • A diferencia de ARP, Neighbour Discovery detecta fallas de medio enlace (utilizando la Detección de inalcanzabilidad de vecinos) y evita enviar tráfico a los vecinos con los que la conectividad bidireccional está ausente.

  • A diferencia de IPv4 Router Discovery, los mensajes de anuncio de enrutador no contienen un campo de preferencia. El campo de preferencia no es necesario para manejar enrutadores de diferente "estabilidad"; la Detección de inalcanzabilidad vecina detectará enrutadores muertos y cambiará a uno en funcionamiento.

  • El uso de direcciones locales de enlace para identificar enrutadores de forma exclusiva (para anuncios de redireccionamiento y redireccionamiento de enrutadores) hace posible que los hosts mantengan las asociaciones de enrutadores en caso de que la numeración del sitio use nuevos prefijos globales.

  • Al establecer el Límite de saltos en 255, Neighbour Discovery es inmune a los remitentes fuera de enlace que envían mensajes ND accidental o intencionalmente. En IPv4, los remitentes fuera de enlace pueden enviar redireccionamientos ICMP y mensajes de anuncio de enrutador.

  • La ubicación de la resolución de la dirección en la capa ICMP hace que el protocolo sea más independiente de los medios que ARP y permite utilizar mecanismos genéricos de autenticación y seguridad de la capa IP, según corresponda.

Fuente RFC 4861 Descubrimiento de vecinos en IPv6


Otras lecturas


¿Cómo defiende el PND el envenenamiento por agaísta?
Grawity

@grawity Buena pregunta! Utiliza el Protocolo de descubrimiento de vecinos seguros (SEND). Respuesta actualizada
DavidPostill

2
Hmm, cuántos sistemas operativos realmente usan ENVIAR
grawity

2
@DavidPostill No, IPsec funciona en una capa diferente que ARP / NDP. Necesita un canal de comunicación que funcione para establecer sus características de seguridad.
scai

44
@DavidPostill Gran publicación. Sin embargo, su publicación es engañosa porque sugiere que SeND es (a) una parte integral del NDP y (b) una solución común. Este no es el caso: SeND es un complemento y no hay implementaciones de SeND aparte de las experimentales. Además, SeND tiene sus propias deficiencias y abre posibilidades para ataques de denegación de servicio. Finalmente, es razonable suponer que SeND nunca despegará (al menos no en su forma actual) y, por lo tanto, no se debe proponer demasiado alto.
contramode

9

NDP tiene más funciones que ARP , que incluyen:

  • A través de NDP, los dispositivos en la red pueden determinar la dirección MAC / capa de enlace (misma función que ARP).

  • Usando NDP, los dispositivos en la red pueden localizar la ruta para llegar a otro dispositivo en una red externa, ubicando el mejor enrutador para el dispositivo de destino.

  • NDP permite la configuración automática de direcciones IPv6.

Comparándolo con ARP, el mecanismo es diferente:

ARP usa mensajes de difusión, mientras que NDP usa mensajes ICMPv6 de multidifusión.

El dispositivo envía un mensaje de multidifusión llamado "Mensaje ICMP de solicitud de vecino" o NS . El dispositivo de destino responde con un "mensaje ICMP de anuncio vecino" o NA .

El mensaje NS utiliza una dirección de destino de multidifusión especial llamada dirección de multidifusión de nodo solicitada que representa a todos los hosts con los mismos últimos 24 bits de sus direcciones IPv6. El uso de multidifusión en lugar de difusión reduce el flujo de tráfico innecesario en la red.


5

La introducción de NDP en lugar de ARP se debió principalmente al deseo de consolidar los protocolos de control en torno a IP. IPv4 disfruta de varios protocolos de control como ICMP, IGMP y ARP / RARP. Con IPv6, NDP (sucesor de ARP) y MLD (sucesor de IGMP) se diseñaron como subprotocolos de ICMPv6 para que solo haya un protocolo de control. No hubo razón de seguridad para esto, ND es tan susceptible a la suplantación de identidad como lo es ARP, y ND no fue diseñado para la seguridad.

En los primeros días del desarrollo de IPv6, IPsec era visto como elmedida de seguridad genérica y, por lo tanto, obligatoria. Sin embargo, este requisito se ha degradado a una recomendación (RFC 6434, creo que se debe principalmente a los dispositivos integrados y al IoT, que simplemente no son capaces de realizar cálculos de clave pública, además de que tropezarían con problemas de PKI de todo tipo , de todos modos) y no funciona bien (hablando cortésmente) para asegurar ND. SeND se introdujo para agregar seguridad a ND, pero como para prácticamente todos los intentos anteriores en el diseño de software de seguridad retroactiva, el resultado fue, digamos, menos que óptimo. Como todavía no hay implementaciones de SeND, salvo algunas experimentales, a todos los efectos prácticos, SeND es inexistente. Además, hay razones para creer que SeND, al menos en su forma actual, nunca despegará.

Por el contrario, SAVI parece más prometedor, pero requiere cambios en la infraestructura de conmutación y los equipos con capacidad SAVI no tienen un precio bastante bajo, por lo que tampoco proliferará rápidamente. SAVI trabaja sobre la base de que dentro de un sitio se debe "conocer" qué asignaciones entre las direcciones HW (es decir, la dirección MAC) y las direcciones IP son legítimas y, por lo tanto, debería ser posible identificar y eliminar mensajes falsos de NDP.

Las mejores recetas son las más simples, pero a menudo se pasan por alto: divida las LAN grandes en otras más pequeñas, para que la suplantación de ARP y ND solo funcione para objetivos en la misma LAN. Por lo tanto, solo colocando dispositivos no confiables en sus propios segmentos de LAN (no se requieren reglas de firewall / filtrado) se reducirá en gran medida la superficie de ataque.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.