（附讲稿全文和PPT）百度讲师：以struts2 为例，教你打造一款互联网思维的安全防御 | 硬创公开课

在基于流量的监控方面，大带宽下数据包捕获是一个很棘手的问题。好在现在有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注入漏洞，使用参数化查询，不要用拼接的方式，同时告知该漏洞的具体风险。而开发人员对参数查询很清晰，修复起来很容易。对方需要知道的是漏洞的类别、危害和修复方法的方向，如果能给他代码级的修复方法更好。所以我们也可以写文档，总结常见漏洞的修复方法，让他学习和修复，但是他修复完你必须进行复测，如果复测没有问题，工单或者流程就可以关闭。

（编辑：佛山站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!