浅聊 WAF 的矛盾点
WAF是专门为保护基于web应用程序而设计的，不像传统的防火墙，是基于联网地址和端口号来监控和阻止数据包。一个标准端口号对应一种网络程序类型。它的出现是由于传统防火墙无法应对应用层的攻击进行有效抵抗。并且IPS也无法从根本上防护应用层的攻击，因此出现了web应用防火墙系统。
WAF是一种基础的安全保护模块，通过特征提取和分块检索进行特征匹配，主要针对HTTP访问的web程序保护。WAF部署在web应用程序前面，在用户请求到达web服务器前对用户请求进行扫描和过滤，分析并校验每个用户请求的网络包，确保每个用户请求有效且安全，对无效或有攻击行为的请求进行阻断或隔离。通过检查HTTP流量，可以防止源自WEB应用程序的安全漏洞（如SQL注入，跨站脚本攻击，文件包含和安全配置错误）的攻击。
在行业、规章制度对网站的 WAF 防护效果的要求下，WAF必须达到多少指标才算合格。随着要求越严格，这个指标也就越高。保证了一些必要的审查能顺利通过。这就是第一个点“防护好”。
但是呢，到了使用者角度，客户在这样的“高安全”的 WAF 下，又会觉得自己有很多正常的请求被拦截了。这就是第二个点“误报高”。
这个就是平常作为行业人员我们见过的矛盾点“防护好”与误报高”，其实这些都是来源于客户说的，只是客户站在了不同的视角。防护好”是客户被动的为了等保和各种行业要求，“误报高”是客户主动的感官体验。
如何平衡这第一个矛盾点呢？目前的普遍方案都是加白名单，针对 URL、源IP、header字段、规则等等。我们的想法是让客户自己来根据自己的需求去加对应的白名单。这个办法在平时也是用得很好的。
但是总有一个“要求高“的客户，他们会提出说：”这些加白了以后是不是在这个加白的规则下也有有攻击？“。 答案是肯定的，但是这个时候客户会认为这样有安全风险。
怎么解决呢？第二招就是waf 规则 的AI 分析，利用客户的业务流量让 AI进行前期的分析，再配合人工的手动判定，让WAF更适配客户的 站点情况。并且白名单这边也加入组合检测，将原有的单个场景组合使用，比如 URL 为/a/b,且 header 里面包含有“aa”的请求进行放白。这样也更大程度减小了原有白名单的风险。
在这样的“检测全”的情况下，新的问题出现了。客户又觉得这样前期接入调试的周期较长，并且丰富了规则后网站的整体响应时长也增加了。影响网站的使用体验。这就是第二个矛盾点“检测全”和“性能低”，增加各种规则和 AI 都是对性能的消耗，增加了检测过程，那么响应时间自然比原有的降低了。
目前能想到的解决方案就是看客户关系了，怎么说服客户去理解这些。