Mailing-List: contact dev-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <dev@tomcat.apache.org>
Received-SPF: pass (nike.apache.org: domain of apache-lists@riggs.me
 designates 66.128.242.154 as permitted sender)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1082)
Subject: Re: RemoteIpValve advices
From: Jim Riggs <apache-lists@riggs.me>
In-Reply-To: <4D473049.3060301@apache.org>
Date: Fri, 4 Feb 2011 13:46:49 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <05FDD6E1-202E-4D0F-B587-9F3AE8C0C184@riggs.me>
References: <AANLkTin_Z1Mni1hqYMEu4cxyaGDyb-NSMTV9Dp+fWvak@mail.gmail.com>
	<4D3D5F40.9030006@apache.org>
	<AANLkTi=WgvH=1+v+-gtHY0PLa4+8TQ1mXtf_4m9rTyxa@mail.gmail.com>
	<AANLkTimivJ7oPx3yjg06DkrPmUhRzjS=LRo72-Jb_JhK@mail.gmail.com>
	<4D3FE4E1.3090502@apache.org>	<4D404122.1070305@christopherschultz.net>
	<AANLkTi=xQH87fRUvYa6pSccpkSetxksC00-7ZLC4y1RQ@mail.gmail.com>
	<4D445E3D.5060805@apache.org>
	<AANLkTikj2w=7O-O5-RTcJOV0hcv3rLt-D4bMqRznQRPy@mail.gmail.com>
	<4D470356.6040103@rowe-clan.net>
 <AANLkTinbcO0Q0VwdiAX7_v6wAYtjoHiczMhLNhtR0tcu@mail.gmail.com>
 <4D473049.3060301@apache.org>
To: "Tomcat Developers List" <dev@tomcat.apache.org>

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.
>>=20
>> 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.
>>=20
>> the Valve is not activated by default and should only be used in
>> Amazon Load Balancing case.
>>=20
>>> 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.
>>=20
>>> 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.
>>=20
>> x-forwarded-server: domU-12-31-38-00-B2-08.compute-1.internal is a
>> trusted server, aka EC2 box.
>>=20
>> 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 ?
>=20
> 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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org