Re: X-Forwarded-For contortions

I think this will address my issue, thanks a lot! Sorry for not getting back to your questions sooner; I just returned from an end-of-summer trip.

I'll check it out soon. It's in 1.4 trunk but not in any release yet, correct?

-Bryan

On Fri, Aug 19, 2011 at 2:04 PM, Willy Tarreau <w#1wt.eu> wrote:
> Hi Bryan,
>
> On Tue, Aug 16, 2011 at 07:51:07AM +0200, Willy Tarreau wrote:
>> Hi Bryan,
>>
>> On Mon, Aug 15, 2011 at 11:13:18AM -0700, Bryan Talbot wrote:
>> > That would work but there are several CIDR networks that contain a trusted
>> > proxy.  The CDN is global and has proxies on most continents and many of
>> > them are on different networks.
>> >
>> > Since the "option forwardfor" can only handle a single network in the
>> > "if|unless" argument the only real use case it can support is where all the
>> > upstream proxies come from the same network -- like for an upstream SSL
>> > terminator.
>> >
>> > The logic I need is:
>> >
>> > if <traffic is from a trusted upstream proxy of multiple networks>
>> >   leave existing XFF header alone
>> > else
>> >   strip any XFF header from request and add our own
>>
>> Well, I think we could see it slightly differently :
>>
>>   if <traffic is from a trusted upstream proxy of multiple networks>
>>     leave existing XFF header alone
>>   else
>>     strip any XFF header from request
>>
>>   if (no XFF is present)
>>     and add our own
>>
>> This way we could use the ACLs to delete any existing occurrence
>> and have a simple flag to indicate the addition is conditionnal.
>> For instance we could have a "dont-replace" flag on the fwdfor
>> config line to indicate that it should only be set and not replaced.
>>
>> However we have to keep in mind that XFF is performed both in the
>> frontend and the backend, so the conditional logic must be compatible
>> between both. This means that if either of the front or back has the
>> option without the "dont-replace" flag, it will still be replaced.
>
> I did it, though I changed the argument name to "if-none" to make it
> less ambiguous especially in the case where both the frontend and the
> backend have the option. It is even supported in the defaults section
> (but this should be avoided since it has security implications).
>
> Thus, for your case above, you'd simply remove the header if the IP
> comes from an untrusted host, then conditionally add it :
>
>   reqidel ^x-forwarded-for if !from_proxies
>   option forwardfor if-none
>
> I'm attaching the patch, but it's already pushed upstream.
>
> Regards,
> Willy
>
>
Received on 2011/08/24 19:51