Solicitudes de ARP de unidifusión: ¿Se considera dañino?

Después de un poco de ida y vuelta en la lista de correo de Snort (y no contactar al autor para esto Regla), he decidido tomar

  

No es el comportamiento definido, y aunque el Sondeo de ARP puede ser una cosa en algunos sistemas específicos, la regla aún debe estar allí porque no sabemos a priori si está justificado por algún contexto. Mecanismo específico. E incluso si nosotros no vemos cómo podrían ser peligrosos, no hay razón para que un anfitrión legítimo envíe solicitudes de unidifusión, por lo que debería desencadenar una alerta como cualquier otro ortodoxo. comportamiento.

para una respuesta. Ustedes plantean puntos interesantes, pero son más como suposiciones educadas y menos como la respuesta "definitiva" que busqué, que supongo que solo Jeff Nathan puede proporcionar.

Sin embargo, gracias por tus respuestas, sí aprendí de ellas.

NB: antes de mi edición, esta respuesta suponía que tal vez esto se debía a que el host agrega un emparejamiento de MAC < - > IP a su tabla, independientemente de si el paquete ARP entrante es una solicitud o una respuesta (y así podría inundar la tabla de un host enviando solicitudes), pero luego me di cuenta de que el algoritmo de recepción en RFC 826 hace que el host actualice su tabla siempre que el campo de Destino del Protocolo corresponda a su IP, por lo que la solicitud no tendría que Sé unicast para que este ataque funcione, de vuelta al punto uno.

NB2: Tuve una conversación divertida con un colega que tiene mucha más experiencia que yo sobre el tema. Le pregunté acerca de la regla y cuando le conté sobre ARP Polling, su primera reacción fue voltear completamente y volver a su máquina para asegurarse de que no estaba enviando este tipo de solicitudes. Debido a que no hay razón para que su computadora esté hablando con la red cuando he no significa :) (también porque argumenta que para un host con el que no se comunica con frecuencia, esta función de sondeo resulta inútil). tráfico).

El uso normal de ARP es a través de cuadros de transmisión, porque ARP está destinado a permitir Máquinas para descubrir las direcciones MAC de otros hosts: esto solo tiene sentido si la dirección MAC, de hecho, no se conoce de antemano. Normalmente, una máquina es responsable de responder a las solicitudes sobre sí misma: si alguien solicita la dirección MAC de la máquina que posee actualmente la dirección IP 10.0.17.42, se supone que dicha máquina responde; y, lo que es más importante, otros hosts en la red se abstendrán de responder, incluso si conocen la dirección MAC del propietario actual de la dirección 10.0.17.42.

El hecho de que solo el propietario de la dirección responda en realidad evita ahogar la red. Si alguna máquina respondía a todas las solicitudes que ve, entonces una solicitud ARP de difusión en una red ocupada podría desencadenar cientos de respuestas.

Para que una solicitud ARP de unidifusión tenga sentido, debe enviarse a un host para el cual se conoce la dirección MAC, por lo que no es el propietario de la dirección IP (de lo contrario, ¿cuál sería el punto de la solicitud)? pero ese host no responderá, por defecto. Por lo tanto, las solicitudes ARP de unidifusión legítimas solo se producirán en contextos donde exista un ARP-respondedor conocido que se haya configurado para responder a las solicitudes ARP de direcciones IP asignadas a otras máquinas. Esta es una configuración bastante inusual.

Un sistema Linux puede configurarse para responder a las solicitudes de ARP para las direcciones de otras máquinas; Esto se llama Proxy ARP . Sin embargo, el caso de uso principal es para algunos cortafuegos transparentes: la LAN se divide en varias LAN distintas, sin que las máquinas locales estén al tanto de la división. La máquina que conecta las sub-LAN juntas ejecuta ARP proxy para mantener la ilusión de una única LAN, mientras aún filtra las comunicaciones. Pero en ese caso, las máquinas desconocen de la configuración; una solicitud ARP de unidifusión solo se produciría desde una de las máquinas que de alguna manera sabría que se realizó una división de LAN.

Por lo tanto, en la práctica , las solicitudes de ARP de unidifusión son generalmente el signo de juego sucio. Las máquinas normales no hacen eso.

Posiblemente debido a ataque de inundación de MAC - una especie de ataque de inundación de unidifusión donde un atacante agotaría espacio en la tabla de asignación de MAC de un conmutador, por lo que no puede encuentre la dirección correcta en el caché de direcciones (todos fueron suministrados por el atacante), inundaría el paquete a todos los puertos (si un conmutador recibiera un paquete de unidifusión con una dirección de destino desconocida para él, el paquete se tratará como un paquete de difusión) y se envía a todos los hosts en la red). Después de que la mayoría / todos / los MAC legítimos de destino fueron forzados a salir de la tabla, es un buen momento para iniciar un rastreador de paquetes, ya que los paquetes que antes no estaban disponibles y que fueron expulsados por el interruptor supuestamente están disponibles para la captura. Incluso si no se pretende capturar un paquete, esto ya es un tipo de ataque DoS, especialmente. en redes grandes (debido a la cantidad de clientes que hablan con el conmutador), lo que sin duda degrada el rendimiento de la red.

Por cierto, las solicitudes ARP de unidifusión son legítimas según RFC1122 que se indica en la página 23:

  

(2) Encuesta de unidifusión: sondea de forma activa el host remoto                         enviando periódicamente una solicitud ARP punto a punto                         y elimine la entrada si no hay respuesta de ARP.                         Recibido de N encuestas sucesivas. De nuevo, el                         el tiempo de espera debe ser del orden de un minuto, y                         normalmente N es 2.

No conozco ningún uso legítimo para una solicitud ARP de unidifusión. Usted menciona que esta es una característica de algunas implementaciones; ¿Tienes más detalles sobre eso?

Sospecho que el uso malintencionado de una solicitud ARP de unidifusión es para eludir las características anti-spoofing. Por ejemplo, el kernel de Linux no escuchará una respuesta ARP no solicitada, pero puede usar una solicitud ARP falsa para engañarla y hacerla pensar que se solicita una respuesta. Y es menos probable que una solicitud de unidifusión afecte a otros dispositivos o sea notada que una solicitud de difusión.

Dado que hay tantas reglas en snort, sugiero que se centre en adquirir experiencia con una variedad de problemas, en lugar de centrarse en este único problema con gran detalle.