网络保护第三层 WAF-网络应用防火墙

1 WAF 介绍

传统的防火墙主要专注于网络层的攻击防御，工作在三层或者四层，隔离了外网和内网，使用预设的规则，只允许特定IP地址和端口号的数据包通过，拒绝不符合的数据流入或者流出内网，实际上是一种网络数据过滤设备。对 Web 安全的防御能力相对欠缺。

WAF（Web Application Firewall，Web 应用防护系统 ） 就是应用网关防火墙的一种，它只专注于 Web 安全的防御。工作在七层，能看到整个HTTP报文，所以能够使用更复杂的条件、规则来过滤数据。

说白了，WAF 就是一种 HTTP入侵监测和防御系统。

WAF 都能干什么呢？

通常一款产品能够称为 WAF，要具备下面的一些功能：

• IP 黑名单和白名单，拒绝黑名单上地址的访问，或者只允许白名单上的用户访问；
• URI 黑名单和白名单，与 IP 黑白名单类似，允许或禁止对某些 URI 的访问；
• 防护 DDoS 攻击，对特定的 IP 地址限连限速；
• 过滤请求报文，防御“代码注入”攻击；
• 过滤响应报文，防御敏感信息外泄；
• 审计日志，记录所有检测到的入侵操作。

WAF 不拘泥于形式，是软件、设备，亦是即服务。策略可定制，以满足您对 Web 应用或 Web 应用组合的独特需求。虽然许多 WAF 要求您定期更新策略以解决新的漏洞，但机器学习的进步使一些 WAF 能够自动更新。随着威胁环境愈发复杂和不确定，这种自动化变得越来越重要。

2 WAF的工作模式

WAF 的本质是“专注于 Web 安全的防火墙”，Web 安全关注于应用层的 HTTP 请求。因此，WAF 的分析和策略都工作于应用层。

在 Web 安全这个方向上，WAF 对比防火墙又做出了哪些改进呢？我们可以从 WAF 的三种工作模式入手，探讨这两者的区别。这三种工作模式分别是：透明代理、反向代理和插件模式。

透明代理和大部分防火墙的工作模式相同：在客户端和服务端通信不需要作出任何改变的情况下，对 HTTP 流量进行请求和转发。在这个过程中，为了解密 HTTPS 流量，WAF 必须和服务端同步 HTTPS 对称密钥。

透明代理的优点就是容易部署，它不需要客户端和服务端进行任何改动。但是，透明代理的缺点也有很多。透明代理本身不是一个 Web 服务，所以它无法修改或者响应 HTTP 的请求，只能够控制请求的通过或者拒绝。正因为如此，它也无法实现 Web 服务所提供的认证、内容过滤等功能。

区别于透明代理，反向代理要求客户端将请求的目标地址指向 WAF，而不是服务端。在反向代理工作模式中，服务端接收的请求，实际上也是由 WAF 发起的。在这个过程中，WAF 本身就相当于一个 Web 服务，只不过对所有的 HTTP 请求都进行了转发。

因为反向代理 WAF 本质上是一个 Web 服务，所以 HTTPS 证书可以直接部署在 WAF 上。WAF 在对 HTTPS 流量解密之后，就可以在内网中用 HTTP 的形式，向服务端发起代理请求了。

而且，反向代理 WAF 作为一个 Web 服务，能够提供的功能也更加丰富。比如，WAF 可以充当一个前置的认证平台，对所有请求进行身份校验和身份管理。同时，也因为在反向代理工作模式中，客户端和服务端不直接通信，而是将全部请求都先请求到 WAF 上，所以反向代理 WAF 对服务端的隔离也更加彻底。

但是，反向代理同样存在缺点。首先，功能更丰富意味着性能开销更大。因此，反向代理 WAF 对硬件要求更高。其次，反向代理 WAF 一旦宕机，就无法响应客户端的任何请求。这样一来，即使服务端仍然正常，但用户已经无法正常使用应用了。而对于透明代理 WAF 来说，如果 WAF 宕机了，只是无法提供 Web 防护而已，客户端和服务端的通信不会受到任何影响。

最后，我们来看插件模式。在插件模式中，WAF 不再是网络中一个独立的安全产品了，而是以插件的形式依附于 Web 服务端本身，为 Web 安全提供防护。

那怎么才能将 WAF 植入到服务端的逻辑中呢？我们最常使用的一种技术就是AOP（Aspect Oriented Programming，面向切面编程）技术。在 AOP 技术中，WAF 可以作为一个切片植入到服务端的逻辑中。

而且，目前 AOP 技术十分流行，各类编程语言都支持。所以，插件模式的 WAF 部署同样十分简单。但是，这种将 WAF 和服务端强耦合的方式，会带来一定的负向影响。

首先，WAF 和服务端一块工作在服务器上，会消耗服务器额外的资源，对 Web 服务本身的性能产生影响。

其次，WAF 和服务端耦合，也就意味着 WAF 的所有改动都会直接影响到服务端。对于代理模式的 WAF 来说，通常只需要自测就可以升级了。而对于插件模式的 WAF，它本身的升级必须和服务端一起进入评估和测试流程，就会增加额外的工作量。

3 WAF 功能

在部署模式上 WAF 比防火墙具备更高的灵活性。WAF 可以根据不同的需求，以不同的形式为 Web 服务提供保护。同样的，在功能上，WAF 也可以去实现一些 HTTP 请求中特有的安全功能。比如去解析 HTTP 数据、解密 HTTPS 流量等。下面，我们就来看一下，WAF 到底有哪些功能服务？

1.HTTP 解析能力

WAF 专注于 Web 安全。因此，对 HTTP 请求进行解析是 WAF 最基础的能力。在 HTTP 中，通用的内容包括：请求的 URL 以及其中的参数、HTTP 头部信息、POST 的 body 内容等。

除此之外，某些攻击特征可能隐藏得比较深，比如 JSON 中的某个字段，无法通过 JSON 的整体内容检测出来，我们必须一个字段一个字段去判断。因此，WAF 还需要解析 XML、JSON 等 RPC 传输协议，能够理解对应的 key 和 value 分别是什么。

除了单纯地解析内容，WAF 还需要对 HTTP 内容做必要地处理。为什么要这么做呢？这主要有两方面原因。

第一，HTTP 中的内容可能经过了 UrlEncode 等编码方式的处理，因此，WAF 需要具备解码能力，避免攻击的特征通过编码来进行绕过。

第二，**想要看到 HTTPS 中的加密内容，WAF 必须能够解密 HTTPS 请求。**在透明代理模式中，WAF 需要和服务端同步 HTTPS 的密钥，才能够获得解密的请求；

在反向代理中模式中，WAF 自带证书，可以直接解密；在插件模式中，WAF 依靠服务端解密请求之后，再进行 HTTP 的解析。

2.Web 安全防护

通过对 HTTP 请求进行解析、对编码内容进行解码和对 HTTPS 进行解密之后，WAF 就能够获得全部 HTTP 请求内容了。在此基础之上，WAF 就可以对请求内容进行分析，为 Web 服务提供安全保护了。

我总结了三种主要的分析手段。

• 签名匹配：和杀毒软件中病毒库的概念类似，WAF 也可以维护一个攻击样本库。样本库中存有已知攻击请求的散列签名，只要 HTTP 请求内容的散列签名在这个样本库，就说明 HTTP 请求中携带了攻击内容。

• 正则匹配：签名匹配需要请求完全一致才能够检测出来，而正则匹配只需要部分特征就可以检测。WAF 可以通过抽象一些攻击特征的正则表达式，对 HTTP 请求进行检测。比如，如果请求的某个参数中出现了单引号，那么很有可能就是黑客发起的 SQL 注入攻击。

• 行为分析：除了针对单次请求的分析之外，WAF 还可以针对连续的访问请求特征进行提取和分析。为什么要这么做呢？这是因为，很多时候，我们无法准确判 断单次请求是不是攻击请求，但是如果疑似的攻击请求频繁出现，我们就基本能够确定了。也就是说，一个用户不会频繁地访问同一个页面，而黑客需要对一 个漏洞点发起多次尝试，才能够实现攻击的效果。

在识别到攻击的请求之后，WAF 就可以对请求进行拦截，从而避免 Web 服务受到黑客的攻击了。

3.审计告警

WAF 还有另外一个重要的功能，就是为 Web 服务提供安全相关的审计和告警功能。Web 安全相关的审计包括：**发生攻击的时间、路径、频次等。**通过这些信息，开发人员能够知道自己的 Web 服务面对的攻击威胁是什么样的，也就能够更好地评估威胁，完善 Web 安全防护机制。

除此之外，WAF 还能提供其他的审计能力。这是因为，WAF 能够解析出 HTTP 请求的全部内容，提供审计所需要的全部日志字段。这些日志可以是各个页面的访问次数、用户的访问行为和接口的响应性能等。尽管这些指标和安全没有太多关系，但是它们对于产品设计和服务质量来说都很常见，那么 WAF 就可以作为一个统计分析工具，来为你提供服务。

4.数据保护和虚拟补丁

反向代理或者插件模式的 WAF，还能够对 HTTP 请求中的数据进行一定的处理，提供额外的数据保护功能。

最简单的，WAF 可以加密 HTTP 响应中的 Cookie 内容，使得 Cookie 以保密的形式存储在浏览器中。当浏览器将加密后的 Cookie 附加到 HTTP 请求中的时候，WAF 又可以进行解密。这样一来，服务端接收到的始终是明文的信息，而实际上，WAF 通过加解密为 Cookie 提供了额外的保护。另外，WAF 还可以对返回内容中的手机号、身份证号等敏感字段进行统一的打码处理，避免因为开发的疏忽，导致这些敏感信息的泄漏。

在介绍插件漏洞的时候，我们提到了防火墙可以提供虚拟补丁的功能，来临时对插件漏洞进行修复。如果插件是 Web 相关的服务，那么 WAF 是不是也可以提供虚

拟补丁的功能呢？当然是可以的。那 WAF 是如何提供虚拟补丁的呢？我来举个简单的例子。

在经典的 Structs 2 漏洞中，黑客是通过 Structs 2 中包含的漏洞接口发起攻击的。所以，WAF 只需要将这些包含漏洞的接口进行封禁，或者对请求内容中的 Structs 2 攻击特征（特定接口的异常序列化数据）进行分析拦截，就能够临时避免 Structs 2 受到已公开的漏洞攻击。之后，我们只需要对 Structs 2 进行升级再打上补丁，这样就可以下线虚拟补丁了。、

4 WAF 解决方案

4.1 基于软件Nginx实现

我们可以使用Apache、Nginx、OPenResty 实现。

比如说，在Nginx里实现IP地址黑名单，可以利用map指令，从变量 $remote_addr 获取IP地址，在黑名单上就映射为1，然后在"if"指令里判断。

map $remote_addr $blocked {
    default       0;
    "1.2.3.4"     1;
    "5.6.7.8"     1;
}
 
 
if ($blocked) {
    return 403 "you are blocked.";  
}

Nginx 的配置文件只能静态加载，改名单必须重启，比较麻烦。如果换成 OpenResty 就会非常方便，在 access 阶段进行判断，IP 地址列表可以使用 cosocket 连接外部的 Redis、MySQL 等数据库，实现动态更新：

local ip_addr = ngx.var.remote_addr
 
local rds = redis:new()
if rds:get(ip_addr) == 1 then 
    ngx.exit(403) 
end

ngx_lua_waf是一个基于ngx_lua的web应用防火墙。可以实现WAF的相关防护功能。

用途

防止sql注入，本地包含，部分溢出，fuzzing测试，xss,SSRF等web攻击
防止svn/备份之类文件泄漏
防止ApacheBench之类压力测试工具的攻击
屏蔽常见的扫描黑客工具，扫描器
屏蔽异常的网络请求
屏蔽图片附件类目录php执行权限
防止webshell上传

推荐使用lujit2.1做lua支持

ngx_lua如果是0.9.2以上版本，建议正则过滤函数改为ngx.re.find，匹配效率会提高三倍左右。

使用说明：

nginx安装路径假设为:/usr/local/nginx/conf/

把ngx_lua_waf下载到conf目录下,解压命名为waf

在nginx.conf的http段添加

 lua_package_path "/usr/local/nginx/conf/waf/?.lua";
     lua_shared_dict limit 10m;
     init_by_lua_file /usr/local/nginx/conf/waf/init.lua; 
        access_by_lua_file /usr/local/nginx/conf/waf/waf.lua;

配置config.lua里的waf规则目录(一般在waf/conf/目录下)

​ RulePath = “/usr/local/nginx/conf/waf/wafconf/”

绝对路径如有变动，需对应修改

然后重启nginx即可

配置文件详细说明

RulePath = "/usr/local/nginx/conf/waf/wafconf/"
        --规则存放目录
        attacklog = "off"
        --是否开启攻击信息记录，需要配置logdir
        logdir = "/usr/local/nginx/logs/hack/"
        --log存储目录，该目录需要用户自己新建，切需要nginx用户的可写权限
        UrlDeny="on"
        --是否拦截url访问
        Redirect="on"
        --是否拦截后重定向
        CookieMatch = "on"
        --是否拦截cookie攻击
        postMatch = "on" 
        --是否拦截post攻击
        whiteModule = "on" 
        --是否开启URL白名单
        black_fileExt={"php","jsp"}
        --填写不允许上传文件后缀类型
        ipWhitelist={"127.0.0.1"}
        --ip白名单，多个ip用逗号分隔
        ipBlocklist={"1.0.0.1"}
        --ip黑名单，多个ip用逗号分隔
        CCDeny="on"
        --是否开启拦截cc攻击(需要nginx.conf的http段增加lua_shared_dict limit 10m;)
        CCrate = "100/60"
        --设置cc攻击频率，单位为秒.
        --默认1分钟同一个IP只能请求同一个地址100次
        html=[[Please go away~~]]
        --警告内容,可在中括号内自定义
        备注:不要乱动双引号，区分大小写

4.2 ModSecurity

ModSecurity 是一个开源的、生产级的 WAF 工具包，历史很悠久，比 Nginx 还要大几岁。它开始于一个私人项目，后来被商业公司 Breach Security 收购，现在则是由 TrustWave 公司的 SpiderLabs 团队负责维护。

这两年 SpiderLabs 团队就开发了全新的 3.0 版本，移除了对 Apache 架构的依赖，使用新的“连接器”来集成进 Apache 或者 Nginx，比 2.x 版更加稳定和快速，误报率也更低。

ModSecurity 有两个核心组件。第一个是“规则引擎”，它实现了自定义的“SecRule”语言，有自己特定的语法。但“SecRule”主要基于正则表达式，还是不够灵活，

所以后来也引入了 Lua，实现了脚本化配置。

ModSecurity 源码提供一个基本的规则配置文件“modsecurity.conf-recommended”，使用前要把它的后缀改成“conf”。

有了规则集，就可以在 Nginx 配置文件里加载，然后启动规则引擎：

modsecurity on;
modsecurity_rules_file /path/to/modsecurity.conf;

“modsecurity.conf”文件默认只有检测功能，不提供入侵阻断，这是为了防止误杀误报，把“SecRuleEngine”后面改成“On”就可以开启完全的防护：

#SecRuleEngine DetectionOnly
SecRuleEngine  On

基本的规则集之外，ModSecurity 还额外提供一个更完善的规则集，为网站提供全面可靠的保护。这个规则集的全名叫“OWASP ModSecurity 核心规则

集”（Open Web Application Security Project ModSecurity Core Rule Set），因为名字太长了，所以有时候会简称为“核心规则集”或者“CRS”。

CRS 也是完全开源、免费的，可以从 GitHub 上下载：

git clone https://github.com/SpiderLabs/owasp-modsecurity-crs.git

其中有一个“crs-setup.conf.example”的文件，它是 CRS 的基本配置，可以用“Include”命令添加到“modsecurity.conf”里，然后再添加“rules”里的各种规则。

Include /path/to/crs-setup.conf
Include /path/to/rules/*.conf

里面用“SecRule”定义了很多的规则，基本的形式是“SecRule 变量 运算符 动作”。

另外，ModSecurity 还有强大的审计日志（Audit Log）功能，记录任何可疑的数据，供事后离线分析。但在生产环境中会遇到大量的攻击，日志会快速增长，消耗磁盘空间，而且写磁盘也会影响 Nginx 的性能，所以一般建议把它关闭：

SecAuditEngine off  #RelevantOnly
SecAuditLog /var/log/modsec_audit.log