On Wednesday 16 July 2003 03:27, you wrote: > On Wednesday, July 16, 2003, at 10:36 AM, Gustaf Neumann wrote: > > PS: with the log-file-change in the aolserver, there is a > > potential small security leak. The proxy MUST bock > > requests that have already X-Forwarded-For set (easily > > configurable in pound). otherwise, it is possible that the > > wrong client address is written into the logfile, > > and a client can hide its identity.... > > You probably don't want to block requests that have X-Forwarded-For > set, and using it to log the client address is also a bit of a > crapshoot, because you never know how many proxies a request has passed > through before reaching you, each of which may have added an > X-Forwarded-For header. If you're doing this, what you'd want to do is > configure Pound to strip out any existing X-Forwarded-For headers > before putting in it's own.
you are right, i've just added this to my verison of pound. > >>> That X-Forwarded-For is a very useful little feature, thanks for > >>> doing > >>> it Zoran! > >> > >> Well, it seemed trivial to include, so I did it. > >> Some people have expressed concern about potential > >> security issue with this, so I may end up making this > >> configurable over some (yet to name) ns_param in the > >> config file for the nslog facility. > > Personally (speaking as an unknown, new voice here), while I can see it > could be a useful feature, I'd rather see it configurable and > defaulting to off. I'd expect that rewriting the logged client address > like this in the access log is only *required* when you're sitting > behind an accelerator, in which case you should know to turn it on. If > you're not behind an accelerator then it could well make the stats you > collect out of the logs *less* useful - many businesses use their own > proxies and have clients sitting on 192.168/16 or 10/8 networks, and > having my logs full of rfc1918 client addresses isn't the most useful > for figuring out who my visitors are. agreed that it is a good idea to switch it per default of. In general there are a couple of more issues: in principle one request can contain multiple X-Forwarded-For header fields (stemming from a chain of proxies), so there are multiple choices which of the to pick. with the change in pound mentioned above (stripping external x-forwarded-for headers), this should be fine. Another issue is that in the general case, it would be desireable to configure in a webserver using x-forwarded-for info, which proxy we trust (i.e. our local proxies) and accept only x-forwarded-for from those (e.g. localhost, my_local_proxy, ...) (i am not arguing to add such a feature) Again in the special case, where pound established the ssl connection and hides all external traffic from the backend (aol) servers, having a simple switch to turn use_x_forwarded_for on, is in my opinion sufficient. a final issue coming to my mind is [ns_conn peeraddr]. it is questionable to use the address form x_forwarded_for here as well (when the flag is turned on). Currently it is not clear to me, in how many cases [ns_conn peeraddr] should return the ip-address of the proxy or of the "true peer"; for our application it would be conveniant to return the info of true peer and not of the proxy. But it is not clear to me whether this will break some applications. Ideas? cheers -gustaf neumann -- Univ.Prof. Dr.Gustaf Neumann Abteilung für Wirtschaftsinformatik WU-Wien, Augasse 2-6, 1090 Wien -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
