之前介绍过WAF评估标准（参见：Web Application Firewall Evaluation Criteria-WAF评估标准-v1.0），这份标准对于开发WAF有很好的指导作用，至少为你框定了很好的实现范围，不过之前给出的是英文原版的。一直以来自己也没有时间去翻译它，不过今天我看到有同学已经翻译出来了，我也就转载下喽。

以下是转载，原文在：http://blog.csdn.net/bill_lee_sh_cn/archive/2009/08/27/4488641.aspx

Web应用防火墙（WAF Web Application Firewall）评价标准.zip (65.95 kb)

Web应用防火墙（WAF Web Application Firewall）评价标准

Version 1.0 (January 16, 2006)

Copyright © 2005,2006 Web Application Security Consortium (http://www.webappsec.org)

Table of Contents

前言

撰稿者

译者

联系方式

评价项目

第1部分 - 部署方式

第2部分 - HTTP 和HTML 支持

第3部分 - 检查技术

第 4 部分 - 保护技术

第 5 部分 - 日志

第 6部分 - 报告

第 7 部分 - 管理t

第 8 部分 - 性能

第 9 部分- XML

A. Licence

前言

Web应用防火墙 (WAF) 代表了一种新的信息安全技术，用于保护Web站点（或者说Web应用程序），使其在受攻击的情况下表现出更强的抵抗力。 在抵御Web攻击方面，WAF 提供了防火墙和IDS等常规信息安全产品所不具备的能力。WAF不需要修改Web应用程序的源代码。随着目前针对Web应用的攻击手段越来越复杂化，为WAF制定一个规范的评价标准显得重要起来，有了这个标准，我们就可以去准确地比较和评价WAF产品。

本项目的目的是研究出一套WAF的评价标准，同时研究出一套测试方法，使得有经验的工程师可以使用本文中提到的知识独立的对WAF产品的优劣进行测试和评价。这里需要指出的是，由于WAF技术上的实现方式多种多样，对于WAF产品来说，并不要求其支持本文中提到的所有具体技术。

总之： 这篇文章的目的是要引起测试人员对WAF产品可能使用的一些技术的重视。我们列出的评价项目清单很长，你可以以其为基础，从中抽出部分项目对特定产品的进行测试。

评价项目如下：

1. 部署方式

2. HTTP协议支持

3. 检测技术Detection Techniques

4. 防御技术Protection Techniques

5. 审计Logging

6. 报告Reporting

7. 管理Management

8. 性能Performance

9. XML

在以后的版本里，我们准备新增和加以充实的条目还有：

· 主动学习（Compliance）,认证（ certifications）和协同工作（interoperability）

· 更深入的研究对性能 的评价(尤其是网络层性能)

· 更深入的研究对XML相关功能的评价指标

撰稿者

本文的诞生源自团队的努力。以下是为本文无私贡献了宝贵时间和经验的兄弟姐妹们：

· Robert Auger (SPI Dynamics)

· Ryan C. Barnett (EDS)

· Charlie Cano (F5)

· Anton Chuvakin (netForensics)

· Matthieu Estrade (Bee Ware)

· Sagar Golla (Secureprise)

· Jeremiah Grossman (WhiteHat Security)

· Achim Hoffmann (Individual)

· Amit Klein (Individual)

· Mark Kraynak (Imperva)

· Vidyaranya Maddi (Cisco Systems)

· Ofer Maor (Hacktics)

· Cyrill Osterwalder (Seclutions AG)

· Sylvain Maret (e-Xpert Solutions)

· Gunnar Peterson (Arctec Group)

· Pradeep Pillai (Cisco Systems)

· Kurt R. Roemer (NetContinuum)

· Kenneth Salchow (F5)

· Rafael San Miguel (daVinci Consulting)

· Greg Smith (Citrix Systems)

· David Movshovitz (F5)

· Ivan Ristic (Thinking Stone) [Project Leader]

· Ory Segal (Watchfire)

· Ofer Shezaf (Breach Security)

· Andrew Stern (F5)

· Bob Walder (NSS Group)

译者

李毅< http://blog.csdn.net/bill_lee_sh_cn>

本文译文地址< http://blog.csdn.net/bill_lee_sh_cn/archive/2009/08/27/4488641.aspx>

联系我们

Web应用防火墙评价标准项目对所有人开放，如果你想参与或是评论请联系Ivan Ristic (<ivanr@webkreator.com>).

评价项目

第1部分 – 部署方式

这一部分描述了WAF在既定环境中的部署问题

1.1 运行模式

该WAF可以支持被动(旁路监听)和主动（串接等）模式吗？

请指出该WAF支持以下主动模式中哪种或哪几种？

1. 透明网桥模式. 是否支持 fail open?【译者注：“fail open”是指当该WAF宕机或停止工作时，网络流量仍然可以穿过它，只是不再被检查】

2. 路由模式.

3. 反向代理模式（Reverse Proxy）. 通过修改DNS将网络访问流量定向到WAF上。

4. 插件模式（Embedded）.这时 WAF作为一个插件被直接安装在Web服务器上。 支持哪几种Web服务器？请指出与Web服务器如何结合： 有的插件形式WAF插在Web服务器的通讯之前，所有的检查和过滤任务都是自己完成的，而有的则依赖Web服务器的功能去完成这些任务.(这两种方式各有自己的优缺点。)

1.2 SSL

SSL通常用来保护与Web应用交互的通讯数据。这种机制在达到保护通讯数据的同时也对防御保护系统 （如IDS、WAF等）的正常使用造成了困难。如果WAF无法得到被加密的原文，它就没有办法实施保护。

请描述该WAF如何得到被加密的原文数据：

1. 作为SSL的一端（Terminates SSL）. 需要重新规划网络结构使得由WAF来完成SSL操作。 WAF 自己对HTTP数据进行加密和解密，而WAF同Web服务器之间的通讯可以使明文或也使用SSL加密。

2. 被动SSL解密（Passively decrypts SSL）.在WAF上拷贝一份Web服务器的私钥从而使WAF 可以解密SSL通讯数据. 原始的SSL通讯数据可以不受影响的到达服务器。

3. 不受SSL影响. 这一般发生在作为Web服务器插件的WAF情况下, 该WAF的工作位置在SSL已经被Web服务器解密成明文之后。

客户端证书：

1. 在被动模式下支持客户端证书吗？

2. 在主动模式下支持客户端证书吗?

3. In termination mode, can the content from client certificates be sent to the application using some alternative transport method (e.g. request headers).

其他的 SSL 相关问题：

1. 在 termination 模式中, 后台的通讯(WAF到web 服务器)使用SSL加密吗？

2. 该 WAF在后台通讯中支持客户端认证吗？

3. 是否支持所有的主流加密算法（cipher suites）？都是哪些？

4. 该WAF是否可以从外部的密钥存储设备中获取密钥 (e.g. network-based Hardware Security Module)?

5. 所支持的SSL 是否可以通过FIPS 140-2 认证? 支持哪一级的 FIPS (level II and/or III)?

6. 是否支持硬件SSL加速? 如果支持的话，SSL证书是存储在硬件中的吗？

1.3 阻断方式

如果该WAF支持阻断恶意的访问，请问采用下面的哪种方式？

1. 连接中介模式（Connection Intermediation）. 由WAF根据网络协议中途截断通讯，攻击在到达目的地之前就被阻断。【译者注：这可能是在代理模式下，或是在具备存储转发功能的WAF中的工作模式，WAF将网络层甚至是应用层的请求接完全后认为没有危险才提交给服务器】

2. 连接中断（Connection Interruption）. 这种方式中网络流量一直被监视，但是不会被WAF截断。通过阻断到目的地的连接来阻断攻击，这种方式可以使得所有数据包都会被被阻断（如只有一个数据包的攻击），也可能会有一些不能构成完整攻击的数据包到达目的地（如分片包）。【译者注：或是其他一些需要多个数据报文组成的攻击，如teardrop，需要两个分片数据报文才能构成一个攻击，而就第一个数据报文来说是无害的】

【译者注：以上两种方式从翻译来说不好判断区别，好像第一种是从应用层来说的，进行了大量的存储后转发，第二种是工作在网络层，类似于IPS。】

3. 连接重置（Connection Reset）. 主动模式、被动模式或是插件模式的WAF都可以通过重置TCP连接的方式的方法来阻断攻击。

4. 通知第三方设备进行阻断. WAF只监视网络通信，发现攻击时通知其他设备
（如路由器或防火墙）进行阻断。

请描述一下可以阻断的对象：

1. 阻断HTTP request.

2. 阻断TCP connection.

3. 封锁 IP 地址.

4. 阻断应用层会话（application session）.

5. 阻断应用层的用户.

当在HTTP应用层进行阻断时，该WAF是否可以给用户发出一个友好的信息？是否可以为用户提供一个唯一的事务ID (见 5.1)?

如果该WAF支持阻断，是否可以将阻断功能关掉（包括彻底关掉或是针对特定的请求关闭部分阻断功能?

1.4 分发方式

请说明该WAF是以何种形式进行分发的：

1. 硬件方式：将软件安装在特定的硬件中进行分发的好处在于硬件通常进行了高度的优化并且可以配之以特殊的硬件模块来提高性能。该WAF是否有可选的硬件模块来提高性能(这里除了SSL,我们已经在1.2中提到过了)?

2. 软件方式 ：请给出参考的硬件配置。该WAF是随着操作系统集成在其中进行分发的，还是要使用者在操作系统中安装？支持哪些操作系统（包括版本号）？需要其他额外的硬件模块来提高性能吗（譬如说SSL加密卡等）？

1.5 高可用性

高可用性有两个方面：一是要防止这个WAF在出现问题时影响了其他应用，二是要让该WAF在高负载的情况下不至于影响其功能的发挥。现在有如下问题：

1. 当使用主动模式（active mode）时, 是否可以配置成fail open?

2. 是否支持多节点并行处理? 如支持请说明其架构和实现原理。

3. 在双机热备的模式下，如何进行失效接管（fail over）以及之间需要多长时间?

4. 在双机热备的模式下，备机可以用来分担部分负载吗？

5. 各节点的状态可以共享吗？ (如果共享状态的话，一个节点失效对整个系统来说不会有任何影响) 再问一下,是否也支持SSL的会话状态共享?

6. 是否支持集群（两个节点以上）? 如果支持的话最大支持多少节点？

7. 节点在物理上可以分散部署吗？如果可以的话请说明这样部署的话对失效接管以及状态共享有什么影响?

1.6 串接模式下的功能 Inline operation

1. 该WAF是否支持模拟出所有的Web服务器的功能？【译者注：这里的意思是由WAF直接同浏览客户端和Web服务器进行通信，再将浏览器的请求或是服务器的回应向对方传递】请描述一下支持哪些：

a. 虚拟的主机.

b. 网络端口.

c. URL 映射

d. Authentication realms. (这个在 2.7中详细解释.)

e. Cookies.

f. Sessions.

2. 该WAF 支持 HTML (response)重写来改变其中的URI吗？

3. 用户可以自定义 HTML重写功能吗？支持哪些部分的重写？

a. Request headers.

b. Response headers.

c. Parameters (包括查询参数, application/x-www-form-urlencoded POST 参数, and multipart/form-data POST 参数等).

d. Request body - raw.

e. Request body - XML.

f. Request body - other (list supported content types).

g. Response body - raw.

h. Response body - HTML.

i. Response body - other (list supported content types).

4. 支持网页缓存吗?

5. 支持响应网页的压缩吗?

6. 可以完全的重塑对真实服务器的请求吗？

1.7 对非HTTP协议的支持

请说明除了HTTP还支持其他的协议吗 (如： FTP, DNS, LDAP)?

对工作在网络层的串接模式的WAF来说，是否同时具备网络层防火墙的功能？

第 2部分 - HTTP 和 HTML 支持

2.1 支持的 HTTP 版本

是否支持以下版本：

1. HTTP/0.9

2. HTTP/1.0

3. HTTP/1.1

2.2 支持常用的编码方式

应该支持下面列出的编码方式：

1. application/x-www-form-urlencoded 编码

2. multipart/form-data 编码

3. v0 cookies

4. v1 cookies

5. request分块编码(chunked encoding) 【译者注：分块编码(chunked encoding)传输方式是HTTP 1.1协议中定义的Web用户向服务器提交数据的一种方法，当服务器收到chunked编码方式的数据时会分配一个缓冲区存放它，如果提交的数据大小未知，客户端会以一个协商好的分块大小向服务器提交数据。】

6. response分块编码(chunked encoding)

7. request 压缩

8. response 压缩

2.3 严格的协议检查Strict protocol validation

1. 如何进行限制（限制方法详见下面）

2. 限制协议和协议的版本

3. 严格的 (per-RFC) request 验证

4. 检查URL编码字符 URL-encoded characters

5. 检查不规范的编码如 %uXXYY字符

6. 强制规定所使用的 cookie 类型(如只允许v1 cookies)

限制方法

限制方法包括如下部分：

1. 元素内容

2. 元素长度

3. 元素字节范围.

4. 字符集限制 (如：UTF-8)。都支持哪些字符集?

当对request的不同部分使用不同的限制时WAF的灵活性如何？

2.3 其他的协议限制

是否支持如下的与协议相关的限制：

1. request method length

2. request line length

3. request URI length

4. query string length

5. protocol (名称 和版本) length

6. header的数目

7. header name length

8. header value length

9. request body length

10. cookie name length

11. cookie value length

12. cookies的数目

2.4 HTML 限制

1. parameter 名称长度

2. parameter 值长度

3. parameter的数目

4. parameter的总共长度 (名称和值的长度和)

2.5 文件传输

1. 支持 POST方法文件上传(multipart/form-data encoding)

2. 支持 PUT方法文件上传

3. 每个上传文件的大小可限制

4. 一次上传多个文件时，总大小可限制

5. 请求的文件数目可以限制

6. 是否支持添加自定义的文件检查规则?

2.6 支持多种字符集

WAF必须可以对request中使用不同编码的字符进行检查以提供更好的保护功能。

2.7 身份认证

这部分涉及普通的身份认证方法，从两个方面进行评价

该WAF支持使用下述认证方法的应用吗？

1. 基本的身份验证（Basic Authentication）【译者注：这里可能指的是常规的用户名/口令认证】

2. 使用摘要算法的身份验证（Digest Authentication）【译者注：这里可能指的是对口令进行了MD5加密的认证】

3. NTLM身份验证

4. 客户端证书

该 WAF 是否本身支持以下的身份验证方式(由WAF为应用提供额外的身份验证)?

1. 基本的身份验证（Basic Authentication）

2. 使用摘要算法的身份验证（Digest Authentication）

3. NTLM身份验证

4. 客户端证书

5. 双因素身份验证

注：关于SSL中对客户端证书支持的更详细的描述请见1.2.

该WAF可以将身份验证集成到后台的验证机制中吗？是否支持一些通用的身份验证方法（如LDAP、RADIUS等）？

该 WAF 支持一些主流的安全标记语言（security assertion）或是联合身份认证协议（Federated Identity protocols）吗？

1. 安全断言标记语言（SAML ）(1.0, 1.1, 2.0)

2. Liberty-ID-FF (1.0, 1.1, 1.2)

3. WS-Trust【译者注：Web Service中的一种安全协议】

2.8 Response 过滤

该WAF支持对服务器发送出的响应内容进行检查分析吗 (有时这种功能被称为"Identity Theft Protection"或 "Intellectual Property Firewalling")?

1. Response headers

2. Response body

3. Response status

第3 部分- 检查技术Detection Techniques

3.1 数据还原

Web系统通常和其他相关系统一同使用【译者注：如数据库系统等】。这就使得攻击者将攻击行为伪装成一种看上去无害的形式（譬如通过编码变换）提交进来以攻击后台的其他系统【译者注：如SQL注入，对Web应用本身无害，是对后台数据库的攻击】。由于后台系统的种类繁多，WAF必须识别出针对这些系统的攻击，这为WAF的开发带来了很大的难处，为了使WAF的规则可以有效的抵御这些攻击，WAF必须发现出这些攻击并将变换的输入数据还原成正常的数据。

请描述该 WAF是否支持以下的数据还原方法：

1. URL解码 (如%XX)

2. 以空字节结尾的字符串（Null byte string termination）【译者注：如C风格字符串】

3. 路径中的本级目录引用 (如使用 /./ 或与之等价的编码字符串)

4. 路径中的上级目录引用(如使用 /../ 或与之等价的编码字符串)

5. 大小写混合使用（Mixed case）【译者注：如SeLeCt 】

6. 大量使用空格字符

7. 注释移除(如将DELETE/**/FROM 改为 DELETE FROM)【译者注：这点我也不明白】

8. 将"\"(Windows下的)改为"/"

9. 对IIS制定的Unicode编码进行转换 (%uXXYY)

10. 对HTML中的一些特殊定义的字符进行转换(如&#99;【译者注：这个其实就是HTML代码里用ASCII代码表示字符的方式. &#99; 代表的就是字符为99的ASCII字符，即“c”】, &quot;【译者注：引号】, &#xAA;【译者注：这是使用十六进制表示的字符，相当于&#170;即“ª”】，关于html中特殊字符请见一篇文章<html中特殊字符>：地址：http://sailinglee.javaeye.com/blog/446898)

11. 转义字符（Escaped characters） (如\t, \001, \xAA, \uAABB)

3.2 被动安全模式（Negative security model）

【译者注：也就是所谓的黑名单机制】

当使用被动安全模式时，除了那些包含攻击的行为被阻止外，其他的行为都被允许放行。这种模式的安全性取决于WAF对有害行为的定义和检查效果

请问该WAF的黑名单定义采用了下述的哪种机制：

1. 基于签名（Signature-based）. 签名的方法通常采用关键字或是正则表达式对流量内容进行检查。

2. 基于规则（Rule-based）. 同签名方法很相似，但是规则可以在逻辑上更复杂（如支持AND 、OR），同时也可定义对内容的某一特定部分进行检查。

3.3 主动安全模式（Positive security model）

【译者注：也就是所谓的白名单机制】

主动模式下除了那些被相关规则判别出是有效和安全的流量可以通过外，其他所有的流量都默认禁止通过。这种方法在处理效率上比较高(因为允许通过的流量的特征比较少，所以对流量进行检查时使用的检查规则较少，同时也更安全，但其缺点在于需要对受保护的系统有较深入的了解以决定哪些流量是允许的。这种主动模式在Web应用经常变化的情况下维护起来比较困难。

请回答下述问题：

1. 是否支持主动模式？

2. 可以手工修改主动模式的配置吗?

3. 主动模式下其配置可以自动修改吗（如采用学习模式）？自动配置使用了什么工具？自动配置需要如何来维护 (动态？手工？还是完全自学习？)?

4. 支持升级吗?升级时需要重启WAF吗？

主动模式可以采用严格的内容检查规则方法、统计分析方法或是基于异常检测的神经网络方法。

3.4 签名和规则库

请回答下述相关问题：

1. 产品在出厂时具有对已知攻击所定义的签名或规则库吗？

2. 该库都支持哪些产品？

3. 签名或规则库的升级周期是多长时间？

4. 签名或规则库中是否指定了针对的操作系统、应用及其版本？是否允许管理员只使用其中合适的部分？【译者注：即规则可选择，否则如果所有的规则都进行检查，对性能影响太大】

3.5 API 接口

是否支持API接口允许自开发插件？

第 4部分 – 保护技术Protection Techniques

这一部分列出了使用普通的保护机制无法达到的一些特定的安全需求，这篇文章无法描述出所有的Web安全问题，这些内容可以从我们的另外的一个有关各种威胁分类的项目中找到http://www.webappsec.org/projects/threat/.

4.1 限制暴力破解攻击

1. 可以检测到HTTP访问控制中的暴力破解攻击(HTTP status code 401).

2. 可以检测到应用中任一部分的暴力破解攻击(对同一资源的大量访问)。

3. 可以为不返回401错误的应用定制防暴力破解攻击规则 (probably with a regular expression applied to a response part).

4. 可以采用限制或阻止攻击者的手段。

5. 可以检测到Session管理机制中的暴力破解攻击(从单一IP或某个IP段发出的Session太多)。

6. 可以检测到自动客户端(Session请求的频率过高)。

4.2 Cookie保护方法Cookie Protections Measures

1. 对cookie进行签名，防止在客户端对之进行修改。

2. 对cookie进行加密以隐藏其中的内容。

3. 对cookie进行完全隐藏(cookie机制虚拟化：发送到客户端的每一个cookie都是用唯一ID)。

4. 是否可以为每一个应用定制保护规则？【译者注：一个WAF可能保护了多个Web应用，每个Web应用都有自己的特点，这句话的意思是针对每个应用制定不同的cookie保护方法】

4.3 限制会话攻击

1. 为了完全接管应用中的session处理机制，需要支持下面的机制：

a. Cookies

b. Form parameters

c. URI 重写

2. session IDs 可以同 SSL中的 session ID 值相符吗?

3. session IDs可以结合到身份验证机制里吗?

4. 是否可以为每一个应用定制保护规则？

4.4 保护表单中的隐藏域

是否可以防止表单中隐藏域的值被篡改？

4.5 URL加密和参数保护

是否支持URL和参数的加密以防止它们被任意的访问(如强制访问、session劫持等)?【译者注：cryptographic URL Encryption ：这种方法很好，有两个层面，一个是URL的加密，要同Session等一次性的机制结合起来，使得每次访问的目标都要通过Web应用的一个统一解密入口才能到达真正的URL，还有一个是参数的加密，可以有效的防止暴力猜测】

4.6 严格的请求顺序控制

是指WAF严格的监视请求的顺序，只有那些可能的后续请求才能被允许。【译者注：这一块我是意译的，不知道对不对，但这种方法的确很好，譬如说某个站点有ABC三个网页，A中有一个链接到B，但是没有到C的直接链接，那么在访问A之后马上访问C就是一种异常的访问，有可能是一种攻击】

第 5部分 –日志

5.1 唯一的事务ID

为每一个HTTP事务（一个事务定义为一个请求 和其相应的响应）分配一个唯一的ID并在包括在日志信息里面。

5.2 访问日志

访问日志是指对通过WAF的所有事务的记录。访问日志通常是文件的形式，也有一些其他的形式（如数据库）。

1. 访问日志可以导出至文件。

2. 支持哪些常用的日志格式？

3. 访问日志的格式可以定制。

4. 访问日志是否可以发送至Syslog服务器？

5. 访问日志是否可以定时的发送至日志服务器 (如通过 FTP, SFTP, WebDAV, o或SCP).？

5.3 事件日志和通知

事件日志是指对那些可疑的事务的记录。事件日志通常是文件，也可以保存在数据库中。

我们希望WAF可以支持下面的事件通知方法：

1. 邮件

2. Syslog

3. SNMP Trap

4. OPSEC Event Logging API (ELA - http://www.opsec.com/intro/sdk_overview.html#ela)

5. 使用 HTTP(S) push进行通知【译者注：HTTP push是一个新鲜玩意，该技术通过延长response的时间保持与客户端的TCP连接，这样就可以在其中加入通知内容提醒客户端，具体的方法请见《HTTP PUSH技术原理，结合ASP.NET实现以及评述》，地址http://blog.csdn.net/banmuhuangci/archive/2008/09/20/2955719.aspx】

6. 定期的日志上传

事件日志的格式也很重要，请描述一下日志的格式是哪一种？

1. 文本格式?

2. XML?

3. 提供API支持定制格式？

5.4 完整的事务日志

一个完整的事务日志必须包括HTTP请求及其响应。重点是请求的body部分，响应的body部分可选。完整的事务日志有以下的要求：

1. 有对事务日志格式的描述性文档。

2. 日志的详细程度应该可以定制。如：允许用户只记录request的body部分而不记录response的body部分，应该只对那些可疑的事务进行详细的记录，而对那些非可疑的事务只进行有限详细的记录。

3. 可以指定哪些事务需要记录，譬如说：只记录可疑的事务，或是只记录带参数的动态页面事务。

4. 对于支持Session机制的WAF来说应该记录包含可疑事务的整个Session中的访问数据。s

5.5 日志访问

对日志的访问有如下要求：

1. 日志可以定期通过FTP 或SCP导出为文件。

2. 日志可以直接通过访问数据库得到，数据库的结构需要有详细的文档描述。

3. 日志可以通过提供的API访问获得(取pull).

4. 提供API支持开发插件在消息到来时即时获得 (推push).

5. 日志可以签名为thwart tampering吗?

5.6 支持Syslog

如果支持 Syslog 需要评价以下几个方面：

1. 支持基于UDP的Syslog

2. 支持面向连接的Syslog【译者注：如TCP】

3. 在面向连接的Syslog中应该支持SSL来保护传输内容

4. 当使用SSL时，客户端和服务器端的证书应该可以还有其他的作用

5.7日志留存

这是指设备对于重要日志的保存能力，防止存储空间溢出。

1. 可以设置日志保存的最大期限，对超出这个期限的日志进行删除

2. 可以设置日志的最大存储空间，当达到空间限制值时删除最早的日志

3. 支持多中日志留存规则（如违反规则的日志可以保存的时间长一些）

4. 在删除日志之前可以进行自动的备份。

5.8 敏感数据处理

1. 可以从日志中删除敏感数据吗？

2. 可以设置哪些是敏感数据吗？

3. 可以自动识别哪些是敏感数据吗? 可以定制吗?

4. 可以使用哪些模糊化的处理方法? (一个简单的办法是使用替换方法，如替换成*，或者使用一种可以还原的转换方法，允许特定的人员在必要时进行还原)

【译者注：敏感数据的处理是对日志的一个高要求，如用户提交的银行账号、密码等，这些如果记录在日志中会存在很大的风险，所以可以将其转换为*，或采用可逆的加密机制，在可控的情况下进行还原】

第6 部分- 报告

6.1 事件报告

由于分析员可能会经常查看事件日志，需要用报告来跟踪综合的安全等级

1. 可以生成可理解的事件报告吗？支持哪些过滤条件？

a. 日期和时间?

b. IP地址范围?

c. 事件类型?

d. 其他(请一一指出).

2. 报告可以随时生成。

3. 报告可以定期生成 (如：每日或每周)

6.2 报告格式

以下是常用的格式：

1. Word

2. RTF

3. HTML

4. PDF

5. XML

6.3 报告的显示

定制的目的是使报告看上去和公司的其他文档格式一致

1. 显示相关定制 (如色彩、logo等).

2. 内容定制 (目标群体如主管、开发人员等)

3. 是否在报告中包含了适合的图表?

4. 支持哪些目标群体?

6.4 报告分发

支持以下哪几种方式：

1. 自动通过邮件分发 (push).

2. 自动通过 FTP分发 (push).

3. 通过第三方的报告集中管理平台分发 (pull).

第 7部分 – 管理

对于网络设备来说管理是一个重要的部分，尤其对于安全设备来说，因为业务需要的不停变化需要对设备不停的进行设置。从这个角度来说，WAF的管理模块必须满足策略更新的需求，同时管理模块的设计和实现上需要格外小心， 保证不会影响吞吐量和可用性。下面是关系到WAF管理模块的几个方面，我们对其进行了分类，以便区分不同的管理需求，这可以从一个较高的抽象层次来对WAF进行评价，而不必深入到具体的相关技术。

7.1 策略管理

7.1.1 可以方便的弃用某些自动生成的策略

大多数的WAF设备都可以自动的学习应用的逻辑结构并建立与之对应的安全策略，然而，如果这些策略带来了大量的误报，应该有一种机制可以很方便的弃用其中的某些策略，而不是从零开始再手工建立策略。

7.1.2 可以方便的修正误判

对于某些策略将合法的请求误判是攻击的情况应该可以方便的将这些合法的请求移出过滤规则。

7.1.3 为不同的应用定制不同的策略

标题已经很清楚了。对于新部署的应用需要对之采用学习模式，而那些已经建立了稳定的策略的老应用. 则不能再使用学习模式了。

更多的关于策略粒度的要求请参见 2.2.4。

7.1.4 可以定制攻击的特征及其响应事件

主动安全模式中应该没有自定义攻击特征的概念了，然而，一些商用的产品中往往将这两种功能结合在一起来增强准确性，管理模块应该支持自定义特征来对付那些针对某些应用的特别的攻击行为。

7.1.5 可以定制防止DoS的策略

由于应用环境的不同，对DoS也不好作出一个标准的定义，因此， WAF产品需要能允许管理员自己定义如何去辨别DoS攻击，有些具有一定智能的WAF可以为正常的应用访问建立一个统计模型，通过监控流量是否偏离了这个正常模型来判断是否发生了DoS攻击。

7.1.6 可以将探测和阻断结合起来

策略需要能在较细的粒度上提供支持，不能支持在整个应用的层面上不停的从检测和阻断模式之间进行切换，必须要在组件的层次上支持对每一个攻击在检测和阻断之间进行组合，这使得管理员可以方便的再阻断那些真实攻击的同时也可以对流量进行检测【译者注：这段话翻得比较晦涩，意译过来应该就是尽量的让功能模块化，并使得各模块之间可以同时工作和进行信息交换】。

7.1.7 回退机制

如果新设置的策略没有正确的保护网站或者影响了网站的服务，应该有一种机制能方便的返回到先前的策略状态。

7.1.8策略共享

该WAF的策略是否可以共享到其他的系统？如果可以的话，如何进行策略同步？策略可以导出为一个文件并导入到其他系统中吗？如何控制策略的版本？

7.2 学习机制

7.2.1 识别出可信任的主机

学习模式的基础是对客户端和应用服务器之间的流量进行监视，但是在一个时间段中可能没有任何的攻击行为发生，因此不能将这个作为学习无害流量的基础，应该可以指定一些可信任的主机让WAF将这些主机的流量作为无害流量来学习。

7.2.2 在无人干涉的情况下对应用特征进行学习

应该有一种内建的机制使得WAF可以在没有用户访问网站的情况下也可以对应用的特征进行学习。就像网络爬虫或是扫描器那样对网站的每一个链接页面和所有服务进行分析，这种爬虫需要和策略编辑器有机的结合起来，同时，应可以定时进行扫描以发现Web应用的更改并及时对策略进行修正。

7.2.3在图形界面外可以对策略进行修正

有时GUI提供的策略向导并不能生成足够准确的策略，因此必须可以对策略中的细节进行调整，譬如说修改那些正则表达式中的某些值等【译者注：策略往往就是界面中的一条规则，通过GUI我们可能只能对其中有限的部分进行修改，这样有可能无法达到我们的目的，这一段话的意思是允许我们对策略中的细节进行修改】

7.2.4 对策略进行检查

1. 是否可以很方便的审计安全策略并对之生成报告？如何审计？

2. 策略的变化师傅进行了审计？审计都包括那些细节 (如： 更改的内容, 日期, 时间, 管理员等)?

7.3 配置管理

7.3.1 用户验证和角色管理

需要对登录的用户划分不同的权限，可以包括但不限于：设备管理员（设备配置）、应用所有者（策略配置）、审计员（日志查看）等。

7.3.2 支持信任主机

信任主机 (通过IP或IP范围指定)有时需要被允许进行违反策略的操作。如在渗透性测试中，需要关闭保护机制或者仅仅产生报警。

1. WAF是否可以针对信任主机不采用阻断机制而仅仅是将错误写入日志？

2. WAF是否可以忽略来自信任主机的任何访问请求 (连日志也不记)?

7.3.3攻击特征库自动升级和安装

如果攻击特征库是作为一种检查手段的话，需要在每一个探测器上都可以自动下载和升级它。

7.3.4 远程管理

我们建议在安全的网络上对WAF进行远程管理。这使得管理员的维护工作变得更安全，同时管理的网络流量需要能方便的通过防火墙并且要进行加密，以防被截获。

7.4 日志和监测

7.4.1 可以感知系统出错和性能的下降

管理模块应该可以对系统状态进行监测，以便在发生错误或性能下降时通知管理员，通常使用的通知方式是电子邮件、SNMP、Syslog或短信。

7.4.2 日志抑制

所谓日志抑制其实是一种简单的机制，它通过一种巧妙的办法将相似的日志聚合为一条，并说明其次数，从而看起来更为简洁。如何去聚合则可由用户定义。

7.4.3 服务和系统状态统计

统计报表可以在WAF在没有达到预期效果时为管理员提供帮助，同时，也有助于了解受保护的服务器的活动和性能，下面列出了相关工具可以提供的一些基本统计因素：

· 每秒的请求数/连接数/会话数

· 恶意请求的百分比

· 阻断的请求百分比

· 错误数

· 识别出的浏览器类型 (通过对 User-Agent header的判断得到)

· 访问最频繁的URL

这些数据应该存储在容易获取到的日志中，甚至可以直接显示在设备上。

7.5 其他

7.5.1 界面的强壮性和可靠性

当WAF的界面存在BUG是很麻烦的，因此在设计界面时应该注意避免出现意外错误和管理失效的情况发生。应该设计一种机制在设置新策略失败时，WAF可以恢复到原来的状态。

另一方面，WAF得管理界面不能存在像其准备去保护的应用中的那些相同的弱点，如SQL注入漏洞、参数恶意修改漏洞（Parameter Tampering）等。

【译者注：Parameter Tampering：修改那些hidden的参数值或是url中参数值，详细的请见http://www.owasp.org/index.php/Web_Parameter_Tampering】

7.5.2 管理接口实现方式

管理接口采用以下哪种实现方式？

1. 本地程序（Native application）?【译者注：Native application大概是指以前那种CS模式】

2. B/S结构？

7.5.3 管理接口

是否为管理使用一个独立的网络接口从而提供一个独立管理通道？

是否为管理接口进行特殊设计，请描述一下：

1. 使用独立的网络接口提供SSH/HTTPS 访问

2. 串口控制台

是否支持双因素认证？都是哪些因素？

7.5.4 后台控制API

WAF是否提供了后台控制的API使得后台受保护的程序可以利用其操纵WAF进行某些操作(如：终止用户会话，阻断某个IP或限制登录尝试等)?

7.5.5 WAF 自身安全

WAF如何保证自身安全？使用了什么操作系统?该操作系统如何维护，是否定期的打补丁？补丁升级是否是自动的？

第 8部分 – 性能

不得不承认性能问题很复杂，尤其是在网络层这一层去衡量WAF的性能更是一个难题，这也超出了本文的讨论范围(有关内容可以去看看NSS 的相关文章： http://www.nss.co.uk/WebApp/Ed1/WebApp%AD_Performance_Testing.htm)。下面的两个部分是对WAF作为普通网络设备的性能评价指标，并未涉及其保护机制的性能评价，我们将在以后扩展这一部分。

8.1 HTTP层性能

1. 最大新建连接速率（Maximum new connections per second.）

2. 最大吞吐量（Maximum throughput per second） (访问一个 32KB大小的页面).

3. 最大请求速率（Maximum requests per second） (with Keep-Alives enabled).

4. 最大并发连接数（Maximum number of concurrent connections.）

5. 请求延迟（Request latency）.

上面的性能指标均是假定在零丢包的情况下测得的最大值。

8.2 打开SSL的HTTP层性能

这是在后台应用没有使用SSL的情况下，单纯测试如果WAF代替后台进行SSL传输时的性能值：

1. 最大新建SSL连接速率（Maximum new connections per second.）

2. 最大新建SSL会话速率（Maximum SSL session resumptions per second.）

3. 在指定加密算法下最大SSL流量吞吐量(访问一个 32KB大小的页面)

4. 最大请求速率（Maximum requests per second）(with Keep-Alives enabled).

5. 最大并发连接数（Maximum number of concurrent connections.）

6. 请求延迟（Request latency）.

上面的性能指标是假定在零丢包的情况下测得的最大值。

8.3 负载下的性能

系统的管理能力是否在较大的流量下会受影响？是否在较大的攻击流量下会受影响？

第 9部分 - XML

这一部分仅涉及一些基本的XML相关问题。我们将在以后的版本中展开对XML的更深入的讨论.

1. WAF是否可以保护基于XML的 Web Services?

2. 是否支持指定WS-I Basic conformance (http://www.ws-i.org)?

3. WAF 是否可以对使用WASDL定义 Web Services 函数调用进行限制？

a. WAF 是否可以阻止由管理员指定禁止访问的Web Services函数调用？

b. WAF 是否可以检查Web Services函数调用时输入的参数数值或类型？

4. WAF是否可以对 Web Services和 RPC通讯数据进行验证？

5. WAF是否可以 对Web Services XML 文档内容有效性进行验证？【译者注：这里的“验证”，在原文中是validation，实际上是指对XML文档自身格式有效性或使用DTD、XML Schema对其数据内容有效性进行验证】

【译者注：这里多说一点， Xpath也存在注入风险，Web Service以HTTP为传输协议，以XML为数据载体，对其进行保护是WAF义不容辞的责任】

A. Licence

This work is licensed under the Creative Commons Attribution License. To view a copy of this license, visit http://creativecommons.org/licenses/by/2.5/ or send a letter to: Creative Commons, 559 Nathan Abbott Way, Stanford, California 94305, USA.