From owner-freebsd-net Wed Dec 12 13:31:32 2001 Delivered-To: freebsd-net@freebsd.org Received: from mta4-rme.xtra.co.nz (mta4-rme.xtra.co.nz [210.86.15.132]) by hub.freebsd.org (Postfix) with ESMTP id BE13637B405 for ; Wed, 12 Dec 2001 13:31:16 -0800 (PST) Received: from internet1.paradise.net.nz ([210.55.57.50]) by mta4-rme.xtra.co.nz with ESMTP id <20011212213114.SRTG24850.mta4-rme.xtra.co.nz@internet1.paradise.net.nz> for ; Thu, 13 Dec 2001 10:31:14 +1300 Message-Id: <5.1.0.14.2.20011213102454.0280ee78@pop3.paradise.net.nz> X-Sender: tompeck@pop3.paradise.net.nz X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 13 Dec 2001 10:25:04 +1300 To: freebsd-net@FreeBSD.ORG From: Tom Subject: RE: 1 IP - 1 Firewall - 2 Webservers Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org At 19:04 11/12/2001 -0800, you wrote: >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. :| Well, ok, I lied - it's not exactly closed source. One of the machines is a freeBSD 4.4 webserver, which would not be a problem, and the other is an SME / e-smith 5.0 server - which is basically a linux server in a box - but without all the necessary tools to do source installs etc. I've been reluctant to have to muck around with the server too much as it works perfectly as it is. Would it be possible to apply the Mod without having to re-compile and re-install apache? > 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. Yes, you have the gift of explaining things too :-) > 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. Yep it looks that way. My network dude has already setup Squid for this purpose, so we ARE halfway there! > 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. :| Well, running Apache I'm sure it can be done - but this depends on the methods which have to be taken to have it up and running. I have posted a message on the e-smith forum about adding mods to an already installed Apache server - but they are pretty slow at responding to things over there - so someone here can probably shed some light for me :-) Again Kelly, thanks for the time spent - I really do love the open-source community and their willingness to help. Tom To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message