There are many reasons why an organization would want to restrict access to their website or web applications to a certain country, or list of countries. Business-related reasons may include localization of pricing and/or product offerings based on geographical market. Cybersecurity-related reasons may include an uptick in attacks from “script kiddies”, hacktivists, and state-sponsored attackers from certain countries. Last but not least, legal and compliance-related reasons may include blocking sanctioned or embargoed countries, restricting access to securities/ICO/IEO offering information, or ensuring compliance with the GDPR if you do not target European residents.
Cloud-based web application firewalls, known as WAFs, such as CloudFlare support blacklisting countries based on the inferred country from the IP range of the visitor. You can also effectively “whitelist” traffic by blocking every country in the world except for the countries that you wish to allow. But it isn’t as simple as migrating your DNS to CloudFlare and setting up some firewall rules. There is also some setup on the server-side needed to ensure that only traffic from the CloudFlare reverse proxy can reach your website or web application.
Also, you should know that blocking countries using a web application firewall isn’t designed to be 100% foolproof. Users who are determined to circumvent your geo-block can easily use a VPN to mask their real IP address with a VPN IP address – based in one of the countries that you allow. From a legal & compliance perspective though, proving that you set up a WAF that restricts access to certain countries, may help prove that you do not intend to trade with sanctioned parties, promote an unregistered security offering, or violate data protection regulations such as the GDPR. You should consult an attorney or lawyer in your jurisdiction for advice to ask if setting up a WAF such as CloudFlare could help you meet your compliance requirements.
U.S. individuals and entities can access an updated list of sanctioned countries from the U.S. Department of the Treasury – Office of Financial Assets Control (OFAC) online.
To assist with cybersecurity, a WAF can use the firewall rules that its security team has developed, in addition to AI-based heuristic analysis to deter attackers who used VPNs and proxies to get around a country-based block. CloudFlare automatically challenges and blocks traffic that is designed to exploit vulnerabilities such as SQL injections in common web applications such as WordPress, Drupal, or Joomla. Unwanted robots who want to scrape your website for data are also blocked with an automatic CAPTCHA based on your Security Level. This also cuts down on the amount of comment spam for moderators to review, for websites which support user-generated content.
One of the things that most folks don’t know about the CloudFlare WAF is that it’s still possible to circumvent it, and access your server through the origin IP directly – if you configure your server and/or network with some countermeasures. DNS history tools can reveal your origin IP prior to when you began using CloudFlare, making it simple for attackers to scan your server for potential vulnerabilities or mount a DDoS attack to take it out of service.
Best Practices for Configuring CloudFlare Firewall
All the benefits of CloudFlare’s security tools can be rendered useless if you don’t restrict traffic to CloudFlare’s IP ranges, set up Authenticated Origin Pulls on your web server, and use the Full (Strict) SSL setting in CloudFlare. Also, you should consider that CloudFlare is a reverse proxy for HTTP and HTTPS traffic. Initially, it was only ports 80 and 443, but support for some common, alternative ports such as 8080 and 8443 have been added. Note that this does not mean you can use CloudFlare to proxy non-HTTP-or-HTTPS traffic, such as FTP or SSH traffic. Those services must still be accessed directly using the IP address of your server, or using a “jump box” in your internal network. If you don’t ensure that any non-HTTP/HTTPS services are properly secured, you could still face an attack similar to the one we described in our article about DDoS reflection attacks.
If you moved to CloudFlare based on the recommendation of your web host, you may have the basic configuration that accelerates traffic to your website through their CDN, but doesn’t take full advantage of the advanced security settings that are available.
You can use a server level firewall such as iptables, firewalld, or ufw to restrict HTTP and HTTPS access to only CloudFlare’s IP ranges by creating a new firewall zone and adding the CloudFlare CIDR blocks as sources within that zone.
Example IPv4 configuration for firewalld with CloudFlare on CentOS
firewall-cmd --zone=cloudflare --add-service=http
firewall-cmd --zone=cloudflare --add-service=https
firewall-cmd --zone=cloudflare --add-source=188.8.131.52/20
… # all IP ranges from this list https://www.cloudflare.com/ips/
firewall-cmd --zone=cloudflare --list-all
firewall-cmd --zone=public --remove-service=http
firewall-cmd --zone=public --remove-service=https
firewall-cmd --zone=public --list-all
Remember to remove the services http and https and ports 80 and 443 from any existing zones (such as public) which have the public network adapter attached to them.
Also, if a cloud firewall such as an AWS or Azure Security Group, Oracle Security List, or DigitalOcean Cloud Firewall is available, you should also configure stateful rules (or pairs of ingress & egress stateless rules) limiting access to the CloudFlare IP ranges as well – to provide defense in depth.
Authenticated Origin Pulls
The setup for Authenticated Origin Pulls depends on the web server being used (e.g. Apache or Nginx), but the basic premise of it involves installing CloudFlare’s client certificate onto your server, and having the web server verify every SSL request against that certificate. This can increase the load on your web server, but provides a much-needed additional layer of protection against attackers circumventing the WAF using the origin IP.
To properly configure this feature, it is not sufficient to simply switch the Authentication Origin Pulls option to ON in the CloudFlare dashboard. If that is the only thing you do, CloudFlare’s proxy will present the client certificate – but your server will not verify it.
Restoring original client IPs in your server logs
Another recommendation that we have when using CloudFlare is adding a custom module (mod_cloudflare) to your web server that enables it to log the original client IP using the X-Forwarded-For header – instead of the IP of the CloudFlare reverse proxy. This makes it much easier to identify suspicious or abusive visitors to your web application, and set up custom firewall rules to blacklist them.
Comprehensive CloudFlare CDN & Firewall Configuration Service
If you want professional assistance with configuring CloudFlare for your business, cybersecurity, and/or compliance needs, please don’t hesitate to contact our security specialists. We also help with customizing Page Rules to optimize CloudFlare’s performance and prevent conflicts with your custom web applications.