Bug 63113 - X-Forwarded-For header not resolved by mod_remoteip when comma delimited multiple values
Summary: X-Forwarded-For header not resolved by mod_remoteip when comma delimited mult...
Status: RESOLVED INVALID
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: mod_remoteip (show other bugs)
Version: 2.4.25
Hardware: Other Linux
: P2 normal (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-01-25 11:39 UTC by George
Modified: 2019-03-08 16:36 UTC (History)
0 users



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description George 2019-01-25 11:39:34 UTC
Using the remote_ip module we are getting an issue whereby the X-Forwarded-For header is not getting resolved when it contains multiple IPs delimited with a comma - the expected format.
If a single value is present it works as expected and the client-ip is updated with the X-Forwarded-For IP.

X-Forwarded-For:5.6.7.8, 10.10.20.10 <- won't work as expected
Resulting log entry (last field in brackets is X-Forwarded-For)
1.2.3.4 hostname.net:443 - - [25/Jan/2019:10:45:20 +0000] "GET /xx HTTP/1.1" 200 8938 "https://example.com/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/73.0.3682.0 Safari/537.36" (5.6.7.8, 10.10.20.10) <- X-Forwarded-For not changed

X-Forwarded-For:5.6.7.8 <- works fine
5.6.7.8 hostname.net:443 - - [25/Jan/2019:10:34:02 +0000] "GET /xx HTTP/1.1" 200 5656 "https://example.com/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/73.0.3682.0 Safari/537.36" (-) <- X-Forwarded-For stripped

Server version: Apache/2.4.25 (Debian)
Server built:   2018-11-03T18:46:19
Server's Module Magic Number: 20120211:68
Server loaded:  APR 1.5.2, APR-UTIL 1.5.4
Compiled using: APR 1.5.2, APR-UTIL 1.5.4
Architecture:   64-bit
Server MPM:     prefork
  threaded:     no
    forked:     yes (variable process count)
Comment 1 Rainer Jung 2019-01-25 12:00:57 UTC
What is your mod_remoteip configuration?
Comment 2 George 2019-01-25 12:04:44 UTC
<IfModule remoteip_module>
RemoteIPHeader X-Forwarded-For
RemoteIPProxiesHeader X-Forwarded-By
RemoteIPTrustedProxyList /etc/apache2/mods-available/remoteip-trusted-proxies.lst
RemoteIPInternalProxy 127.0.0.1/8
</IfModule>

The RemoteIPTrustedProxyList contains a list of Cloudfront ips (these are the ones that work with only one ip in the XF header)
and two NGINX ips (that don't work as they return multipile ips)

RemoteIPTrustedProxyList contents (abridged)

52.124.128.0/17
54.230.0.0/16
...
Comment 3 Rainer Jung 2019-01-25 12:22:39 UTC
Are you sure, that the requests with two items in XFF actually come from one of the addresses in the trusted list? I'm asking because the access log snippet you quoted contains 1.2.3.4 as the client IP, possibly redacted by you. So is the address at the beginning of the access log line part of the trusted proxy list (eg. one of your nginx addresses)?

You could also add remoteip:trace8 to your LogLevel and check whether there's something interesting for the faling request in the logs.

Regards,

Rainer
Comment 4 George 2019-01-25 12:47:49 UTC
You are correct the 1.2.3.4 is redacted and the actual ip is in the list.

Turned on trace8 and bingo - thanks!

When a single ip 1.2.3.4 is given

[Fri Jan 25 12:41:31.453912 2019] [remoteip:trace1] [pid 9517] mod_remoteip.c(404): [client 1.2.3.47:57276] Using 1.2.3.4 as client's IP by proxies 4.5.6.7
Works

When multiple: 1.2.3.4, 10.10.10.10

[Fri Jan 25 12:41:45.544435 2019] [remoteip:debug] [pid 9523] mod_remoteip.c(341): [client 4.5.6.7:57333] AH01569: RemoteIP: Header X-Forwarded-For value of 10.10.10.10 appears to be a private IP or nonsensical.  Ignored
Fails


The x-forwarded-header contains a private internal address  and this causes it to fail.
Is this correct - as I'm not sure I can stop the NGinx proxy sending the internal address as part of the forwarded for header?
Comment 5 Rainer Jung 2019-01-25 14:22:35 UTC
As HTTP request headers can be set by any client to arbitrary values, mod_remoteip has rules from which peers it trusts the value of the remote ip header.

There are two levels of trust here:

- trusted proxies: mod_remoteip trusts any values in the header except for private addresses

- internal proxies: like trusted proxies but also accept private addresses in the header as correct

You have declared you nginx "only" as trusted, so mod_remoteip mistrusts the private address values in the header send by the nginx. Put the proxies in front of your apache, that set private addresses into the header and which you want mod_remoteip to trust into RemoteIPInternalProxy or RemoteIPInternalProxy and try again.

I myself find the names trusted versus internal confusing but it's to late to change that. Try the "Internal" variants of the directives and see if it works.

Regards,

Rainer
Comment 6 George 2019-01-25 15:09:55 UTC
Thanks for that.

I have put the Ips of the Nginx proxies into  a list of RemoteIPInternalProxyList and also tried putting the list of the 'local' ips in the list.


But unfortunately it still rejects them as:

RemoteIP: Header X-Forwarded-For value of 10.0.8.65 appears to be a private IP or nonsensical.  Ignored

The same is true for a single value in the RemoteIPInternalProxy

It seems that it just won't accept XF headers with private addresses in them.
Comment 7 Rainer Jung 2019-01-25 15:37:56 UTC
Do you build yourself? Any chance you could rebuild with a patched (debugging) version of mod_remoteip if I provide a debug patch?
Comment 8 George 2019-01-25 15:55:59 UTC
I didn't build it myself - but I can give that a go next week - thanks for your assistance with this.
Comment 9 George 2019-03-04 17:23:25 UTC
Have you had any more thoughts on this - or is there anything I can do to help test?
Comment 10 William A. Rowe Jr. 2019-03-05 16:27:28 UTC
You can't *usefully* decipher XFF private addresses across networks.
{private subnet} -> {public addressing} -> {private subnet} gives you
zero useful information about the private subnet on the other side of
the public zone.

I'm guessing you have several 10. proxies (the ngnix you mentioned)
on your side of the zone that are not deciphered?

RemoteIPInternalProxy 127.0.0.1/8

will obviously not trust any 10. addresses as part of your internal
network. You need to expand the list of RemoteIPInternalProxy links
to include all internal proxies.

I'm marking as resolved since this was a configuration question in
the first place, it belongs on users@httpd.apache.org, this issue
tracker is strictly for reporting defects in ASF source code.
See http://httpd.apache.org/lists.html#http-users for obtaining peer
help with configuration.
Comment 11 George 2019-03-06 14:14:09 UTC
Thanks for that and I will post over there - but I think it is a bug as none of the suggested configurations of Trusted and Internal proxies help and always raises errors when an ip in the range 10. is present in the X-Forwared-for header.
Comment 12 William A. Rowe Jr. 2019-03-06 18:45:03 UTC
George, again, I ask if you added all the corresponding proxies for any
10. addresses *within your intranet* are present in the RemoteIPInternalProxy
and not the RemoteIPTrustedProxy lists.

Version 2.4.25 is mentioned in this report, note 2.4.30 - 2.4.33 were missing
the correct merge of the global trust list to the virtual host trust list,
see http://svn.apache.org/viewvc?view=revision&revision=1833070
Comment 13 George 2019-03-08 16:36:41 UTC
Hi William Thanks for getting back.
Yes I have listed the local 10. addresses in the RemoteIPInternalProxy list and not in the RemoteIPTrustedProxy list

Traffic from proxies (listed in RemoteIPTrustedProxy) without local 10. ips in the XF header are resolving ok it is just traffic that have 10. ips in the XF header


e.g. traffic without local ips in the XF header:
[Thu Mar 07 17:34:29.305890 2019] [remoteip:trace1] [pid 466] mod_remoteip.c(423): [client 106.120.173.132:18024] Using 106.120.173.132 as client's IP by proxies 70.132.3.133

Traffic with local 10. in XF
[Thu Mar 07 17:34:07.697226 2019] [remoteip:debug] [pid 684] mod_remoteip.c(360): [client 34.243.27.172:25236] AH01569: RemoteIP: Header X-Forwarded-For value of 10.0.7.53 appears to be a private IP or nonsensical.  Ignored, referer: {redacted}

All the 10. ips are listed in the RemoteIPInternalProxy