Difference between revisions of "Proxy"
m (→Introduction) |
m (→Discussion) |
||
| Line 7: | Line 7: | ||
= Discussion = | = Discussion = | ||
| − | A proxy will pass traffic to the WAF, in most cases this will be comprised of a proxy in front of your web server. When the proxy passes traffic to apache, it will make the requests to apache using the proxies IP address, and not the actual clients. The WAF will then detect and report attacks as having come from the proxy, and not from the actual source of the attack. This is because the attack is in fact coming from the proxy, as far as your web server is concerned. | + | A proxy will pass traffic to the WAF, in most cases this will be comprised of a proxy in front of your web server. When the proxy passes traffic to apache, it will make the requests to apache '''using the proxies IP address, and not the actual clients IP address.''' The WAF will then detect and report attacks as having come from the proxy, and not from the actual source of the attack. This is because the attack is in fact coming from the proxy, as far as your web server is concerned. |
| + | |||
| + | To address this, any decent proxy will pass on the actual source of the connection sent to the proxy server using a custom header. These proxy servers use what is referred to as "a forwarding header" to pass on this information. The format of this header differs from vendor to vendor, and some require special software be installed with Apache to make use of this header. There is no generic solution for this issue. | ||
'''WARNING: This header can be forged, and should never be blindly trusted.''' | '''WARNING: This header can be forged, and should never be blindly trusted.''' | ||
| − | All proxy headers can in fact be forged, so the key to using this header is to only trust specific sources and to restrict the use of this header otherwise. Do not blindly trusted "forwarding" headers. For example, if you proxy traffic to apache, you should block any other traffic to apache so that it can only come from the proxy server. | + | All proxy headers can in fact be forged, so the key to using this header is to only trust specific sources, only the proxy servers for example, and to restrict the use of this header otherwise. Do not blindly trusted "forwarding" headers. Attackers forge them all the time, and they are not trusted. The only way to make "trusted" use of these headers to only trust specific trusted hosts that send these headers. A better solution is to block all web traffic to your server except from your CDN or proxy server(s). For example, if you proxy traffic to apache, you should block any other traffic to apache so that it can only come from the proxy server. |
| − | You must configure your web server for the specific proxy solution you are using to do this for you. ASL will not do this for you. Failure to do this will result in certain rule sets, such as the Crawler Protector and RBL rules, from working correctly. | + | You must configure your web server for the specific proxy solution you are using to do this for you. ASL will not do this for you. Failure to do this will result in certain rule sets, such as the Crawler Protector and RBL rules, from working correctly and if you blindly trust the forwarded-for headers you will be opening your system up to compromise. |
= Warnings = | = Warnings = | ||
Revision as of 12:18, 23 August 2013
Contents |
Introduction
If you use a proxy or CDN solution in front of an ASL protected system, you must configure your web server to log the actual source of the clients connection, and not the proxy or CDNs source IP. By default, web servers will incorrectly log the CDN/proxies IP address and not the actual client. This will cause all sorts of problems with any WAF, and is something you must correct to use a WAF with your CDN/proxy correctly. Otherwise your WAF will block the proxy/CDN and not the actual attacker! ASL will not set this up for you, you must do this yourself.
All reputiable proxy vendors will be able to provide you with an official solution for using their proxy with your web server. Contact your proxy or CDN provider for support.
Discussion
A proxy will pass traffic to the WAF, in most cases this will be comprised of a proxy in front of your web server. When the proxy passes traffic to apache, it will make the requests to apache using the proxies IP address, and not the actual clients IP address. The WAF will then detect and report attacks as having come from the proxy, and not from the actual source of the attack. This is because the attack is in fact coming from the proxy, as far as your web server is concerned.
To address this, any decent proxy will pass on the actual source of the connection sent to the proxy server using a custom header. These proxy servers use what is referred to as "a forwarding header" to pass on this information. The format of this header differs from vendor to vendor, and some require special software be installed with Apache to make use of this header. There is no generic solution for this issue.
WARNING: This header can be forged, and should never be blindly trusted.
All proxy headers can in fact be forged, so the key to using this header is to only trust specific sources, only the proxy servers for example, and to restrict the use of this header otherwise. Do not blindly trusted "forwarding" headers. Attackers forge them all the time, and they are not trusted. The only way to make "trusted" use of these headers to only trust specific trusted hosts that send these headers. A better solution is to block all web traffic to your server except from your CDN or proxy server(s). For example, if you proxy traffic to apache, you should block any other traffic to apache so that it can only come from the proxy server.
You must configure your web server for the specific proxy solution you are using to do this for you. ASL will not do this for you. Failure to do this will result in certain rule sets, such as the Crawler Protector and RBL rules, from working correctly and if you blindly trust the forwarded-for headers you will be opening your system up to compromise.
Warnings
Improper use of a proxy will result in the proxy server being shunned by the active response system. It will also cause rules such as RBL rules, and the Crawler protector rules to not function properly (as the actual source of the connection will be incorrectly reported by Apache). It is the users responsibility to work with their proxy vendor to properly configure their web server to use the actual source of the connection, and not the proxy servers IP in all logs. Each proxy vendor does this in a different way, and it is not possible to provide guidance for all potential proxy solutions. Please contact your proxy vendor for support with configuring Apache to log the actual source IP address, and not the proxy servers.
Guidance
Note: The following information is provided as a courtesy to our customers. Contact your Proxy vendor for instructions about how to setup your web server with their proxy solution.
CloudFlare
Please contact CloudFlare for support with their solution. You must configure your server when using Cloudflare to log the actual clients IP in your logs, and not the Cloudflare proxy servers IP. Failure to do so will result in shunning of the proxy servers, and will prevent rules such as the Crawler Protector and RBL rules from working correctly.
The following links are provided as a courtesy and in no way should be construed as supported by Atomicorp. Contact CloudFlare for instructions on setting up Apache to work with mod_security.
http://www.cloudflare.com/resources-downloads
https://www.cloudflare.com/support
Generic Apache Guidance
If you are using another proxy with Apache, this guidance may be helpful. You will need to ensure that you setup Apache correctly yourself for this condition, not all proxies work the same and this guidance may not work for your proxy solution.
Apache must be configured to report the actual IP of the connecting host. When Apache is placed behind a proxy it will only "see" the IP of the proxy in front of it, which will break a lot of things as the actual source of the connection will be hidden to Apache. For example, DNS based WAF rules will not work correctly, and shuns may result in shuns of your proxy server, this includes the Crawler Protector rules, RBL rules, and Spam URI rules amongst others. Shunning will also not work correctly as the proxy IP address will be detected as the source of the attack.
Therefore, to make this work correctly you will want to use a module with apache that can automatically determine what the actual IP address is from the headers the proxy is passing to apache and will change the source information in apaches logs. The best place to find out what module(s) to use is from your proxy vendor. Some vendors require special proprietary modules to work with their proxy. You will also want to use a module that will automatically restrict the use of the "forwarded for" headers to a trusted set of sources, as discussed above, and to reject all other sources. Using a module like this restores apache to its "normal" behavior, where apache will report the actual source of the attack (and connection, which is helpful for log analysis tool) and not the proxies IP address(es).
The mod_rpaf module is one example of a module that may help you to do this. Please check with your proxy vendor for assistance with the right tools to use, this module is neither provided by or supported by Atomicorp and may or may not provide what you need for your proxy solution. You can get the module from the URL below:
http://stderr.net/apache/rpaf/
Instructions for its installation are available at the URL above. You will want to make sure that all of your apache logs are logging the actual clients IP, and NOT the IP of the proxy server as the source.
