A service bound to the IP of eth1 is still visible from eth0.
This is not an RFC violation (RFC1122 calls this "weak end host"), but
it is unexpected for most Linux users, and the very reason why people
bind a service to the IP of a specific network interface usually is to
make sure it can only be used from that interface (DHCP, samba, squid
and intranet web servers come to mind).
This is not an ARP issue. Making the kernel stop answering to ARP
requests will not make it harder for an attacker to reach the service.
Here is how to reproduce the behaviour:
host a (eth0 connected to eth0 of host b):
ifconfig eth0 10.0.0.1
ifconfig eth1 23.0.0.1
tcpserver -RHl localhost 23.0.0.1 8000 echo fnord
host b:
ifconfig eth0 10.0.0.2
route add 23.0.0.1 gw 10.0.0.1
telnet 23.0.0.1 8000
No ARP request or answer for 23.0.0.1 is involved at all.
tcpserver is from ucspi-tcp, use any other method to quickly bind a
service to 23.0.0.1 at your discretion. This appears not work for
services bound to 127.0.0.1, as this appears to be magically hard-wired
to 127.0.0.1 (setting lo to another IP and setting a static route did
not make a TCP connection appear on eth0 for me). This means that I
could not get telnet on host b to send packets destined for 127.* out
over eth0. That should not hinder attackers using other operating
systems or raw sockets to pull this attack off.
Previously, when this issue was brought up, the canonical answer was to
# echo 1 > /proc/sys/net/ipv4/conf/eth1/hidden
but this option is no longer available in recent 2.4 kernels.
I put together an experimental patch for 2.4.18 at
http://www.fefe.de/linux-eth-forwarding.diff
Be warned, though, that it may be horribly broken (not tested for SMP or
machines with more than one IP per interfaces). There is a Linux
specific kludge^Whack^Wmethod to bind to an interface, but I am not
aware of any software using it. If you have multi homed hosts and rely
on a service bound to eth1 not being visible to eth0, you need to use
netfilter or this patch!
Felix
