Linux risponde alle richieste ARP per altre interfacce - potrebbe essere una vulnerabilità di sicurezza?

Question

Linux risponde alle richieste ARP per altre interfacce - potrebbe essere una vulnerabilità di sicurezza?

#1 da (1 voti)

3

Linux risponde alle richieste ARP su tutte le interfacce per impostazione predefinita.

Per spiegare, dì che hai questa configurazione:

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

E l'IP eth1 del server è 192.168.1.1 e eth0 IP è 192.168.250.1. Questi sono su due reti isolate separate.

Se il client 1 invia una richiesta ARP per l'IP 192.168.250.1, per impostazione predefinita il server Linux risponderà con l'indirizzo MAC di eth1. Questo comportamento può essere modificato con l'impostazione 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

Anche se arp_filter è impostato su 1 , è possibile che il Cliente 1 invii una richiesta normalmente limitata a 192.168.250.1 e abbia la risposta del server?

Ad esempio, diciamo che c'è un listener UDP sul server, in ascolto sulla porta 192.168.250.1 123, che esegue un comando ricevuto in un pacchetto inviato. È possibile che Client 1 invii una richiesta al server con l'IP di destinazione impostato come 192.168.250.1, ma con l'indirizzo MAC di eth1 nell'intestazione ethernet? L'impostazione sopra influirà su questo?

Per spiegarlo ulteriormente, espanderò il diagramma:

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

Poiché il listener UDP è in ascolto solo su 192.168.250.1:123, ciò dovrebbe impedire a qualsiasi dispositivo sulla rete 192.168.1.0/24 di connettersi ad esso. Tuttavia, a causa del comportamento sopra riportato in merito alle risposte ARP, significa anche che il server accetterà connessioni a 192.168.250.1 su eth1?

Qual è il modo migliore per testare questa vulnerabilità e come sarebbe classificato?

linux configuration network ip

posta SilverlightFox 03.02.2016 - 19:33

fonte

1 risposta

Leggi altre domande sui tag linux configuration network ip

Primitive cross-language contro gli attacchi di timing comparativo delle stringhe? Che cos'è la vulnerabilità della chiave di pseudo-crittografia?

score 1 · Accepted Answer

Sì, questo è possibile, anche se arp_filter è impostato su 0.

Ascolto del server:

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

Connessione dal client 1 - Il client 1 è impostato per indirizzare tutto il traffico tramite server, quindi non ha bisogno di alcuna risposta ARP per eth1:

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

Il client 1 ora può comunicare con il server, anche se non si trova sulla rete collegata 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

Comunicazione mostrata sul server:

# 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

Questo perché Linux accetterà connessioni per tutti gli IP configurati per tutte le interfacce, anche da interfacce che non hanno il socket associato. arp_filter riguarda solo se questo è pubblicizzato o meno. Se si tratta di un comportamento indesiderato, è possibile utilizzare IPTABLES per impedire connessioni a IP non configurati su un'interfaccia.

Questa potrebbe essere una vulnerabilità se la sicurezza del server si basava sul fatto che solo le connessioni ai servizi in ascolto su un indirizzo IP potevano essere connesse alla sottorete di tale interfaccia.