Linux responds to ARP requests for other interfaces - could this be a security vulnerability?

Question

Linux responds to ARP requests on all interfaces by default.

To explain, say you have this setup:

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

And the server's eth1 IP is 192.168.1.1 and eth0 IP is 192.168.250.1. These are on two separate, isolated networks.

If Client 1 sends an ARP request for the IP 192.168.250.1, by default the Linux server will respond with eth1's MAC address. This behaviour can be changed with the arp_filter setting:

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

Even with arp_filter set to 1, is it possible for Client 1 to send a normally restricted request to 192.168.250.1, and have the server answer?

For example, say there's a UDP listener on the server, listening on 192.168.250.1 port 123, which executes a command received in a sent packet. Is it possible for Client 1 to send a request to the server with the destination IP set as 192.168.250.1, but with eth1's MAC address in the ethernet header? Will the above setting affect this?

To explain this further, I'll expand upon the diagram:

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

As the UDP listener is listening on 192.168.250.1:123 only, this should prevent anything on the 192.168.1.0/24 network from connecting to it. However, due to the above behaviour in regards to ARP responses, does this also mean that the server will accept connections to 192.168.250.1 over eth1?

What is the best way to test for this vulnerability, and what would it be classed as?

Answer 1

Yes, this is possible, even with arp_filter set to 0.

Server listening:

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

Connection from Client 1 - Client 1 is set to route all traffic via server, so it does not need any ARP response for eth1:

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

Client 1 can now communicate with the server, even though it isn't on the network connected to 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

Communication shown on the 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

This is because Linux will accept connections for all configured IPs for all interfaces, even from interfaces that do not have the socket bound. arp_filter only affects whether this is advertised or not. If this is undesired behaviour, then IPTABLES can be used to prevent connections to IPs not configured on an interface.

This could be a vulnerability if the server's security was based upon the fact that only connections to services listening on one IP address could be connected to from that interface's subnet.