Marc Singer wrote: > On Mon, Dec 05, 2005 at 09:01:00AM -0500, John W. Linville wrote: >> On Sat, Dec 03, 2005 at 10:33:32AM -0800, Ben Greear wrote: <SNIP> >> The association between IP addresses and links is already a bit murky. >> Reference the arp_announce sysctl for what I mean. I recall Dave M. >> emphasizing on at least one occassion that IP addresses belong to >> the _box_, not to the link. > > Precisely the case. It should be the case that a box response to an > arp on *any* interface for *any* IP address known to the box. Thus you have the following nice setup: 10.100.10.0/24 = 10Gbit streaming network 10.100.20.0/24 = 10mbit admin network 10.100.10.1 on eth0 10.100.20.1 on eth2 Then some idiot misconfigures his client box, putting 10.100.10.42/24 on the NIC that is supposed to be in the admin network only. Suddenly your 10mbit link is full because the arp's get answered on this link. I wonder how many RFC's it violates. An interface must only answer ARP's on the interface that it is configured on, not anything else. There is a low level of brokeness here already. When you have: eth0 = 10.100.10.1/24 eth1 = 192.168.1.1/24 default route towards 192.168.1.250, forwarding enabled. SMTP on 192.168.1.1. Now when a client from 10.100.10.5 contacts 192.168.1.1, the FORWARD chain of iptables is skipped. The packet directly comes into INPUT. Blocking based on the decision that it is actually being forwarded is impossible because of this, unless you do -i eth0 -d 192.168.1.1. Combine this with the above and you can suddenly access internal IP's when the firewall is configured correctly to block FORWARD's from the eth1 interface and you have an internal service on 10.100.10.1. You only have to find a way to be local on the external interface so that you can do arp's for internal IP's. It will be loved by pesky ISP's who limit people and disallow them to do NAT of course. Greets, Jeroen
Attachment:
signature.asc
Description: OpenPGP digital signature
