扫描器只能是一个公司安全整体情况的晴雨表，通过扫描结果反馈不足并不断改进。而这个晴雨表的效果来自于整体扫描能力的构建。
另一个常见问题是大多数扫描器资产发现能力很弱，单靠爬虫等会使得扫描输入源（访问url和参数）很有限，输入源少了，自然整体扫到的漏洞也少。一种有效的方法是通过流量中、浏览器插件、access日志等获取更多的输入源补充到扫描任务中。
如果不满足商业扫描器的功能&灵活性，或者希望更深入了解扫描器的原理，或者干脆自己实现一款扫描器，那么可以参考下W3AF（如上图所示）。W3AF是一款很优秀的开源扫描器，使用python语言实现。其中的audit模块包含了常见漏洞的检测及判断方法。而crawl模块包含了爬虫、googlehacking、dictionarylist等多种资产发现方式。整体上来看，很具有参考价值。
WAF通常是放在了一些中小型企业DMZ区域的最外侧。同样的，WAF也不是万能的，别指望有了WAF就一切万事大吉了（这是大家一直的误区）。它所解决的问题，其一是让扫描器得不到想要的结果，混淆扫描器；其二是在拦截0day方面，由于是最外侧入口，有着不可比拟的优势，在业务没有统一修复之前，针对性利用代码，防范0day。
同时WAF也可以作为一些数据产出，比方说根据近期攻击情况做防御调整，比方说收集最新的POC等。
上面第一个是我们从WAF收集到的具有攻击性的POC（poc放出当天就发现了）。下面的两个是我们收集到的构造十分精巧的POC，后来放在我们一部分扫描规则中。
既然我已经说了，WAF在0day拦截方面有着非常好的效果，那么大家就跟随我一起，实际做下这次的struts20day在waf上的防御吧。
首先让我们先对struts2进行下漏洞分析。
以上我们只通过diff代码向上回溯LocalizedTextUtil.findText函数的调用关系，便找到了重要信息：该漏洞的触发是在contenttype中，而且包含multipart/form-data时。
但是跟进了下findText寻找触发命令执行的关键点，并没有发现什么有价值信息（分支条件很多，不知道走到哪了）。这时候，poc上场（如果没有poc，这个分析将会技术要求很高了）。
Poc如下：
单步调试，发现走到evaluator.evaluate(var)，弹出计算器。
分析之后，漏洞成因已经很清晰了。
Contenttype中包含multipart/form-data而且内容包含%{….}、${….}的，中间内容会被当做ognl表达式执行，从而引发命令执行。
上图是做%{….}、${….}的判断。
关于监控，主要的思路是数据采集+数据分析。而采集方面，包含的内容非常之多，我们这里只看下通过hook大法实现的安全监控。这一类监控通常是在漏洞发生的最根本位置进行恶意识别，所以其获取到的报警通常效果最好。
例如常见的SQL注入漏洞，好一点的情况是最外层有waf做拦截，但是waf存在各种各样的绕过&误伤等等，况且很多公司根本没有没有部署WAF。同时扫描器针对这种漏洞扫描起来也比较困难，需要考虑多种注入方式。那么如何有效的对SQL注入进行识别，做到：如果存在注入攻击便及时报警呢？hook数据库拿到查询日志并进行分析是一个很有效的方案。为了简化，这里直接取数据库的查询日志log做分析（实际场景采用DBProxy类技术会有更好的性能和稳定性）
那么现在要做的，就是格式化查询，最终匹配出恶意查询行为并报警。
在演示例子中，我们实现了对查询进行语法解析并且替换字符串的功能。
图上第一行为原始查询，第二行是经过解析和字符串替换后的查询，可以清楚的看到，
第一次查询为正常的业务请求
第二次查询被解析成了selectxxfromxxwherename=’s’unionallselectnull,null--。这是一个明显的注入测试操作并且匹配了unionallselectnull,null的规则
第三次实际上仍然是黑客在做注入测试，只不过没有成功闭合引号，一大串查询测试仅是被当做成了一个长字符串。
通过这种方法，仅需要预定义几种注入攻击特征，便能很高效的对SQL这种攻击进行监控识别。
PHP引擎的hook以及redis的hook也是类似原理，从最根本层面发现入侵行为，排除其他干扰因素。
篇幅的关系，这里不详细介绍。
我们再来看看基于流量的监控。其实这一块很早大家就在做，传统的IPS、IDS就是做的这块，也有很多人搭建开源的snort等系统。但是实际效果来看，这些硬件、软件系统都没有发挥太大的价值，究其原因，有可能一个是规则方面的问题，数量大而又老旧；一个是理念方面的问题，只着眼于一个方向的特征识别（请求或返回）。
其实基于流量方面的监控（这里指外部流量，非IDC内部），能做的事情非常的多，但是还是那个问题，覆盖的太多or太宽泛，都会导致报警指数级增加，真正有用信息被淹没。另一方面，外界的各种扫描是无时无刻的，这些信息触发的报警实际上是无价值的。
在基于流量的监控方面，大带宽下数据包捕获是一个很棘手的问题。好在现在有PF_RING、DPDK等高性能数据包捕获方案做支持。这两种方案，都能达到线速收发，而新的瓶颈，似乎放到了如何快速解析4层or7层协议的问题上了。
而在入侵行为的识别上，现在普遍的一种观点是识别请求与响应报文，通过匹配两个方向，找出已经入侵成功反弹shell上传shell等，或者利用高危漏洞（例如redis远程命令执行、代理漏洞等）成功的情况，这种报警一般非常准确并且不像是传统IDS那样量级巨大。
最后，我们来看一下以这次的struts2为例，应急响应的流程该如何做。
如上只是一种推荐的应急响应流程，具体实施还得看企业的安全能力、漏洞种类等多种情况。
最后，其实一个企业能不能做好安全，技术只是一方面，同时还要看公司整体的支持、公司领导的支持、体系架构的建设等很多管理因素。但是不管现阶段如何，总有方法可以改善并且做的更好。
所以，建议先下线服务，或至少把外网先下了，再进行安全排查，看是否有可疑进程和网络链接，如果判断确认没有问题，就可重新部署服务，强烈建议重装系统再部署服务。
对于修复，建议替换成官网最新的struts2的jar包。经常遇到的问题是，业务线系统非常久远，老的jar包替换成新的jar包，会遇到很多不可预知的问题，这时建议使用filter拦截器拦截contenttype中的恶意内容。
2.对于类似漏洞，企业今后应该做好哪些方面的防护体系？
如果企业自身安全能力有限，做一些外界的众测，也比较有效。但是做众测不是单单为了找漏洞，更重要的是反馈企业的应用存在哪类问题。比如，众测发现企业存在两三个SQL注入的漏洞，就需要告诉我们的开发人员，可能有大量这些漏洞的存在，我们需要排查，解决类似问题，同时设定相应标准，以后用安全的方式避免问题再次发生。
3.对系统漏洞怎么进行评估风险，确定修复的必要性？漏洞修复的流程步骤如何？对于像大规模主机的漏洞修复又该如何进行修复更科学或快速？
百度小灰灰：如何评估？比如，linux有些系统组件存在存在溢出问题，有安全风险，这种漏洞通常在入侵到内网后才能触发，修与不修，安全整体收益不大。但是，如果修复，产生的不可控性比漏洞更严重，甚至会引发中断业务，这种业务就不能接受。
比如，glibc版本过低，使用gethostbyname()可能会造成安全风险。但是贸然升级glibc会导致大量的依赖风险，对业务可能造成巨大影响。推荐的方法是，排查对外业务，如果使用了gethostbyname()，需要进行升级。否则内网中大量系统，不升级风险也不是太大。
漏洞的修复步骤，我只说下WEB漏洞的修复，系统漏洞方法类似。建议安全人员指导研发人员来修复，比如，SQL注入，安全人员会对开发人员说，xxx处存在xx类型的SQL注入漏洞，使用参数化查询，不要用拼接的方式，同时告知该漏洞的具体风险。而开发人员对参数查询很清晰，修复起来很容易。对方需要知道的是漏洞的类别、危害和修复方法的方向，如果能给他代码级的修复方法更好。所以我们也可以写文档，总结常见漏洞的修复方法，让他学习和修复，但是他修复完你必须进行复测，如果复测没有问题，工单或者流程就可以关闭。
针对大规模主机的漏洞修复，如果规模很大，势必会有统一的运维系统去进行操作、部署，不会让你一个一个去安装。所以，你要和运维人员沟通，为什么必须修复，给出必要性，让运维人员进行灰度测试，比如，有20万台机器，先对2000台机器进行灰度测试没有问题，，再上一些机器测试，按部就班地进行。
4.请您推荐下比较好用的开源扫描器。
百度小灰灰：其实，我之前也推荐了W3AF的扫描器。为什么选它，一则是用Python语言写的，安全工程师一般对python上手很容易。其次，这是开源扫描器，我们主要是借鉴扫描思路，甚至可以自己写一个扫描器。比方说他的audit审计模块，会包含大量常见漏洞的检测和判断方式和规则，参考这些规则就知道如何去实现一个扫描器了。
5.怎么才能成为您的同事？（实习生、正式员工）
百度小灰灰：
一句话：能力强就ok。有兴趣的同学可以发简历到security@baidu.com。