Computer Security, Technology, Tutorials, WordPress

How To Prevent Cloud WAF Bypass By Blocking HTTP Access To A Website

October 12, 2016

Any attacker who is interested in obtaining your website’s origin IP address will likely be able to retrieve it using any of the variety of methods listed from here. Therefore, when the attacker has your site’s origin IP address, he will be able to access your site directly and bypass your cloud’s Web Application Firewall (CloudFlare, Incapsula, or Sucuri’s CloudProxy). This will open a huge security gap on your site’s web server, allowing the attacker to penetrate the server directly since the protections of the cloud service has been effectively circumvented. A majority of individuals are extremely reliant on merely the protective capabilities of these CDNs or the ability of these CDNs to make it more difficult to find the site’s origin IP. Therefore, they do not seek a layered approach to security and also fail to consider an endpoint solution. For example, an endpoint WAF like Wordfence can prevent malicious requests that elude the CDNs incorporated in a WordPress site. If the origin web server restricts all inbound traffic to just the IP addresses of the cloud’s WAF, this will prevent all malicious requests that bypassed the WAF initially, resulting in a 403 forbidden error or a timeout depending on what cloud security solution was put into action. Hence, even if the attacker gets a hold of your site’s origin IP address, he will be unable to exploit a web application installed on the site like WordPress since HTTP access is denied. Nevertheless, the malicious requests can be filtered by blocking direct access to your web server via modifications to either Apache, Nginx, or a firewall installed on the origin web server. Significantly, most people aren’t aware of this hardening technique and therefore do not have it enabled. This ignorance debilitates their server’s security and opens it to many potential attacks when a malicious actor has successfully exposed the origin IP address. Keep in mind that this method will not prevent DDoS attacks if the attacker has the site’s origin IP address. Therefore, alterations to the .htaccess or iptables rules will not assist against a large DDoS attack.

Preventing Firewall Bypass

CloudFlare

Apache (.htaccess):

If your server is using Apache, add the following to the top of your .htaccess file:

<FilesMatch ".*">
Order deny,allow Deny from all
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
</FilesMatch>

Nginx (ngx_http_access_module):

If your server is using Nginx, add the following to the configuration file:

location / {
Allow 199.27.128.0/21;
Allow 173.245.48.0/20;
Allow 103.21.244.0/22;
Allow 103.22.200.0/22;
Allow 103.31.4.0/22;
Allow 141.101.64.0/18;
Allow 108.162.192.0/18;
Allow 190.93.240.0/20;
Allow 188.114.96.0/20;
Allow 197.234.240.0/22;
Allow 198.41.128.0/17;
Allow 162.158.0.0/15;
Allow 104.16.0.0/12;
Allow 172.64.0.0/13;
Allow 2400:cb00::/32;
Allow 2405:8100::/32;
Allow 2405:b500::/32;
Allow 2606:4700::/32;
Allow 2803:f800::/32;
Allow 2c0f:f248::/32;
Allow 2a06:98c0::/29;
deny all;
    # Existing NGINX rules
}

Incapsula

Apache (.htaccess):

If your server is using Apache, add the following to the top of your .htaccess file:

<FilesMatch ".*">
order deny,allow
deny from all
allow from 199.83.128.0/21
allow from 198.143.32.0/19
allow from 149.126.72.0/21
allow from 103.28.248.0/22
allow from 185.11.124.0/22
allow from 45.64.64.0/22
allow from 192.230.64.0/18
allow from 107.154.126.0/24
allow from 2a02:e980::/29
</FilesMatch>

Nginx (ngx_http_access_module):

If your server is using Nginx, add the following to the configuration file:

location / {
# allow Incapsula
allow 199.83.128.0/21;
allow 198.143.32.0/19;
allow 149.126.72.0/21;
allow 103.28.248.0/22;
allow 185.11.124.0/22;
allow 45.64.64.0/22;
allow 192.230.64.0/18;
allow 107.154.126.0/24;
allow 2a02:e980::/29;

# drop rest of the world
deny all;
}

IPtables:

#Incapsula proxies access restriction
#Allow HTTP (port 80) from Incapsula
iptables -A INPUT -s 199.83.128.0/21 -p tcp --dport http -j ACCEPT
iptables -A INPUT -s 198.143.32.0/19 -p tcp --dport http -j ACCEPT
iptables -A INPUT -s 149.126.72.0/21 -p tcp --dport http -j ACCEPT
iptables -A INPUT -s 103.28.248.0/22 -p tcp --dport http -j ACCEPT
iptables -A INPUT -s 185.11.124.0/22 -p tcp --dport http -j ACCEPT
iptables -A INPUT -s 45.64.64.0/22 -p tcp --dport http -j ACCEPT
iptables -A INPUT -s 192.230.64.0/18 -p tcp --dport http -j ACCEPT
iptables -A INPUT -s 107.154.126.0/24 -p tcp --dport http -j ACCEPT
iptables -A INPUT -s 2a02:e980::/29 -p tcp --dport http -j ACCEPT

#Block HTTP from other sources
iptables -A INPUT -p tcp --dport http -j DROP

#Allow HTTPS (port 443) from Incapsula
iptables -A INPUT -s 199.83.128.0/21 -p tcp --dport https -j ACCEPT
iptables -A INPUT -s 198.143.32.0/19 -p tcp --dport https -j ACCEPT
iptables -A INPUT -s 149.126.72.0/21 -p tcp --dport https -j ACCEPT
iptables -A INPUT -s 103.28.248.0/22 -p tcp --dport https -j ACCEPT
iptables -A INPUT -s 185.11.124.0/22 -p tcp --dport https -j ACCEPT
iptables -A INPUT -s 45.64.64.0/22 -p tcp --dport https -j ACCEPT
iptables -A INPUT -s 192.230.64.0/18 -p tcp --dport https -j ACCEPT
iptables -A INPUT -s 107.154.126.0/24 -p tcp --dport https -j ACCEPT
iptables -A INPUT -s 2a02:e980::/29 -p tcp --dport https -j ACCEPT

#Block HTTPS from other sources
iptables -A INPUT -p tcp --dport https -j DROP

Sucuri

Apache & Nginx:

For Sucuri, go into Settings > Security (Tab) > Scroll all the way down > Follow the Apache or Nginx instructions given to limit HTTP access to only Sucuri’s CloudProxy.

You Might Also Like

  • Pingback: Sucuri CloudProxy Firewall Review - Sunny Hoi()

  • Anon

    Hello, Sunny. I have Cloudflare and asked my managed host provider to edit my .htaccess file after I obtained CF’s up-to-date IP list. However, they somehow managed to block HTTP cloud access to my domain, and when I queried the result, said that editing the .htaccess file would always affect the domain rather than the server-based endpoint. Is that correct, or is it possible they mistakenly set things up? I never saw their .htaccess before the setup was reversed. I will soon research editing .htaccess and might try creating a .htaccess backup and then carefully implementing the change if they got things a little mixed up. Thanks.

Back to top
%d bloggers like this: