Skip to content

Latest commit

 

History

History
44 lines (41 loc) · 8.85 KB

产品经理眼中未来两年的完美WAF.md

File metadata and controls

44 lines (41 loc) · 8.85 KB

原文 by 兜哥

WAF简介

WAF(Web Application Firewall,简称:WAF),百度百科上的定义,Web应用防火墙是通过执行一系列针对HTTP/HTTPS的安全策略来专门为Web应用提供保护的一款产品。作为绝大多数互联网公司Web防御体系最重要的一环,承担了抵御常见的SQL注入、XSS、远程命令执行、目录遍历等攻击的作用,就像大厦的保安一样默默工作,作为第一道防线守护业务的安全。

传统WAF的不足

WAF在不少安全公司都是重要产品线,究其原因我认为有三个:第一,绝大多数互联网公司没有足够的专职安全人员负责安全,解决安全问题是第一刚需,WAF作为入门级产品帮助企业抵御了常见的攻击行为,需求量大。第二,产品成熟,市场教育成本低,不像不少酷炫的新产品需要开发布会才能让同行知道你干啥,和用户要拿ppt死磕办小时才能让用户知道你卖啥,第三,研发WAF的起点不高,最草根的做法基于常见的nginx+lua架构就可以开始开发。也正是由于这三方面原因,市场上WAF种类繁多但同质化严重,缺乏创新。个人总结传统WAF在安全方面存在下面几个问题:

防护能力不足以应对黑产

传统WAF主要依赖规则,一方面是吃一堑长一智,针对已知攻击形式有一定防御,针对未知攻击无防护能力,另外一方面即使是已知攻击行为,由于正则表达式天生的局限性以及shell、php等语言的极其灵活多变的语法,理论上就是可以绕过的,事实上也是比较容易绕过的,主流安全咨询媒体没几篇讲如何绕过WAF的文章都不好说意思和人打招呼。我就列举一个例子:
http://xi.baidu.com/rce.php?cmd=pwd
假设cmd参数存在命令执行漏洞,输入参数pwd会当做shell命令执行,由于shell命令的灵活性 pwd p'w'd p'''''w'''''d ''''p'w'd'''' 都是可以执行的,针对ls、ifconfig等也是一样,如果谁能写出个规则防止这个url的命令执行漏洞的利用,可以告诉我。所以面对怀有经济利益驱动的黑产或则有足够赖心的白帽子,绕过WAF只是时间问题。
另外一个要提的,多数WAF处于性能的考虑,检测策略主要是基于请求或者应答内容,缺乏上下文以及请求应答关联分析的能力,势必看问题就很片面和局限,大家可以试下在有输入框的地方输入alert(/1/)有多少WAF会拦截。

缺乏有效的基础业务安全防护能力

WAF是否需要承担业务安全或者说业务风控的职责,其实厂商和用户直接一直没有达成一致,多数厂商认为整个不是WAF的事,从撞库、刷短信接口到薅羊毛等,确实是专业风控产品的菜;从用户角度讲,我以前被人撞库、刷短信接口到薅羊毛等我分析日志加nginx封IP能搞定一部分的,结果上WAF却搞不定了,还非要忽悠我买贼贵的风控。我认为WAF还是要有基础的业务安全防护能力,无论是自动还是用户可以配置。

审计能力不足

闲时看PV,出事能取证,出现安全事件时可以很方便的查询原始流量,这个对于应急响应的同学很重要。令人遗憾的事,多数WAF即使可以保存访问日志,也只能保存请求头、基础的url,对于攻击定位很重要的post body,应答内容记录的很少,当然我们也理解,存储空间问题、性能问题。不少厂商也认为这个应该是nginx自己、siem或者流量审计类设备的功能,我说下我认为WAF应该做这个的原因:

  • WAF记录黑客很难删除,nginx上记录很容易毁尸灭迹,还没见过有自我修养的黑客不删除日志的
  • https普及后,流量审计想记录也记录不了了,只能表示遗憾

我理想中的WAF

首先声明,我理想中的WAF部分功能有的厂商在做了,完全实现的还没有,如果另外一个WAF产品经理说他们都实现了挑战我,我还是直接认怂算了,反正不知道又不遭雷劈。

上下文理解能力

这个不是功能,而是处理能力,传统WAF对于http协议的理解主要是单向处理请求或者应答,缺乏对应http整个session行为的分析,缺乏结合上下文综合理解请求应答内容的能力,这好比盲人摸象,对于问题分析很片面。比如盲注这类没有明显回显特征的,仅依赖请求包特征,不去分析整个session多个应答包的时间特征就很难准确发现。

语义分析能力

语义分析,部分厂商叫沙箱,名字叫啥不太重要,本质上是WAF具备语义识别常见的SQL、PHP、shell语言的能力,传统WAF的规则多是基于正则,说白了就是用文本的角度去理解http协议,走简单的正则匹配,好比用鸟的大脑去尝试理解人类的语言,结果肯定是误报率和漏报率无法平衡。有了语义理解能力以后,就可以从http载荷中提取的疑似可执行代码端,用语义去理解看是否可以执行。还是以刚才的case来说。
http://xi.baidu.com/rce.php?cmd=pwd 对于参数cmd的内容,如果用shell的语法去理解,pwd p'w'd p'''''w'''''d ''''p'w'd'''' 都是一回事,都是pwd。原理上来说,对于语法公开的语言都可以实现语义分析。
语义理解,理论上可以解决基于正则的规则的搂抱和误报的问题,不过也不是万能的,比如http协议中究竟哪部分是疑似可执行的代码段,这个就是个不好解决的问题。另外http协议中,对于SQL注入攻击存在的都是代码段,或者说是SQL片段,如何拼接保证可以正常解析也是麻烦事,市面上已经出现了一些基于语义的WAF,究竟这些问题解决到什么程度还有待于实战考验。

机器学习能力

机器学习、人工智能、深度学习,这三个词已经被用滥了,各类会议ppt不提下都不好意思和人打招呼。这类文章很多很多很多,我就不多说了,就期待吧。

审计取证能力

能够以http会话作为存储单位,保存至少一个月的存储日志,完整记录请求应答内容,至少包括请求和应答的前4兆内容,支持基于常见http字段的正则查询,支持ELK那种基础的聚合、TOP、大于、小于操作等操作。比较理想情况可以类似去年RSA会议上说的基于流量的时光机器,按照一定条件可以回放整个访问过程。

情报能力

威胁情报这两年一直比较火,逐渐也从概念层面过渡到实战,从IP地址库、http代理库、vpn库进步到真正是肉鸡库等,这一进步也给WAF带来了新的武器,对于大面积机器攻击行为,比如CC/DDoS肉鸡等可以做到直接封禁。

业务安全防护能力

业务安全的方范围非常广,我认为至少包括方面希望WAF是可以解决的:

  • 网站内容保护——反恶意抓取、垃圾信息注入、黄赌毒信息注入等、主页篡改(这个对党政军用户非常非常非常重要)等
  • 高级业务逻辑CC攻击——对API接口的海量调用、例如短信接口、验证码接口、登录接口、数据查询接口等,撞库也可以算这类
  • 轻量级防薅羊毛–暴力注册、刷红包、刷代金券、各种刷

市场上也出现了号称可以业务安全WAF,这是一大进步,本质上提供能够根据用户自定义的URI、参数名、源IP/目的IP、目的URL等条件,拦截超出正常频率的机器访问行为的能力,就可以一定程度解决不少业务安全的问题了。当然指望用户去提炼这些规则还是很困难的,建议可以内置一些检测规则,用户可以在历史数据中检测规则有效性,调整阈值后再上线。我一直有个观点,黑产、羊毛党(按照法律貌似不算违法,暂且叫灰产吧)也是讲究攻击成本的,只要攻击你的成本高于其他P2P、电商等网站,他们多会转向攻击攻击成本低的,人家也是讲究性价比的,能够提供基础业务防护能力就是进步。

协同能力

这个我很看中,因为WAF不是万金油,也不可能包打天下,再牛逼也可能被绕过,但是WAF的卡位很好,位于网路边界,特别适合做隔离操作,比如hids发现webshell,协同WAF阻断访问;数据库审计发现拖库或者敏感操作协同WAF阻断(这个还依赖WAF和数据库联动分析,将http会话和SQL操作关联)等。

总结

安全厂商可能都清楚很多时候排名或者说甲方采购不完全是取决于安全能力,合规、渠道、价格每个环节都可以左右最后结论,不过从一个产品经理角度,还是很想做出一款有在安全能力上有差异化,在市场上能被广泛接受的WAF,这个是一个WAF产品经理的自我修养。