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

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

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

下面直接进入正题。

一、事件发生

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

二、发现问题

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

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

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

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

三、紧急处理

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

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

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

四、加固方案

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

1. 修改服务器SSH访问端口；
2. 删除Tomcat中的示例文档与示例项目；
3. 删除Tomcat控制台功能，或设置复杂控制台口令；
4. 修改SHUTDOWN命令；
5. 单独创建Tomcat用户权限；
6. 禁止显示文件列表；
7. 开启记录访问日志。

详细说明一下每项加固的操作方法：

1.修改服务器SSH访问端口：

为了避免攻击者通过互联网扫描到SSH的默认端口22，进行破解登陆服务器。具体操作步骤如下（示例服务器OS为CentOS7）：

第一步，修改SSH配置文件：

vi /etc/ssh/sshd_config

第二步，找到如下行（22端口是被注释的状态，SSH默认端口就是22）：

#Port 22

第三步， 自行修改为调整后的端口号（其中的端口号55000是我自己修改的，修改后的端口号最好按习惯大于1024）：

#Port 22
Port 55000

按配置的端口号同步调整防火墙策略，由于我们使用的是某云平台，策略统一在云平台后台进行配置。此处不再赘述防火墙策略的配置过程。需要注意，在下一步重启SSH服务后远程连接的客户端会断开，如果在下一步之前防火墙没有允许新端口的使用就会无法远程登陆服务器。

第四步，重启SSH：

systemctl restart sshd

完成，从此以后SSH就可以使用新端口了，默认的22端口不再起作用。

2.删除Tomcat中的示例文档与示例项目：

进入tomcat目录下的webapps目录，会发现其中有docs和examples这两个目录，其中的内容是Tomcat示例用到的页面和文档内容，对实际部署的应用并没有任何实际用途，反而有可能被恶意攻击者利用。建议直接删除docs和examples这两个目录及目录下的所有文件。

3.删除Tomcat控制台功能，或设置复杂控制台口令

Tomcat6默认会提供控制台功能，但不会提供默认的用户名和密码。可以通过http://ip:port/manager/html访问，访问时会弹出要求输入用户名与密码，如下图：

由于控制台内的功能很难被用到（大部分情况下很难用到，如你想知道有什么情况会用到，可以查看其他关于tomcat6 manager的介绍），而且暴露在外的控制台对于用户账户的管理还是会存在一定的风险，当然也可以配置成只允许指定IP访问，但如果服务器被入侵，这些基于应用的配置还是风险很大，建议直接删除控制台功能。

删除方法：找到tomcat目录下的webapps目录，删除其内的manager和host-manager两个目录即可。

如确实需要保留控制台功能，建议设置复杂口令。设置控制台口令的方法如下：

第一步，打开保存口令的文件：

vi $tomcat_home/conf/tomcat-users.xml

第二步，找到文件中的节点，发现其中的内容都是注释掉的，原始内容如下：

第三步，在  节点内按如下格式增加角色与用户，并设置用户名和复杂口令。例如：

这里稍微扩展一下，此处使用到的rolename为manager-gui，Tomcat一共有四种角色：manager-gui、manager-status、manager-script、manager-jmx，这四种都在$tomcat_home/webapps/manager/WEB-INF/web.xml里定义了，感兴趣的朋友可以自己看看每个角色都有什么样的权限。

4.修改SHUTDOWN命令

这项操作是为了防止8005端口被攻击者telnet到后，发送SHUTDOWN命令停止我们的tomcat服务。这里的8005端口与SHUTDOWN命令都是Tomcat默认的配置，均可以进行修改。修改SHUTDOWN命令串就可以防范这类的恶意攻击，同时修改8005端口也是可以的。操作过程如下：

第一步，打开Tomcat的server.xml文件：

vi $tomcat_home/conf/server.xml

第二步，找到SHUTDOWN命令对应的配置位置，如下：

第三步，修改SHUTDOWN命令的字符串（也可以同时修改8005端口），设置为复杂字符串：

5.单独创建Tomcat用户权限

这一点各项目团队都会做，即使Tomcat用户口令被破解或泄露也不会影响到服务器的其他目录。这里对用户权限配置的过程不再进行赘述，可直接使用各OS配置用户组、用户权限的方式操作。

6.禁止显示文件列表

这项操作是为了防止在使用不含页面名称直接访问目录时找不到默认主页，会显示出目录下所有文件的风险发生。Tomcat6中默认这一项是禁止的，符合我们的要求，但需要检查到位，防止已被攻击者打开或被运维人员由于某些原因开启（误开启，或有其他目的的开启）。操作过程如下：

第一步，打开Tomcat的web.xml文件：

vi $tomcat_home/conf/web.xml

第二步，找到listings的配置，如下：

    listings
    false

我们可以看到默认的配置是false，这样是我们需要达到的效果，能够禁止显示文件列表。如果不是false建议改回false。

7.开启记录访问日志

Tomcat6的访问日志默认是未开启的，开启访问日志的目的是得到每一次访问的记录，事后能根据这份记录进行审核和分析，如有异常访问在这份日志里是可以分析出来的。开启方式如下：

第一步，打开Tomcat的server.xml文件：

vi $tomcat_home/conf/server.xml

第二步， 找到配置AccessLog的地方，如下：

可以看到目前默认是注释掉的状态，打开注释即可。Tomcat6访问日志默认存放的位置在$tomcat_home/logs目录下，生成的日志文件名称格式如：localhost_access_log.2017-12-13.txt。打开文件，能看到记录的内容还是很详细的，如下：

其中记录有请求IP、请求的时间、请求方式、被请求的文件路径、响应的http状态码等信息对于事后分析都很有用，建议开启访问日志。需要注意做好访问日志的备份与清理（每一次向服务器发起的请求都会被记录，业务量大的时候硬盘会被吃的很快）。

以上几项Tomcat中的配置完成后，重启Tomcat服务即可生效。

五、事后思考

这次事件对服务器造成的影响很大，机器的带宽和IO在一段时间内差点达到峰值导致宕机，所幸某云的预警发现较早，给了我们一段时间进行紧急处理，没有造成服务中断的恶性事件。

Z项目的系统做了这几项加固后，经过这两年的运行没再出现过相同的事件，但我们依然应该保持清醒保持警惕，每一次的教训都应转变为下一次处理时的经验。

六、感谢

这次的事件处理，要大力感谢某云工程师的配合（为了避免打广告嫌疑，这里使用某云指代我们的云服务供应商），由于当时的客观原因，我们团队成员中并没有运维工程师或安全工程师，事件的处理过程中某云工程师都能尽力配合，共同完成了这次的救火任务。