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.
- Login to Cloudflare.
- Click on the DNS area of Cloudflare.
- Add a new A record, type in ‘yourdomain.com’ in the Name field, and the assigned Sucuri firewall IP address in the Value field.
- Add another new A record, type in ‘www’ in the Name field, and the same assigned Sucuri firewall IP address in the Value field.
- Make sure the orange cloud is enabled for both of the new A records. Orange cloud means Cloudflare is active.
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.
- Login to Sucuri’s Firewall Dashboard.
- Click on ‘General‘ section.
- Click on ‘CDN Support‘ section.
- Choose Cloudflare from the box. Then click Proceed.
- Click on ‘Hosting IP Address‘ section of Sucuri’s Firewall Dashboard.
- Type your server’s origin IP address in the ‘Add new address…‘ box and click on ‘Add Address’
Now the Sucuri Firewall is pointing to your hosting provider.
- Go back to Cloudflare’s dashboard.
- Click on ‘Network‘ section and confirm that IPv6 is ‘Off‘ and NOT ENABLED.
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:
- Go back to Sucuri’s Firewall Dashboard.
- Click on ‘Security‘ section and scroll all the way down until you see the ‘Preventing Firewall Bypass‘ section of the page.
- You will see codes for Apache 2.4, Apache 2.2, and Nginx. Pick one that corresponds to your server and version.
- 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.
- 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.
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 188.8.131.52/21 Allow from 184.108.40.206/20 Allow from 220.127.116.11/22 Allow from 18.104.22.168/22 Allow from 22.214.171.124/22 Allow from 126.96.36.199/18 Allow from 188.8.131.52/18 Allow from 184.108.40.206/20 Allow from 220.127.116.11/20 Allow from 18.104.22.168/22 Allow from 22.214.171.124/17 Allow from 126.96.36.199/15 Allow from 188.8.131.52/12 Allow from 184.108.40.206/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.
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 CrimeFlare, ViewDNS, and other methods such as those described here.
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.