Linux responde a las solicitudes de ARP para otras interfaces, ¿podría ser una vulnerabilidad de seguridad?

Question

Linux responde a las solicitudes de ARP para otras interfaces, ¿podría ser una vulnerabilidad de seguridad?

#1 de SilverlightFox (1 votos)

3

Linux responde a las solicitudes de ARP en todas las interfaces de forma predeterminada.

Para explicar, diga que tiene esta configuración:

Client 1 ---> [eth1] server [eth0] <--- Client 2

Y el IP eth1 del servidor es 192.168.1.1 y el IP eth0 es 192.168.250.1. Estos están en dos redes separadas, aisladas.

Si el Cliente 1 envía una solicitud ARP para la IP 192.168.250.1, de manera predeterminada, el servidor Linux responderá con la dirección MAC de eth1. Este comportamiento se puede cambiar con la configuración arp_filter:

arp_filter - BOOLEAN
1 - Allows you to have multiple network interfaces on the same
subnet, and have the ARPs for each interface be answered
based on whether or not the kernel would route a packet from
the ARP'd IP out that interface (therefore you must use source
based routing for this to work). In other words it allows control
of which cards (usually 1) will respond to an arp request.

0 - (default) The kernel can respond to arp requests with addresses
from other interfaces. This may seem wrong but it usually makes
sense, because it increases the chance of successful communication.
IP addresses are owned by the complete host on Linux, not by
particular interfaces. Only for more complex setups like load-
balancing, does this behaviour cause problems.

arp_filter for the interface will be enabled if at least one of
conf/{all,interface}/arp_filter is set to TRUE,
it will be disabled otherwise

Incluso con arp_filter establecido en 1 , ¿es posible que el Cliente 1 envíe una solicitud normalmente restringida al 192.168.250.1, y que el servidor responda?

Por ejemplo, digamos que hay un oyente UDP en el servidor, escuchando en el puerto 123 de 192.168.250.1, que ejecuta un comando recibido en un paquete enviado. ¿Es posible que el Cliente 1 envíe una solicitud al servidor con la IP de destino establecida como 192.168.250.1, pero con la dirección MAC de eth1 en el encabezado de Ethernet? ¿El ajuste anterior afectará esto?

Para explicar esto con más detalle, ampliaré el diagrama:

Client 1 ---> [eth1 - 192.168.1.1] server [eth0 - 192.168.250.1] <--- Client 2

Como el oyente UDP está escuchando solo en 192.168.250.1:123, esto debería evitar que se conecte a la red 192.168.1.0/24. Sin embargo, debido al comportamiento anterior con respecto a las respuestas ARP, ¿esto también significa que el servidor aceptará conexiones a 192.168.250.1 sobre eth1?

¿Cuál es la mejor manera de probar esta vulnerabilidad y cómo se clasificaría?

network linux configuration ip

pregunta SilverlightFox 03.02.2016 - 19:33

fuente

1 respuesta

Lea otras preguntas en las etiquetas network linux configuration ip

¿Es seguro: autenticación de red social Wi-Fi + no segura para acceder a la web? ¿Cuándo vale la pena perseguir a un hacker?

score 1 · Accepted Answer

Sí, esto es posible, incluso con arp_filter establecido en 0.

Escucha del servidor:

# nc -nlvu -s 192.168.250.1 -p 123
listening on [192.168.250.1] 123 ...

Conexión del cliente 1: el cliente 1 está configurado para enrutar todo el tráfico a través del servidor, por lo que no necesita ninguna respuesta ARP para eth1:

# ncat -nvu 192.168.250.1 123 
Ncat: Version 7.01 ( https://nmap.org/ncat )
Ncat: Connected to 192.168.250.1:123.

El cliente 1 ahora puede comunicarse con el servidor, aunque no esté en la red conectada a eth1:

# ncat -nvu 192.168.250.1 123 
Ncat: Version 7.01 ( https://nmap.org/ncat )
Ncat: Connected to 192.168.250.1:123.
FOO
BAR

Comunicación mostrada en el servidor:

# nc -nlvu -s 192.168.250.1 -p 123
listening on [192.168.250.1] 123 ...
connect to [192.168.250.1] from (UNKNOWN) [192.168.1.2] 57677
FOO
BAR

Esto se debe a que Linux aceptará conexiones para todas las IP configuradas para todas las interfaces, incluso desde las interfaces que no tienen el socket enlazado. arp_filter solo afecta si esto se anuncia o no. Si este es un comportamiento no deseado, entonces IPTABLES puede usarse para evitar conexiones a direcciones IP no configuradas en una interfaz.

Esto podría ser una vulnerabilidad si la seguridad del servidor se basara en el hecho de que solo las conexiones a los servicios que escuchan en una dirección IP podrían conectarse desde la subred de esa interfaz.