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

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to