On Jan 31, 2011, at 3:57 PM, Mark Thomas wrote: > On 31/01/2011 21:54, Henri Gomez wrote: >>> Not necessarily. The closest immediate proxy is the last entry in that >>> list. You might not trust all of the machines in that proxy chain to >>> provide >>> legitimate IP details. >> >> In my case, x-forwarded-for: 1.2.3.4, 10.122.47.36, 1.2.3.4 was my >> browser IP and 10.122.47.36 EC2 IP. >> >> the Valve is not activated by default and should only be used in >> Amazon Load Balancing case. >> >>> mod_remoteip has the concept of trusted vs. untrusted proxies, where only >>> the >>> trusted ones will be allowed to present the next-immediate-left IP address >>> as >>> a legitimate proxy address, and that IP is then compared to the trust list. >> >>> So you might trust yahoo or google's proxy servers, but not your typically >>> pwned user PC which is relaying spam or being employed as a DDoS agent. >> >> x-forwarded-server: domU-12-31-38-00-B2-08.compute-1.internal is a >> trusted server, aka EC2 box. >> >> So +1 to have this on RemoteIpFilter/Valve, an uniq filter/valve to >> handle such cases. >> Mark to you need code contribution on RemoteIp Valve ? > > Patches to RemoteIpFilter/Valve are the place to start. The issue of > trusted proxies are already handled so the patches should be able to > take advantage of that.
I'm a bit slow catching up and picking up on this thread, but I want to make sure that we are very careful with who we trust and what we do with regards to the X-Forwarded-* headers. As they are just ad-hoc (non-)standards, there is very different behavior out there in the wild WRT proxies. In general (at least in my experience), the only header that is fairly well supported is X-Forwarded-For. All of the others are a crapshoot. For example, say that a request goes through 3 proxies, A, B, and C. If they all behave relatively well, we will get an `X-Forwarded-For: A, B, C'. We trust B and C, so we will get a remote IP of A in TC. Now, we also get `X-Forwarded-Proto: https', `X-Forwarded-Host: foo', etc. Now where did these come from? I have personally never seen a proxy that will append comma-separated values to any of these other headers (e.g. `X-Forwarded-Proto: https, http, http'), and even if they did, they could easily be forged. If anything is done with these, you had better be certain -- without a shadow of a doubt -- that these values can be trusted. That is, if you are only getting a single value for X-Forwarded-(Port|Proto|Host|Server|...), you need to be sure it was set by your last trusted proxy. What does this mean from a TC perspective? Without an official standard for X-Forwarded-*, we need to be cautious about what we do with these headers. Even the handling we currently do with X-Forwarded-Proto and setting the port and scheme is dubious. Having the options to handle additional headers is good, but they should have to be explicitly enabled. As for me, one of the first things I do when traffic hits my perimeter boxes is to strip off all X-Forwarded-* headers. That way when I use them internally, I know they can be trusted. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
