Have you heard of CloudProxy? It’s a WAF (website firewall) service offered by Sucuri, one of the most trusted names in cloud-based security technology. When looking at WAF and CDN solutions I often times came up disappointed. I always wanted a combined version that kicked ass, but never really found it. When I did find something that I thought was promising the cost was outrageous. I recently set out to create a combined hybrid of CloudProxy WAF with MaxCDN (total cost $35/mo with a max under $100/mo) and here’s the result:

Using SNI?

As of the publication date if you are using SNI on the IP associated with the domain, you’re out of luck. Scroll down to “A Note About SSL” to read more about SNI.

The Struggle:

Most CDNs (content delivery networks) either offer nothing more than a CDN or combine the CDN with a WAF (website firewall). The two most commonly known that combine these services are Cloudflare and Incapsula. MaxCDN is a pure CDN solution (for the most part), while CloudProxy is a WAF. CloudProxy does function as a CDN, although not really advertised. The CloudProxy WAF is not really a full featured CDN solution, doesn’t allow per file purging or custom domain names. Both CloudFlare and Incapsula (the two that combine both a CDN and a WAF) are very pricy especially when you opt for DDOS protection. In addition, both Incapsula and Cloudflare have come under heavy fire due to the amount of bypassed SQL injections XSS and LFI/RFI attacks allowed through. So wouldn’t it be nice if you could have both a CDN and a really good WAF with DDOS Protection at a fraction of the price. Well you can, and here’s how:

There’s already a guide for this, right?

Both MaxCDN and CloudProxy have a guide for setting up a CDN with the CloudProxy WAF. The guide assumes that the CDN is a mirror of the website (which isn’t the case with WordPress and W3TC). In the scenario presented by the guide all traffic passes through the CDN, then through the WAF and eventually to your server. This is a bit much and although it’s lickity split, it does create another few hops. We’re going let W3TC assign the correct cname to static content, therefore serving it from the CDN edge servers, all the while passing the rest of the dynamic, non-CDN content, through the CloudProxy WAF.

The Logic:

When you request a website through your browser your request goes through a series of procedures. First your browser attempts to locate the IP address to the server hosting the website. This is done through a DNS request. DNS can be subject to DDOS attacks, therefore transferring your DNS to CloudProxy is a good option to thwart these attacks. In the DNS phase there’s a few other things that happen including load-balancing, round robin etc, but those aren’t specific to this tutorial. After the IP is found the browser makes a GET request to the server, the browser identifies itself, and states the types of responses that it will accept. Normally, the IP address would be that of your server. However, because we have setup CloudProxy the IP address is now that of the Firewall. This first GET request is used to determine if the request is from a browser, bot, spammer, DDOSer etc. If the Firewall determines that the requester should be blocked they reach the end of the road. If the firewall determines that they should be let through, the GET request is sent to the server. The server then handles the request and sends back an HTML response. This response contains the urls of the static content which will be served by the CDN. The browser then begins rendering the content.

This provides the best of both worlds. The CDN is pushing the heavy weight of static content while the WAF is filtering the requests made to the server. If someone uses a direct link to the static content there’s not an issue because the content is cached on the edge servers and the request is never passed through to the server. When the CDN attempts to refresh the cached content it will obtain the new content without going through the WAF. There’s no reason for the CDN to be filtered by the WAF.

Another great reason to go this route is to avoid double caching. If the CDN retrieved its content through the WAF the WAF would be caching the content as well. This would mean that in order to purge the cached content you would need to clear it from both places. If you have a website with a lot of traffic this would be almost impossible because you would have to clear the content from both places before someone requested the content again. Another limitation to the CloudProxy WAF is that specific files cannot be purged. Because we’re serving dynamic content through the firewall, you should never have to purge the cache from CloudProxy. Any changes to CSS or JS should be purgable through MaxCDN.

The Setup:

The setup includes a WordPress website, W3 Total Cache, MaxCDN and CloudProxy.

The basics of this will be serve the static content, as usual, to the CDN for distribution on the edge servers. All dynamic content will be routed through the WAF.

1 – We will enable MaxCDN
2 – We are going to use w3tc (a free WordPress plugin) and set it up for connection to MaxCDN.
3 – We will setup CloudProxy
4 – We will modify DNS entries

Setup MaxCDN

MaxCDN will be setup just like you would normally setup a pull zone. There’s nothing special that you need to do in order to get it working correctly. If you are going to serve content over https make sure that you upload your certificate so that it works properly. Create as many Custom Domains as you want for custom URLs. I would suggest purchasing the flex locations if you plan on serving content to other countries, especially Asia and Australia.

In the guide for setting up MaxCDN with CloudProxy you are told to enable XFF and also the Origin Information. If you want to serve your static content through the firewall you can enable these options and set them up as described in the guide supplied by CloudProxy. Whenever content is retrieved from the server it will first pass through the CloudProxy. If you would rather just get the static content from your server directly leave the XFF disabled. The next paragraph will talk about the Origin Information and why we have to enable it anyway. We don’t feel that there is a substantial need to go through the firewall since the content will be delivered from cache over 90% of the time.

MaxCDN will automatically grab the IP address of your server. It’s important to note that because we will be changing the A record we need to manually tell MaxCDN where the server is located in order to get the files directly from the server and bypass the CloudProxy firewall. To do this we need to modify Origin Information on the settings page. Your settings should now look like this (replace the X’s with your server iP):

Your Edge settings should look like this:

Setup W3TC

W3TC will be setup in the same manner as it normally would. Nothing special about the settings here. There’s a mountain of information on the interwebs on how to setup W3TC if you are unfamiliar. Of course make sure the CDN is set to MaxCDN.

Setup CloudProxy

Once you have signed up for CloudProxy and you’ve followed the instructions to setup the domain, you’ll be presented with the settings page. At the very bottom of the settings page you’ll see an area for CDN. We want to make sure that it’s set to “None”. Even if you decide to send your CDN content through the firewall you’ll still want to set it to “none”. It’s very important that you ignore basically everything in this box.

Make sure that you submit your SSL certificate to them if you plan on https access to the website.

A Note About SSL: As of this publishing date SNI (Server Name Indication) is not supported. The certificate added in Sucuri must match the certificate associated with the IP on your server. Therefore, this will not work on shared hosting platforms without a dedicated IP address. For that matter, a dedicated server with multiple SSL certificates on a single IP will not work. Subdomains etc are fine so long as you’re not passing subdomain traffic through the firewall. If you are, then you’ll need a wildcard SSL, which we’ve confirmed works well.

Now we have a couple options. You can click on the DNS tab and follow the instructions to have your DNS re-routed through Sucuri or you could leave it as be. In our deployment we left it alone and continued to use our DNS servers. Next step would be to get the IP addresses that are listed as the Firewall IP Addresses. These are shown below your hosting IP address in the settings page of CloudProxy. Once you have these two IP addresses you’ll need to proceed to the next step.

Setup Your DNS

In your web hosting control panel modify the appropriate DNS A records to point to the IP addresses for the CloudProxy firewall. Once the DNS propagation is complete traffic will begin to flow through the firewall.

Preventing Direct Access

If someone knows your hidden Hosting IP address, they can bypass the CloudProxy firewall and try to access your server directly. It is not common or easy to do, but for additional extra security, we recommend only allowing HTTP access from the firewall and CDN. In order to do this we need to add the following to the .htaccess file in your web hosting root folder:

<FilesMatch ".*">
    Order deny,allow
    Deny from all
    #Begin CloudProxy
    Allow from 198.50.174.33
    Allow from 142.4.217.187
    Allow from 198.50.174.34
    Allow from 142.4.217.188
    Allow from 199.223.236.179
    Allow from 130.211.175.145
    Allow from 130.211.155.136
    Allow from 130.211.173.11
    Allow from 146.148.117.213
    Allow from 130.211.59.253
    Allow from 23.251.134.134
    Allow from 104.155.235.101
    Allow from 104.155.203.164
    Allow from 178.33.238.180
    Allow from 142.4.217.0/24
    Allow from 167.114.0.0/24
    Allow from 192.99.17.0/24
    Allow from 5.196.79.0/24
    Allow from 130.211.0.0/16
    Allow from 104.155.0.0/16
    #Begin MaxCDN
    Allow from 146.88.136.0/21
    Allow from 108.161.176.0/20
    Allow from 70.39.132.0/24
    Allow from 174.36.204.195
    Allow from 94.31.33.128/27
    Allow from 64.125.76.96/27
    Allow from 64.125.102.32/27
    Allow from 174.36.204.196
    Allow from 64.125.78.224/27
    Allow from 94.31.33.160/27
    Allow from 64.125.76.64/27
    Allow from 37.58.110.67
    Allow from 94.31.33.192/27
    Allow from 64.125.102.96/27
    Allow from 64.125.78.96/27
    Allow from 37.58.110.68
    Allow from 64.125.78.192/27
    Allow from 64.125.102.64/27
    Allow from 216.12.211.60/32
    Allow from 158.85.206.228
    Allow from 198.232.124.0/22
    Allow from 216.12.211.59/32
    Allow from 27.50.77.226/32
    Allow from 158.85.206.231
    Allow from 27.50.79.130/32
    Allow from 50.31.249.226/32
    Allow from 119.81.131.130
    Allow from 50.31.251.34/32
    Allow from 119.81.131.131
    Allow from 146.88.128.0/21
</FilesMatch>

Please note that these IP addresses may need to be changed as time goes on and IP addresses are removed or added. If you’d like to use this guide with a different CDN please make the correct modifications to the list. Here’s the links to the current list of IP addresses:

CloudProxy – List can be found in your security settings tab
MaxCDN

Links

I am not affiliated with any of the below links. They are not affiliate links and I make no money from them. It’s just pure love:
Get started with Sucuri WAF
Get started with MaxCDN
Download W3TC