[Zope] Remote IP usefulness (was: accessing REMOTE_ADDR)

[Bill Anderson]

On Thu, 2001-10-04 at 11:45, Richard Barrett wrote:

This became two issues, so I separated them ...

...
> >...
> >
> > > 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.

You can't in all cases, but you can in many. There is a difference. The
preclusion of some cases does not mandate the exclusion of all cases.
Additionally, many of the Zope servers talked about in the mailing lists
are intranet servers, where the rules are a little different.

 
> 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.

uhh, not to be rude, but do you realize that the private network ranges
are not routable over the Internet? That is to say that if you are
operating a server on the public Internet, you will only get local IP
addresses, unless spoofed, from the Internet. I covered IP Spoofing. In
this case, you don't set up your public webserver to accept private net
IP addresses from the public Internet, which is good practice regardless
of Zope or IP use. of course, any responses to a spoofed private IP sent
to the public Internet go nowhere anyway - at most, they could activate
something, but they could not get a response without some very elaborate
methods.

In your case above, the private machine with the private IP, on the
private network, will be working through a proxy, where you would see
the proxy/MASQ address, not the private IP from the Private,
non-Internet routed IP.
 
> 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.

Irrelevant to the claim. This fact does not support the claim that this
method is a hole, and not useful at all. The rational answer is that it
can be useful, under certain circumstances, and not under others. you
seem to be operating under the assumption that someone setting up IP
based security is necessarily ignorant of the situation regarding the IP
scheme in use by the client. I would argue that someone ignorant of the
situation will screw up pretty much any type of security. Security
configuration for publicly available servers (or privately, really) is
not for the ignorant.

Simply put, if the other side does not have a static, non-shared IP, you
don't use IP for user authentication. You can, however, use it for
domain authentication. 

For example, say I had a site that only allowed people to enter if they
were coming from HP. Knowing their IP network ranges, I could certainly
use  IP checking for granting access. In this case, I am using their
proxy server(s) Ip address(es) just as intended.


> 
> 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.

Again, irrelevant to the claim. Saying that IP authentication is not
useful in all situation is not tantamount to saying it is not useful, or
can not be used securely.

> 
> 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.

Again, you may not need the IP on the end machine, not all security
levels are needed for all situations, and security should be set up by
someone with knowledge of both the procedures, and the situation.
Security is essentially on ore more of the following three realms:

 o Something you know (ie. a PIN, password, shared secret)

 o Something you have (ie. an ATM Card or a Cookie)

 o Something you are  (ie. Biometrics, or perhaps, it could be argued, a
MAC address or machine ID or IP address)

The tighter security you need, the further down the list you go, and the
more of the three you incorporate.

 
> 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.

... or you could just use ZEO to provide a listener on the public, and a
listener on the private network :). or, you could set up apache to
listen on the public and the private IP addresses, and then simply look
at which one it came in through, no need for time-consuming reverse DNS
lookups. :)

Cheers,
Bill