分类： 系统运维
2016-11-20 20:45:57
Version 1.0 (January 16, 2006)
Copyright © 2005,2006 Web Application Security Consortium ()
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 (<>).
这一部分描述了WAF在既定环境中的部署问题
该WAF可以支持被动(旁路监听)和主动（串接等）模式吗？
请指出该WAF支持以下主动模式中哪种或哪几种？
1. 透明网桥模式. 是否支持 fail open?【译者注：“fail open”是指当该WAF宕机或停止工作时，网络流量仍然可以穿过它，只是不再被检查】
2. 路由模式.
3. 反向代理模式（Reverse Proxy）. 通过修改DNS将网络访问流量定向到WAF上。
4. 插件模式（Embedded）.这时 WAF作为一个插件被直接安装在Web服务器上。 支持哪几种Web服务器？请指出与Web服务器如何结 合： 有的插件形 式WAF插在Web服务器的通讯之前，所有的检查和过滤任务都是自己完成的，而有的则依赖Web服务器的功能去 完成这些任务.(这两种方式各有自己的优缺点。)
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证书是存储在硬 件中的吗？
如果该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支持阻断，是否可以将阻断功能关掉（包括彻底关掉或是针对特定的请求关闭部分阻断功能?
请说明该WAF是以何种形式进行分发的：
1. 硬件方式：将软件安装在特定的硬件中进行分发的好处在于硬件通常进行了高度的优化并且可以配之以特 殊的硬件模块来提高性能。该WAF是否有可选的硬件模块来提高性能(这里除了SSL,我们已经在1.2中提到过了)?
2. 软件方式 ：请给出参考的硬件配置。该WAF是随着操作系统 集成在其中进行分发的，还是要使用者在操作系统中安装？支持哪些操作系统（包括版本号）？需要其他额外的硬件模块来提高性能吗（譬如说SSL加密卡等）？
高可用性有两个方面：一是要防止这个WAF在出现问题时影响 了其他应用，二是要让该WAF在高负载的情况下不至于影响其功能的发挥。现在有如下问题：
1. 当使用主动模式（active mode） 时, 是否可以配置成fail open?
2. 是否支持多节点并行处理? 如支持请说明其架 构和实现原理。
3. 在双机热备的模式下，如何进行失效接管（fail over）以及之间需要多长时间?
4. 在双机热备的模式下，备机可以用来分担部分负载吗？
5. 各节点的状态可以共享吗？ (如果共享状态的 话，一个节点失效对整个系统来说不会有任何影响) 再问一下,是否也支持SSL的会话状态共享?
6. 是否支持集群（两个节点以上）? 如果支持的话最大 支持多少节点？
7. 节点在物理上可以分散部署吗？如 果可以的话请说明这样部署的话对失效接管以及状态共享有什么影响?
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. 可以完全的重塑对真实服务器的请 求吗？
请说明除了HTTP还支持其他的协议吗 (如： FTP, DNS, LDAP)?
对工作在网络层的串接模式的WAF来说，是否同时具备网络层防火墙的 功能？
是否支持以下版本：
1. HTTP/0.9
2. HTTP/1.0
3. HTTP/1.1
应该支持下面列出的编码方式：
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 压缩
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的灵活性如何？
是否支持如下的与协议相关的限制：
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的数目
1. parameter 名称长度
2. parameter 值长度
3. parameter的数目
4. parameter的总共长度 (名称和值的长度和)
1.
支持 POST方法文件上传(multipart/form-data encoding)
2. 支持 PUT方法文件上传
3. 每个上传文件的大小可限制
4. 一次上传多个文件时，总大小可限 制
5. 请求的文件数目可以限制
6. 是否支持添加自定义的文件检查规 则?
WAF必 须可以对request中使用不同编码的字符进行检查以提供更好的保护功能。
这部分涉及普通的身份认证方法，从两个方面进行评价
该WAF支持使用下述认证方法的应用吗？
1. 基本的身份验证（Basic Authentication）【译者注：这里可能指的是常规的用户名/口令认证】
2. 使用摘要算法的身份验证（Digest Authentication）【译者注：这里可能指的是对口令进 行了MD5加密的认证】
3. NTLM身份验证
4. 客户端证书
该 WAF 是否本身支持以下的身份验证方式(由WAF为应用提供额外 的身份验证)?
1. 基本的身份验证（Basic Authentication）
2. 使用摘要算法的身份验证（Digest Authentication）
3. NTLM身份验证
4. 客户端证书
5. 双因素身份验证
该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中 的一种安全协议】
该WAF支持对服务器发送出的响应内容进行检查分析吗 (有时这种功能被称为"Identity Theft Protection"或 "Intellectual Property Firewalling")?
1. Response headers
2. Response body
3. Response status
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中的一些特殊定
义的字符进行转换(如c【译者注：这个其实就是HTML代码里用ASCII代码表示字符的方式. c 代表的就是字符为99的ASCII字符，即“c”】, "【译者注：
引号】, ª【译者注：
这是使用十六进制表示的字符，相当于ª即“ª”】，关于html中特殊字符请见一篇文章<html中特殊字符>：地址：http://sailinglee.javaeye.com/blog/446898)
11.
转义字符（Escaped characters） (如\t, \001, \xAA, \uAABB)
【译者注：也就是 所谓的黑名单机制】
当使用被动安全模式时，除了那些包含攻击的行为被阻止外，其他的行为都被 允许放行。这种模式的安全性取决于WAF对有害行为的定义和检查效果
请问该WAF的黑名单定义采用了下述的哪种机制：
1. 基于签名（Signature-based）. 签名的方法通常采用关键字或是正则表达式对流量内容进行检查。
2. 基于规则（Rule-based）. 同签名方法很相似，但是规则可以在逻辑上更复杂（如支持AND 、OR），同时也可定义 对内容的某一特定部分进行检查。
【译者注：也就是 所谓的白名单机制】
主动模式下除了那些被相关规则判别出是有效和安全的流量可以通过外，其他 所有的流量都默认禁止通过。这种方法在处理效率上比较高(因为允许通过的流量的特征比较少，所以对流量进行检查时使用的检查规则较少，同时也更安全， 但其缺点在于需要对受保护的系统有较深入的了解以决定哪些流量是允许的。这种主动模式在Web应用经常变化的情况下维护起来比较困难。
请回答下述问题：
1. 是否支持主动模式？
2. 可以手工修改主动模式的配置吗?
3. 主动模式下其配置可以自动修改吗 （如采用学习模式）？自动配置使用了什么工具？自动配置需要如何来维护 (动态？手工？还是完全自学习？)?
4. 支持升级吗?升级时需要重启WAF吗？
主动模式可以采用严格的内容检查规则方法、统计分析方法或是基于异常检测 的神经网络方法。
请回答下述相关问题：
1. 产品在出厂时具有对已知攻击所定 义的签名或规则库吗？
2. 该库都支持哪些产品？
3. 签名或规则库的升级周期是多长时 间？
4. 签名或规则库中是否指定了针对的 操作系统、应用及其版本？是否允许管理员只使用其中合适的部分？【译者注：即规则可选择，否则如果 所有的规则都进行检查，对性能影响太大】
是否支持API接口允许自开发插件？
这一部分列出了使用普通的保护机制无法达到的一些特定的安全需求，这篇文 章无法描述出所有的Web安全问题，这些内容可以从我们的另外的一个有关各种威胁分类的项目中找到.
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请求 的频率过高)。
1. 对cookie进行签名， 防止在客户端对之进行修改。
2. 对cookie进行加密以 隐藏其中的内容。
3. 对cookie进行完全隐 藏(cookie机制虚拟化：发送到客户端的每一个cookie都是用唯一ID)。
4. 是否可以为每一个应用定制保护规 则？【译者注：一个WAF可能保护了多个Web应用，每个Web应用都有自己的特点，这句话的意思是针对每个应用制定不同的cookie保护方法】
1. 为了完全接管应用中的session处理机 制，需要支持下面的机制：
a. Cookies
b. Form parameters
c. URI 重写
2. session IDs 可以同 SSL中的 session ID 值相符吗?
3. session IDs可以结合到身份验证机制里吗?
4. 是否可以为每一个应用定制保护规 则？
是否可以防止表单中隐藏域的值被篡改？
是否支持URL和参数的加密以防止它们被任意的访问(如强制访问、session劫持等)?【译者注：cryptographic URL Encryption ：这种方法很好，有两个层面，一个是URL的加密，要同Session等一次 性的机制结合起来，使得每次访问的目标都要通过Web应用的一个统一解密入口才能到达真正的URL，还有一个是参数的加密，可以有效的 防止暴力猜测】
是指WAF严格的监视请求的顺序，只有那些可能的后续请求才能被允许。【译者注：这一块我是意译的，不知道对不对，但这种方法的确很好，譬如说某个站点有ABC三个网页，A中有一个链接到B，但是没有到C的直接链接，那么在 访问A之后马上访问C就是一种异常的访问，有可能是一种攻击】
为每一个HTTP事务（一个事务定义为一个请求 和其相应的响应）分配一个唯一的ID并在包括在日志信 息里面。
访问日志是指对通过WAF的所有事务的记录。访问日志通常是文 件的形式，也有一些其他的形式（如数据库）。
1. 访问日志可以导出至文件。
2. 支持哪些常用的日志格式？
3. 访问日志的格式可以定制。
4. 访问日志是否可以发送至Syslog服务器？
5. 访问日志是否可以定时的发送至日 志服务器 (如通过 FTP, SFTP, WebDAV, o或SCP).？
事件日志是指对那些可疑的事务的记录。事件日志通常是文件，也可以保存在 数据库中。
我们希望WAF可以支持下面的事件通知方法：
1. 邮件
2. Syslog
3. SNMP Trap
4. OPSEC Event Logging API (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支持定制格式？
一个完整的事务日志必须包括HTTP请求及其响应。重点是请求的body部分，响应的body部分可选。完 整的事务日志有以下的要求：
1. 有对事务日志格式的描述性文档。
2. 日志的详细程度应该可以定制。 如：允许用户只记录request的body部分而不记录response的body部分，应该只对那些可疑的事务进行详细的记录，而对那些非可疑的事务只进行有限详细的记 录。
3. 可以指定哪些事务需要记录，譬如 说：只记录可疑的事务，或是只记录带参数的动态页面事务。
4. 对于支持Session机制的WAF来说应该记录包 含可疑事务的整个Session中的访问数据。s
对日志的访问有如下要求：
1. 日志可以定期通过FTP 或SCP导出为文件。
2. 日志可以直接通过访问数据库得 到，数据库的结构需要有详细的文档描述。
3. 日志可以通过提供的API访问获得(取pull).
4. 提供API支持开发插件在消 息到来时即时获得 (推push).
5. 日志可以签名为thwart tampering吗?
如果支持 Syslog 需要评价以下几个方面：
1. 支持基于UDP的Syslog
2. 支持面向连接的Syslog【译者注：如TCP】
3. 在面向连接的Syslog中应该支持SSL来保护传输内容
4. 当使用SSL时，客户端和服 务器端的证书应该可以还有其他的作用
这是指设备对于重要日志的保存能力，防止存储空间溢出。
1. 可以设置日志保存的最大期限，对 超出这个期限的日志进行删除
2. 可以设置日志的最大存储空间，当 达到空间限制值时删除最早的日志
3. 支持多中日志留存规则（如违反规 则的日志可以保存的时间长一些）
4. 在删除日志之前可以进行自动的备 份。
1. 可以从日志中删除敏感数据吗？
2. 可以设置哪些是敏感数据吗？
3. 可以自动识别哪些是敏感数据吗? 可以定制吗?
4. 可以使用哪些模糊化的处理方法? (一个简单的办法 是使用替换方法，如替换成*，或者使用一种可以还原的转换方法，允许特定的人员在必要时进行还原)
【译者注：敏感数据的处理是对日志的一个高要求，如用户提交的银行账号、密码等，这些如果记录在日志中会存在很大的 风险，所以可以将其转换为*，或采用可逆的加密机制，在可控的情况下进行还原】
由于分析员可能会经常查看事件日志，需要用报告来跟踪综合的安全等级
1. 可以生成可理解的事件报告吗？支 持哪些过滤条件？
a. 日期和时间?
b. IP地址范围?
c. 事件类型?
d. 其他(请一一指出).
2. 报告可以随时生成。
3. 报告可以定期生成 (如：每日或每周)
以下是常用的格式：
1. Word
2. RTF
3. HTML
4. PDF
5. XML
定制的目的是使报告看上去和公司的其他文档格式一致
1. 显示相关定制 (如色彩、logo等).
2. 内容定制 (目标群体如主管、 开发人员等)
3. 是否在报告中包含了适合的图表?
4. 支持哪些目标群体?
支持以下哪几种方式：
1. 自动通过邮件分发 (push).
2. 自动通过 FTP分发 (push).
3. 通过第三方的报告集中管理平台分 发 (pull).
对于网络设备来说管理是一个重要的部分，尤其对于安全设备来说，因为业务 需要的不停变化需要对设备不停的进行设置。从这个角度来说，WAF的管理模块必须满足策略更新的需求，同时管理模块的设计和实现上需要格外小心， 保证不会影响吞吐量和可用性。下面是关系 到WAF管理模块的几个方面，我们对其进行了分类，以便区分不同的管理需求，这可以从一个较高的抽象层次来对WAF进行评价，而不必 深入到具体的相关技术。
大多数的WAF设备都可以自动的学习应用的逻辑结构 并建立与之对应的安全策略，然而，如果这些策略带来了大量的误报，应该有一种机制可以很方便的弃用其中的某些策略，而不是从零开始再手工建立策略。
对于某些策略将合法的请求误判是攻击的情况应该可以方便的将这些合法的请 求移出过滤规则。
标题已经很清楚了。对于新部署的应用需要对之采用学习模式，而那些已经建 立了稳定的策略的老应用. 则不能再使用学习模式了。
更多的关于策略粒度的要求请参见 2.2.4。
主动安全模式中应该没有自定义攻击特征的概念了，然而，一些商用的产品中 往往将这两种功能结合在一起来增强准确性，管理模块应该支持自定义特征来对付那些针对某些应用的特别的攻击行为。
由于应用环境的不同，对DoS也不好作出一个标准的定义，因此， WAF产品需要能允 许管理员自己定义如何去辨别DoS攻击，有些具有一定智能的WAF可以为正常的应用访问建立一个统计模 型，通过监控流量是否偏离了这个正常模型来判断是否发生了DoS攻击。
策略需要能在较细的粒度上提供支持，不能支持在整个应用的层面上不停的从 检测和阻断模式之间进行切换，必须要在组件的层次上支持对每一个攻击在检测和阻断之间进行组合，这使得管理员可以方便的再阻断那些真实攻击的同时也可以对 流量进行检测【译者注：这段话翻得比较晦涩，意译过来应该就是尽量的让功能模块化，并使得各模块之 间可以同时工作和进行信息交换】。
如果新设置的策略没有正确的保护网站或者影响了网站的服务，应该有一种机 制能方便的返回到先前的策略状态。
该WAF的策略是否可以共享到其他的系统？如果可以的话，如何进行策略同步？策略可以导出为一个文 件并导入到其他系统中吗？如何控制策略的版本？
学习模式的基础是对客户端和应用服务器之间的流量进行监视，但是在一个时 间段中可能没有任何的攻击行为发生，因此不能将这个作为学习无害流量的基础，应该可以指定一些可信任的主机让WAF将这些主机的流量作为无害流量来学 习。
应该有一种内建的机制使得WAF可以在没有用户访问网站的情况下也可 以对应用的特征进行学习。就像网络爬虫或是扫描器那样对网站的每一个链接页面和所有服务进行分析，这种爬虫需要和策略编辑器有机的结合起来，同时，应可以 定时进行扫描以发现Web应用的更改并及时对策略进行修正。
有时GUI提供的策略向导并不能生成足够准确的策略，因此必须可以对策略中的细节进行调整，譬如说修 改那些正则表达式中的某些值等【译者注：策略往往就是界面中的一条规则，通过GUI我们可能只能对 其中有限的部分进行修改，这样有可能无法达到我们的目的，这一段话的意思是允许我们对策略中的细节进行修改】
1. 是否可以很方便的审计安全策略并 对之生成报告？如何审计？
2. 策略的变化师傅进行了审计？审计 都包括那些细节 (如： 更改的内容, 日期, 时间, 管理员等)?
需要对登录的用户划分不同的权限，可以包括但不限于：设备管理员（设备配 置）、应用所有者（策略配置）、审计员（日志查看）等。
信任主机 (通过IP或IP范围指定)有时需要被允许进行 违反策略的操作。如在渗透性测试中，需要关闭保护机制或者仅仅产生报警。
1. WAF是否可以针对信任主机不采用阻断机制而仅仅是将错误写入日志？
2. WAF是否可以忽略来自信任主机的任何访问请求 (连日志也不记)?
如果攻击特征库是作为一种检查手段的话，需要在每一个探测器上都可以自动 下载和升级它。
我们建议在安全的网络上对WAF进行远程管理。这使得管理员的维护工 作变得更安全，同时管理的网络流量需要能方便的通过防火墙并且要进行加密，以防被截获。
管理模块应该可以对系统状态进行监测，以便在发生错误或性能下降时通知管 理员，通常使用的通知方式是电子邮件、SNMP、Syslog或短信。
所谓日志抑制其实是一种简单的机制，它通过一种巧妙的办法将相似的日志聚 合为一条，并说明其次数，从而看起来更为简洁。如何去聚合则可由用户定义。
统计报表可以在WAF在没有达到预期效果时为管理员提供帮 助，同时，也有助于了解受保护的服务器的活动和性能，下面列出了相关工具可以提供的一些基本统计因素：
· 每秒的请求数/连接数/会话数
· 恶意请求的百分比
· 阻断的请求百分比
· 错误数
· 识别出的浏览器类型 (通过对 User-Agent header的判断得到)
· 访问最频繁的URL
这些数据应该存储在容易获取到的日志中，甚至可以直接显示在设备上。
当WAF的界面存在BUG是很麻烦的，因此在设计界面时应该注意避免出现意外错误和管理失效的情况发生。应该设计一 种机制在设置新策略失败时，WAF可以恢复到原来的状态。
另一方面，WAF得管理界面不能存在像其准备去保护的 应用中的那些相同的弱点，如SQL注入漏洞、参数恶意修改漏洞（Parameter Tampering） 等。
【译者注：Parameter Tampering：修改那些hidden的参数值或是url中 参数值，详细的请见】
管理接口采用以下哪种实现方式？
1. 本地程序（Native application）?【译者注：Native application大概是指以前那种CS模式】
2. B/S结构？
是否为管理使用一个独立的网络接口从而提供一个独立管理通道？
是否为管理接口进行特殊设计，请描述一下：
1. 使用独立的网络接口提供SSH/HTTPS 访 问
2. 串口控制台
是否支持双因素认 证？都是哪些因素？
WAF是 否提供了后台控制的API使得后台受保护的程序可以利用其操纵WAF进行某些操作(如：终止用户会话， 阻断某个IP或限制登录尝试等)?
WAF如 何保证自身安全？使用了什么操作系统?该操作系统如何维护，是否定期的打补丁？补丁升级是否是自动的？
不得不承认性能问题很复杂，尤其是在网络层这一层去衡量WAF的性能更是一个 难题，这也超出了本文的讨论范围(有关内容可以去看看NSS 的相关文章： )。下面的两个部分是对WAF作为普通网络设备的性能评价指标，并未涉及其保护机制的性能评价，我们将在以后扩展这一部 分。
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）.
上面的性能指标均是假定在零丢包的情况下测得的最大值。
这是在后台应用没有使用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）.
上面的性能指标是假定在零丢包的情况下测得的最大值。
系统的管理能力是否在较大的流量下会受影响？是否在较大的攻击流量下会受 影响？
这一部分仅涉及一些基本的XML相关问题。我们将在以后的版本中展开 对XML的更深入的讨论.
1. WAF是否可以保护基于XML的 Web Services?
2. 是否支持指定WS-I Basic conformance ()?
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义不容辞的责任】
