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 "UQH9hAoAAGMAABBzQNEAAAAA"] 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
