作者：刘焱
出版社：机械工业出版社
格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT
企业安全建设入门：基于开源软件打造企业网络安全试读：
前言
十年前，因机缘巧合，我进入了安全这个行业，而且在一个公司干到现在。当时公司虽然已经很有名气，但是体量和现在比起来还是很小，安全防护体系还非常脆弱。我的第一个项目就是开发公司的准入系统，当时公司其实已经从国外购买了商业准入系统，而且号称是当时Gartner全球排名前几名的产品，但是在公司具体环境下这个系统却没有办法很好地运行，无论是易用性、可管理性甚至是基础的安全性，都出过问题。老外的售后支持也就那样，对出现的几次事故也没给出让人信服的解释。最后我们老大，也就是传说中“我的华为十年”那篇文章的作者家俊，决定自己开发准入系统。我们两个小伙伴初生牛犊不怕虎，硬是用三个月开发出了第一版，后面我们按照部门、楼层、总部大厦、分公司的顺序在全集团范围推广，这个系统已经服役到现在。也就是从这个项目起，我对开源软件产生了浓厚的兴趣，并尝试在后面的企业安全建设中使用，从SNORT、OSSIM、Kippo到OSSEC、OpenSOC、Kong等，我都调研或者使用过。坦诚讲，开源软件存在可管理性差、运营压力大等问题，尤其在专业性要求特别强的领域，比如APT、防火墙和硬件令牌领域，使用商业安全产品比自己研发工具性价比更高。但是开源软件容易上手、可高度定制、可扩展性强，事实上整个互联网就是基于开源软件发展起来的，使用开源软件在互联网公司做安全也是一个不错的选择。我最近三年主要负责公司对外的商业安全产品，我发现很多模块可以直接使用开源软件，比如Storm、Kafka、ELK、Celery、Hadoop、TensorFlow等，这些开源软件都可以让我们不重复造轮子，把精力放在更核心的安全检测能力和业务逻辑上。
本书的第1章概述开源软件和网络安全的关系。第2章开始介绍互联网公司的防护体系建设，涉及WAF、抗DDoS攻击和服务器主机安全。第3章介绍业务网的基础安全加固，包括资产管理、补丁管理、操作系统加固等内容。第4章介绍这几年非常火的威胁情报，并且从开发角度介绍了其中常见的几种威胁情报源的获取方式。第5章介绍业务风控，并详细介绍了如何使用Kong保护API接口。第6章介绍代码审计，并详细介绍了如何使用RIPS做PHP代码审计。第7章介绍蜜罐的相关知识，并详细介绍了几种常见的开源蜜罐的使用方法，包括Glastopf、Kippo、Elasticpot和Beeswarm。第8章介绍态势感知系统，并分别介绍了如何使用开源软件做漏洞扫描、入侵检测。第9章介绍如何使用开源软件建设SOC系统，整个架构都是基于OpenSOC的。第10章介绍数据库安全，并详细介绍了如何使用DBProxy充当数据库防火墙，使用mysql-audit进行主机端数据库审计，使用MySQL Sniffer进行数据库流量审计。第11章介绍办公网如何防止数据泄露。第12章介绍如何进行办公网加固和基于开源软件开发准入系统。
本书的每个章节都会介绍国内外对应的一些商业安全产品，国外厂商列表主要来自业内比较认可的Gartner发布的数据，国内数据主要来自“安全牛”的安全全景图，大家可以根据实际情况选择使用商用产品还是基于开源软件DIY。本书并不是介绍商业产品的黄页，而且安全创业公司近几年如雨后春笋般成长，所以有遗漏之处敬请原谅。
我一直有个想法就是用我写书的钱开一个烧烤店，虽然目前看开个烧烤摊也勉强，但是我会继续努力，所以本书的演示环境都是基于我假想的在线烧烤网站www.douwaf.com，该网站基于Nginx+PHP+MySQL架构，部署了phpMyAdmin和WordPress，整个环境在我购买的云主机上。
在这里我要感谢我的家人对我的支持，本来工作就很忙，没有太多时间处理家务，写书以后更是花费了我大量的休息时间，我的妻子无条件承担起了全部家务，尤其是照料孩子方面的繁杂事务。我很感谢我的女儿，写书这段时间几乎没有时间陪她玩，她也很懂事的自己玩，我也想用这本书作为她的生日礼物。我还要感谢编辑吴怡对我的支持和鼓励，让我可以坚持把这本书写完。最后还要感谢各位业内好友在编写本书时对我的各种形式上的支持，排名不分先后：聂君@安信证券、Killer@腾讯、刘长波@云堤、云舒@默安科技、薛峰@微步在线、大路@天际友盟、林榆坚@安赛、廖威@易宝支付、sbilly@360、帮主@运维帮、赵广@运维派、张婉桥@360。最后我还要感谢我的亲密战友哲超、新宇、子奇、月升、张琳、碳基体、刘超、王胄、吴梅，以及曾经一起的战友徐家俊、黄颖、冯永校、林健、刘秀英、王龙、阮小伟、程伟、彭正茂、刘永树、李亚强、吴登辉、张雨霏、高磊、邵杨民、王致桥、赵铁壮、张浩、刘铁铮、张东辉、李婷婷、程岩、宋柏林、王志刚、吴圣、刘袁君、王珉然，咸鱼。
本书面向运维和安全行业从业者，以及信息安全爱好者、开源技术爱好者。我平时在Freebuf专栏以及“i春秋”分享企业安全建设以及人工智能相关经验与最新话题，同时也运营我的微信公众号“兜哥带你学安全”，欢迎大家关注并在线交流。本书使用的代码和数据均在GitHub上发布，对应地址为：https://github.com/duoergun0729/4book，代码层面任何疑问可以在GitHub上直接反馈。本书的写作时间主要集中在晚上十一点以后，难免会有错漏之处，恳请大家将发现的错别字和表述有误的地方反馈给我，我会在后面的版本中改正。▶▶第1章开源软件与网络安全1.1 开源软件重大事件
1.盘古开天地之GNU计划
1983年9月27日，理查·斯托曼发起GNU计划，GNU成就了开源和自由软件在今日的繁荣昌盛。1985年理查·斯托曼又创立了自由软件基金会来为GNU计划提供技术、法律以及财政支持。随着时间的推移，GNU计划产生了不计其数的开源软件，GNU通用公共许可证（GPL）也随之诞生。这时候的GNU软件中就差一个OS内核尚未完成。1992年Linux与其他GNU软件结合，完全自由的操作系统正式诞生。
2.石破天惊之Linux
1991年的年初，林纳斯·托瓦兹开始在一台386兼容机上学习minix操作系统。
1991年4月，林纳斯·托瓦兹开始酝酿并着手编制自己的操作系统。
1991年7月，第一个与Linux有关的消息是在comp.os.minix上发布的。
1991年的10月，林纳斯·托瓦兹在comp.os.minix新闻组上发布消息，正式向外宣布Linux内核的诞生。
1993年，大约有100余名程序员参与了Linux内核代码编写工作，其中核心组由5人组成，此时Linux 0.99的代码大约有十万行，用户大约有10万左右。也许当时谁也不会想到，Linux会在未来的几十年深[1]刻改变了世界。
3.雨后春笋
在Linux出现后的几十年里，各种开源软件如雨后春笋般出现，它们深刻改变着互联网的面貌。
1993年，红帽成立；
1994年，MySQL启动；
1996年，Apache称霸互联网；
2005年，Hadoop横空出世；
2010年，OpenStack出现；
2015年，TensorFlow开始流行。[1] http://wiki.mbalib.com/wiki/Linux1.2 国内外安全形势
2016年4月，CNCERT监测发现一个名为“Ramnit”的网页恶意代码被挂载在境内近600个党政机关、企事业单位网站上，一旦用户访问网站就有可能受到挂马攻击，对网站访问用户的PC主机构成安全威胁（见图1-1）。Ramnit恶意代码是一个典型的VBScript蠕虫病毒，可通过网页挂马的方式进行传播，当用户浏览含有Ramnit恶意代码的HTML页面时，点击加载ActiveX控件，用户主机就很有可能受到恶意[1]代码的感染。
2016年5月，俄罗斯黑客成功制造了一场大规模的数据泄露事故。在此次网络攻击中，黑客盗取了2.723亿个账号，以俄罗斯最受欢迎的电子邮件服务Mail.ru用户为主，此外还有Gmail地址、雅虎以及微软电邮Hotmail用户。路透社称，数以亿计的数据目前正在“俄罗斯[2]的地下黑市”出售。图1-1 国内部分网站存在Ramnit恶意代码攻击
2016年10月，提供动态DNS服务的Dyn DNS遭到了大规模DDoS攻击，攻击主要影响其位于美国东区的服务。此次攻击导致许多使用DynDNS服务的网站遭遇访问问题，其中包括GitHub、Twitter、Airbnb、Reddit、Freshbooks、Heroku、SoundCloud、Spotify和Shopify。攻击导致这些网站一度瘫痪，Twitter甚至出现了近24小时[3]无访问的局面。
2016年11月，希拉里因“邮件门”最终落败美国总统竞选。希拉里在担任国务卿期间，从未使用域名为“@state.gov”的政府电子邮箱，而是使用域名为“@clintonemail.com”的私人电子邮箱和位于家中的私人服务器收发公务邮件，涉嫌违反美国《联邦档案法》关于保存官方通信记录的规定。希拉里被美国联邦调查局（FBI）调查，民众支持率节节下降。[1] http://www.cnvd.org.cn/webinfo/show/3821[2] http://www.freebuf.com/news/103646.html[3] https://www.oschina.net/news/78269/dyndns-attacked-by-ddos1.3 开源软件与网络安全[1]
开源软件核心是一种崇尚自由和技术的黑客精神，理查·斯托曼和林纳斯·托瓦兹就是著名黑客。开源软件在促进互联网发展的同时，也为互联网安全提供了强大支持。
1.PDR与P2DR模型
PDR模型是由美国国际互联网安全系统公司（ISS）提出，它是最早体现主动防御思想的一种网络安全模型。PDR模型包括Protection（保护）、Detection（检测）、Response（响应）三个部分。
保护就是采用一切可能的措施来保护网络、系统以及信息的安全。保护通常采用的技术及方法主要包括加密、认证、访问控制、防火墙以及防病毒等。
检测可以了解和评估网络和系统的安全状态，为安全防护和安全响应提供依据。检测技术主要包括入侵检测、漏洞扫描技术。
应急响应在安全模型中占有重要地位，是解决安全问题的最有效办法。解决安全问题就是解决紧急响应和异常处理问题，因此，建立应急响应机制，形成快速安全响应的能力，对网络和系统而言至关重[2]要。
P2DR模型是ISS在PDR模型上做了改进，增加了策略这个环节，强调根据风险分析产生的安全策略描述了系统中哪些资源要得到保护，以及如何实现对它们的保护等，如图1-2所示。策略是模型的[3]核心，所有的防护、检测和响应都是依据安全策略实施的。
2.开源安全软件崭露头角
虽然安全厂商几乎每年都会有新的概念出现，但是从实战的角度讲，企业安全防护的模型基本都是在PDR模型上发展而来。相对于利益驱动的黑产和商业间谍，目前大多数互联网企业在安全上的重视程度和投入都是远远不够的，所以对应的防护能力相当堪忧，甚至很多方面是0和1的差别。本书的重点就是比较系统的介绍如何使用开源软件建设企业信息安全。图1-3是一个互联网公司常见的基础安全技术组件，每个组件几乎都有不错的开源解决方案（见图1-4）。图1-2 P2DR模型图1-3 互联网企业安全基础组件举例图1-4 基于开源软件的互联网企业安全基础组件举例
3.开源安全与商业安全软件的对比
开源软件和商业安全软件的界限其实并没有那么明显，一个典型的例子就是Sourcefire。Sourcefire成立于2001年1月，总部设在马里兰州哥伦比亚，Sourcefire公司由马丁·罗斯奇创立，马丁·罗斯奇是开源Snort的创始人，提供的产品包括安全检测/防护系统、防火墙以及恶意软件保护等，可连续自动侦测和保护各类大中型组织的动态网络、端点、移动设备及虚拟环境的安全。Sourcefire公司目前管理着一些行业最受人尊敬的开源安全项目，这些项目包括Snort、ClamAV和Razorback。其中Snort和ClamAV是业内最常用的开放源码防病毒和反恶意软件。2013年7月，网络巨头思科收购网络安全公司[4]Sourcefire，收购金额达27亿美元。
虽然本书重点介绍的是使用开源软件，但是公正地讲，并非全盘使用开源软件就一定是最合适，没有最好的解决方案，只有最合适的解决方案。我个人经验，专业性特别强的领域，适合使用有专业公司支持的商业产品，比如APT检测、垃圾邮件、杀毒软件、防火墙、抗D和硬件令牌；定制化需求较大，或者性能要求远超过商业产品的，可以使用开源软件，比如主机安全、SOC等；还有一个中间状态，定制化需求较少，性能要求也不是特别高，商业产品价格尚能接受，自行开发人力尚可，大家可以根据实际情况评估，比如WAF、数据库安全产品、蜜罐、漏洞扫描等。表1-1是我个人总结的开源安全软件与商业安全软件的对比。表1-1 开源安全软件与商业安全软件对比[1] “黑客”原指水平高超的计算机专家，但后来逐渐区分为白帽、灰帽、黑帽等，本书中的“黑客”除了这里之外，大部分指黑帽。[2] http://wiki.mbalib.com/wiki/PDR%E6%A8%A1%E5%9E%8B[3] https://www.netentsec.com//news/show-2015-835.html[4] http://www.baike.com/wiki/Sourcefire1.4 本章小结
本章介绍了开源软件发展的历史，开源软件极大地促进了互联网甚至是科技的发展，同时面对严峻的安全形势，开源软件也将同样发挥巨大作用。虽然相对于商业安全软件，开源软件存在各种各样的问题，但是瑕不掩瑜，基于社区支持，代表创新和极客精神的开源软件，将继续深刻改变人们对企业安全建设的思路和方法。▶▶第2章业务网纵深防御体系建设
大多数互联网公司的业务开展都依赖互联网，所以我们这里讨论的是基于数据中心/云环境下的业务网安全问题。甲方安全的主要职责是保护公司互联网业务的安全，比如业务持续性、业务数据的私密性，所以需要优先解决以下问题：
·抗DDoS，保障业务的持续性，典型案例就是前不久发生在美国的大面积DDoS攻击，连GitHub服务器都未能幸免于难；
·防拖库，保护业务数据的私密性，防止用户数据、交易数据等核心数据被窃取，典型案例就是前不久某公司的账户遭到泄露；
·防后门，防止黑客非法获取服务器权限。
本章将介绍如何建立起企业的防御体系，包括建设WAF系统、抗DDoS系统，以及比较新的应用实时防护（RASP）。2.1 常见防御体系
业内对防御体系的划分比较多，这里列举比较常见的几种。
1.边界防御体系
最常见的防御体系是边界防护，从UTM到下一代防火墙、WAF都是这一体系的产物，这类体系强调御敌于国门之外，在网络边界解决安全问题。优势是部署简单，只要在网络边界部署安全设备就行了，似乎包治百病；但弱点也很明显，一旦边界被黑客突破，即可长驱直入。有人打过一个比方，称这种防御体系是城堡体系，防御都在城墙，防护住了还好，没防住就只能让敌人进城屠城了。
2.纵深防御体系
纵深防御体系是对边界防御体系的改进，强调的是任何防御措施都不是万能的，存在黑客可以突破防御措施的概率，所以纵深防御的本质就是多层防御，就好比在城堡外围建设了好几层防御，城堡又分外城和内城，内部重要设施还配备专职守卫，黑客必须突解好几层才能接触到核心数据资产，能大大提高攻击成本。纵深防御的理念在很长一段时间内都是成功的，因为毕竟黑客攻击也有成本的，不少黑客久攻不下，就开始想其他方法了，最典型的案例就是社工，这个是后话了。大型的传统安全厂商一般都会有纵深防御的解决方案，如图2-1所示，在Web领域至少会包含下面几层，数据库端、服务器端、网络层、网络边界。优点是每个产品功能定位清晰，允许不同品牌产品混用，攻击成本较高，安全性较好，不足之处是各个产品之间缺乏协同机制，如同盲人摸象、各自为政，检测手段多是基于规则和黑白名单，对于0day以及刻意绕过防御的抱有经济、政治目的的专业黑客，攻克这种防御体系也只是时间问题。需要说明的是，完整的纵深对抗方式其实还会包括服务器内核级别检测与对抗，这部分内容已经超过本书的范围，而且实际工作中，在以上四个层面如果能有效进行检测与对抗，已经可以解决绝大部分问题了。图2-1 纵深防御体系
对应的安全产品为：
·数据库端：数据库审计、数据库防火墙。
·服务器端：主机IDS、服务器杀毒、内核加固类产品、主机WAF。
·网络层：IDS、Web威胁感知、Web审计。
·网络边界：防火墙、UTM、WAF、IPS、本地流量清洗设备。
3.河防体系
腾讯lake2提出的河防体系，概念来自“捻乱止于河防”，防御方要赢就要靠一个字：“控”，即把对手控制在一个可控范围，再用丰富的资源打败他。回到企业入侵防御上来，“控”的思路就是坚壁清野，步步为营，层层设防，让黑客即使入侵进来也是在可控的范围内活动。具体措施就是要在隔离的基础上，严格控制办公网对生产网的访问，同时在对生产网内部进行隔离的基础上进行边界防护以及检测。河防体系特别适合数据中心用户，而且从业务规划就融入安全管控的公司，对于具有一定开发能力的公司，如果打算自助建设安全体[1]系可以参考该体系。
4.塔防体系
数字公司提过多次塔防体系，我认为塔防体系本质上也是纵深防御，不过优于纵深防御的是强调了终端要纳入安全防御网络中，具有自我防御能力，并且有了云的管控能力和威胁情报数据，即图2-2所示的数字公司主推的云+端+边界+联动的下一代安全体系。[2]图2-2 数字公司提出的下一代安全体系（图片来自网络）
5.下一代纵深防御体系
下一代Web纵深防御系统突破了传统基于边界防护安全的设计理念，从网络、主机、数据库层面，依托人工智能技术以及沙箱技术，结合威胁情报提供全方位的Web纵深防护，保护企业核心Web业务不被黑产网络攻击中断，保障企业核心业务数据不被黑产窃取。帮助企业建立完整的Web防护体系，从传统的边界防护过渡到新一代的基于预测、检测、协同、防御、响应、溯源理念的Web纵深防御。威胁情报好比是积累的知识，大数据和人工智能好比是聪明的大脑，WAF、SIEM、服务器安全等好比是有效的武器，大家互相配合，实现了下一代的纵深防御，在对已知威胁有较好的防御能力外，对于未知威胁也具有一定防御能力。阿里、腾讯、百度、金山、UCLOUD等都在自己的云上不同程度实现了下一代纵深防御的理念，比如阿里云的防御产品集合云盾（包括高防IP、WAF和安骑士）+检测产品集合态势感知方案，腾讯云的主机防护产品集+大禹网络安全产品集，金山的海陆空防御体系等。图2-3是下一代Web纵深防御的一种实现。图2-3 下一代Web纵深防御体系[1] https://security.tencent.com/index.php/blog/msg/68[2] http://security.zhiding.cn/security_zone/2016/0927/3083757.shtml2.2 WAF概述
WAF（Web Application Firewall，Web应用防火墙）是通过执行一系列针对HTTP/HTTPS的安全策略为Web应用提供保护的一种产品。作为绝大多数互联网公司Web防御体系最重要的一环，承担了抵御常见的SQL注入、XSS、远程命令执行、目录遍历等攻击的作用，就像大厦的保安一样默默工作，是守护业务安全的第一道防线。
1.传统WAF的不足
WAF在不少安全公司都是重要产品线，究其原因我认为有三个：
·绝大多数互联网公司没有足够的专职安全人员负责安全，解决安全问题是第一要务，WAF作为入门级产品帮助企业抵御了常见的攻击行为，需求量大。
·产品成熟，市场教育成本低，有不少酷炫的新产品需要开发布会才能让同行知道产品有什么特点，通过PPT才能让用户知道产品到底是什么。
·研发WAF的起点不高，最草根的做法基于常见的Nginx+Lua架构就可以入手。也正是由于这三方面原因，市场上WAF种类繁多但同质化严重，缺乏创新。
个人总结传统WAF在安全方面存在以下几个问题。
1）防护能力不足以应对黑产。
传统WAF主要依赖规则，一方面是吃一堑长一智，针对已知攻击形式有一定防御，针对未知攻击无防护能力，另外一方面，即使是已知攻击行为，由于正则表达式固有的局限性以及shell、PHP等语言的灵活多变的语法，因此理论上是可以绕过的，事实上也是可以绕过的，主流安全咨询媒体都有几篇讲如何绕过WAF的文章。我就列举一个例子：http://www.douwaf.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会拦截。
2）缺乏有效的基础业务安全防护能力。
WAF是否需要承担业务安全或者说业务风控的职责，其实厂商和用户一直没有达成一致，多数厂商认为这不是WAF的职责，撞库、刷短信接口、薅羊毛等，确实是专业风控产品的职责；从用户角度讲，以前被人撞库、刷短信接口、薅羊毛等，分析日志加Nginx封IP能解决一部分问题，结果上WAF却搞不定了，还非要忽悠我买昂贵的风控。我认为WAF还是要有基础的业务安全防护能力，无论是自动还是由用户配置。
3）审计能力不足。
闲时看PV，出事能取证，出现安全事件时可以很方便地查询原始流量，这个对于应急响应的同学很重要。令人遗憾的是，多数WAF即使可以保存访问日志，但也只能保存请求头、基础的URL，对于攻击定位至关重要的post body，应答内容记录的却很少，当然我们也能理解，这是由于存储空间问题、性能问题造成的。不少厂商也认为这个应该是Nginx本身、siem或者流量审计类设备的功能，我认为WAF应该做这个的原因如下：
·WAF记录黑客很难删除，Nginx上的记录很容易被删除，还没见过有自我修养的黑客不删除日志的行为；
·HTTPS普及后，流量审计想记录也记录不了了，对此表示遗憾。
2.理想中的WAF
首先声明，我理想中的WAF部分功能有的厂商在研发中，完全实现还没有，如果有某个WAF产品经理说他们实现了WAF的所有功能，我还是直接认怂算了。
理想中的WAF功能有如下几个。
1）上下文理解能力。
这个不是功能，而是处理能力，传统WAF对于HTTP协议的理解主要是单向处理请求或者应答，缺乏对HTTP整个session行为的分析，缺乏结合上下文综合理解请求应答内容的能力，这好比盲人摸象，对于问题分析很片面。比如盲注这类没有明显回显特征的，仅依赖请求包特征，不去分析整个session多个应答包的时间特征就很难准确发现。
2）语义分析能力。
语义分析，部分厂商称之为沙箱，本质上是WAF具备语义识别常见的SQL、PHP、shell语言的能力，传统WAF的规则多是基于正则，说白了就是从文本的角度去理解HTTP协议，按简单的正则匹配，好比用鸟的大脑去尝试理解人类的语言，结果肯定是误报率和漏报率无法平衡。有了语义理解能力以后，就可以从HTTP载荷中提取的疑似可执行代码段，用语义去理解是否可以执行。还是以刚才的案例来说明。http://www.douwaf.com/rce.php?cmd=pwd
对于参数cmd的内容，如果用shell的语法去理解，pwd p'w'd p""'w""'d""p'w'd""都是一回事，都是pwd。从原理上说，对于语法公开的语言都可以实现语义分析。
语义理解，理论上可以解决基于正则的规则的漏报和误报的问题，不过也不是万能的，比如HTTP协议中究竟哪部分是疑似可执行的代码段，这是个不好解决的问题。另外HTTP协议中，对于SQL注入攻击存在的都是代码段，或者说是SQL片段，如何拼接以保证正常解析也是麻烦事，市面上已经出现了一些基于语义的WAF，究竟这些问题解决到什么程度还有待于实战考验。
3）机器学习能力。
可以参考我的另外一本书《Web安全之机器学习入门》。
4）审计取证能力。
能够以HTTP会话作为存储单位，保存至少一个月的存储日志，完整记录请求应答内容，至少包括请求和应答的前4兆内容，支持基于常见HTTP字段的正则查询，支持ELK那种基础的聚合、TOP、大于、小于等操作。比较理想情况是类似去年RSA会议上提到的基于流量的时光机器，可以按照一定条件回放整个访问过程。最新的网络安全法要求保存至少半年的日志，这对于WAF来说也是个机会，可以把审计取证，日志离线备份作为一个卖点。
5）情报能力。
威胁情报这两年一直比较火，也逐渐从概念层面过渡到实战，从IP地址库、HTTP代理库、VPN库进步到真正是肉鸡库等，这一进步也给WAF带来了新的武器，对于大面积机器攻击行为，比如CC/DDoS肉鸡等可以做到直接封禁。
6）业务安全防护能力。
业务安全的防护范围非常广，我认为至少包括以下三个方面：
·网站内容防护——反恶意抓取、垃圾信息注入、黄赌毒信息注入、主页篡改（这个对党政军用户至关重要）等；
·高级业务逻辑CC攻击——对API接口的海量调用，包括短信接口、验证码接口、登录接口、数据查询接口等，撞库也可以算作此类；
·轻量级防薅羊毛–暴力注册、刷红包、刷代金券等。
市场上也出现了号称保证业务安全的WAF，这是一大进步，我见过几款产品，本质上提供能够根据用户自定义的URI、参数名、源IP/目的IP、目的URL等条件，拦截超出正常频率的机器访问行为的能力，在一定程度上解决了不少业务安全的问题。我一直有个观点，黑产、羊毛党（按照法律貌似不算违法，暂且叫灰产吧）也是讲究攻击成本的，只要攻击你的成本高于其他P2P、电商等网站，他们多会转向攻击成本低的，人家也是讲究性价比的，能够提供基础业务防护能力就是进步。
7）协同能力。
这个能力我认为很重要，因为WAF不是万金油，也不可能包打天下，再强大也可能被绕过，但是WAF的卡位很好，位于网路边界，特别适合做隔离操作，比如hids发现WebShell，协同WAF阻断访问，数据库审计发现拖库或者敏感操作协同WAF阻断（这个还依赖WAF和数据库联动分析，将HTTP会话和SQL操作关联）等。2.3 常见WAF部署模式
1.透明模式
常见部署模式之一是透明模式，如图2-4所示，在网络边际部署WAF，使用方式非常类似IPS，这种方式的优点是部署方便，缺点是横向扩展能力差。图2-4 透明模式
2.反向代理模式
另外一种常见部署模式是反向代理模式，如图2-5所示，通过指DNS的方式接入。这种方式的优点是不变化网络架构，横向扩展方便。缺点是配置略麻烦，需要逐步切换DNS。图2-5 反向代理模式
3.主机部署
还有一种WAF部署形式，就是直接在Web服务器上安装插件，典型的就是mod_security，这个插件在大规模使用上的案例较少，不作为重点介绍。2.4 自建WAF系统
基于开源软件自建WAF是个不错的选择，本节以春哥的[1][2]OpenResty以及unixhot开源的WAF为基础，以Centos系统为例，介绍如何建立WAF。unixhot开源的WAF虽然功能比较简单，但其代码逻辑清晰，对于理解WAF的基本原理非常有帮助，然而应用在实际环境中还有许多需要修改的地方。我会在unixhot的基础上提供一个升级版本，有兴趣的读者可以参考本书配套GitHub的code/waf。
1.OpenResty简介
OpenResty是一个基于Nginx与Lua的高性能Web平台，其内部集成了大量精良的Lua库、第三方模块以及大多数的依赖项，用于方便地搭建能够处理超高并发、扩展性极高的动态Web应用、Web服务和动态网关。OpenResty通过汇聚各种设计精良的Nginx模块，从而将Nginx有效地变成一个强大的通用Web应用平台。这样，Web开发人员和系统工程师可以使用Lua脚本语言调动Nginx支持的各种C以及Lua模块，快速构造出足以胜任10K乃至1000K以上单机并发连接的高性能Web应用系统。OpenResty的目标是让你的Web服务直接运行在Nginx服务内部，充分利用Nginx的非阻塞I/O模型，不仅仅对HTTP客户端请求，甚至于对诸如MySQL、PostgreSQL、Memcached以及Redis等的远程后端都进行一致的高性能响应。
2.安装OpenResty
首先安装依赖的库：yum install -y readline-devel pcre-devel openssl-devel
然后下载OpenResty并编译安装，安装路径在/home/maidou/opt/openresty：wget https://openresty.org/download/ngx_openresty-1.9.3.2.tar.gz./configure --prefix=/home/maidou/opt/openresty --with-luajit --with-http_stub_status_module --with-pcre --with-pcre-jitgmakegmake install
3.安装unixhot
从GitHub同步对应的代码：git clone https://github.com/unixhot/waf.git
将WAF的Lua文件复制到Nginx配置文件目录：cp -fr waf /home/maidou/opt/openresty/nginx/conf/
修改Nginx配置文件nginx.conf，在HTTP标签处增加WAF相关配置，其中lua_package_path表示Lua脚本对应的目录，init_by_lua_file表示Lua初始化脚本，access_by_lua_file表示处理每个请求的Lua脚本：http { include mime.types; default_type application/octet-stream; sendfile on;#WAF相关配置 lua_shared_dict limit 50m; lua_package_path "/home/maidou/opt/openresty/nginx/conf/waf/?.lua"; init_by_lua_file "/home/maidou/opt/openresty/nginx/conf/waf/init.lua"; access_by_lua_file "/home/maidou/opt/openresty/nginx/conf/waf/access.lua";
Nginx重新加载配置文件生效：./nginx -s reload
4.Nginx反向代理
Nginx+Lua WAF很重要的一个基础功能，即反向代理功能，假设需要保护网站：http://www.douwaf.com
解析域名对应的IP地址为112.80.255.48：nslookup www.douwaf.comwww.douwaf.com canonical name = xi.n.shifen.com.Name: xi.n.shifen.comAddress: 112.80.255.48
如图2-6所示，使用反向代理，将www.douwaf.com的域名解析从112.80.255.48改向180.76.234.74。图2-6 Nginx反向代理示例
在nginx.conf配置文件倒数第二行处添加一行，增加www.douwaf.com的反向代理配置，保护的网站多了以后会导致nginx.conf太大难以维护，所以通常会把不同服务的配置文件独立组成文件。include "/home/maidou/opt/openresty/nginx/conf/www.douwaf.com.conf";
include指令也支持通配符，所以更常见的做法是：include "/home/maidou/opt/openresty/nginx/conf/*.conf";
编辑www.douwaf.com.conf，定义upstream组，对应是后端真实提供服务的服务器地址和端口，即112.80.255.48：80。配置监听80端口，把全部访问www.douwaf.com的HTTP请求转发给upstream组：upstream xi{ server 112.80.255.48:80;}server { listen 80; server_name www.douwaf.com; location / { proxy_pass http://xi; index index.html index.htm; } }
把DNS指向切换到WAF上，即把www.douwaf.com指向180.76.234.74，查看目前的DNS解析：nslookup www.douwaf.comwww.douwaf.com canonical name = xi.n.shifen.com.Name: xi.n.shifen.comAddress: 180.76.234.74
使用页面访问，可以正常使用，说明反向代理配置生效。测试阶段也可以不进行DNS切换，修改/etc/hosts文件也可以达到同样效果：180.76.234.74 www.douwaf.com
查看访问日志，可以看到对应的访问记录：61.135.169.80 - - [21/Jul/2017:19:09:03 +0800] "GET / HTTP/1.1" 200 11762 "-" "curl/7.51.0"
5.基于Nginx+Lua的WAF
可以把Lua理解为一个进程，贯穿在整个Nginx服务的HTTP报文处理的流程中，可以针对HTTP报文的任何字段进行处理，如图2-7所示。这里只是为了方便理解，事实上Lua就像胶水一样粘入了Nginx的处理流程，其实并没有真实存在一个Lua进程。下面以unixhot的WAF为例，我们一起来理解WAF的运行原理。图2-7 Nginx+Lua WAF原理
1）WAF配置。
WAF的配置在config.lua文件中完成，其中比较重要的几个配置内容如下所示。
·config_waf_enable：表明WAF是否拦截，on表明检测并拦截，off表明检测不拦截：config_waf_enable = "on"
·config_log_dir：表明WAF日志对应的路径：config_log_dir = "/home/maidou/opt/openresty/nginx/logs/waf"
·config_rule_dir：表明WAF规则对应的路径：config_rule_dir = "/home/maidou/opt/openresty/nginx/conf/waf/rule-config"
·config_url_check：表明是否对URL进行检测：config_white_url_check = "on"
·config_url_args_check：表明是否对URL的参数进行检测：config_url_args_check = "on"
·config_user_agent_check：表明是否对user_agent进行检测：config_user_agent_check = "on"
·config_cookie_check：表明是否对cookie进行检测：config_cookie_check = "on"
·config_post_check：表明是否对post内容进行检测：config_post_check = "on"
·config_output_html：表明检测到攻击后返回给用户的页面内容：config_output_html=[[
Protect by douWAF
]]2）Lua环境初始化。
Lua的初始化是在init.lua文件中完成的，根据配置分别加载不同的规则文件。
比如在函数url_attack_check中，首先判断配置文件中是否配置需要检测URL：function url_attack_check() if config_url_check == "on" then
如果配置了该选项，则加载对应的检测规则：local URL_RULES = get_rule('url.rule')
其他检测URL参数、cookie以及post内容都类似。
3）Lua处理HTTP协议。
这个是整个WAF最核心的部分，流程如图2-8所示，Nginx处理HTTP协议的请求内容，将HTTP协议解析成URL、URL参数、post内容、cookie、user-agent等字段，Lua针对这些字段进行检测，判断攻击类型。处理应答内容类似，不再赘述。
整个处理过程体现在access.lua文件，可以看出一个HTTP请求会如图2-9所示，串行经过各种检测：function waf_main() if white_ip_check() then elseif black_ip_check() then elseif user_agent_attack_check() then elseif cc_attack_check() then elseif cookie_attack_check() then elseif url_attack_check() then elseif url_args_attack_check()图2-8 Lua处理流程图2-9 Lua检测流程图示例
Lua的检测规则在rule-config目录，不同检测内容保存在不同文件中，如下所示：[root@instance-ubtsv90g rule-config]# lltotal 24-rw-r--r--. 1 root root 749 Jul 20 22:43 args.rule-rw-r--r--. 1 root root 0 Jul 20 22:43 blackip.rule-rw-r--r--. 1 root root 652 Jul 20 22:43 cookie.rule-rw-r--r--. 1 root root 739 Jul 20 22:43 post.rule-rw-r--r--. 1 root root 307 Jul 20 22:43 url.rule-rw-r--r--. 1 root root 173 Jul 20 22:43 useragent.rule-rw-r--r--. 1 root root 0 Jul 20 22:43 whiteip.rule-rw-r--r--. 1 root root 6 Jul 20 22:43 whiteurl.rule
以针对URL参数的检测为例，配置文件在url.rule文件，查看对应内容：[root@instance-ubtsv90g rule-config]# cat url.rule\.(htaccess|bash_history)\.(bak|inc|old|mdb|sql|backup|java|class|tgz|gz|tar|zip)$(phpmyadmin|jmx-console|admin-console|jmxinvokerservlet)java\.lang\.svn\//(attachments|upimg|images|css|uploadfiles|html|uploads|templets|static|template|data|inc|forumdata|upload|includes|cache|avatar)/(\\w+).(php|jsp)
逐行分析规则内容，我们发现规则主要包括以下内容：
·检测对常见备份文件的访问：.(bak|inc|old|mdb|sql|backup|java|class|tgz|gz|tar|zip)$
·检测对SVN文件的访问：
试读结束[说明：试读内容隐藏了图片]