> --UlVJffcvxoiEqYs2
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
[snip]
> What you describe as a 'flaw' is actually caused by one issue (in linux
> at least), and is exploited by commercial vendors.
In Solaris with default ip configuration as well, although poster has
pointed out that in Solaris you can turn it off.
> First, when Linux receives an IP packet on an interface, it runs through
> the list of valid IP addresses associated with the machine and dumps the
> packet if it doesn't match and it's not in promiscuous mode.
>
> Second, many network hardware vendors use this 'feature' as something called
> direct service return.
>
> It goes like this:
>
> a) loadbalancer receives a connection request to port 80 of 128.128.121.15
> b) loadbalancer forwards the packet to the inside machine using an internal
> ARP table that isn't derived from broadcasts.
> c) inside machine 192.168.1.21 has a loopback interface of 128.128.121.15
> d) inside machine accepts connection and replies back to the client with return
> address of 128.128.121.15 via the 192.168.1.21 ethernet interface.
>
> That is called direct service return; the loadbalancer doesn't have to rewrite
> outgoing packets.
>
> This method is used at least by Foundry and Resonate (oldschool resonate was like
> this) and proably others.
The Linux Virtual Server load balancer (upon which Redhat Piranha, and most
likely TurboLinux Cluster, is derived from) also works this way in Direct
Routing mode. See http://www.linuxvirtualserver.org for details.
> If you simply prefix this advisory as a warning not to rely on internal interfaces,
> that's fine. But asking vendors to CHANGE the functionality of this would incurr
> the wrath of EVERY company using loabalancers with DSR.
The Linux Virtual Server folks would also probably be less than pleased.
It might be nice if the '-arp' option to ifconfig also worked as
documented - right now it is a bit of aggravation to work around having
multiple systems try to reply to ARP requests for a shared Virtual IP.
> In short, yes security through obscurity is dumb, but calling for people to change
> this functionality is unwarranted when machines can be firewalled.
And when people rely on the behavior. If you *must* fix this, make it
a configuration option, as in Solaris.
> On Mon, Mar 05, 2001 at 07:44:43PM +0000, Woody wrote:
> > Subject: Loopback and multi-homed routing flaw in TCP/IP stack.
> > Author: Woody <[EMAIL PROTECTED]>
> >
> > We believe there to be a serious security flaw in the TCP/IP stack of
> > several Unix-like operating systems. Whilst being "known" behavior on
> > technical mailing lists, we feel that the implications of this
> > "feature" are unexpected. Furthermore, not all platforms behave in the
> > same way, which will obviously lead to invalid expectations.
> >
> > PLEASE NOTE: We have received a lot of replies to this advisory from
> > developers who have missed the point. Before you reply, please
> > read the advisory at least twice, to ensure you understand its
> > implications, and scope.
Maybe the developers are not the ones missing the point - many of them
probably understand how this works in great detail - certainly the
Linux Virtual Server crowd does.
> > The Issue:
> >
> > There is a flaw in the TCP/IP stack, such that packets intended for
> > loopback and/or local network interfaces, routed via any other
> > interface, will be delivered EVEN IF THE MACHINE IS CONFIGURED NOT TO
> > BE A GATEWAY (note that in the case of packets destined for the
> > loopback interface, we consider this to be a fault no matter how the
> > host is configured - see RFC 1122 comments below).
What about a virtual IP bound to the loopback interface, or a dummy
interface? This is precisely what many load balancing and high
availability failover clusters do, as previously mentioned.
--
John Cronin
mailto: `echo [EMAIL PROTECTED] | sed 's/[NOSPAM]//g'`
