Date: Wed, 19 Jan 2000 01:07:04 +0100 From: "mouss" <usebsd@free.fr> To: <robert+freebsd@cyrus.watson.org> Cc: <freebsd-ipfw@freebsd.org> Subject: RE: Two-way transparency Message-ID: <NDBBJDFPGLMLFHLNEEOMOEKKDKAA.usebsd@free.fr> In-Reply-To: <Pine.BSF.3.96.1000118134044.2527D-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> When trying what you suggest--it could be that I'm doing it wrong, or it
> could be that there is actually a test to check for a valid client IP.
> This code from netinet/in_pcb.c suggests that there is such a check, at
> lest in 3.4-STABLE:
>
> } else if (sin->sin_addr.s_addr != INADDR_ANY) {
> sin->sin_port = 0; /* yech... */
> if (ifa_ifwithaddr((struct sockaddr *)sin) == 0)
> return (EADDRNOTAVAIL);
>
> I.e., if there is no interface hosting the given address, then reject the
> address. This is after a check for multicast addresses... I haven't read
> the divert code in detail, so don't know how that might impact things.
you're right. my claim "the normal stack does not check the address" is not
true.
I was working with a modified code that indeed does not check ;-<
We then have to modify the code above.
The simplest is to allow processes to bind to any address they want:
} else if (sin->sin_addr.s_addr != INADDR_ANY) {
#ifndef FULLY_TRANSPARENT
sin->sin_port = 0; /* yech... */
if (ifa_ifwithaddr((struct sockaddr *)sin) == 0)
return (EADDRNOTAVAIL);
#endif
with this, a user may send packets with a forged sourc address. however, on
a
serious firewall, only trusted guys should be able to start network
services.
one can restrict the addresses to those for which a divert rule exists.
a more restrictive scheme would be to maintain a list of diverted packets
and to allow the above-binding only to the source addresses of these
packets, but
this would be a lot of job for nothing!
maybe some guys who know the divert code have a better answer...
> I would have thought it would be possible given that, if the client uses
> (clientIP,port) then it knows it is unique, meaning that we should also
> have no existing binding for (clientIP,port) on the firewall box. My
> understanding was that on a given box (*,port) didn't have to be available
> just (mychoiceIP,port).
What did I smoke?
using he client port is only a problem when not using the client address,
but this
would be a strange choice!
> I'm not clear on what you mean--to what extent, based on the tcp
> connection block configured using bind, will the kernel know to "just do
> the right thing"? Will I need to add an ipfw fwd entry to force packets
> to the right place come from the target host via the proxy?
the response packet is first examined by ip_input. its destination address
is compared
to local addresses, and if no macth is found and no ip filtering rule
requires that
the packet be locally delivered, it will be forwarded and no check is done
at the TCP level.
ip_input won't check the PCB's to see whether a process is waiting for this
response.
thus, you have to add a filtering rule so that the packet is considered as a
local one
so that the code in ip_input would "goto ours".
such a rule may be added by the proxy itself (and then removed by the proxy
when it is no
more needed). This way, there would be no need to add a static rule, and
morover, the
rule may be "very specific", that is, it may contain all the ports (while on
a static
rule, you won't specify the arbitrary port).
A more serious problem is when many routes exist between the client and the
server.
If the server resonse is not delivered to the firewall that relayed the
client request,
then there is no chance that the proxy gets it.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-ipfw" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?NDBBJDFPGLMLFHLNEEOMOEKKDKAA.usebsd>