ARP falsificando con Scapy. ¿Cómo se desvía Scapy tráfico?

4

Fondo:

Entiendo que para que ARP pueda falsificar a una víctima en una red utilizando Scapy, debemos enviar paquetes de respuesta ARP a la víctima y al enrutador de la puerta de enlace con el destino y la dirección IP de origen correctos, pero con la dirección Mac de origen del atacante. esencialmente declarando que el atacante es la puerta de entrada a la víctima, y la víctima a la puerta de entrada, por lo tanto, es el hombre en el medio. Además, el atacante debería hacer eco de 1 en / proc / sys / net / ipv4 / ip_forward para habilitar el reenvío de IP

Pregunta:

Entonces, mi pregunta es, después de que Arp envenenó a la víctima y al gateway, ¿cómo se redirigirá el tráfico de la víctima al enrutador, y el tráfico de respuesta del enrutador se redirigirá a la víctima? ¿Necesitará el atacante cambiar las configuraciones del firewall en iptable? ¿Por ejemplo, en la cadena de enrutamiento previo de la tabla nat, redireccionar el puerto TCP de tráfico de la víctima 80 y 443 a la IP de la puerta de enlace, y también reenviar los paquetes de respuesta del enrutador (puerto src 80/443) a la víctima?

Como la mayoría de los ejemplos en la web no hablan de sus configuraciones de firewall, me preguntaba si cambiar la tabla nat para la cadena de enrutamiento previo también era un paso necesario para administrar un ataque MITM.

Ejemplo :

enlace Pregunta sobre este video de ejemplo: ¿Cómo en el mundo el atacante olfateó el paquete dns usando scapy simplemente filtrando el puerto TCP 80. Ya que en el video el atacante no mostraba ninguna configuración de firewall (iptables), asumí que todo el tráfico de la víctima Todos los paquetes de consulta DNS incluidos se enviaron al atacante, entonces, ¿cómo obtuvo la víctima la conexión con Google y Twitter si el atacante no reenvía el tráfico a la puerta de enlace / víctima?

¿Alguien puede explicar? Gracias de antemano.

    
pregunta Rennitbaby 18.01.2018 - 01:48
fuente

1 respuesta

5

Scapy no enruta el tráfico, ni toca el tráfico en este escenario. Cuando habilita el reenvío de IP en un host, se convierte en un enrutador. Cuando el host recibe un paquete que no está destinado a una de sus propias direcciones, enrutará el paquete por su tabla de enrutamiento. Dado que el tráfico de la víctima tiene una dirección IP de destino que no coincide con la máquina del atacante, en la mayoría de los casos, el tráfico se reenviará a la puerta de enlace predeterminada del atacante, que suele ser la puerta / enrutador de la red.

Por ejemplo, un atacante ha realizado un ataque de envenenamiento ARP bidireccional. La víctima piensa que la máquina del atacante es el enrutador, y el enrutador cree que la máquina del atacante es la de la víctima. La víctima envía un paquete a 8.8.8.8, que se recibe en la máquina del atacante. El paquete no está dirigido al atacante, por lo que se envía a la puerta de enlace predeterminada. La respuesta del servidor se comporta de la misma manera; el enrutador enviará el paquete dirigido a la víctima, que irá al atacante. Nuevamente, no está dirigido al atacante, por lo que se reenvía nuevamente.

Mencionas que hay reglas de firewall involucradas. Una configuración limpia de iptables tiene el valor predeterminado ACEPTAR para todas las cadenas. No hay nada que inhiba el enrutamiento de paquetes anterior una vez que el reenvío está activado en el kernel, a menos que se hayan agregado reglas de firewall para evitarlo.

    
respondido por el multithr3at3d 18.01.2018 - 04:29
fuente

Lea otras preguntas en las etiquetas