Note：F5售后服务“一点通”专栏，是由F5售后工程师主笔，收集和总结客户在实际工作中遇到的常见多发性问题，汇编成小技巧和知识点，通过F5官方微信号定期进行分享，希望有相同问题的客户从中得到解决问题的指导。“一点通”栏目的口号是“一点就通，痛并快乐的学习并解决问题！”。

作者：李恺 F5客户现场工程师

2017年加入F5售后技术团队，具有9年以上网络维护/售后技术支持经验。

F5 Certificated Technology Specialist – LTM/GTM/ASM

原文链接：https://mp.weixin.qq.com/s/zRzg22Xh_ZYN_4F6nhrLxw

安全是Web应用永远无法绕开的重点话题。F5 Advanced WAF为客户的Web应用保驾护航。针对不同的Web安全威胁，F5 Advanced WAF提供了精细的安全策略设置。也正是因为安全策略配置繁多，加之Web应用本身也不断更新变化，误报事件时有发生。出于安全考虑，客户往往希望先在非生产环境中复现误报问题并验证可能的解决方案。本文记录一次由于错误配置导致的Attack Signature误报拦截正常流量的真实案例，希望可以帮助小伙伴们了解针对Advanced WAF系统误报事件的基本排障过程。

有过LTM排障经验的小伙伴们在遇到问题时往往都会在第一时间收集qkview并上传iHealth以便初始排障。Advanced WAF系统中所有Security Policy的配置其实都是存储在系统的MySQL数据库中的。iHealth目前也并不具备分析MySQL数据库的能力，所以即使将qkview上传至iHealth后我们能够复查问题出现时间点的日志，但也无法核实Security Policy的配置。另外，所有Learning Suggestion和本地Event Log也都是存储在MySQL数据库中的。在排障时可以通过以下命令收集asmqkview：

# asmqkview --add-request-log --include-traffic-data –s0

通过上述命令生成的asmqkview会包含普通qkview的所有内容，外加所有Security Policy的配置，所有Learning Suggestion，以及所有本地Event log，因此相比普通qkview，生成asmqkview所需的时间往往更长。

F5 Support的小伙伴们可能会使用上传的asmqkview在lab环境中尝试复现问题。但有时在lab设备中加载客户asmqkview时并不能加载所有MySQL数据库表项，所以可能会建议通过以下命令在客户设备上导出所有MySQL数据库表项：

# mysqldump -uroot -p$(perl -MPassCrypt -nle 'print PassCrypt::decrypt_password($_)' /var/db/mysqlpw) --all-databases > /shared/tmp/alldb.sql

问题描述：

当访问某特定Web应用时发现：当使用iOS客户端应用访问时，Advanced WAF系统会拦截iOS客户端请求；当使用Android客户端应用访问时，一切正常。

在GUI中（Security ››  Event Logs : Application : Requests），查看到被拦截的Event Log记录。依据该记录发现，iOS客户端请求被拦截是因为Advanced WAF系统检测到客户端请求命中了Attack Signature 200022004。

“正常流量被拦截”，面对这种典型的误报事件时，回溯Event Log是第一步。我们可以通过Support ID，source IP，URL，Request Status等多种过滤条件来定位与误报事件有关的Event Log记录。每一条Event Log都会详细记录与该事件有关的VS名，Security Policy名等基本信息。我们可以在Security Policy列表中导出该策略以备测试系统复现。如果是拦截记录，系统也会记录拦截该请求的原因。例如本例中，Event Log提示系统拦截原因为HTTP request命中Attack Signature 200022004。此外，每一条Event Log还会记录触发该事件的HTTP request请求报文的详细内容。SSH登录系统后，通过vi创建一个文本文件并复制该请求的所有内容，由此我们可以轻松构建用于复现误报问题的报文。例如本例中的iOS.txt。在生产环境中，很多Log Profile都设置为“Log illegal requests”。本例也是如此，所以为了得到Android客户端请求报文，我们可以临时将Log Profile设置为“Log all requests”。通过Android客户端复现正常访问后，可以用相同方法回溯Event Log得到Android.txt。

为与实际生产VS相区别，我们创建一个新的VS ，基本配置保持相同，无需配置pool，只需调用以下iRule：

为新建VS配置相同的Security Policy后，我们就可以尝试复现。如果有非生产设备用于测试，我们只需将测试系统升级到相同版本后导入该Security Policy，并重复上述步骤。这里为使iRule正常工作，我们需要在Policy Properties中开启ASM iRule。

可以看到系统拦截了iOS客户端的请求但并未拦截Android客户端的请求。

通过对比两种客户端的请求报文不难发现他们的HTTP payload均是json格式，且每个对象的内容都相同，只是对象书写顺序不同。所以不难猜测：HTTP payload中的任何单一对象均不会触发Attack Signature 200022004，可能是iOS客户端请求报文中不同json对象的特定组合顺序错误地触发了该Attack Signature，使得Advanced WAF系统误以为该请求存在攻击风险，所以错误地拦截了iOS客户端的请求。

如果禁用Attack Signature 200022004，不管是在全局还是URL level禁用，都会停止误报。但如果真遭遇此类攻击，系统也无法检测到该攻击。如果Attack Signature 200022004只对单个对象做检查，而不是对不同对象的组合做检查也应当能避免系统误报。在GUI中，Security ››  Application Security : Attack Signatures，查看Attack Signature 200022004的使用范围是Parameter, Cookie, XML, JSON, GWT, Plain Text。所以理论上，该Attack Signature本应就只为每一个HTTP parameter做检查。也就是说，系统错误的将不同json对象的组合看成了一个单一的HTTP parameter。

原因：配置Security Policy时误删了json content profile。这样一来，Advanced WAF系统会将整个json payload视为一个parameter。正确配置json content profile后，系统会将每个json对象视为一个单独的parameter。

找到了可行的方案后我们同样可以使用之前的方法来验证。依据客户端请求报文的内容，我们在测试系统中新建一个Allowed URL条目（注意区分HTTP/HTTPS）并应用系统默认的json content profile。

可以看到利用Event Log对误报问题分析很有帮助。无需等待客户端或服务器侧的配合，我们可以尝试这种方法快速复现问题并验证可能的解决方案，很多时候你需要的环境只是一个VS。