Computer Security, Sucuri, Technology, Tutorials, Web Security, WordPress

How To Setup Cloudflare CDN And Sucuri WAF To Protect Origin Server

April 9, 2017

One method I adopt to protect my server infrastructure/hide origin server IP is using both Cloudflare and Sucuri. Cloudflare as a speedy CDN while Sucuri for the Web Application Firewall and Protection. An advantage of this setup is that the site enjoys the benefits of a swift Content Delivery Network, strong Web Application protection, and DDoS scrubbing capabilities. Also by switching providers whether from previous utilizations as a CDN/reverse proxy creates confusion among the less competent actors aka script kiddies. For maximum effectiveness, switch to a new server origin IP prior to using this setup.

How to do it: Essentially, I have Cloudflare pointing to the Sucuri firewall’s IP Address with A Records in Cloudflare’s DNS management.

  1. Login to Cloudflare.
  2. Click on the DNS area of Cloudflare.
  3. Add a new A record, type in ‘yourdomain.com’ in the Name field, and the assigned Sucuri firewall IP address in the Value field.
  4. Add another new A record, type in ‘www’ in the Name field, and the same assigned Sucuri firewall IP address in the Value field.
  5. Make sure the orange cloud is enabled for both of the new A records. Orange cloud means Cloudflare is active.

An example of my current Cloudflare CDN setup which points to Sucuri firewall IP address for enhanced protection and benefits.

By not pointing the A records directly to your server’s origin IP address in Cloudflare’s dashboard, you are minimizing the potential for exposure of the origin IP. We point the Sucuri Firewall (CloudProxy) to your hosting provider’s IP in the following section which creates a ‘double layer’ chain. Cloudflare travels to Sucuri before reaching the origin server. Logically, two layers are better than one.

For Sucuri:

  1. Login to Sucuri’s Firewall Dashboard.
  2. Click on ‘General‘ section.
  3. Click on ‘CDN Support‘ section.
  4. Choose Cloudflare from the box. Then click Proceed.

An illustration of how to enable the External CDN support on Sucuri’s Firewall Dashboard.

 

  1. Click on ‘Hosting IP Address‘ section of Sucuri’s Firewall Dashboard.
  2. Type your server’s origin IP address in the ‘Add new address…‘ box and click on ‘Add Address’

An illustration of the Hosting IP Address section of Sucuri’s Firewall Dashboard.

Now the Sucuri Firewall is pointing to your hosting provider.

 

  1. Go back to Cloudflare’s dashboard.
  2. Click on ‘Network‘ section and confirm that IPv6 is ‘Off‘ and NOT ENABLED.

An illustration of IPv6 Compatability disabled for Cloudflare to ensure a conflict-free experience with Sucuri.

 

Those are the steps required to fully enable the use of Cloudflare’s CDN with Sucuri’s WAF (CloudProxy) on your site.

Of course, you probably have already used Cloudflare’s nameservers in your Domain Provider settings. If not, just add them in. Plain and simple.

There is another important thing you should do. Modify your .htaccess file to prevent Sucuri’s Firewall from being bypassed in the event that a clever malicious actor manages to grab hold of your origin server IP.

For Sucuri’s .htaccess:

  1. Go back to Sucuri’s Firewall Dashboard.
  2. Click on ‘Security‘ section and scroll all the way down until you see the ‘Preventing Firewall Bypass‘ section of the page.
  3. You will see codes for Apache 2.4, Apache 2.2, and Nginx. Pick one that corresponds to your server and version.
  4. Copy and paste the code into the root .htaccess of your site. You may log in using SFTP to edit the .htaccess file. Important: You should make a backup of the original, unaltered .htaccess prior to modification.
  5. Save your changes, upload the modified .htaccess file back to your server. Changes should take effect immediately without needing to clear any CDN/browser caches.

An illustration of the various server codes offered by Sucuri’s Firewall Dashboard used to prevent CloudProxy Firewall bypass.

You should also incorporate the IP addresses provided by Cloudflare here into the .htaccess file. Mixing both Sucuri and Cloudflare IP addresses into one single .htaccess is fine (.htaccess in root). Just add all the CloudFlare IP addresses right before ‘</FilesMatch>’.

For Cloudflare’s .htaccess:

The Apache .htaccess is below:

Allow from 199.27.128.0/21
Allow from 173.245.48.0/20
Allow from 103.21.244.0/22
Allow from 103.22.200.0/22
Allow from 103.31.4.0/22
Allow from 141.101.64.0/18
Allow from 108.162.192.0/18
Allow from 190.93.240.0/20
Allow from 188.114.96.0/20
Allow from 197.234.240.0/22
Allow from 198.41.128.0/17
Allow from 162.158.0.0/15
Allow from 104.16.0.0/12
Allow from 172.64.0.0/13
Allow from 2400:cb00::/32
Allow from 2405:8100::/32
Allow from 2405:b500::/32
Allow from 2606:4700::/32
Allow from 2803:f800::/32
Allow from 2c0f:f248::/32
Allow from 2a06:98c0::/29

 

By allowing only Sucuri and Cloudflare access to the origin server, the security of your origin server increases dramatically. A person that tries to directly access your server via the origin IP using HTTP 80 will be denied, preventing successful bypass of Sucuri’s CloudProxy Firewall. This will hinder the actor from attacking the server’s web application directly. However, this does not stop the actor from directly launching DDoS attacks against the origin IP. The DDoS attacks would not be effectively mitigated by the CDN or WAF since the actor knows the origin IP. Only server-side protections could help in this situation, but if the DDoS is large, it would be a good idea to change your server’s origin IP.

An illustration of a 403 error served to me when I attempt to access my site’s server via the origin IP address. This indicates effective use of the .htaccess file located in the root directory.

For more information, check out another article I’ve written to prevent Cloud WAF Bypass here that also has the above code with the exception that the code indicated in this article has been specifically tailored for use with Sucuri.

Also, when Cloudflare asks whether you want to use their SSL certificate, you agree even though you might choose to use a third-party SSL or Sucuri’s SSL. The reason is that Cloudflare will create confusion by generating these certificates which can be looked up using tools like Censys. With the increase of SSL certificates showing up in the Censys lookup, it takes longer to look through the records and can easily cause confusion.

Evidently, a disadvantage is that speed will be impacted by this overall setup since visitors who access the site will be proxied through both Cloudflare and Sucuri before their request reaches my server. Hence, it adds a bit of time to the site’s load speed. Nevertheless, I perceive the added benefits provided by CloudFlare and Sucuri as worth the mere load time. After all, these companies provide some worthwhile services.

Nonetheless, one of the many benefits enjoyed by this setup is the concealment and creation of confusion pertaining the direct-to-connect IP address in lookups by CrimeFlareViewDNS, and other methods such as those described here.

An illustrating of one of the many lookups I used from CrimeFlare to test my domain for potential exposure of my server’s origin IP address.

As you can see, it shows a direct-connect-IP address for my site’s domain. However, it shows that it points to Sucuri’s firewall server. Of course, the potential malicious actor might be excited to see this, thinking that he actually found my server’s origin IP address. But an IP address lookup of the direct-connect IP refers to it belonging to Sucuri. In fact, clicking on the direct-connect IP below the page indicates several sites protected by Sucuri, one of the domains is shown to belong to me. Any DDoS attacks (layers 3, 4, or 7 ) launched against the listed IP is mitigated by Sucuri’s scrubbing capabilities and anti-DDoS techniques, protecting my server from taking any direct hits.

As you can see, this historical lookup pulls two IP addresses, one belonging to Cloudflare and Sucuri. Sucuri was initially used then I used Cloudflare as a CDN while still retaining Sucuri’s protective services. For someone less competent, he will be confused by the mixed results of this lookup. Nowhere is the origin server IP seen in the above images. Ultimately, this setup is beneficial since cyberattacks are becoming increasingly sophisticated and dangerous.

You Might Also Like

  • Jack

    Great article – I was exactly looking for this very setup and glad I found this post. Let me ask you this. As you alluded in your post, are you noticing any delay in rendering the page for the visitors? Is that negligible delay or we can see a big difference in load time?

    • There will be an inevitable negligible delay in load time since the traffic firstly goes through Cloudflare, Sucuri, and then to your origin server. Cloudflare > Sucuri > Origin Server. Therefore, this setup can add some time to your site’s load speed.

      What’s funny is that combining the usage of both Cloudflare as a CDN and Sucuri as a WAF has been faster than using merely Sucuri’s CDN and WAF. Speed times have actually improved drastically. At least, that has been the case for me.

      Do remember that if you are using Cloudflare with Sucuri, you should refrain from using Cloudflare’s Flexible SSL. The flexible SSL that Cloudflare offers is not fully secure since traffic traveling from Cloudflare to your server is not in fact encrypted. This indicates that Internet Service Providers and the National Security Agency may still read all requests in plain text. Also, the traffic is vulnerable to man-in-the-middle attacks since another server may imitate your server and acquire its traffic.

      As always, you should experiment with the setups and implement what you feel you are most comfortable with. You can always revert and go back to the previous setup.

  • Great security info. I really appreciate you providing this effective strategy.

    I was trying to hide the origin IP address of my site which has been publicly listed on those site scanners like Censys. So after using Sucuri, I got a new IP address and I thought that as long as I’ve switched the IP while behind the Sucuri It would be hard for these engines to detect my new IP. However, to my surprise when I did a search on Censys, it has pulled my new IP address. It seems like this tool is very powerful.

    – Is there a way to stop scanners like Censys from detecting the origin IP (while using Sucuri) other than using Cloudflare cdn as you’ve explained?
    – Can I hide my new IP using just Sucuri?!

    I’d appreciate your help. than you,
    Andrew

    • Hi Andrew,

      An attacker shouldn’t be able to find out your site’s origin server IP address on website archives that store IP history and domain information if certain precautions are taken into careful consideration.

      You can choose not to use Cloudflare CDN and merely use Sucuri which will still be able to mask your origin server’s IP.

      You mentioned that you changed your origin server’s IP address while behind Sucuri. I don’t see how there is a way that new searches will display your origin server IP address and not Sucuri Firewall’s server IP. There ought to be some sort of record being publicly exposed that reveals your website’s new origin IP.

      The first thing you can do is verify that there are no DNS records being left in your account that can provide any clues to the attacker. Thus, take a look at your DNS records and remove anything not currently being used.

      Another thing to remember is avoiding running your email server on the same system as your web server. For MX records and avoiding origin IP from being exposed, relocate email service to another server.
      You might want to refrain using well-known subdomain names like FTP that can point to your origin server IP. Hence, something that is better is 5exampleftp.yourdomain.com.

      Perhaps, certain scanners have attempted to scrutinize for IP data in SSL certificates stored on your web server. Consequently, take this into account.

      When you are using Sucuri as a reverse proxy for all incoming http/https traffic, you shouldn’t accept traffic from anywhere else but from Sucuri. Thus, it’s extremely important to utilize IP address restrictions whether from your firewall or iptables that will prevent all traffic coming from non-Sucuri IP addresses. If an attacker can find your server’s origin IP address, their attempts at bypassing Sucuri WAF will inevitably fail. You can find the instructions on Sucuri’s website when you login to their dashboard.

      These are some of the tips to remember for preventing your site’s origin IP address from being exposed and potentially permitting bypass of security mechanisms built within reverse proxies like web application firewalls.

      I hope this has helped you in some way.

      If you require additional assistance, let me know.

      Best,

      Sunny

Back to top
%d bloggers like this: