小明和小红是邻居。
小明会点儿技术，他暗恋小红。
但是情商低的小明在小红不知情的情况下，入侵了邻居小红的网络，顺手从小红电脑里偷出了小红的各种生活照，并做了轰天动地的表白网站，配上了这些图，自以为特别成功地发给了小红。
小明，卒。
表白不成功不是啥事。世界上最痛苦的事儿，莫过于有人入侵了你家的网络，你却不知道。互联网早已经变成了一个没有硝烟的战场。
对个人用户而言，可能是隐私信息、电子财产被盗等，对企业网络而言，形势可能更严峻。
无时无刻，有成千上万的扫描器在不停地扫，有各种各样的系统、中间件、web 程序被曝出漏洞。有那么一群人，为了盗取用户数据、发动 DDoS 攻击、勒索等，疯狂发起攻击。
其实攻击并不可怕，有数据显示，98%的攻击都是试探性的。可怕的是攻击成功——入侵。如何抵抗入侵、及早发现入侵，甚至在萌芽阶段就能阻止入侵，对一个企业网络异常重要。
3月15日，百度安全资深安全工程师小灰灰在雷锋网硬创公开课中，按照自己的实操经验，详细讲解了如何建立一个有效的企业级安全防御。
小灰灰，百度安全资深安全工程师，主要负责百度业务应急响应、入侵排查、0Day 分析等，同时是百度安全监控体系建设技术负责人。主要技术攻关方向为 Web 安全及硬件安全。
由于曾就职在乙方安全公司，现在负责甲方安全，所以对整体的国内安全状态、各方优势以及存在的一些不足都有一些理解&感触。
整体上来看，国内以BAT为首的互联网公司，安全地位都比较高，整体研发能力也很强，基本上各大的安全系统都是自研，灵活性、效果、性能方面都有较大的优势。而国内一些中小型企业，由于整体人员分配、资金投入、业务安全风险等各方面原因吧，处于想做安全但是人力不足、专业技能人员不足，主要靠大量的购买盒子类产品、安全服务等保障公司网络安全。
上图是我亲身经历的很多 case 挑了几个典型代表。可以看见，针对这些安全研发能力一般的（估计这方面研发能力强的，也只有大型互联网公司+一些金融机构了）公司，看起来像是投入了很多资源，也很重视安全（一些定期汇报之类的），但是实际效果其实很差。不是他们不想做好，只是可能缺少了正确的方法。
那么试想下，当前两天的struts2 远程命令漏洞来了，可以预见到，这些企业大多都会被无情的入侵。工程师早上上班一来，发现页面被人改了、数据被人偷了、还搞了个locky病毒：要想赎回数据，请交钱。
所以我希望我能通过介绍互联网公司的，包含理念和具体方法的最佳实践，能够帮助这些企业在安全建设方面开拓些思路，改善下当前买了安全、做了安全但又经常处处挨打的处境。
知己知彼，百战不殆。首先我们来看看黑客们都是如何入侵到企业网络中的，以及他们都做了什么恶事儿。
看起来，他们还是有几个主要途径的，这里面最重要的 莫过于web系统了。暴露的服务越多，遭受攻击的可能性就越大。而且黑客获取服务器权限后还会进一步漫游内网，获取更多资源。
说到web系统，不得不提扫描器。其实黑客大多数也很忙，没有时间针对每个网站一点点人工测试，大多数是这么做的：开一堆扫描器，任其疯狂扫描，坐等最终结果。如果结果中有了一些中高危漏洞，他们便尝试去利用，这时候才开始针对性测试。所以，扫描算是一个重要入口了吧，如果能挡住点扫描行为，扰乱扫描器这群傻机器，其实也可以很大程度上增强安全性了。
对webserver进行些加固、用个效果不错的waf抵挡扫描器的探测、同时自己也用扫描器提前扫一下，针对已知漏洞还是有很大效果的。
但是针对struts2 s2-045 这样的0day漏洞，效果就很有限了。那如何在0day下，也有一部分的防御&感知能力呢？
由于是0day，第一时间：
Ø 没有规则，无法拦截
Ø 没有poc详情，无法扫描
但是，利用漏洞必定会 有攻击路径
Ø 特征（主要是 已入侵，得到shell的方法）
Ø 行为（主要是进一步攻击，漫游，扩大战果）
所以这时，用安全监控作为弥补，感知已入侵的入侵特征和行为，及时发现黑客入侵并应急处置，将变得异常重要和有效。
下面，我会从这三个方面给大家介绍下互联网公司一般是如何做的，以及需要注意的问题。着重讲下安全监控的思路。其中的一些实践经验总结来自于大量的攻防对抗、入侵排查、0day应急处理。
关于扫描器，我们需要明白，扫描器并不是万能的，他主要的作用有两个：
已知问题提前发现，先于黑客发现并修复漏洞，防止被外界利用
新问题 快速review（0day、SRC、其他公司等近期多发高危case）
扫描器只能是一个公司安全整体情况的晴雨表，通过扫描结果反馈不足并不断改进。而这个晴雨表的效果来自于整体扫描能力的构建。
如何评判一个扫描系统是否优秀呢？Poc的数量、质量、是否有智能识别是一个很重要的指标。数量代表了能扫到的漏洞范围（但切记范围要本地化、实用，一些老旧、无大风险的漏洞其实并没有必要），质量代表了扫描效果（例如sql注入扫描poc，是否覆盖了各种注入类型等），智能识别能极大的降低由于“傻扫”带来的资源占用、任务时间延长。
另一个常见问题是大多数扫描器资产发现能力很弱，单靠爬虫等会使得扫描输入源（访问url和参数）很有限，输入源少了，自然整体扫到的漏洞也少。一种有效的方法是通过流量中、浏览器插件、access日志等获取更多的输入源补充到扫描任务中。
如果不满足商业扫描器的功能&灵活性，或者希望更深入了解扫描器的原理，或者干脆自己实现一款扫描器，那么可以参考下W3AF（如上图所示）。W3AF是一款很优秀的开源扫描器，使用python语言实现。其中的audit模块包含了常见漏洞的检测及判断方法。而crawl模块包含了爬虫、google hacking、dictionary list等多种资产发现方式。整体上来看，很具有参考价值。
WAF通常是放在了一些中小型企业DMZ区域的最外侧。同样的，WAF也不是万能的，别指望有了WAF就一切万事大吉了（这是大家一直的误区）。它所解决的问题，其一是让扫描器得不到想要的结果，混淆扫描器；其二是在拦截0day方面，由于是最外侧入口，有着不可比拟的优势，在业务没有统一修复之前，针对性利用代码，防范0day。
同时WAF也可以作为一些数据产出，比方说根据近期攻击情况做防御调整，比方说收集最新的POC等。
上面第一个是我们从WAF收集到的具有攻击性的POC（poc放出当天就发现了）。下面的两个是我们收集到的构造十分精巧的POC，后来放在我们一部分扫描规则中。
既然我已经说了，WAF在0day拦截方面有着非常好的效果，那么大家就跟随我一起，实际做下这次的struts2 0day在waf上的防御吧。
首先让我们先对struts2进行下漏洞分析。
首先diff代码，发现删除了LocalizedTextUtil.findText(......);。由于这次poc也很快放出来了，时间原因我们取个巧，一会，边触发poc边单步调试。
以上我们只通过diff代码向上回溯LocalizedTextUtil.findText函数的调用关系，便找到了重要信息：该漏洞的触发是在content type中，而且包含multipart/form-data时。
但是跟进了下findText寻找触发命令执行的关键点，并没有发现什么有价值信息（分支条件很多，不知道走到哪了）。这时候，poc上场（如果没有poc，这个分析将会技术要求很高了）。
Poc如下：
header["Content-Type"]="aaa_multipart/form-data %{#_memberAccess=@ognl.OgnlContext@DEFAULT_MEMBER_ACCESS,@java.lang.Runtime@getRuntime().exec('calc')};"
单步调试，发现走到evaluator.evaluate(var)，弹出计算器。
分析之后，漏洞成因已经很清晰了。
Content type中包含multipart/form-data 而且内容包含%{….} 、 ${….} 的，中间内容会被当做 ognl 表达式执行，从而引发命令执行。
上图是做 %{….} 、 ${….}的判断。
通过分析后，把相关规则上到WAF上，保证了WAF拦截的有效性和防绕过。
关于监控，主要的思路是数据采集+数据分析。而采集方面，包含的内容非常之多，我们这里只看下通过hook大法实现的安全监控。这一类监控通常是在漏洞发生的最根本位置进行恶意识别，所以其获取到的报警通常效果最好。
例如常见的SQL注入漏洞，好一点的情况是最外层有waf做拦截，但是waf存在各种各样的绕过&误伤等等，况且很多公司根本没有没有部署WAF。同时扫描器针对这种漏洞扫描起来也比较困难，需要考虑多种注入方式。那么如何有效的对SQL注入进行识别，做到：如果存在注入攻击便及时报警呢？hook 数据库拿到查询日志并进行分析是一个很有效的方案。为了简化，这里直接取数据库的查询日志log做分析（实际场景采用DB Proxy类技术会有更好的性能和稳定性）
由于每次的请求（包括攻击请求）已经转化为对应的数据库查询操作，故已经无需考虑编码解码、引号闭合等问题，只需要关注是否存在异常的查询。例如：如果存在 union all select null,null 这样的查询操作，便为明显的数据库注入测试行为，并且关键的是，这种行为已经完成了引号闭合等动作，是一次成功查询。
那么现在要做的，就是格式化查询，最终匹配出恶意查询行为并报警。
在演示例子中，我们实现了对查询进行语法解析并且替换字符串的功能。
图上第一行为原始查询，第二行是经过解析和字符串替换后的查询，可以清楚的看到，
第一次查询为正常的业务请求
第二次查询被解析成了select xx from xx where name =’s’ union all select null,null --。这是一个明显的注入测试操作并且匹配了union all select null,null的规则
第三次 实际上仍然是黑客在做注入测试，只不过没有成功闭合引号，一大串查询测试仅是被当做成了一个长字符串。
通过这种方法，仅需要预定义几种注入攻击特征，便能很高效的对SQL这种攻击进行监控识别。
PHP引擎的hook以及redis的hook也是类似原理，从最根本层面发现入侵行为，排除其他干扰因素。
篇幅的关系，这里不详细介绍。
我们再来看看基于流量的监控。其实这一块很早大家就在做，传统的IPS、IDS就是做的这块，也有很多人搭建开源的snort等系统。但是实际效果来看，这些硬件、软件系统都没有发挥太大的价值，究其原因，有可能一个是规则方面的问题，数量大而又老旧；一个是理念方面的问题，只着眼于一个方向的特征识别（请求或返回）。
其实基于流量方面的监控（这里指外部流量，非IDC内部），能做的事情非常的多，但是还是那个问题，覆盖的太多 or 太宽泛，都会导致报警指数级增加，真正有用信息被淹没。另一方面，外界的各种扫描是无时无刻的，这些信息触发的报警实际上是无价值的。
如果只关注有效入侵&攻击成功的高危漏洞，整体量级就会小很多，而且这些才是我们真正需要处理的。
在基于流量的监控方面，大带宽下数据包捕获是一个很棘手的问题。好在现在有PF_RING、DPDK等高性能数据包捕获方案做支持。这两种方案，都能达到线速收发，而新的瓶颈，似乎放到了如何快速解析4层or 7层协议的问题上了。
而在入侵行为的识别上，现在普遍的一种观点是识别请求与响应报文，通过匹配两个方向，找出已经入侵成功反弹shell 上传shell等，或者利用高危漏洞（例如redis 远程命令执行、代理漏洞等）成功的情况，这种报警一般非常准确并且不像是传统IDS那样量级巨大。
最后，我们来看一下以这次的struts2 为例，应急响应的流程该如何做。
如上只是一种推荐的应急响应流程，具体实施还得看企业的安全能力、漏洞种类等多种情况。
最后，其实一个企业能不能做好安全，技术只是一方面，同时还要看公司整体的支持、公司领导的支持、体系架构的建设等很多管理因素。但是不管现阶段如何，总有方法可以改善并且做的更好。
1.发现被黑客利用 ST2-045 漏洞攻击，如何第一时间修补漏洞降低损失？
百度小灰灰：我们经常遇到的case是，当一台机器被入侵后，黑客有可能会将这台机器种植后门，当做跳板，进行内网漫游，进一步入侵，时间通常很快。这台机器如果不停，一条鱼会搅得一锅腥味，影响到期他机器，影响将扩大。
所以，建议先下线服务，或至少把外网先下了，再进行安全排查，看是否有可疑进程和网络链接，如果判断确认没有问题，就可重新部署服务，强烈建议重装系统再部署服务。
对于修复，建议替换成官网最新的 struts2 的 jar 包。经常遇到的问题是，业务线系统非常久远，老的 jar包替换成新的 jar 包，会遇到很多不可预知的问题，这时建议使用 filter拦截器拦截content type中的恶意内容。
2.对于类似漏洞，企业今后应该做好哪些方面的防护体系？
百度小灰灰：把问题扼杀在萌芽中通常效果最好，也就是说，在编码阶段，就要防止很多漏洞。比如，SQL 注入，要求开发者强制使用参数化查询，不使用拼接的方式。同时，大多数企业有很多安全设备，这些设备的最大问题是没有对规则进行精细化设置，导致很多设备报警过多，都不知道哪些是真实有效的，处于无法运维状态。所以，要优化规则，高优关注攻击行为。
如果企业自身安全能力有限，做一些外界的众测，也比较有效。但是做众测不是单单为了找漏洞，更重要的是反馈企业的应用存在哪类问题。比如，众测发现企业存在两三个 SQL 注入的漏洞，就需要告诉我们的开发人员，可能有大量这些漏洞的存在，我们需要排查，解决类似问题，同时设定相应标准，以后用安全的方式避免问题再次发生。
3.对系统漏洞怎么进行评估风险，确定修复的必要性？漏洞修复的流程步骤如何？对于像大规模主机的漏洞修复又该如何进行修复更科学或快速？
百度小灰灰：如何评估？比如，linux 有些系统组件存在存在溢出问题，有安全风险，这种漏洞通常在入侵到内网后才能触发，修与不修，安全整体收益不大。但是，如果修复，产生的不可控性比漏洞更严重，甚至会引发中断业务，这种业务就不能接受。
比如，glibc版本过低，使用gethostbyname()可能会造成安全风险。但是贸然升级glibc会导致大量的依赖风险，对业务可能造成巨大影响。推荐的方法是，排查对外业务，如果使用了gethostbyname()，需要进行升级。否则内网中大量系统，不升级风险也不是太大。
漏洞的修复步骤，我只说下 WEB 漏洞的修复，系统漏洞方法类似。建议安全人员指导研发人员来修复，比如，SQL 注入，安全人员会对开发人员说，xxx 处存在 xx 类型的 SQL 注入漏洞，使用参数化查询，不要用拼接的方式，同时告知该漏洞的具体风险。而开发人员对参数查询很清晰，修复起来很容易。对方需要知道的是漏洞的类别、危害和修复方法的方向，如果能给他代码级的修复方法更好。所以我们也可以写文档，总结常见漏洞的修复方法，让他学习和修复，但是他修复完你必须进行复测，如果复测没有问题，工单或者流程就可以关闭。
针对大规模主机的漏洞修复，如果规模很大，势必会有统一的运维系统去进行操作、部署，不会让你一个一个去安装。所以，你要和运维人员沟通，为什么必须修复，给出必要性，让运维人员进行灰度测试，比如，有 20 万台机器，先对2000台机器进行灰度测试没有问题，，再上一些机器测试，按部就班地进行。
4.请您推荐下比较好用的开源扫描器。
百度小灰灰：其实，我之前也推荐了 W3AF 的扫描器。为什么选它，一则是用Python语言写的，安全工程师一般对python上手很容易。其次，这是开源扫描器，我们主要是借鉴扫描思路，甚至可以自己写一个扫描器。比方说他的audit审计模块，会包含大量常见漏洞的检测和判断方式和规则，参考这些规则就知道如何去实现一个扫描器了。
5.怎么才能成为您的同事？（实习生、正式员工）
百度小灰灰：
实习生：要求有安全背景、大量攻防对抗经验。
正式员工：要求更高，需要是在攻防领域比较牛的人。
一句话：能力强就ok。有兴趣的同学可以发简历到 security@baidu.com 。
以上就是本次雷锋网硬创公开课的全部总结文，如果想看到更多网络安全干货，请关注雷锋网宅客频道，多多参与雷锋网硬创公开课。如果你有特别期待的嘉宾，也可在雷锋网宅客频道公众号里留言，或许，你的男神/女神就会来讲课啦！
正在生成分享图...
嘉嘉