Re: mod_remoteip does NOT change access-log IP
On Wednesday 23 January 2013, Reindl Harald wrote:
hi
LoadModuleremoteip_module modules/mod_remoteip.so
RemoteIPHeaderX-Forwarded-For
RemoteIPInternalProxy 127.0.0.1 10.0.0.4 10.0.0.103 91.118.73.4
PHP - fine, exactly how it should do:
_SERVER[SERVER_ADDR]10.0.0.99
_SERVER[SERVER_PORT]8080
_SERVER[REMOTE_ADDR]10.0.0.99
BUT access-log contains the ip of the apache trafficserver
this is a major problem for replace mod_rafp with mod_remoteip
because webalizer-usages are more or less useless
10.0.0.103 - - [23/Jan/2013:17:01:53 +0100] GET
/images/page/tidy_16.gif HTTP/1.1 304 -
http://www.test.rh:8080/; Mozilla/5.0 (X11; Linux x86_64;
rv:18.0) Gecko/20100101 Firefox/18.0 (-%)
The problem seems to be ap_get_remote_host() which is used by the %h
used in the default access log format. But resolving an IP address
that came via X-Forwarded-For does not make any sense anyway, because
the server's view of DNS may be different than the proxy's view.
If you use %a instead of %h, that should do the right thing. There is
also a %{c}a to get the proxy's IP.
That's rather confusing. Any opionions if the behavior should be
changed or if this should be fixed by documentation?
Re: mod_remoteip does NOT change access-log IP
Am 24.01.2013 21:02, schrieb Stefan Fritsch:
On Wednesday 23 January 2013, Reindl Harald wrote:
hi
LoadModuleremoteip_module modules/mod_remoteip.so
RemoteIPHeaderX-Forwarded-For
RemoteIPInternalProxy 127.0.0.1 10.0.0.4 10.0.0.103 91.118.73.4
PHP - fine, exactly how it should do:
_SERVER[SERVER_ADDR] 10.0.0.99
_SERVER[SERVER_PORT] 8080
_SERVER[REMOTE_ADDR] 10.0.0.99
BUT access-log contains the ip of the apache trafficserver
this is a major problem for replace mod_rafp with mod_remoteip
because webalizer-usages are more or less useless
10.0.0.103 - - [23/Jan/2013:17:01:53 +0100] GET
/images/page/tidy_16.gif HTTP/1.1 304 -
http://www.test.rh:8080/; Mozilla/5.0 (X11; Linux x86_64;
rv:18.0) Gecko/20100101 Firefox/18.0 (-%)
The problem seems to be ap_get_remote_host() which is used by the %h
used in the default access log format. But resolving an IP address
that came via X-Forwarded-For does not make any sense anyway, because
the server's view of DNS may be different than the proxy's view.
but there is no resolving, the problem is simply
that the proxy is in the internal LAN, 100% trustable
and from the view of the backendserver it must not
appear in any way
even if there is resolving: as long the proxy and the
backend httpd have the same DNS view - no problem
If you use %a instead of %h, that should do the right thing. There is
also a %{c}a to get the proxy's IP.
but how to handle if you have a global defined log-format
and you have some hundret vhosts where some depending on
the typical load are pointing directly to the server and
high-traffic sites pointing to the trafficserver?
having the LAN-IP of the proxy anywhere is wrong and makes from
the view of customers usage of apache trafficserver impossible
and having on several places different client-ip's is bad
the trafficserver is a 100% trusted machine
any X-Forwarded-For is trusted
any connection from this machine contains X-Forwarded-For
the machine with trafficserver has only one service
That's rather confusing. Any opionions if the behavior should be
changed or if this should be fixed by documentation?
mod_rpaf until 2.4 did handle this perfectly
as i played last summer with trafficserver this was the point to
consider it as useable because no impact on logging / security by
have LAN-IP's inside PHP-scripts which may behave different in such
cases and last but not least not touch any vhost-config
* any logfile contained the X-Forwarded-For
* any variable in PHP contained X-Forwarded-For
* mod_security saw the X-Forwarded-For
* X-Forwarded-For only from hard defined addresses, the trusted proxy
* no different configuration for hosts with proxy in front or directly called
signature.asc
Description: OpenPGP digital signature
Re: mod_remoteip does NOT change access-log IP
Am 24.01.2013 21:02, schrieb Stefan Fritsch: 10.0.0.103 - - [23/Jan/2013:17:01:53 +0100] GET /images/page/tidy_16.gif HTTP/1.1 304 - http://www.test.rh:8080/; Mozilla/5.0 (X11; Linux x86_64; rv:18.0) Gecko/20100101 Firefox/18.0 (-%) The problem seems to be ap_get_remote_host() which is used by the %h used in the default access log format. But resolving an IP address that came via X-Forwarded-For does not make any sense anyway, because the server's view of DNS may be different than the proxy's view if there is a different view it makes the behavior more worse example: * httpd is running in a LAN, no public access and has 10.0.0.6 * trafficserver is running on a public IP * trafficserver connects with a second NIC to the httpd-backend you do not want in such cases your private IP's anywhere because X-Forwarded-For is the only place where you see a non LAN-address and from the view of the application you are interested in the public IP * usages / geoip * scripts which behave differently for trusted LAN-addresses signature.asc Description: OpenPGP digital signature
Re: mod_remoteip does NOT change access-log IP
On 24 Jan 2013, at 20:02, Stefan Fritsch s...@sfritsch.de wrote:
The problem seems to be ap_get_remote_host() which is used by the %h
used in the default access log format. But resolving an IP address
that came via X-Forwarded-For does not make any sense anyway, because
the server's view of DNS may be different than the proxy's view.
If you use %a instead of %h, that should do the right thing. There is
also a %{c}a to get the proxy's IP.
That's rather confusing. Any opionions if the behavior should be
changed or if this should be fixed by documentation?
As soon as you enable mod_remoteip, you are in the world of proxies and load
balancers, and by definition you have at least two ip addresses, the address of
the load balancer, and the address of the host beyond the load balancer.
It is up to the administrator to decide which IP address they want to log, the
load balancer IP, or the IP of the host beyond.
We currently offer that option based on the principal of least surprise, to log
the downstream host IP address, as it is the address that the AAA subsystem
probably cares about the most.
It is also up to third party module authors to properly handle the two IPs, and
offer the end user sensible behaviour. Load balancers are a first class concept
properly recognized by httpd in 2.4, and is no longer the request hacks the
parent connection that was going on before.
Regards,
Graham
--
Re: mod_remoteip does NOT change access-log IP
Am 25.01.2013 00:34, schrieb Graham Leggett:
On 24 Jan 2013, at 20:02, Stefan Fritsch s...@sfritsch.de wrote:
The problem seems to be ap_get_remote_host() which is used by the %h
used in the default access log format. But resolving an IP address
that came via X-Forwarded-For does not make any sense anyway, because
the server's view of DNS may be different than the proxy's view.
If you use %a instead of %h, that should do the right thing. There is
also a %{c}a to get the proxy's IP.
That's rather confusing. Any opionions if the behavior should be
changed or if this should be fixed by documentation?
As soon as you enable mod_remoteip, you are in the world of proxies and load
balancers, and by definition you have at least two ip addresses, the address
of the load balancer, and the address of the host beyond the load balancer.
It is up to the administrator to decide which IP address they want to log,
the load balancer IP, or the IP of the host beyond.
We currently offer that option based on the principal of least surprise, to
log the downstream host IP address, as it is the address that the AAA
subsystem probably cares about the most.
It is also up to third party module authors to properly handle the two IPs,
and offer the end user sensible behaviour. Load balancers are a first class
concept properly recognized by httpd in 2.4, and is no longer the request
hacks the parent connection that was going on before.
but that does not change the fact that %h without HostnameLookups should
log the same ip-address and with HostnameLookups resolve this as
$_SERVER['REMOTE_ADDR'] from a php-script sees for the principal of least
surprise to make mod_remoteip really transparent in conext of a proxy in
front
%{c}a is new and special in context of mod_remoteip
%h exists all the time
%a exists all the time
so normally you would not except that they behave different in the
context of a clear usage of mod_remoteip
i will give %a a try instead %h as soon as i am near my test-network
again, thankfully %a Client IP address and port of the request does
not contain the port if it is 80 as it seems and so would not change
the logformat which could confuse webalizer due switch to httpd 2.4
i will give feedback ASAP here
thank you for your responses!
signature.asc
Description: OpenPGP digital signature
Re: mod_remoteip does NOT change access-log IP
Am 25.01.2013 03:47, schrieb Reindl Harald:
Am 25.01.2013 00:34, schrieb Graham Leggett:
On 24 Jan 2013, at 20:02, Stefan Fritsch s...@sfritsch.de wrote:
The problem seems to be ap_get_remote_host() which is used by the %h
used in the default access log format. But resolving an IP address
that came via X-Forwarded-For does not make any sense anyway, because
the server's view of DNS may be different than the proxy's view.
If you use %a instead of %h, that should do the right thing. There is
also a %{c}a to get the proxy's IP.
That's rather confusing. Any opionions if the behavior should be
changed or if this should be fixed by documentation?
As soon as you enable mod_remoteip, you are in the world of proxies and load
balancers, and by definition you have at least two ip addresses, the address
of the load balancer, and the address of the host beyond the load balancer.
It is up to the administrator to decide which IP address they want to log,
the load balancer IP, or the IP of the host beyond.
We currently offer that option based on the principal of least surprise, to
log the downstream host IP address, as it is the address that the AAA
subsystem probably cares about the most.
It is also up to third party module authors to properly handle the two IPs,
and offer the end user sensible behaviour. Load balancers are a first class
concept properly recognized by httpd in 2.4, and is no longer the request
hacks the parent connection that was going on before.
but that does not change the fact that %h without HostnameLookups should
log the same ip-address and with HostnameLookups resolve this as
$_SERVER['REMOTE_ADDR'] from a php-script sees for the principal of least
surprise to make mod_remoteip really transparent in conext of a proxy in
front
%{c}a is new and special in context of mod_remoteip
%h exists all the time
%a exists all the time
so normally you would not except that they behave different in the
context of a clear usage of mod_remoteip
i will give %a a try instead %h as soon as i am near my test-network
again, thankfully %a Client IP address and port of the request does
not contain the port if it is 80 as it seems and so would not change
the logformat which could confuse webalizer due switch to httpd 2.4
i will give feedback ASAP here
thank you for your responses!
for the access-log %a works fine
10.0.0.241 - - [25/Jan/2013:04:35:32 +0100] GET
/status.php?action=rh_serverinfo%3Cscript HTTP/1.1 400 2082 -
Mozilla/5.0 (X11; Linux x86_64; rv:18.0) Gecko/20100101 Firefox/18.0 (-%)
error-log:
[Fri Jan 25 04:35:32.076861 2013] [:error] [pid 4211] [client 10.0.0.103]
ModSecurity: Access denied with code 400
(phase 2). Pattern match (?i:%3Cscript|script|script) at REQUEST_URI.
[file
/etc/httpd/modsecurity.d/modsecurity_99_local_rules.conf] [line 99] [id
62] [msg XSS attack rh-rule] [data
%3Cscript] [hostname www.test.rh] [uri /status.php] [unique_id
UQH9hAoAAGMAABBzQNEA]
i do not see normal 404 errors in ErrorLog at all with 2.4 so error-handling
is a real problem for me compared with apache 2.2 behavior :-(
ErrorDocument 400 !DOCTYPE HTML PUBLIC '-//W3C//DTD HTML 4.01
Transitional//EN'...
ErrorDocument 404 /error.php
ErrorLog /var/log/apache_error.log
LogLevel warn
mod-security:
seems to get also the proxys 10.0.0.103 from which breaks any whitelistings for
security-scanner useragents which needs to be excluded due external security
audits from specified IPs and makes the errorlog unuseable because you will
never see the attackers IP
SecRule REMOTE_ADDR ^10\.0\.0\.241
id:'116',phase:1,nolog,allow,ctl:ruleEngine=off
signature.asc
Description: OpenPGP digital signature
mod_remoteip does NOT change access-log IP
hi LoadModuleremoteip_module modules/mod_remoteip.so RemoteIPHeaderX-Forwarded-For RemoteIPInternalProxy 127.0.0.1 10.0.0.4 10.0.0.103 91.118.73.4 PHP - fine, exactly how it should do: _SERVER[SERVER_ADDR] 10.0.0.99 _SERVER[SERVER_PORT] 8080 _SERVER[REMOTE_ADDR] 10.0.0.99 BUT access-log contains the ip of the apache trafficserver this is a major problem for replace mod_rafp with mod_remoteip because webalizer-usages are more or less useless 10.0.0.103 - - [23/Jan/2013:17:01:53 +0100] GET /images/page/tidy_16.gif HTTP/1.1 304 - http://www.test.rh:8080/; Mozilla/5.0 (X11; Linux x86_64; rv:18.0) Gecko/20100101 Firefox/18.0 (-%) signature.asc Description: OpenPGP digital signature
Re: mod_remoteip does NOT change access-log IP
however: http://vova-zms.blogspot.co.at/2012/07/install-modrpaf-with-apache-24.html patched mod_rpaf works with 2.4 but it would be really nice to have EXACTLY it's behavior in mod_remoteip because i see no way how i sell my customers chaning usages nor can i change the configuration of logging because a very mixed environement of vurtual hosts with or without trafficserver Am 23.01.2013 17:06, schrieb Reindl Harald: hi LoadModuleremoteip_module modules/mod_remoteip.so RemoteIPHeaderX-Forwarded-For RemoteIPInternalProxy 127.0.0.1 10.0.0.4 10.0.0.103 91.118.73.4 PHP - fine, exactly how it should do: _SERVER[SERVER_ADDR]10.0.0.99 _SERVER[SERVER_PORT]8080 _SERVER[REMOTE_ADDR]10.0.0.99 BUT access-log contains the ip of the apache trafficserver this is a major problem for replace mod_rafp with mod_remoteip because webalizer-usages are more or less useless 10.0.0.103 - - [23/Jan/2013:17:01:53 +0100] GET /images/page/tidy_16.gif HTTP/1.1 304 - http://www.test.rh:8080/; Mozilla/5.0 (X11; Linux x86_64; rv:18.0) Gecko/20100101 Firefox/18.0 (-%) signature.asc Description: OpenPGP digital signature
Re: mod_remoteip does NOT change access-log IP
hmpf - with mod_rpaf on httpd 2.4 the access-log-ip is correct but the REMOTE_ADDR variable in PHP-scripts has the proxy-IP means i can not upgrade production to 2.4 because mod_remoteip will destory usages and mod_rpaf security because you have inside php-scripts a LAN address from the proxy mod_rpaf on httpd 2.2 replaces for sure ANY place like access-log, error-log and REMOTE_ADDR in scripts with the X-Forwarded-For from the trusted apache trafficserver SERVER_ADDR 10.0.0.99 SERVER_PORT 8080 REMOTE_ADDR 10.0.0.103 Am 23.01.2013 18:08, schrieb Reindl Harald: however: http://vova-zms.blogspot.co.at/2012/07/install-modrpaf-with-apache-24.html patched mod_rpaf works with 2.4 but it would be really nice to have EXACTLY it's behavior in mod_remoteip because i see no way how i sell my customers chaning usages nor can i change the configuration of logging because a very mixed environement of vurtual hosts with or without trafficserver Am 23.01.2013 17:06, schrieb Reindl Harald: hi LoadModuleremoteip_module modules/mod_remoteip.so RemoteIPHeaderX-Forwarded-For RemoteIPInternalProxy 127.0.0.1 10.0.0.4 10.0.0.103 91.118.73.4 PHP - fine, exactly how it should do: _SERVER[SERVER_ADDR] 10.0.0.99 _SERVER[SERVER_PORT] 8080 _SERVER[REMOTE_ADDR] 10.0.0.99 BUT access-log contains the ip of the apache trafficserver this is a major problem for replace mod_rafp with mod_remoteip because webalizer-usages are more or less useless 10.0.0.103 - - [23/Jan/2013:17:01:53 +0100] GET /images/page/tidy_16.gif HTTP/1.1 304 - http://www.test.rh:8080/; Mozilla/5.0 (X11; Linux x86_64; rv:18.0) Gecko/20100101 Firefox/18.0 (-%) signature.asc Description: OpenPGP digital signature
