[Zope] accessing REMOTE_ADDR

[Richard Barrett]

At 09:03 04/10/2001 -0600, Bill Anderson wrote:
>On Tue, 2001-10-02 at 10:29, Richard Barrett wrote:
> > At 21:47 01/10/2001 -0500, Timothy Wilson wrote:
> > >Hi everyone,
> > >
> > >I've been messing around with my Apache config and the ProxyVia directive
> > >and searching the mailing list archive. I have yet to find the definitive
> > >answer to this question:
> > >
> > >Is it possible to retrieve the actual IP address of the site visitor when
> > >using Zope with Apache ProxyPass or Rewrite rules (without patching 
> Apache)?
> >
> > In the case of mod_proxy and without patching the answer is no.
>
>Sorry, that is wrong.
>
>
>I am using apache 1.3.19, ProxyPass, and have the ProxyVia directive
>turned to full, and it works just fine.
>
>ProxyVia full
>goes in the VirtualHost section in your httpd.conf file.

If you are using vanilla Apache I think you will find that in a proxied 
request Zope will see the REMOTE_ADDR environment variable containing the 
IP number of the Apache server and that there is also a VIA header inserted 
containing the IP info of the Apache server and its version information. 
The former is because that is where Zope saw the incoming connection come 
from. The latter is what Apache is supposed to put in a VIA header if 
ProxyVia is 'On' or 'Full'. Nothing in what is passed to Zope identifies 
the IP number of the machine originating the request coming in to Apache. 
Well that is what Apache 1.3.14 under Suse Linux 7.2 does for me. This is 
with straight Apache proxying for a separate Zope server. I've no idea what 
you get with a fastcgi or pcgi hookup between Apache and Zope.

>Now, I am not using ModRewrite, so there *may* be some issues with that.
>

If instead of mod_proxy and ProxyPass I use mod_rewrite with a RewriteRule 
having a P (proxy) flag I get the same results. No surprise there.

>...
>
> > My advice: give it up; like who cares what the IP number of the user's
> > machine is. If you are after security you've got to rely on the low grade
> > capabilities of Basic Authentication and its cookie cousins, or get some
> > serious protection by wrapping Basic Auth in SSL.
>
>Again, not completely true. if you use IP addresses for security
>purposes, your primary concern is spoofed IPs, If your OS allows it
>(such as Linux), you can block nearly all spoofed IP attempts.
>
>Bill

The point I was making is that in the general internet case you have no way 
of reliably determining the IP number of the machine running the client 
browser which originated an HTTP Request which, finally, your server is 
responding it. The proliferation of NAT and Proxies between the ultimate 
client and the ultimate server prevents this information being available. 
Thus you cannot base a security strategy on the IP number of the machine 
the site visitor was running his browser on.

Consider what use the server can make of the IP number of a client with a 
private IP number that can only reach the server through a proxy on the 
border of the client's home domain; there are potentially a gazillion 
machines with the IP number 172.16.5.70 and all of them have different 
hostnames within their local domain. Even if you had the IP number the 
information content is zero.

Even when you are servicing the incoming request in an Apache or Zope 
server directly connected to the internet you can only know the IP number 
of the machine at the other end of the incoming connection. In many, maybe 
most cases of connections over the internet this is not the IP number of 
the machine running the client browser which made the original request.

HTTP 1.1 (RFC2616) quite specifically provides no mechanism for carrying 
the IP number of the initiating client forward through intermediate HTTP 
proxies; there is no request header defined to carry the information; 
intervening proxies, even those that are HTTP aware, have no defined place 
to put the information. And even if there were somewhere to put it you 
could not have any confidence in what it told you. Trivial code on any 
intermediate machine can manipulate HTTP headers undetectably unless your 
are using SSL.

There are patches to Apache which will, when Apache is proxying, put the IP 
number from which it saw the incoming request come into a VIA header. This 
is an abuse of this header which is defined to accumulate data about 
intermediate proxies handling a request for purely informational purposes. 
Squid can likewise insert a non-standard header X-Forwarded-For header; I 
believe there is also a patch to get Apache to insert a  X-Forwarded-For 
header instead of a dodgy VIA.

If you use these AND control the proxy machine you can get a fairly 
reliable read of the IP number of the machine that made the request to the 
proxy server BUT, in the general internet case, that is not going to be the 
same thing as the IP number of the machine on which the user's browser was 
running. However, in some case it may be useful.

Say you want your server to behave differently for clients inside your 
local network/home domain and those machines may come come direct to Zope 
or via you Apache server as proxy. Then doing reverse DNS lookups of the 
REMOTE_ADDR, falling back to a reverse DNS lookup of the X-Forwarded-For 
header if the REMOTE_ADDR is that of your Apache proxy server, can give a 
reasonably reliable confirmation that the request came from a machine in 
your local network.