I asked a similar question some weeks ago (in respect of -ipmatch and
X-Forwarded-For) , but received no response.
Original question reproduced here:
---------------------------------------------------
I am certain I’m missing something important about the <If> directive and the
-ipmatch operator when used in conjunction with %{HTTP:X-Forwarded-For}.
Please permit me to illustrate the problem by way of example:
<If "%{HTTP:X-Forwarded-For} -ipmatch '10.0.0.0/8'">
LogMessage "Got IP match [%{HTTP:X-Forwarded-For}]"
</If>
<Else>
LogMessage "No IP match [%{HTTP:X-Forwarded-For}]"
</Else>
produces the following log output:
[Wed Sep 04 17:57:03.611095 2019] [log_debug:info] [pid 11134] [client
10.128.10.9:53515] No IP match [10.128.10.9]
Clearly X-Forwarded-For has the value '10.128.10.9', which is certainly within
the 10.0.0.0/8 CIDR.
So I say to myself "Well, maybe -ipmatch doesn't really like a CIDR, despite
what the documentation appears to say".
<If "%{HTTP:X-Forwarded-For} -ipmatch '10.128.10.9'">
LogMessage "Got explicit IP match [%{HTTP:X-Forwarded-For}]"
</If>
<Else>
LogMessage "No explicit IP match [%{HTTP:X-Forwarded-For}]"
</Else>
This produces the log message:
[Wed Sep 04 17:57:03.611108 2019] [log_debug:info] [pid 11134] [client
10.128.10.9:53515] No explicit IP match [10.128.10.9]
So with X-Forwarded-For clearly containing the value 10.128.10.9, I cannot
match 10.0.0.0/8 or 10.128.10.9 with -ipmatch.
Maybe -ipmatch doesn't work?
<If "'10.128.10.9' -ipmatch '10.0.0.0/8'">
LogMessage "Got dummy IP match"
</If>
<Else>
LogMessage "Failed dummy IP match"
</Else>
produces the following log message:
[Wed Sep 04 17:57:03.611112 2019] [log_debug:info] [pid 11134] [client
10.128.10.9:53515] Got dummy IP match
So it appears there's something pathological about %{HTTP:X-Forwarded-For}, but
I can't help but observe that it prints as I expect it to in the LogMessage
output.
Here's another example:
<If "%{HTTP:X-Forwarded-For} == '10.128.10.9' ">
LogMessage "Got string IP match [%{HTTP:X-Forwarded-For}]"
</If>
<Else>
LogMessage "Got no string IP match %{HTTP:X-Forwarded-For}"
</Else>
yields
[Wed Sep 04 17:57:03.611117 2019] [log_debug:info] [pid 11134] [client
10.128.10.9:53515] Got no string IP match 10.128.10.9
I'm convinced there's something subtle I'm overlooking, and would be very
grateful for any suggestions.
-----Original Message-----
From: Maxime VEROONE <maxime.veroone.part...@decathlon.com>
Sent: Wednesday, October 23, 2019 7:26 AM
To: users@httpd.apache.org
Subject: [users@httpd] SentEnvIf and multiple X-Fowarded-For headers
Hi,
This question was previously sent to StackOverflow (ID 57206362), but I believe
it belongs here more than there.
We are using this kind of configuration to grant access to one of our sites
(here with RFC1918 CIDR ranges as an example, but you may imagine different
restrictions using public IP addresses)
<LocationMatch "/*">
Order deny,allow
Deny from all
Allow from 127.0.0.0/8
SetEnvIf X-Forwarded-For "(,| |^)192\.168\." WhiteIP
SetEnvIf X-Forwarded-For "(,| |^)172\.(1[6-9]|2\d|3[0-1])\." WhiteIP
SetEnvIf X-Forwarded-For "(,| |^)10\." WhiteIP
Allow from env=WhiteIP
</LocationMatch>
Indeed, there is another reverse proxy in front of this Apache server so all
clients will have the header, and all Source IP address would be the same, thus
disabling the possible usr of Allow/Deny IP directives.
Problem is sometimes client have others proxies on their side and the
X-Forwarded-For Header will be either duplicated or concatenated. We handle the
concatenation correctly with the (,| |^) regexp trick, but the problem is that
Apache seems to run the SetEnvIf only against the first occurrence of the
Header.
Documentation is unclear to me about this behavior. Any idea on how to handle
this kind of case ? (note: we cannot control how our reverse proxy works, only
Apache) Could that be qualified as a bug ? Searching through this mailing list
archives led to interesting threads, but nothing like this exact topic.
Precision : CentOS 6, Apache 2.2.15 latest patch version
Maxime Véroone
Omnicommerce Operations
Capensis SA on behalf of Decathlon
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org
