On Jul 30, 5:52pm, Zachary Roger Amsden wrote:
} Subject: Re: How secure is xinetd's binding to specific interfaces
} Well, I have looked a little at xinetd's code, but I think it's pretty
} secure. Basically, it probably does a getsockname() on incoming
} connections to find out what interface they are coming in on. It then
} would compare the result to an IP address or interface name and make
} sure they match. I haven't looked in full at the code here, but I would
} place high faith on this part because it is not that tricky to do. What
} I wouldn't place faith on is the kernel's IP forwarding mechanism. On
} many BSD based systems, it is possible to ping an inside interface from
} the outside, even with IP forwarding turned off (so I have been told).
I've seen patches to the BSD networking code that fix this.
--- Forwarded mail from hue @
island .
com (Pond Scum)
>From firewalls-relay @
tus .
ssi1 .
COM Thu Jan 26 15:27:48 1995
Date: Wed, 25 Jan 1995 17:48:56 +0800
From: hue @
island .
com (Pond Scum)
Message-Id: <9501260148 .
AA06263 @
coney .
island .
com>
To: firewalls @
GreatCircle .
COM
Subject: Re: IP spoofing vs tcp wrappers and netacl
Sender: firewalls-owner @
GreatCircle .
COM
Apologies if you are seeing this twice, but I think it didn't make it
out:
> > Doesn't help at all. The packets are forged to be from the internal
> >network, and this is what getsockname()/getpeername() will say. It you
> >use netacl, to protect telnetd to the firewall. (So the the admin can
> >login from the internal network), then the attacker can get to
> >telnetd.
>
> Actually, if the destination is the firewall, it does help, because the
> getsockname tells you the ip-address of the interface that is holding
> up your end of the connection. You know which ip-address you assign
Right, but you can just as easily send to address of the interface on
the internal network from the outside, even with IP forwarding disabled.
To your netacl or tcp wrapper, it looks like a connection to the internal
interface from an internal net. It was pointed out to me in private
email that the only check in ipintr() (BSD derived systems) is whether
the address matches any of the host's interfaces, there is no check for
which interface the packet came in on (I chopped out some code here,
these are just the relevant parts):
/*
* Check our list of addresses, to see if the packet is for us.
*/
for (ia = in_ifaddr; ia; ia = ia->ia_next) {
if (IA_SIN(ia)->sin_addr.s_addr == ip->ip_dst.s_addr)
goto ours;
But what if you made a small change, making sure the interface with
the address which matches the one in the packet is the interface the
packet was received on:
if (IA_SIN(ia)->sin_addr.s_addr == ip->ip_dst.s_addr)
if (ia->ia_ifp == ifp)
goto ours;
else
it came in on the wrong interface, log it and drop it
In that case you could trust getsockname(), because packets sent to the inside
interface from the outside would get dropped.
If your proxies don't allow access to the internal net from the internal net,
it really doesn't matter if someone spoofs the IP address of an inside machine
from the outside. The proxy would just turn them around and they could only go
back out. This is probably the easiest way to combat the problem, but it means
you can't "bounce" stuff off the firewall from the inside anymore. I've gotten
into the lazy habit of doing this with Anarchie on the Macintosh.
-Jonathan hue @
island .
com
--- End of forwarded message from hue @
island .
com (Pond Scum)
--- Forwarded mail from hue @
island .
com (Pond Scum)
>From firewalls-relay @
tus .
ssi1 .
COM Fri Jan 27 00:48:32 1995
Date: Fri, 27 Jan 1995 00:22:51 +0800
From: hue @
island .
com (Pond Scum)
Message-Id: <9501270822 .
AA08991 @
coney .
island .
com>
To: firewalls @
GreatCircle .
COM, patrick @
oes .
amdahl .
com
Subject: Re: IP spoofing vs tcp wrappers and netacl
Sender: firewalls-owner @
GreatCircle .
COM
> ARGH!!!!! Is this true? With IP forwarding a packet shouldn't be accepted
> if it's not to the "reachable" interface. I just tried this out on a
> Sun running Solaris, and an Amdahl machine running UTS, and neither of
> them had this bug. Is it really true that BSD machines will accept a
> packet addressed to one interface on the other?
Well, it's true on my machine, which is SunOS 4.1.3. ip_input.c is the one
sent to this list by Brad .
Powell @
Ebay .
sun .
com, containing the patch to block
source routed packets. I think it's safe to assume that the code in question
is the same in 4.1.3 as in his patched version. I have received email that says
this is the behavior in any BSD distribution.
I ended up trying out that simple change I posted. The only thing you need to
add is code to make sure you don't drop packets coming back up the loopback
interface. Once I did that it did what I expected.
-Jonathan hue @
island .
com
--- End of forwarded message from hue @
island .
com (Pond Scum)
--- Truck
Follow-Ups:
|
|
