所谓的Web应用程序防火墙（WAF），实际上就是Web服务器的附加组件（模块）（例如Apache的mod_security模块），或某种服务（例如Cloudflare、Incapsula，SUCURI），它们的作用是，在将用户的请求发送给Web服务器之前，先对其进行安全分析，如果发现其中存在安全威胁，则阻止它们或进行相应的修改。

此外，应用防火墙还可能提供入侵检测和防御功能。

如果WAF是Web服务器模块，则该软件与Web服务器软件运行于同一计算机上面。如果WAF是一项单独的服务，则可能出现下列情况：

1. 与需要保护的网站运行在同一台服务器上，但不提供保护。

2. DNS记录A提供Web应用程序防火墙的IP地址，即Cloudflare、Incapsula、SUCURI或其他服务的IP地址，而不是该站点的IP地址

3. 之后，当用户向受保护的网站发出请求时，所有请求都将发送到Cloudflare、Incapsula、SUCURI或类似的服务。

4. 相关服务接收请求，对其进行处理，然后向源服务器（我想提醒您，它甚至根本就没有受到保护）发出请求，从源服务器接收必要的页面/数据，并将其重定向到发出请求的用户。

对于访问网站的正常访问者来说，这些并没有任何区别，因为一切都是无缝发生的。但是对网站进行安全审计时，Web应用程序防火墙可能会带来很大的障碍。因为Web应用程序防火墙不仅会阻止恶意请求，而且还能防御(D)DoS攻击。同时，它根本不会接受任何来自脚本（bot）的请求——这些请求在初始阶段就被过滤掉了，或者在验证码验证阶段就被过滤掉了，这使得安全测试人员无法使用WPScan、sqlmap等工具来搜索网站的漏洞。如果遇到WAF是嵌入到服务器中的模块的情况（例如mod_security)，那就只有一种绕过方法——构造可以绕过基于模式的规则的请求；对于WAF服务来说，绕过它们的方法有两种：

1. 与普通WAF绕过方法相同——即试图绕过规则；

2. 直接向服务器发送请求，从而绕过WAF。

在绝大多数情况下，源服务器（它们试图借助外部WAF服务提供保护）仍配置为接受和处理来自任何人（而不仅仅是来自充当代理的WAF）的请求。因此，如果您只需知道网站的实际IP，则可以完全挫败他们借助WAF服务提供的保护。

因此，Cloudflare以及Incapsula、SUCURI等服务的“绕过”方法其实非常简单，最终只要获取网站的实际IP即可。关于搜索网站真实IP地址的讨论，并不鲜见；除此之外，许多情况下也需要网站的实际IP地址，比如为了：信息收集、周边研究、搜索同一服务器上的其他站点等等。顺便说一下，关于这些问题，可以参阅下面列出的文章：

• How to find out all sites at an IP

• Dissection of the scammer site (case)

• How to find out the real IP of a site in Cloudflare

• How to find out if a site is behind CloudFlare or not

实际上，对于这个任务来说，实际上是存在专门的工具的，如CloudFail。在上面提到的文章中，我经常使用方法为：查看域的DNS记录的SecurityTrails历史记录，并检查（使用cURL并指定主机名）找到的IP地址中，哪些能够得到正确的响应。

实际上，上面提到的这种技术，以及其他一些技术，都可以是通过脚本Bypass firewalls by abusing DNS history script（这个脚本的名字有点长）实现自动化。

就该脚本来说，涉及以下服务：

• Securitytrails

• CrimeFlare

• certspotter

• DNSDumpster

• IPinfo

• ViewDNS

该脚本尝试通过不同的方法来找出实际的IP地址：

•    DNS历史分析

• 搜索子域并分析子域的IP地址

查询所有找到的IP地址以进行相应的验证。

下面，我们来展示如何通过Bypass firewalls by abusing DNS history script脚本来绕过防火墙：

sudo apt install jq

git clone https://github.com/vincentcox/bypass-firewalls-by-DNS-history

cd bypass-firewalls-by-DNS-history/

bash bypass-firewalls-by-DNS-history.sh --help

使用BlackArch来安装Bypass firewalls by abusing DNS history脚本：  

sudo pacman -S bypass-firewall-dns-history jq

该程序的用法非常简单——它只有一个强制的-d选项，在该选项之后，您需要指定要分析的域名：

 bypass-firewall-dns-history -d anti-malware.ru

这样，就能找到域名Anti-Malware.ru所在服务器的真实IP地址：

其中，[IP]列是可以直接访问的地址，通过它就可以顺利绕过WAF了；而[Confidence]则是地址数据的置信度（可能有多个IP变体，其置信度会有所不同）；[ Organization]表示所找到的IP的所有者。

该程序将收集一个IP列表，并只对主域进行检查。如果想检查找到的IP是否与检测到的子域相匹配，那么请使用-a选项，具体如下所示：  

bypass-firewall-dns-history -d seo-fast.ru -a

要将结果保存到文件中，请使用-o选项，然后您需要指定文件名，例如：

bypass-firewall-dns-history -d seo-fast.ru -a -o found_ip.txt

实际上，只要找到的IP都会被保存到文件中。

当遇到更复杂的情况，程序无法确定真实的IP地址时，它就派上用场了。事实上，尽管bypass-firewall-dns-history脚本使用了快速的子域搜索服务，但无法保证能够得到最完整的结果。因此，您还可以用其他工具和服务建立自己的子域列表。例如，使用Amass服务：

 amass enum -d seo-fast.ru -o subdm.txt

这时，找到的子域将被保存到subdm.txt文件中。现在，通过-l选项，就可以指定带有额外子域的文件路径，该文件也将用于搜索网站的实际IP地址：

bypass-firewall-dns-history -d seo-fast.ru -l subdm.txt

在这种情况下，即使不通过外部程序进行子域搜索，也可以确定真正的IP——之所以这么做，只是演示用法而已。

如何使用找到的IP（后渗透）

当您找到了站点的真实IP后，可以通过两种方式来绕过Web应用程序防火墙：

第一个方法：编辑主机文件，使得来自您操作系统的任何程序的任何请求都将直接发送到站点，从而绕过防火墙。在Linux/Mac系统上，需要编辑/etc/hosts文件，在Windows系统上，需要编辑C:\Windows\system32\drivers\etc\hosts文件，并添加如下所示的内容：

80.40.10.22 vincentcox.com

第二种方法：设置Burp Suite，详情如下图所示：

完成上述设置后，您的HTTP流量将直接转到原始Web服务器。这样的话，您就可以像平常那样进行渗透测试，而无需担心请求被WAF所阻止了。

如何防范该脚本？

• 如果使用的是Web应用程序防火墙，请确保仅接受流经防火墙的流量，并丢弃所有直接来自Internet的流量。例如，Cloudflare提供了一个IP列表，您可以将某些地址添加到iptables或UFW的白名单中，并阻止所有来自其他地址的流量。

• 首先，请确保没有可通过全局网络访问且仍接受其连接的“老”服务器。  

在线搜索Cloudflare、Incapsula、SUCURI以及其他WAF的实际IP地址

在这篇文章中，我展示了如何使用一个相当简单的脚本来绕过Web应用防火墙。另外，基于这个脚本的服务已经被添加到SuIP.biz网站，具体地址为https://suip.biz/?act=bypass-waf。

如果您的手头上没有Linux系统的话，可以随时使用该网站。

相关文章  

• Revealing the perimeter (CASE) (72.8%)

• How to search subdomains and build graphs of network structure with Amass (52.8%)

• badKarma: Advanced Network Reconnaissance Assistant (51.5%)

• TIDoS-Framework: Web Application Information Gathering and Manual Scanning Platform (51.5%)

• How to discover subdomains without brute-force (51.5%)

• How to create a proxy on shared hosting (RANDOM - 0.6%)

原文地址：https://miloserdov.org/?p=2960

本文作者：mssp299

本文为安全脉搏专栏作者发布，转载请注明：https://www.secpulse.com/archives/157999.html