容器镜像安全加固这件事说起来简单做起来琐碎但有一个细节几乎每个做过生产镜像的人都会碰到——Tomcat的版本号明晃晃地挂在响应头里或者藏在错误页面的底部稍微有点网络基础的人拿浏览器F12一看就能拿到。这件事本身不涉及什么高深技术但它牵扯到的是整个镜像构建流程里“信息暴露面收敛”的思路。我这次要聊的就是怎么把容器镜像里Tomcat的版本号藏干净从响应头、错误页、管理界面到镜像层里的残留文件一层一层处理掉。适合正在做镜像安全基线、等保整改、或者单纯不想让别人一眼看穿你中间件版本的后端和运维同学参考哪怕你刚接触Docker和Tomcat跟着步骤走也能落地。1. 先搞清楚版本号到底从哪几个口子漏出去动手之前得先摸清敌人从哪来。很多人以为改个server.xml里的Server字段就完事了实测下来远不止。Tomcat的版本信息暴露面比想象中宽我把它拆成四个层面来看每个层面的处理方式完全不同。1.1 HTTP响应头里的Server字段这是最显眼的一个。默认情况下Tomcat会在每个HTTP响应里带上类似Server: Apache-Coyote/1.1的头有些版本还会带完整的Apache Tomcat/9.0.xx。这个字段由Connector的server属性控制在conf/server.xml里改就行。但要注意改完之后如果用了AJP或者别的Connector每个Connector都得单独改漏一个就白干。1.2 错误页和默认页里的版本落款Tomcat自带的404、500错误页底部会有一行小字写着版本号默认首页那个经典的Tomcat欢迎页更是直接把版本号印在标题上。这些页面在webapps/ROOT和webapps/manager等目录下属于静态资源改法有两种要么直接替换页面文件要么把默认应用整个删掉。生产环境我倾向于后者因为默认应用本来就不该留。1.3 管理端点和示例应用/manager/html和/host-manager/html这两个管理界面不仅暴露版本还暴露服务器状态。示例应用examples目录里一堆JSP演示页同样带版本信息。这些东西在生产镜像里属于“不该存在”的范畴直接删比改更彻底。1.4 镜像层里的残留痕迹这一层最容易被忽略。就算你把运行时暴露面全堵了镜像的/usr/local/tomcat/lib目录下那堆jar包文件名里还带着版本号RELEASE-NOTES、RUNNING.txt这些文档文件更是把版本写得清清楚楚。有人会说“镜像内部文件别人看不到”但镜像一旦推到公共仓库或者被扫描工具拉取这些信息就是明文。所以镜像层的清理同样要做。把这四个层面理清楚之后处理顺序也就出来了先改配置堵运行时暴露再删应用减攻击面最后清镜像层做彻底收敛。下面按这个顺序展开。2. 配置层改造从server.xml动手配置层是版本号暴露的主渠道也是改起来最直接的一层。核心就是改conf/server.xml但里面有几个坑得提前说清楚。2.1 Connector的server属性怎么改打开server.xml找到Connector标签加上或修改server属性Connector port8080 protocolHTTP/1.1 connectionTimeout20000 redirectPort8443 serverWebServer /这里server的值随便填但建议填一个通用且不指向具体产品的名字比如WebServer或者干脆留空字符串server。留空的话响应头里这个字段就没了更干净。我实测过Tomcat 8.5和9.0两个大版本server都能正常生效响应头里直接不出现Server字段。注意如果你有多个Connector比如同时开了HTTP和AJP每个都要加这个属性。AJP的Connector默认也会带版本信息别只顾着HTTP那个。2.2 关闭AJP Connector的必要性说到AJP这里插一句。除非你前面挂了Apache httpd做反向代理并且确实需要AJP协议否则生产环境应该把AJP Connector整个注释掉。AJP本身有历史安全问题而且它同样会暴露版本。在server.xml里找到Connector port8009 protocolAJP/1.3 ...这一段直接注释掉或者删掉。这一步和隐藏版本号是顺带的但收益更大。2.3 错误页版本落款的配置级处理Tomcat的错误页版本落款其实可以通过ErrorReportValve来控制。在server.xml的Host标签里默认有一个ErrorReportValve它有个showServerInfo属性Host namelocalhost appBasewebapps unpackWARstrue autoDeploytrue Valve classNameorg.apache.catalina.valves.ErrorReportValve showReportfalse showServerInfofalse / /Host把showServerInfo设为false错误页底部的版本信息就没了。showReportfalse则是把整个错误堆栈也藏掉生产环境建议两个都关。这个改法比替换页面文件优雅因为它不依赖具体页面路径升级Tomcat版本也不会丢。2.4 配置改完怎么验证改完server.xml别急着构建镜像先在本地起一个容器验证curl -I http://localhost:8080/看响应头里还有没有Server字段。然后再故意访问一个不存在的路径触发404curl http://localhost:8080/notexist看返回的HTML里还有没有版本号。两步都过了配置层就算收工。3. 应用层清理把默认应用和示例全删掉配置层堵的是“主动暴露”应用层清理堵的是“被动暴露”。Tomcat默认镜像里带了一堆用不上的东西生产环境一个都不该留。3.1 默认webapps目录该留什么标准Tomcat镜像的webapps目录下通常有这几个ROOT、docs、examples、manager、host-manager。生产环境我的做法是只留ROOT而且ROOT里的内容要换成自己的其余四个全删。docs是文档examples是示例manager和host-manager是管理界面没有一个该出现在生产镜像里。删的时候在Dockerfile里用RUN指令RUN rm -rf /usr/local/tomcat/webapps/docs \ /usr/local/tomcat/webapps/examples \ /usr/local/tomcat/webapps/manager \ /usr/local/tomcat/webapps/host-manager这里有个细节如果你用的是官方tomcat镜像webapps目录下可能只有一个ROOT其他应用在webapps.dist里。不同版本镜像的目录结构有差异构建前先docker run进去ls一下确认别照着网上的教程硬套。3.2 ROOT应用的处理策略ROOT目录是默认应用访问根路径时加载的就是它。如果你有自己的WAR包要部署直接把ROOT删掉换成自己的应用就行。如果没有也要把ROOT里的默认页面清掉因为那个经典的Tomcat欢迎页带版本号。最省事的做法是RUN rm -rf /usr/local/tomcat/webapps/ROOT/*然后放一个自己的index.html进去内容随便写个“Service Running”之类的既不留版本信息又能确认服务活着。3.3 管理界面的彻底移除manager和host-manager这两个应用除了暴露版本还暴露服务器状态、部署的应用列表甚至在某些配置下能远程部署WAR包。生产环境留着它们纯属给自己挖坑。除了删目录还要检查conf/tomcat-users.xml里有没有配管理账号有的话一并清掉。另外conf/Catalina/localhost/目录下如果有manager.xml之类的上下文配置也删掉。提示删管理应用这件事要在构建镜像的阶段做别等容器跑起来再进去删。容器重启后改动就没了必须写进Dockerfile。3.4 清理后的验证方法应用层清理完验证方式很简单起容器后依次访问/docs、/examples、/manager/html、/host-manager/html全部应该返回404。如果哪个还能访问说明对应的目录没删干净回去检查Dockerfile里的路径对不对。4. 镜像层深度清理jar包名和文档文件前面两层处理的是运行时暴露面这一层处理的是镜像本身的“静态暴露面”。很多人做到前两步就收手了但镜像一旦被扫描或者推到公共仓库jar包文件名里的版本号照样是明文。4.1 lib目录下jar包的重命名Tomcat的lib目录下有一堆jar文件名形如tomcat-catalina-9.0.xx.jar、tomcat-coyote-9.0.xx.jar。这些文件名里的版本号是明文的。处理方式有两种一是重命名去掉版本号二是干脆不处理但接受这个暴露面。重命名的操作要小心因为Tomcat启动时是按文件名加载jar的改名后要确保类加载不受影响。实测下来把tomcat-xxx-9.0.xx.jar改成tomcat-xxx.jar是可行的Tomcat不依赖文件名里的版本号来加载。但要注意catalina.jar、tomcat-util.jar这些核心包改名后要同步检查conf/catalina.properties里的common.loader配置确保路径匹配。RUN cd /usr/local/tomcat/lib \ for f in *.jar; do mv $f $(echo $f | sed -E s/-[0-9]\.[0-9]\.[0-9]//g); done这条命令把所有jar文件名里的-x.y.z版本段去掉。执行前建议先备份一份原始镜像改完起容器验证Tomcat能正常启动、应用能正常访问确认没问题再固化到Dockerfile里。4.2 文档文件的清理/usr/local/tomcat根目录下有RELEASE-NOTES、RUNNING.txt、NOTICE、LICENSE这些文件其中RELEASE-NOTES和RUNNING.txt里明确写着版本号。生产镜像里这些文档文件没有保留价值直接删RUN rm -f /usr/local/tomcat/RELEASE-NOTES \ /usr/local/tomcat/RUNNING.txtNOTICE和LICENSE涉及开源协议删之前确认一下你们的合规要求有些团队要求保留。如果必须保留至少确认里面没有版本号明文。4.3 镜像历史层的痕迹这一层比较隐蔽。Docker镜像是由多层叠加的就算你在最后一层把文件删了前面的层里可能还留着。用docker history能看到每一层的构建命令如果构建过程中有ADD或COPY操作把带版本号的文件拷进去过历史层里就有记录。处理方式是尽量用多阶段构建把清理操作放在最终镜像的同一层里完成避免中间层残留。另外构建时用--squash参数如果构建工具支持可以把多层压成一层彻底消除历史痕迹。不过--squash不是所有环境都支持得看你们用的构建工具链。4.4 清理效果的检查清单镜像层清理完用下面这个清单逐项检查检查项检查方法预期结果响应头Server字段curl -I看响应头无Server字段或为通用值错误页版本落款访问不存在的路径页面无版本号默认应用访问/docs等路径返回404jar包文件名ls /usr/local/tomcat/lib文件名无版本号文档文件ls /usr/local/tomcat无RELEASE-NOTES等镜像历史docker history无带版本号的ADD/COPY记录这张表建议存下来每次构建新镜像后过一遍形成固定动作。5. 构建流程整合把清理写进Dockerfile前面讲的都是“改什么”这一节讲“怎么固化”。所有清理动作必须写进Dockerfile否则容器一重启就前功尽弃。这里给一个完整的Dockerfile示例基于官方Tomcat镜像做改造。5.1 完整Dockerfile示例FROM tomcat:9.0-jdk11-openjdk-slim # 删除默认应用和示例 RUN rm -rf /usr/local/tomcat/webapps/docs \ /usr/local/tomcat/webapps/examples \ /usr/local/tomcat/webapps/manager \ /usr/local/tomcat/webapps/host-manager \ /usr/local/tomcat/webapps.dist # 清空ROOT并放一个占位页 RUN rm -rf /usr/local/tomcat/webapps/ROOT/* \ echo htmlbodyService Running/body/html /usr/local/tomcat/webapps/ROOT/index.html # 删除版本文档 RUN rm -f /usr/local/tomcat/RELEASE-NOTES \ /usr/local/tomcat/RUNNING.txt # 重命名lib下的jar去掉版本号 RUN cd /usr/local/tomcat/lib \ for f in *.jar; do mv $f $(echo $f | sed -E s/-[0-9]\.[0-9]\.[0-9]//g); done # 替换server.xml提前准备好改好的配置文件 COPY server.xml /usr/local/tomcat/conf/server.xml # 清理tomcat-users.xml里的管理账号 RUN rm -f /usr/local/tomcat/conf/tomcat-users.xml EXPOSE 8080 CMD [catalina.sh, run]这个Dockerfile把前面几层的清理动作全串起来了。server.xml需要提前在本地改好加上server和showServerInfofalse然后COPY进去覆盖默认配置。5.2 多阶段构建减少历史层残留如果对镜像历史层的要求比较严可以用多阶段构建。第一阶段做清理第二阶段只拷贝清理后的结果FROM tomcat:9.0-jdk11-openjdk-slim AS builder RUN rm -rf /usr/local/tomcat/webapps/docs \ /usr/local/tomcat/webapps/examples \ /usr/local/tomcat/webapps/manager \ /usr/local/tomcat/webapps/host-manager RUN rm -f /usr/local/tomcat/RELEASE-NOTES /usr/local/tomcat/RUNNING.txt FROM tomcat:9.0-jdk11-openjdk-slim COPY --frombuilder /usr/local/tomcat/webapps /usr/local/tomcat/webapps COPY --frombuilder /usr/local/tomcat/conf /usr/local/tomcat/conf多阶段构建的好处是最终镜像里只有拷贝进来的文件第一阶段那些rm操作的历史层不会带到最终镜像。但要注意基础镜像本身的历史层还是存在的--squash才能彻底压平。5.3 构建参数和版本锁定的取舍这里有个矛盾点隐藏版本号是为了不让人知道具体版本但构建时又需要锁定基础镜像版本以保证可复现。我的做法是在Dockerfile里用具体版本标签比如tomcat:9.0.xx-jdk11但在最终镜像里把版本痕迹清掉。这样构建可复现运行时又不暴露。别用latest标签那玩意儿今天构建和明天构建可能拿到不同版本出了问题没法排查。5.4 构建后的自动化验证脚本每次构建完手动验证太累写个脚本自动跑#!/bin/bash IMAGE$1 CONTAINER$(docker run -d -p 18080:8080 $IMAGE) sleep 10 echo 检查响应头 curl -sI http://localhost:18080/ | grep -i server echo FAIL: Server头存在 || echo PASS echo 检查错误页 curl -s http://localhost:18080/notexist | grep -i apache tomcat echo FAIL: 错误页含版本 || echo PASS echo 检查默认应用 for path in docs examples manager host-manager; do code$(curl -s -o /dev/null -w %{http_code} http://localhost:18080/$path) [ $code 404 ] echo PASS: /$path || echo FAIL: /$path 返回 $code done docker stop $CONTAINER docker rm $CONTAINER这个脚本可以挂到CI流水线里每次构建自动跑不通过就阻断发布。脚本里的端口18080是随便选的避免和本地已有服务冲突。6. 踩过的坑和排查实录这一节是我实际做这件事过程中踩过的坑有些坑不踩一遍真想不到。6.1 改了server.xml但响应头还在第一次做的时候改完server.xml重启容器curl -I一看Server字段还在当时就懵了。排查下来发现是镜像里有两份server.xml一份在conf/下一份在别的地方某些定制镜像会这样我改的那份没被加载。解决办法是进容器find / -name server.xml确认所有位置确保改的是实际加载的那份。另外如果是用COPY覆盖的确认COPY的目标路径和Tomcat实际读取的路径一致。6.2 jar包改名后应用起不来按4.1的方法批量改名后容器起不来了日志报ClassNotFoundException。原因是某些jar之间存在依赖关系改名后类加载器按文件名匹配的逻辑出了问题。后来发现是tomcat-util-scan.jar和tomcat-util.jar这两个改名后冲突了。解决办法是改名时保留jar的功能名只去掉版本号别把功能名也搞乱。改完一定要起容器验证别改完直接推仓库。6.3 错误页showServerInfo设了false但还有版本这个坑比较隐蔽。showServerInfofalse只对ErrorReportValve处理的错误页生效如果应用自己捕获了异常并返回了自定义错误页那个页面里的版本信息得在应用层处理。另外某些Tomcat版本里showServerInfo的默认值就是false但showReport默认是true错误堆栈里可能带版本信息。两个属性都要显式设成false才保险。6.4 多阶段构建后管理应用又回来了用多阶段构建时第二阶段COPY --frombuilder只拷了webapps和conf但基础镜像自带的webapps.dist没处理结果管理应用又从webapps.dist里被自动部署回来了。解决办法是在第二阶段也执行一遍删除或者干脆在第二阶段用RUN rm -rf把webapps.dist删掉。多阶段构建不是万能的基础镜像自带的东西该删还得删。6.5 常见问题速查表问题现象可能原因解决方向响应头Server字段仍在多个Connector未全改/改错文件检查所有Connector和实际加载的server.xml错误页仍有版本号showReport未关/应用自定义错误页两个属性都设false检查应用层管理应用可访问webapps.dist未删/自动部署删webapps.dist检查autoDeploy配置jar改名后启动失败文件名冲突/依赖匹配失败保留功能名只去版本号起容器验证镜像历史有版本痕迹中间层残留多阶段构建或--squash容器重启后改动丢失改动未写进Dockerfile所有清理动作固化到Dockerfile这张表建议打印出来贴工位上遇到问题先对一遍能省不少排查时间。7. 影响范围与延伸思考做完这一套收益不只是“别人看不到版本号”这么简单。版本号隐藏之后攻击者没法直接针对特定版本的已知问题做定向利用得先花时间探测这就提高了攻击成本。同时镜像里删掉的那些默认应用和示例本身就是攻击面删掉等于直接减少了可被利用的入口。从影响范围来看这套改造对业务代码零侵入改的全是镜像构建层和Tomcat配置层应用该怎么跑还怎么跑。唯一需要注意的是jar包改名可能影响某些依赖文件名做逻辑判断的第三方组件上线前要在测试环境充分验证。另外如果团队有镜像扫描流程改完之后扫描报告里的“信息泄露”类告警应该会明显减少这可以作为改造效果的量化指标。延伸一点说这套思路不局限于Tomcat。Nginx的server_tokens off、Spring Boot的server.error.include-stacktracenever、各种中间件的默认错误页本质都是同一个问题默认配置倾向于“方便调试”而生产环境需要的是“最小暴露”。把“信息暴露面收敛”当成镜像构建的一个固定环节比每次出了问题再临时补救要靠谱得多。我在实际项目里是把这套检查做成了构建流水线的一个卡点镜像构建完自动跑验证脚本不通过就不让往下走坚持下来之后这类低级暴露问题基本绝迹了。