|
From: Reindl H. <h.r...@th...> - 2013-05-06 01:48:20
|
Am 06.05.2013 03:22, schrieb Ryan Barnett: > > On May 5, 2013, at 6:19 PM, "Reindl Harald" <h.r...@th...> wrote: > >> SecRemoteAddrDefine X-Forwarded-For 127.0.0.1 10.0.0.4 10.0.0.103 91.118.73.4 >> >> [root@testserver:~]$ apachectl -t >> AH00526: Syntax error on line 12 of /etc/httpd/modsecurity.d/modsecurity_10_config.conf: >> SecRemoteAddrDefine takes one argument, Define a request header field to define remote addr >> >> it's unbelieveable - do you really not understand that "X-Forwarded-For" >> IS NOT TRUSTABLE and that is why you have to configure it with RemoteIPInternalProxy >> for the trusted original-IP's to not let a RANDOM client send you the headers >> you want to see? > > What is preventing an attacker from forging fake x-forwarded-for headers > while still sending the requests through a "trusted" proxy? bsedies the fact that THIS is not your problem? the proxy ITSELF is sending the "X-Forwarded-For" and does NOT forward a "X-Forwarded-For" from the client connection, the proxy inserts the REAL CONNECTION IP of the client in "X-Forwarded-For" > If your architecture is setup so clients must go through an upstream > load balancer/proxy/cdn of some sort, this still doesn't prevent x-forwarded-for > forging unless these "trusted" hosts are configured to deny access if they receive > requests with x-forwarded-for headers already present they NEED NOT ALWAYS go through the proxy and that is why you define proxy ip's to trust in "RemoteIPInternalProxy", hence on a server with some hundret domains i decide via DNS where load balancing is needed (large sites) or would only be useless overhead in case of small sites with a handful visits each day where any cached content would expire all the time the proxy ITSELF is sending the "X-Forwarded-For" and does NOT forward a "X-Forwarded-For" from the client connection, the proxy inserts the REAL CONNECTION IP of the client in "X-Forwarded-For" > If this is the case, then access control is already handled there > If not, and if these systems only append their IP to the existing > x-forwarded-for header, then this data is still not trusted... you still yeally do not understand it? the load-balancer does send "X-Forwarded-For" and not echo a client-header Apache knows the real IP of the balancer because it connects to the Apache this IP can not be faked and mode_remoteip's job is to deal with "X-Forwarded-For" while mod_security's job is to deal with Apache 2.4 someone would call this "chain of trust" * Apache 2.4 does handle this fine in logs (access as well errors) * Apache 2.4 doe shandle this fine within "Require ip" * PHP does handle this fine in REMOTE_ADDR only mod_security is broken, you do not need to care about the achitecture of my network, you only need to care that mod_security works with Apache 2.4 and mod_remoteip because it's a upstream part of Apache 2.4 and until this is not the case you can not claim mod_security is ready for Apache 2.4 Apache 2.4 was released 2012/02 nearly a year later in 2013/01 after 10 minutes of my first testing i notfied mod_security and httpd-upstream that mod_security does not work correct in this context, httpd upstream said CLEARLY it's up to module-developers to handle this correctly months ago and the only idea so far was "hey use the client header in modsec configuration" or the completly broken idea of "SecRemoteAddrDefine" which leaves a bad taste in case of a application-firewall for many reasons so about what do we discuss here now? |
