Tomcat安全加固--记一次救火经历

-- “隐患险于明火，防范胜于救灾，责任重于泰山”

这篇文章中记录的事件发生在两年前，事件发生并处理后我在自己本地做了记录（本文中的主体内容都来源于这份两年前的记录），最近才在清理旧文件的时候翻了出来。之所以当时没有在博客中进行记录原因有二：第一，之前我太懒（是真的懒，懒到忘了自己博客早就已经注册过）；第二，做了对应处理后，并没有完全的信心认为已经处理妥当。观望了这两年发现确实没再发生同样的事件，说明当时的处理办法是有一定效果的，想要将方案分享出来。

下面直接进入正题。

一、事件发生

Z项目部署于某公有云上，两年前的某一天，某云平台发出预警提示服务器可能受到攻击。赶紧检查（此处感谢某云工程师的配合），发现服务器有可疑进程正在执行某个脚本自动下载文件，并不断与国外的几个IP进行连接。正在执行的业务进程与Z项目完全无关，基本判断为服务器被植入了木马。

二、发现问题

发现了木马，并不能算是发现了问题所在，服务器必然存在某个漏洞导致后门大开，这次的木马即使被清理也无法保证不会再被入侵。应重点处理的根源是填补漏洞，而不是仅仅处理当前木马。

那么进行一下梳理分析（再次感谢某云工程师的配合）：

1. 某云平台中的安全策略已进行了配置，云平台自身防火墙的策略、预警也都已开通（这里没问题）；
2. 服务器出口策略目前定义的是全部放通（这里有风险）；
3. 检查了服务器的定时任务列表，发现被加入不明定时任务（这里已经产生了问题）；
4. 部署的web应用服务器为Tomcat6（这里有风险，加固策略可能存在遗漏）。

经过梳理，初步发现了风险和有问题的地方，先紧急处理目前的问题，再进一步进行分析处理。

三、紧急处理

根据问题的表象，先进行紧急处理：

1. 清理木马文件；
2. 删除服务器中不明定时任务；
3. 将发现的国外服务器地址在出口策略中配置为禁止访问。

紧急处理后服务器运行恢复正常，为我们后续的操作争取到一定的时间。接下来正式处理问题。

四、加固方案

我们的方案重点放在对Tomcat6进行加固。其他风险点我们在某云工程师的配合下已完成了可处理的极限，更多其他方面的安全需要某云来保障了。而对于具体的web应用服务器（Z项目使用Tomcat6），某云工程师无法再提供支持，需要我们项目组内自行处理。综合了网络上各大神的处理办法，我们自己进行了汇总，并实施了以下几个方面的加固（此处记录所有做过的操作，不区分是在本次事件发生后才做的处理还是上线前已做过的处理）：