Thread: Re: [mod-security-users] New SecRemoteAddrDefine (httpd-dev CCed)
Brought to you by:
victorhora,
zimmerletw
|
From: Reindl H. <h.r...@th...> - 2013-05-06 13:02:54
Attachments:
signature.asc
|
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...>> 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 > > > Am 06.05.2013 14:07, schrieb Breno Silva: > > I cannot use mod_remoteip because it is only available to Apache 2.4. This feature should be Apache version > > independent. Should work for Apache 2.0 and 2.2. > > > > Could you please send me the debug log and a pcap of this transaction. I want to check where is the problem > because > > it is working here. > > > > Thanks > > > > > > On Mon, May 6, 2013 at 8:02 AM, Reindl Harald <h.r...@th... <mailto:h.r...@th...> > <mailto:h.r...@th... <mailto:h.r...@th...>>> wrote: > > > > Hi > > > > Am 06.05.2013 04:03, schrieb Breno Silva: > > > Hello Reindl, > > > > > > I wrote a patch for SecRemoteAddrDefine. This is now: > > > SecRemoteAddrDefine X-Forwarded-For /etc/modsecurity/trusted_ip.txt > > > > > > Then in trusted_ip.txt you can insert your ips one per line. > > > > > > Can you test and give me feedback ? > > > > > > Thanks > > > Breno > > > > syntax is accepted but does not work, see below > > _________________________________________________ > > > > i still refuse to understand why here a dirty hack is done especially > > because this changelog shows that there is another crude hack in case > > of logging (i guess blow X-Forwarded-For in any case to the log) instead > > handle it in the proper way PHP does for $_SERVER['REMOTE_ADDR'] > > > > you have to respect the Apache configuration and RemoteIPInternalProxy > > why do you not look how PHP handles this in a correct way? from the > > view of a clean software design this hack-attitude is completly wrong > > > > if mod_remoteip take saction there is no longer a X_FORWARDED_FOR header > > in $_SERVER at all and $_SERVER['REMOTE_ADDR'] contains the correct IP > > > > * Fixed mod_security displaying wrong ip address in error.log using apache 2.4 and mod_remoteip > > _________________________________________________ > > > > [Mon May 06 12:49:14.532293 2013] [:error] [pid 8816] [client 10.0.0.99] ModSecurity: Access denied with > code 404 > > (phase 2). Matched phrase "nessus" at REQUEST_HEADERS:User-Agent. [file > > "/etc/httpd/modsecurity.d/modsecurity_35_bad_robots.conf"] [line "3"] [id "990002"] [msg "Bad Robot"] > [hostname > > "proxy.test.rh"] [uri "/"] [unique_id "UYeKqgoAAGMAACJwT-oAAAAD"] > > ______________________________________________________________ > > > > the proxy i am connected to is for sure 10.0.0.103 and both, my client IP > > and the origin-server from the view of the proxy are 10.0.0.99, the logging > > is correct but this rule should not be active for my IP > > > > [root@rh:/etc/httpd/modsecurity.d]$ cat mod_security.conf | grep "ruleRemoveById=990002" > > SecRule REMOTE_ADDR "^10\.0\.0\.99" "id:'102',phase:1,pass,nolog,ctl:ruleRemoveById=990002" > > > > [root@rh:/etc/httpd/modsecurity.d]$ cat modsecurity_10_config.conf | grep SecRemoteAddrDefine > > SecRemoteAddrDefine X-Forwarded-For /etc/httpd/modsecurity.d/modsecurity_10_mod_remoteip.conf > > > > [root@rh:/etc/httpd/modsecurity.d]$ cat /etc/httpd/modsecurity.d/modsecurity_10_mod_remoteip.conf > > 127.0.0.1 > > 10.0.0.4 > > 10.0.0.103 > > 91.118.73.4 |
|
From: Breno S. <bre...@gm...> - 2013-05-06 13:05:06
|
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...>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...>> 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 > > > > > > Am 06.05.2013 14:07, schrieb Breno Silva: > > > I cannot use mod_remoteip because it is only available to Apache > 2.4. This feature should be Apache version > > > independent. Should work for Apache 2.0 and 2.2. > > > > > > Could you please send me the debug log and a pcap of this > transaction. I want to check where is the problem > > because > > > it is working here. > > > > > > Thanks > > > > > > > > > On Mon, May 6, 2013 at 8:02 AM, Reindl Harald < > h.r...@th... <mailto:h.r...@th...> > > <mailto:h.r...@th... <mailto:h.r...@th...>>> > wrote: > > > > > > Hi > > > > > > Am 06.05.2013 04:03, schrieb Breno Silva: > > > > Hello Reindl, > > > > > > > > I wrote a patch for SecRemoteAddrDefine. This is now: > > > > SecRemoteAddrDefine X-Forwarded-For > /etc/modsecurity/trusted_ip.txt > > > > > > > > Then in trusted_ip.txt you can insert your ips one per line. > > > > > > > > Can you test and give me feedback ? > > > > > > > > Thanks > > > > Breno > > > > > > syntax is accepted but does not work, see below > > > _________________________________________________ > > > > > > i still refuse to understand why here a dirty hack is done > especially > > > because this changelog shows that there is another crude hack > in case > > > of logging (i guess blow X-Forwarded-For in any case to the > log) instead > > > handle it in the proper way PHP does for > $_SERVER['REMOTE_ADDR'] > > > > > > you have to respect the Apache configuration and > RemoteIPInternalProxy > > > why do you not look how PHP handles this in a correct way? > from the > > > view of a clean software design this hack-attitude is > completly wrong > > > > > > if mod_remoteip take saction there is no longer a > X_FORWARDED_FOR header > > > in $_SERVER at all and $_SERVER['REMOTE_ADDR'] contains the > correct IP > > > > > > * Fixed mod_security displaying wrong ip address in error.log > using apache 2.4 and mod_remoteip > > > _________________________________________________ > > > > > > [Mon May 06 12:49:14.532293 2013] [:error] [pid 8816] [client > 10.0.0.99] ModSecurity: Access denied with > > code 404 > > > (phase 2). Matched phrase "nessus" at > REQUEST_HEADERS:User-Agent. [file > > > "/etc/httpd/modsecurity.d/modsecurity_35_bad_robots.conf"] > [line "3"] [id "990002"] [msg "Bad Robot"] > > [hostname > > > "proxy.test.rh"] [uri "/"] [unique_id > "UYeKqgoAAGMAACJwT-oAAAAD"] > > > ______________________________________________________________ > > > > > > the proxy i am connected to is for sure 10.0.0.103 and both, > my client IP > > > and the origin-server from the view of the proxy are > 10.0.0.99, the logging > > > is correct but this rule should not be active for my IP > > > > > > [root@rh:/etc/httpd/modsecurity.d]$ cat mod_security.conf | > grep "ruleRemoveById=990002" > > > SecRule REMOTE_ADDR "^10\.0\.0\.99" > "id:'102',phase:1,pass,nolog,ctl:ruleRemoveById=990002" > > > > > > [root@rh:/etc/httpd/modsecurity.d]$ cat > modsecurity_10_config.conf | grep SecRemoteAddrDefine > > > SecRemoteAddrDefine X-Forwarded-For > /etc/httpd/modsecurity.d/modsecurity_10_mod_remoteip.conf > > > > > > [root@rh:/etc/httpd/modsecurity.d]$ cat > /etc/httpd/modsecurity.d/modsecurity_10_mod_remoteip.conf > > > 127.0.0.1 > > > 10.0.0.4 > > > 10.0.0.103 > > > 91.118.73.4 > > |
|
From: Reindl H. <h.r...@th...> - 2013-05-06 13:08:30
Attachments:
signature.asc
|
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...>> 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...>>> 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 |
|
From: Breno S. <bre...@gm...> - 2013-05-06 13:11:31
|
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.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...>> 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...>>> > 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 > > |
|
From: Reindl H. <h.r...@th...> - 2013-05-06 13:17:22
Attachments:
signature.asc
|
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...>> 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...>>> 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...>>>> 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 > > -- Reindl Harald the lounge interactive design GmbH A-1060 Vienna, Hofmühlgasse 17 CTO / CISO / Software-Development p: +43 (1) 595 3999 33, m: +43 (676) 40 221 40 icq: 154546673, http://www.thelounge.net/ http://www.thelounge.net/signature.asc.what.htm |
|
From: Breno S. <bre...@gm...> - 2013-05-06 13:20:11
|
* 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 ? On Mon, May 6, 2013 at 10:17 AM, Reindl Harald <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...>> 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...>>> > 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...>>>> 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 > > > > > > -- > > Reindl Harald > the lounge interactive design GmbH > A-1060 Vienna, Hofmühlgasse 17 > CTO / CISO / Software-Development > p: +43 (1) 595 3999 33, m: +43 (676) 40 221 40 > icq: 154546673, http://www.thelounge.net/ > > http://www.thelounge.net/signature.asc.what.htm > > |
|
From: Reindl H. <h.r...@th...> - 2013-05-06 13:49:43
Attachments:
signature.asc
|
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 |
|
From: Breno S. <bre...@gm...> - 2013-05-06 14:00:05
|
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 > > |
|
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 >> >> > |
|
From: Reindl H. <h.r...@th...> - 2013-05-10 16:39:59
Attachments:
signature.asc
|
Hi will this be the release version of mod_security-2.7.4? as confirmed all works as expected but i hestitate to update the production servers while all my configs are well prepared for the migration from Apache 2.2 to Apache 2.4 and the not business-critical machines are already there Apache 2.4 brings a lot of improvements and after rolled out the first major update to the webservers after 7 years i can die in peace and our company will still survive :-) Am 06.05.2013 16:34, schrieb Breno Silva: > Reindl, > > Final implementaion is here https://github.com/SpiderLabs/ModSecurity/tree/remotes/trunk > Without SecDefineRemoteAddr. Could you run make CFLAGS=-DMSC_TEST test to check if it is all fine ? > > On Mon, May 6, 2013 at 11:00 AM, Reindl Harald <h.r...@th... <mailto:h.r...@th...>> wrote: > > works fine > > both tested, proxy listed in "RemoteIPInternalProxy" and without > > * listed: SecRule REMOTE_ADDR "^10\.0\.0\.99" works > * not listed: access with nessus-useragent denied as expected > > thank you! |
|
From: Breno S. <bre...@gm...> - 2013-05-10 16:41:01
|
Hello Reindl, We expect release it next Monday. Thanks On Fri, May 10, 2013 at 1:39 PM, Reindl Harald <h.r...@th...>wrote: > Hi > > will this be the release version of mod_security-2.7.4? > > as confirmed all works as expected but i hestitate to update > the production servers while all my configs are well prepared > for the migration from Apache 2.2 to Apache 2.4 and the not > business-critical machines are already there > > Apache 2.4 brings a lot of improvements and after rolled > out the first major update to the webservers after 7 years > i can die in peace and our company will still survive :-) > > Am 06.05.2013 16:34, schrieb Breno Silva: > > Reindl, > > > > Final implementaion is here > https://github.com/SpiderLabs/ModSecurity/tree/remotes/trunk > > Without SecDefineRemoteAddr. Could you run make CFLAGS=-DMSC_TEST test > to check if it is all fine ? > > > > On Mon, May 6, 2013 at 11:00 AM, Reindl Harald <h.r...@th...<mailto: > h.r...@th...>> wrote: > > > > works fine > > > > both tested, proxy listed in "RemoteIPInternalProxy" and without > > > > * listed: SecRule REMOTE_ADDR "^10\.0\.0\.99" works > > * not listed: access with nessus-useragent denied as expected > > > > thank you! > > |
|
From: Reindl H. <h.r...@th...> - 2013-05-10 16:45:27
Attachments:
signature.asc
|
thank you for your feedback so i am prepared to upgrade Apache on monday and get rid of some hundret files after tuning since january my "httpd.spec" fro Fedora 17/18 have a nice weekend! Am 10.05.2013 18:40, schrieb Breno Silva: > Hello Reindl, > > We expect release it next Monday. > > Thanks > > > On Fri, May 10, 2013 at 1:39 PM, Reindl Harald <h.r...@th... <mailto:h.r...@th...>> wrote: > > Hi > > will this be the release version of mod_security-2.7.4? > > as confirmed all works as expected but i hestitate to update > the production servers while all my configs are well prepared > for the migration from Apache 2.2 to Apache 2.4 and the not > business-critical machines are already there > > Apache 2.4 brings a lot of improvements and after rolled > out the first major update to the webservers after 7 years > i can die in peace and our company will still survive :-) > > Am 06.05.2013 16:34, schrieb Breno Silva: > > Reindl, > > > > Final implementaion is here https://github.com/SpiderLabs/ModSecurity/tree/remotes/trunk > > Without SecDefineRemoteAddr. Could you run make CFLAGS=-DMSC_TEST test to check if it is all fine ? > > > > On Mon, May 6, 2013 at 11:00 AM, Reindl Harald <h.r...@th... <mailto:h.r...@th...> > <mailto:h.r...@th... <mailto:h.r...@th...>>> wrote: > > > > works fine > > > > both tested, proxy listed in "RemoteIPInternalProxy" and without > > > > * listed: SecRule REMOTE_ADDR "^10\.0\.0\.99" works > > * not listed: access with nessus-useragent denied as expected > > > > thank you! |