Yes.. but we cannot assume all users is doing it right :) And to be honest i think many are not doing it.
Do you have a box without rpaf or you can disable it to test SecDefineRemoteAddr ? Also i will need this feature for nginx/iis module. Thanks On Mon, May 6, 2013 at 10:08 AM, Reindl Harald <h.rei...@thelounge.net>wrote: > i do not think so > > anybody which is running his webserver behind a load-balancer > without a solution like rpaf is obviously a fool because any > apache error/access-log is useless, any Allow/Deny does not > work as expected and last but not least REMOTE_ADDR in CGI > and PHP scripts is the address from the proxy and god beware > you have restrictions based on the client IP in your scripts > and not aware that you always have the same client-IP > > Am 06.05.2013 15:04, schrieb Breno Silva: > > Good. But is think we still need SecDefineRemoteAddr for Apache 2.2 > without rpaf right ? > > > > On Mon, May 6, 2013 at 10:02 AM, Reindl Harald > > <h.rei...@thelounge.net<mailto: > h.rei...@thelounge.net>> wrote: > > > > thank you, this works exactly as expected with Apache 2.4 and > > mod_remoteip / mod_security, how i tested is expplained at bottom > > > > PLEASE revisit the mod_security 2.7.2 change > > * Fixed mod_security displaying wrong ip address in error.log using > apache 2.4 and mod_remoteip > > > > this was obviously a wrong intented hack only affacted the logging > > and without look at the source i guess you are logging > "X-Forwarded-For" > > in case it exists without respect mod_remoteip > > _________________________________________________________________ > > > > SecRemoteAddrDefine is not needed beause with Apache 2.2 and mod_rpaf > > this works all the time caused by a different handling inside Apache > > and you need "mod_rpaf" there at least for the correct ip-address > > in the accesslog to have useable webalizer-stats > > > > even with Apache 2.2 mod_security should not re-invent the wheel > > it's up to Apache to handle this correctly and it does if > > correctly configured > > _________________________________________________________________ > > > > and to answer Ryan Barnett's "What is preventing an attacker from > forging > > fake x-forwarded-for headers while still sending the requests through > > a "trusted" proxy?" here the a snippet form the httpd-docs > > > > > http://httpd.apache.org/docs/current/mod/mod_remoteip.html#processing > > > When multiple, comma delimited useragent IP addresses are listed in > > > the header value, they are processed in Right-to-Left order. > Processing > > > halts when a given useragent IP address is not trusted to present > the > > > preceding IP address. The header field is updated to this remaining > > > list of unconfirmed IP addresses, or if all IP addresses were > trusted, > > > this header is removed from the request altogether > > _________________________________________________________________ > > > > testing to prove the correct working of the attached source from you > > > > * UserAgent Switcher and my Firefox claims to be "Nessus" > > * SecRule REMOTE_ADDR "^10\.0\.0\.99" > "id:'102',phase:1,pass,nolog,ctl:ruleRemoveById=990002" > > * 10.0.0.103 is the real IP of the Apache-Trafficserver > > * with the configuration below i get no access denied as expected > > * if i replace the "10.0.0.103" with "10.0.0.104" and restart httpd > > as expected i get access denied > > * that's the state which i expected and demanded since january > > > > <IfVersion >= 2.4> > > LoadModule remoteip_module "modules/mod_remoteip.so" > > RemoteIPHeader X-Forwarded-For > > RemoteIPInternalProxy 127.0.0.1 10.0.0.103 > > RemoteIPProxiesHeader X-Forwarded-For > > </IfVersion> > > _________________________________________________________________ > > > > Am 06.05.2013 14:30, schrieb Breno Silva: > > > Let's try this patch. Should work for Apache 2.4 + mod_remoteip > and Apache2.2 with the SecDefineRemoteAddr > > > > > > On Mon, May 6, 2013 at 9:19 AM, Reindl Harald < > h.rei...@thelounge.net <mailto:h.rei...@thelounge.net> > > <mailto:h.rei...@thelounge.net <mailto:h.rei...@thelounge.net>>> > wrote: > > > > > > why do you refuse to understand that we do not need a new > feature or at > > > it is NOT up to you to re-invent the wheel > > > > > > Apache 2.2 works with proxy and mod_rpaf does not need any > change > > > in mod_security, mod_rpaf does the same as mod_remoteip in a > different > > > way which is no longer the way to go with Apache >= 2.4 > > > > > > if i use %a in log-configuration i have ALWAYS the desired > behavior > > > with Apache 2.2 with and without proxy AND Apache 2.4 with and > without > > > mod_remoteip as i am currently run Apache 2.2 with mod_rpaf > which > > > everybody in context of load-balancers does and so you do not > need to > > > care about this in mod_security because in Apache 2.2 %h > contains the > > > correct address and in Apache 2.4 %a does the same > > > > > > until a few weeks ago nobody cared about this at all > > > > > > now if it is brought up by me that Apache 2.4 has BUILTIN > support for > > > proxy-handling of the remote-addr simply respect this in case > we are > > > running under Apache 2.4 and understand that it is the > completly wrong > > > way you are going all the time starting with hacking the > modsec-logging > > > > > > http://httpd.apache.org/docs/current/mod/mod_log_config.html > > > %a Client IP address and port of the request. > > > %{c}a Underlying peer IP address and port of the connection > (see the mod_remoteip module) > > > > > > http://httpd.apache.org/docs/current/mod/mod_remoteip.html > > > > http://httpd.apache.org/docs/current/mod/mod_remoteip.html#remoteipheader > > > > http://httpd.apache.org/docs/current/mod/mod_remoteip.html#remoteipinternalproxy > > > > http://httpd.apache.org/docs/current/mod/mod_remoteip.html#remoteipinternalproxylist > > > > http://httpd.apache.org/docs/current/mod/mod_remoteip.html#remoteipproxiesheader > > > > http://httpd.apache.org/docs/current/mod/mod_remoteip.html#remoteiptrustedproxy > > > > http://httpd.apache.org/docs/current/mod/mod_remoteip.html#remoteiptrustedproxylist > >
