Date: Tue, 11 Dec 2001 19:04:20 -0800 (PST) From: Kelly Yancey <kbyanc@posi.net> To: Tom Peck <tom@masaclaw.co.nz> Cc: freebsd-net@FreeBSD.ORG Subject: RE: 1 IP - 1 Firewall - 2 Webservers Message-ID: <Pine.BSF.4.21.0112111836540.30401-100000@gateway.posi.net> In-Reply-To: <5.1.0.14.2.20011212151716.0289a4a8@mail.masaclaw.co.nz>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 12 Dec 2001, Tom Peck wrote:
> YES! That's exactly the problem! Your memory is obviously far superior to
> most :-).
>
That's a scary proposition indeed! :)
> > Of course, if you have the source to your web server (i.e. apache) then you
> >could teach it to populate REMOTE_HOST with the IP address obtained from the
> >squid-supplied header also and have it be transparent to your apps.
>
> And if we don't :-( One of the servers has a pre-complied OS which cannot
> be altered in this way. Surely there must be a simpler way!!
>
Ack. Alright, see my previous post regarding squid, that part of the
configuration should be simple. With squid supplying the information in the
HTTP headers, the only matter left is getting the web server or web
application to extract that information and to use that for the REMOTE_HOST
IP. Perhaps you could share with us what web server you are using (again, I
apologize if you included that in your original message).
Also, do you just need a custom app to pick up the originating client's IP
address or do you also need it to be logged or used in web server-supplied
IP-based security? The former would be simple to solve that the app should
just have to be modified to obtain the client's IP from the header. For
logging, many web servers allow you to customize the log format to include the
value associated with a given HTTP header (so you could log the
X-Forwarded-For header). If you need it from web server-supplied IP-based
security, you're probably out of luck. In this case, the web server would have
to supply a knob to enable this behaviour.
> Thanks for the time taken in responding to my problem. Unfortunately we
> are not prepared to go to these lengths to get the thing working how we
> would like it.. I'm quite surprised there isn't something available to
> make this feasible.
>
There is the capability in the open-source tools :): squid supplies the
information and apache, by means of the mod_extract_fordward module, can
extract it so everything is transparent. The only issue at hand is whether
your closed-source web server can be made to extract the information. :|
Just to recap:
The issue is that normally web servers obtain the client's IP address from
the source IP of the HTTP connection. However, in your setup, the proxy
receives the request (and therefor knows the client's IP), but it then
reissues the request using it's inside IP to your NAT'ed web server. The web
server only ever receives these proxied requests, therefor the web server
always gets the same source IP on all of it's incoming HTTP connections: that
of the proxy.
Because of this, you need some way to communicate the client IP information
from the proxy to the web server, and a way to configure the web server to
switch from obtaining the IP from the HTTP connection and instead obtain it
from the proxy-supplied data. The first half of the puzzle is solved; squid
can pass the client IP via a HTTP header (X-Forwarded-For). All you need is a
solution for the latter half of the puzzle.
All that said, I don't suspect too many commerical web servers are going to
supply such a knob due to the potential security issues. Forging a
X-Forward-For header is far more trivial than forging the source address of a
HTTP connection. In your scenario, I don't think it's an issue so long as you
only honor the last IP in the X-Forwarded-For's IP address list (the one your
trusted squid cache added). But commercial vendors don't necessarily have your
scenario on their radar. :|
Kelly
--
Kelly Yancey - kbyanc@{posi.net,FreeBSD.org}
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0112111836540.30401-100000>