On Sat, 2 Mar 2002 erich@uruk.org wrote:
> [My apologies for getting into this thread rather late, but I just
> came across this on a network I'm working with which is all on the
> same switch/VLAN... I had 2 network cards per machine and was
> puzzled why traffic destined for one interface went to the other]
If another host (spoofer) on the LAN is faster all
your devices lose the race.
> I.e. the machine still may be accepting traffic destined for one
> interface on another, even though it won't *advertise* that fact
> any more.
You mix two different issues:
1. ARP replying for same request through many devices
2. ARP probes advertising same source IP through many devices
Your statement is related to (1). There are some golden
rules on this issue:
- use rp_filter protection for all your external interface
- use different "external" interfaces for the different external
networks if you want to differentiate the traffic from/to them
and protect them with rp_filter
- use rp_filter protection for all "internal" interfaces
attached to same medium (hub) as the "external" interfaces
- no need to use rp_filter protection for the other "internal"
interfaces, it is recommended, though
- if you want to differentiate traffic by protocol or ports
use firewall rules (IPSec, stateful conntracking, etc)
As for (2) I don't see how this can be remotely
exploited but my opinion is that it should be fixed.
The current behavior is still valid: if you can talk
from one local IP to some remote IP through one device
then you should allow the reverse traffic to work. With
my fix we just want to reduce the set of the local IPs
that can be used for ARP announcement. It is only a local
problem - ARP uses scope link routes. Make sure (1) does
not lead to problems caused remotely.
> Am I the only one that saw this kind of scary hole?
The users prefer protection provided from firewall
rules, even for address spoofing, a matter of taste.
Regards
-- Julian Anastasov <ja@ssi.bg>- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/