Bug 53099 - Allow multiple values in RemoteIPHeader
Summary: Allow multiple values in RemoteIPHeader
Status: NEW
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: mod_remoteip (show other bugs)
Version: 2.4-HEAD
Hardware: PC Linux
: P2 enhancement (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-04-18 11:48 UTC by Brett
Modified: 2017-09-07 23:58 UTC (History)
1 user (show)



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Brett 2012-04-18 11:48:28 UTC
It would be nice if in mod_remoteip, you could specify a list of
headers and not just one.

suggestion is to allow multiple parameters to RemoteIPHeader, eg:

RemoteIPHeader X-Forwarded-For, X-Forward
RemoteIPTrustedProxy 10.0.2.0/24
RemoteIPTrustedProxy gateway.localdomain

Headers would preferably to be checked for in the provided order. 

Use case example is :

1. If there is X-Forwarded-For header use it (as the traffic is
through a forward proxy, such as squid)

2. Otherwise if there is X-Forward header use it (traffic is direct,
but via a SNAT-ing content switch)

3. Otherwise use the connection's REMOTE_ADDR as usual (traffic is direct - and
not via a SNAT-ing content switch OR a forward proxy)

In the current mod_remoteip, you can only pick one header - the
different headers in our case are created by different devices. The content switch makes X-Forward with a single ip address and the forward proxy adds X-Forwarded-For in the usual manner.

Both headers rewrite fine using the existing code, except i must choose to rewrite either the content switch header OR the forward proxy header, but not both.
Comment 1 msporleder 2013-08-02 18:48:51 UTC
I could use this too
Comment 2 William A. Rowe Jr. 2016-02-11 16:38:28 UTC
Mike, this statement confuses me...

/* If no RemoteIPInternalProxy, RemoteIPInternalProxyList, RemoteIPTrustedProxy
   or RemoteIPTrustedProxyList directive is configured,
   all proxies will be considered as external trusted proxies.
*/

mod_remoteip should not be translating any addresses from an unrecognized proxy.  These untrusted addresses continue to live in the header they were presented in (e.g. X-Forwarded-For) for modules to inspect, but must not enter the authnz scheme of httpd.

Is this an issue with the module's logic (original, or as-patched), or just a mis-statement?
Comment 3 William A. Rowe Jr. 2016-02-11 16:46:48 UTC
Ignore the earlier comment #2, I meant to direct that to #55962
Comment 4 William A. Rowe Jr. 2016-02-11 17:11:49 UTC
This is a good suggestion, but I think we should take this one step further...

RemoteIPInternalHeader X-RemoteIP
RemoteIPHeader X-Forwarded-For, X-Forward

In the absence of an RemoteIPInternalHeader list, the RemoteIPHeader list would be used instead to unwind the forwarded addresses for RemoteIPInternalProxy members. When the RemoteIPInternalHeader list is exhausted, the RemoteIPInternalProxy list would continue to be honored, but treated as trusted external proxies, for purposes of dis-honoring private IP addresses. This should ensure maximum compatibility with existing configurations and offer the fewest unintended consequences of a misconfiguration.

It's unclear to me if https://tools.ietf.org/html/rfc7239 will see widespread adoption and how it would interact with older conventions.

The header "Forwarded" could be treated as a special-case, supporting the new RFC, but deciphered in the order it appears.  (I imagine it would typically be first where the immediate proxies which are trusted have adopted the convention).

Sadly, https://tools.ietf.org/html/rfc7239#section-7.4 is less than helpful on this subject :)
Comment 5 Tom Sommer 2017-05-30 15:07:47 UTC
+1

This would be extremely useful, as modern proxies have moved away from X-Forwarded-From, to their own header for each (Cloudflare, Securi, etc.)
Comment 6 Jason 2017-09-07 23:58:33 UTC
I too would like to see multiple Headers supported here for the very reason that Tom mentions in Comment #5:

This would be extremely useful, as modern proxies have moved away from X-Forwarded-From, to their own header for each (Cloudflare, Securi, etc.)

I find myself wrestling with Load Balancer's which use one Header and CloudFlare which uses another. Installing both mod_cloudflare and mod_remoteip will cause Apache to crash if both modules attempt to set different IPs. 

I'd like to keep control of the headers in one place as well. It's simple enough to emulate mod_cloudflare with mod_remoteip but in doing so we cannot convert our LB IPs because mod_remoteip only accepts one header.