Re: [mod-security-users] New SecRemoteAddrDefine (httpd-dev CCed)
Brought to you by:
victorhora,
zimmerletw
Menu
▾
▴
Re: [mod-security-users] New SecRemoteAddrDefine (httpd-dev CCed)
|
From: Breno S. <bre...@gm...> - 2013-05-06 14:21:07
|
We will release 2.7.4 without SecDefineRemoteAddr.. but with the fix for Apache 2.4 + mod_remoteip. If we see a reason in the future do add it .. we can do. Thanks Breno On Mon, May 6, 2013 at 10:59 AM, Breno Silva <bre...@gm...> wrote: > I think SecDefineRemoteAddr should be present. People just need to > understand that it will only change the IP address for mod_security and not > for all apache modules. > > If people are using Apache 2.4 + mod_remoteip or Apache 2.2 + rpaf, just > do not set SecDefineRemoteAddr. If no modules like this are present in > Apache / Nginx / IIS people will have at least one option builtin in > mod_security to get the client ip address > > > On Mon, May 6, 2013 at 10:49 AM, Reindl Harald <h.r...@th...>wrote: > >> Am 06.05.2013 15:20, schrieb Breno Silva: >> > * in this case they also would not configure SecRemoteAddrDefine >> > Why not ? If the proxy/load balancer is setting the X-Forwarded-For we >> could extract the data using >> > SecDefineRemoteAddr right ? >> >> but you do you expect people not care about the implications of a >> reverse-proxy/load-balancer start to use SecRemoteAddrDefine correctly >> >> if they would do things right they would use rpaf or whatever >> module/solution >> with the same functionality and not need SecRemoteAddrDefine >> >> even if they do - for what benefit? >> in the overall context mod_security is only a small piece >> _____________________________ >> >> there are three options: >> >> * care about how to do it right and find out that mod_security >> is a showstopper to the the right behavior in any layer of >> your infrastructure as i found out with < 2.7.4 >> >> * care not at all, in this case SecRemoteAddrDefine would not get >> configured >> >> * care partly without understand what you are doing, in this case >> you start using SecRemoteAddrDefine because you found it somewhere >> and the worst case is that people think they are done after that >> while the app-developer happily continues to code >> if(substr($_SERVER['REMOTE_ADDR'], '10.0.0.') !== false) not realizing >> that all connections coming from 10.0.0.x >> _____________________________ >> >> if you think it is a good idea, go ahead but please be careful >> not to introduce regressions somewehere in mod_security because >> this is a really sensitive place and mistakes can do a lot of harm >> >> > On Mon, May 6, 2013 at 10:17 AM, Reindl Harald <h.r...@th...<mailto: >> h.r...@th...>> wrote: >> > >> > >> > Am 06.05.2013 15:11, schrieb Breno Silva: >> > > Yes.. but we cannot assume all users is doing it right :) >> > > And to be honest i think many are not doing it. >> > >> > in this case they also would not configure SecRemoteAddrDefine >> > >> > > Do you have a box without rpaf or you can disable it to test >> SecDefineRemoteAddr ? >> > >> > no, all the development stuff is on Apache 2.4 since 2013/01 and >> > with mod_security 2.7.4 production servers will also be upgraded >> > >> > > Also i will need this feature for nginx/iis module. >> > >> > in my opinion this is clearly up to the webserver and not >> > a random extension, it maybe does more harm as it helps >> > because the overall behavior get's unpredictable >> > >> > however, please do not forget revisit "Fixed mod_security >> displaying wrong ip >> > address in error.log using apache 2.4" from modsec 2.7.2! >> > >> > > On Mon, May 6, 2013 at 10:08 AM, Reindl Harald < >> h.r...@th... <mailto:h.r...@th...> >> > <mailto:h.r...@th... <mailto:h.r...@th...>>> >> 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.r...@th... <mailto:h.r...@th...> >> > <mailto:h.r...@th... <mailto:h.r...@th...>> >> > > <mailto:h.r...@th... <mailto:h.r...@th...> >> <mailto:h.r...@th... >> > <mailto:h.r...@th...>>>> 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.r...@th... >> > <mailto:h.r...@th...> <mailto:h.r...@th...<mailto: >> h.r...@th...>> >> > > <mailto:h.r...@th... <mailto:h.r...@th...> >> <mailto:h.r...@th... >> > <mailto:h.r...@th...>>> >> > > > <mailto:h.r...@th... <mailto: >> h.r...@th...> <mailto:h.r...@th... >> > <mailto:h.r...@th...>> <mailto:h.r...@th...<mailto: >> h.r...@th...> >> > > <mailto:h.r...@th... <mailto:h.r...@th...>>>>> >> 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 >> >> > |
