关于安全体系中WAF的探讨

摘要

最近分享了我在WAF建设方面的一些经验,原文点我其中评论有一些让我有点意外,在这里引用一下:

只是为了检测和报警的话,就镜像流量旁路,自己随便玩,不要串联。

如果串联了,误报和误拦截就是致命的问题,业务方会砍死你 + 频繁的调整waf策略会拖垮你。

除非是典型的挖坑不埋的人, 这类人见得太多了,前人挖坑加薪跑路,后人填坑填到死还经常被坑扣钱,最后只能废弃换坑,折腾了半天啥有价值的东西都没有。

首先我要说WAF存在的意义到底是什么?

WAF全名为Web Application Firewall,中文是web应用防火墙,主要用于拦截web层面发生的攻击,原理是通过匹配关键正则判断请求是否具有威胁。使用WAF可以增加业务在web层的安全性。

众所周知,阻断的意思是当一个恶意请求发送过来时,通过一系列判断此请求有威胁,发出告警并拒绝向后端转发的行为称之为阻断行为。评论中的只为了检测和报警称之为仅检测行为,意为当一个恶意请求发送过来时,通过一系列判断此请求有威胁,发出告警但不拒绝向后端转发的行为。

WAF存在的意义是自动拦截恶意请求,如果仅检测,那我为什么要使用WAF?用日志审计不好吗?甚至直接用syslog不好吗?更加节省人力成本、研发成本与时间成本。为什么要使用WAF?不就是因为WAF可以阻断恶意请求吗?

第二点,串联的误报误拦问题,这点是所有的WAF普遍存在的,WAF其实好坏的差别主要就在于策略,一个好的WAF,策略会相对更贴合与实际业务,产生的误拦问题会比较少。但是,哪个厂商敢说我的WAF不用调试,上了就能用,直接开阻断。如果有这样的厂商麻烦大家推荐给我,反正我的3年工作经验中不论甲方乙方都没有见到过如此厉(niu)害(B)的厂商。

整个WAF体系构建中,我说过使用ELK作为日志分析工具,那么ELK能不能做到规则触发汇总,我想这点官网上都有说明,并且不难实现。至于关联配置文件自动化过滤策略,就需要自行写脚本了。厂商的设备也是自动化调整策略而已,甚至有些也需要自己手动调整。我不明白这条评论背后的人是看不起WAF还是真的打酱油不想做任何调试。

什么是试运行?WAF上生产的前1周甚至1个月,运行的是仅检测模式,主要就是为了过滤一些误报,调整策略,把误报的策略关掉,尽量使生产不出现问题。而其中监控的主要作用也是为了一旦发生误报误拦,能够第一时间恢复业务,在我的监控体系中,基本能做到半分钟恢复业务。其中告警响应大概用时5S,因为需要读告警内容,判断是哪里出的问题,25S时间用来解决问题,当然大型复杂事故大概需要10分钟左右恢复。这也是监控存在的意义。我也不太懂,如果一个业务死了好几个小时,你还没有发现解决,业务方有什么理由不砍死你?

送你一把大宝剑:

第三,任何产品研发上线都需要交接文档与手册,这点我在之前等保文章中其实有涉及到,这甚至是需要写进管理制度中的,就是为了防止交接的人对于现有的系统不能快速上手,甚至我在部署使用时就撰写了一系列文档,包括可行性分析报告、部署报告、操作手册、常见问题记录、策略调整记录。其中可行性报告是对业务整体的分析、部署WAF需求分析、选用开源防火墙的依据、现阶段存在的问题等等。部署报告顾名思义就是部署的整体环境与拓扑图。操作手册记录了关键步骤的操作,比如策略怎么调整,日志分析怎么做,怎么切换运行模式,甚至运行模式我都有做解释什么时候用什么模式。常见问题记录是在部署和升级过程中的一些坑。策略调整记录顾名思义。我不认为我给之后的人挖了个坑,甚至我是跟他们趟了不少的坑。讲这段其实不是为了抱怨什么,而是想告诉大家说,平时记录的重要性。

第四,我严重怀疑这兄弟是在安全部中打酱油的角色。这点其实没有什么多说的,我只想说如果要提高企业的安全性,首先就不能否定了自己,如果因为怕麻烦或者怕影响业务,那干脆什么都不做就好了!

以上基本属于个人的唠叨,下面进入正题,如何收紧策略?

WAF在使用中最大的问题也是最怕的问题就是误报与漏报,下面将我 的经验分享给大家。

为什么会误报?

针对这个问题,不得不说一下WAF的研发原理,WAF其实就是正则匹配,一般恶意请求会有正则特征,第一批安全专家就根据攻击者的特征做了一个正则特征库,原意为匹配特征的行为基本可以确定为攻击。而现实并不是那么美好,因为我们在运行业务中偶尔进行的一些行为也会被当作恶意攻击。

这里举个例子:

图片上传,我上传一个带木马的图片,与一个正常的图片

图一木马图片:

图二正常图片:

正常图片按理说会通过WAF的正则检测,但是包在转递的时候会将图片转码,会触发WAF的LFI规则

图三正常图片:

这时候也同样会造成误报。

针对这个问题,我特意请教了modsec的研发者,他的解决方案是不抓图片的包,但是实际上不容易实现,而且一旦发生攻击,会造成很大影响。于是我自行做了解决方案:

规则不变,将图片上传的URL做仅检测处理,监控中重点监控。ELK关联到zabbix,通过zabbix进行微信告警。一旦有图片触发告警策略,第一时间查看是否合规。图片上传被触发的几率大概是1%,所以不用担心频繁告警。

很多规则其实都是需要适应业务的,比如我们的业务是java语言写的,那么php的语言规则很多都是没有必要的,要适当删减掉。

于此同时在ELK中做日志分析,取transaction.messages:*的值,因为modsec日志输出时如果使用的是json格式,告警name就是transaction.messages,取他所有的值用作分析,如果做触发数量统计便可以取值中的message字段。

在match字段中是匹配到的正则表达式,在这里可以判断触发是否合理,file字段是正则表达式所在的文件,可以对规则进行修改,ruleId是规则标号,可以直接过滤掉此条规则,之后将不在对此ID的规则进行检测。

正常业务大概需要试运行1个月,谨记,监控一定要做到位,确保出问题能够马上响应后再切换模式。

我是一个爱折腾的懒人,不甘心打酱油过日子,谋定后动,稳中求胜,但不意味着随波逐流,什么都不做。也希望大家能找到自己存在的意义,找到自己最喜欢的工作方式。

目前评论:0 条

发表评论