您好,欢迎访问专业IT管理知识分享平台

上传文档

当前位置:首页 > 文章列表 > 中小企业安全体系构建之WAF实战

「ITIL文章」中小企业安全体系构建之WAF实战

嘉宾介绍

赵舜东

江湖人称赵班长,曾负责武警某部指挥自动化架构和运维工作,2008年退役后一直从事互联网运维工作。UnixHot运维社区创始人、《SaltStack入门与实践》作者,老男孩教育兼职讲师。

引言

首先声明本人非安全从业人员,请专业人士不要吐(gao)槽(wo)。但是我相信作为中小企业的运维人员和我一样,面临的困境就是:公司没有专业的安全工程师!不出问题,企业往往意识不到安全的重要性……

这个话题不深入讨论。

那么怎么办?作为一名运维工程师,我们的知识范围连“背黑锅”这么专业的技术都有,安全我们也可以兼职一下的。这就是答案,我们要自己干,有总比没有好!不埋怨!我们不能改变环境,但是可以改变自己,来影响环境

WAF介绍

安全也是一个比较大的课题,不同视角、不同层级都会有不同的体系结构。那么今天的分享,我选择了一个特别贴近运维工程师实际工作的一个话题:如何使用Nginx+Lua来实现一个WAF。

WAF(Web Application Firewall),也就是Web应用防火墙。

一般企业用户都会选择使用防火墙作为企业安全的第一道防线,那么传统的网络防火墙墙只能够进行四层(OSI七层模型中的传输层)的防护,那么像SQL注入、XSS、网页挂马等安全问题却无法识别和解决,因为这些攻击是七层的(OSI七层模型中的应用层),那么Web应用防火墙就顺势而生。因为有一个让我们胆战心惊的事实: “80端口是永远的后门”。(不管你怕不怕,反正我是怕了)

如果你觉得WAF比较陌生,没关系,作为非安全人员,这可以理解。那么我们先来亲近亲近,下面几个代码片段你一定非常的熟悉。我们经常会使用Nginx来做一些常规的安全防护:

上面这三个例子,我相信大家都比较熟悉了,我们使用Nginx可以在应用层进行针对请求头部的UA进行过滤和指定动作(返回403)、针对请求的URL进行过滤匹配和指定动作(返回404)和针对请求的参数进行过滤匹配和指定动作(返回403)。是的,Nginx非常的强大,帮了我们很大忙,你还可以给指定的URL再增加频率限制来防止CC攻击。但是!待我细细道来……。

痛点是什么?

本文是介绍如何使用Nginx+Lua来实现一个Web应用防火墙,那么就像上面我们的例子,标准的Nginx可以实现很多的功能呢?为什么要自己造轮子?

我是一个比较保守的运维者,虽然偶尔也会为了个人的技术提高而使用某些技术,但是决不会为了这些而不干正事!所以说如果要造轮子一定是为了解决运维痛点,“凡是不以解决问题为出发点的造轮子就是耍流氓”,那么痛点是什么:

Nginx不支持白名单:试想如果你要想这么设置,某一个IP不做防护(可能是你准备的一个漏洞扫描器,你当然不想被Nginx拦截);某一个URL不做防护(由于业务原因,有一些URL不能做CC防护)。

Nginx安全防护配置繁琐复杂:如果写一堆if else非常的繁琐,而且不能很直观的记录防护日志,比如我想单独把防护日志写成JSON的,把日志存入ELKStack中。

Nginx语法简单:想自定义一些逻辑进去,Nginx支持的简单高效的语法有点苍白无力。

注: 上面这些痛点如果你脑洞大开其实有很多魔法可以让Nginx来实现我说的这些哦,有兴趣自己试试,但是实现起来还是比较费劲。

注: Nginx其实提供了非常丰富的全局变量,我们可以拿来进行相应的匹配和过滤,详细可见源码包中的./src/http/ngx_http_variables.c的源码文件中。

我要造轮子!

好的,经过几个日夜的思考,我醒悟了,既然Nginx实现这么费劲,那么我就看看有没有别的方案:

Modsecurity:是我看到的第一个方案并在线上测试很长一段时间,因为它太强了,强大到我Hold不住,而且当时只支持Apache,后来才支持Nginx,但是经过我的测试,Nginx编译上Modsecurity之后,性能下降太大,放弃。不过Modsecurity可以作为造轮子的一个设计图纸。

ngx_lua_waf: 这个一个基于lua-nginx-module的web应用防火墙,作者是张会源(ID : kindle),微博:@神奇的魔法师,目前是快网云安全产品技术总监。很牛x的一个人,而且儿子长的也很帅!更多的开源项目可以关注:

https://github.com/loveshell/

好的,下面我们的目标就是参照ngx_lua_waf使用Nginx+Lua来自己实现一个WAF,也就是当请求进来的时候经过我们的WAF进行检查,正常的请求,畅通无阻,非法请求关进小黑屋。至于Nginx+Lua相关的知识,大家可以自行搜索,本文使用Openresty来进行讲解。

先画一个图纸

作为一个非安全专业的运维人员,想搞一个WAF出来还是有点困难,不过胖子也是一口一口吃出来的,我们先画一个设计图纸,先具备基本功能,然后再慢慢完善。

那么WAF一句话描述,就是解析HTTP请求,然后做规则检测,做不同的防御动作,并将防御过程记录下来。我将这句话中四个重要的词进行了加粗,通过这一句话,我们就可以知道编写一个WAF需要的四个基本模块:

  • 解析HTTP请求:协议解析模块,openresty给我们提供了丰富的API。

  • 规则检测:规则检测模块,当然还需要有规则库。

  • 防御动作:动作模块,比如是直接拒绝还是返回某一个状态码,还是重定向到某个页面。

  • 过程记录:日志记录模块,过防御日志记录下来,编译后期统计和分析。

同时我们还需要一个配置文件,可以称之为WAF的第五个模块,配置模块。

当然这个是一个非常简化的图纸了,如果你想真正开始开发一个产品,那么还是差很远,不过有一个还不错的设计图可以推荐一下:

http://www.freebuf.com/tools/54221.html

安装Nginx+lua(openresty)

安装依赖包

下载并编译安装openresty

测试openresty安装

Hello World

功能介绍

开始造轮子之前需要先设想一下,我们需要实现哪些功能。

  • 配置文件:

    • 支持开启和关闭WAF,开启某项功能等。

    • CC防护频率设置

    • 规则库、日志记录的相关配置。

    • 异常请求处理配置,是返回403还是调整到某个页面

  • IP白名单和黑名单

  • URL白名单

  • User Agent限制

  • URL限制

    • 比如限制非安全访问、非安全下载等

  • URL参数限制

    • 防止SQL注入、XSS

  • Cookie限制

    • 防止SQL注入

  • POST限制

    • 防止SQL注入、XSS

  • CC防护

  • 防护输出

    • 支持直接返回403

    • 支持直接输出一个页面

    • 支持直接调整到某个页面

好的,现在如果你有开发经验,那么需要30-60分钟的时间,看一看Lua语言快速入门之后,我们就可以开始了。

配置模块

那么我们先从配置模块开始,要编写一个WAF,那么肯定要有配置文件,配置文件用来控制和管理WAF的某些行为和相关的访问路径。

第一个要做的是一个配置开关,让用户可以自定义是否全部打开、全部关闭WAF防护,是否开启或者关闭某些WAF功能。这个很有必要,尤其是我们刚上线的时候,我们需要的场景是WAF不进行防御处理,只记录日志,用来观察WAF都干了什么,是否有误杀。

https://github.com/unixhot/waf/blob/master/waf/config.lua

配置文件,直接使用lua语法,没有设计单独的配置文件,这样的好处可以直接被lua其它代码require(include)进去。

基础库

由于我们后面需要获取用户的UA、用户的真实IP、规则库中的规则和通用的日志记录模块,所以我们把这些全部放在一个lib.lua文件里面,称之为基础库。

https://github.com/unixhot/waf/blob/master/waf/lib.lua

真正干活的时候到了。代码很简单,易读性也好,大家可以根据需求自己增加。

https://github.com/unixhot/waf/blob/master/waf/init.lua

—CC返回,把IP和URL进行配对,一个IP访问相同的URL不能超过配置的次数。功能更强大的CC防护可以参考HttpGuard,同样是Nginx+lua。很容易集成过来。(由于代码过多,详细见链接地址)

https://github.com/centos-bz/HttpGuard

main函数

main函数看似简单,但是顺序很重要哦。(由于代码过多,详细见链接地址)

https://github.com/unixhot/waf/blob/master/waf/access.lua

生产上线

现在,我们的WAF开发完毕了,要开始生产上线了,需要提前准备好环境,如果你之前使用的是openresty那么不需要重新编译,如果是Nginx需要重新编译增加lua模块,具体的步骤可以参考github上的文档。

由于篇幅有限,这里把几个技巧总结一下。

  • 技巧一:不要一次性部署上线,先部署后,只记录日志,然后观察和调整规则,保证正常的请求不会被误防。

  • 技巧二:使用SaltStack管理规则库的更新。

  • 技巧三:使用ELKStack进行日志收集和分析,非常方便的可以在Kibana上做出一个漂亮的攻击统计的饼图。

有激情的下一步

好的,我们现在拥有了一个“相对完善”的WAF,而且并部署上线,可以帮我们有效的防御一些攻击,那么下一步我们需要怎么办呢?这里我列举了一些路径,有必选和可选,任君喜好!

漏洞平台:(必选)http://wooyun.org/ WooYun是一个位于厂商和安全研究者之间的安全问题反馈平台,作为厂商非常有必要注册一个厂商用户,这样如果有白帽子贡献漏洞,你就可以非常及时的发现,不过别忘了赠送礼品哦。

持续更新防护规则:(必选)规则更新也是安全技术的学习过程,不断的学习,不断将有效的规则增加到规则列表中,让规则库变得更加强大起来,不过前提最好是你Hold住,不要让一些莫名其妙的规则影响了正常的业务运行。

持续增加功能:(可选)既然选择了,就要坚定的走下去,或许你并不想自己造一个轮子,那么直接使用第三方的也是不错的选择。

并不明朗的展望

我们设计和部署了WAF,或者说使用了第三方的WAF服务,是不是就万事大吉,高枕无忧了呢?事实是WAF并不是万能的,或者说世界上任何一款安全产品都无法提供100%的安全防护。让我想起曾经读过的一句话:

凡是人设计的程序都存在人为因素,而任何一个人为因素都可以导致系统被入侵。

那么除了WAF自身的安全问题外,有一个悲伤的话题是WAF存在被绕过的风险。具体的资料大家可以通过网络搜索来获得,但不可否认的是WAF可以帮我们防御大部分的常规攻击,对于一些攻击者中的佼佼者,WAF并不能阻挡他们入侵的脚步,他们可以绕过WAF来实施攻击,而且还有更神秘的“社会工程学”!

总结:安全是相对的,没有100%的安全防护,但是做总比不做好,而且好很多很多。

暂时没有评论,评论一个吧?

您需要登录后才能评论 , 去登录

发表文章

Powered by DS文库

Copyright © 专业IT管理知识分享平台 All Rights Reserved. 鄂ICP备19005274号-1
×
保存成功