企业官网建设流程全解析

每次做授权范围内的安全演练，我都会先让人去碰Tomcat管理后台。

原因很简单：Tomcat弱口令+getshell这条链路，是典型的“入门看着容易、实际一碰全是细节”的题目。它包含端口发现、服务指纹识别、HTTP基础认证、应用部署权限、恶意应用投放、命令执行落地六七个环节，几乎把渗透测试入门需要掌握的关键概念全部串起来了。这篇笔记不是把网上现成工具跑一遍就完事，而是把我自己在本地靶场里从环境搭建、弱口令场景构造、攻击链复盘到加固整改的完整过程，一步一步拆开来讲。目的就是让准备攻这块硬骨头的朋友弄明白：为什么弱口令会发展到getshell，中间每一环都在干什么，以及作为防守方应该怎么堵。

1. 这个实战笔记到底在练什么

1.1 标题里三个关键词的份量

先说Tomcat。Tomcat是国内大量Web应用在用的Java应用服务器，尤其是一些业务系统、数据平台、内部管理系统，跑了七八年都没换过版本。它本身是开源软件，功能非常成熟，但历史包袱也重：早期的默认配置、历史遗留的管理接口、为方便开发而保留的样例应用，都可能成为安全隐患。

再看弱口令。所谓弱口令，并不仅仅指123456这种简单密码。它还包括默认账号、长期不更换的固定密码、多环境共用的同一套口令，以及直接写在文档或者配置注释里的明文密码。Tomcat管理后台的弱口令，往往代表着整个服务器还处于“裸奔”状态，因为管理后台一旦能被登录，接下来基本就是代码层面的完全控制。

最后是getshell。这个英文词在安全圈里指的是：攻击者通过漏洞拿到了目标主机上执行命令的能力。通俗点说，就是原本只能在Web页面上点来点去，现在可以直接在服务器操作系统里执行命令。到了这一步，问题性质就变了——从“Web服务被入侵”升级为“主机被控制”。

1.2 适合谁来啃这块硬骨头

如果你是刚接触渗透测试的初学者，这篇笔记能帮你建立一条完整的攻击链认知。如果你是Web开发转安全方向，这篇文章可以让你理解Tomcat的认证、授权、部署机制本身就是在配置层面决定了安全边界。如果你是运维人员，这篇笔记更有现实意义，因为Tomcat加固清单里的每一条，都可能直接影响线上服务的风险等级。

不同基础的人读这篇文章，获取到的层次不一样。有基础的人可以直接看第5节的加固实操和第7节的排查速查表，新手则建议从头到尾读一遍，尤其是第2节的身份认证机制和第4节的攻击链逻辑，这部分搞懂了，后面很多所谓“高深”的漏洞本质上都是同一套思维。

1.3 必须先说清楚的合规边界

在进入正文之前，必须把最重要的一条原则放在开头：所有这类验证操作，只能在你自己拥有合法控制权的环境中进行。比如自己搭的本地靶场、实验虚拟机、公司明确授权测试的服务器、各类竞赛提供的靶标环境，这些都属于“授权范围之内”。

没有授权就对一个陌生人系统做密码尝试、应用部署、命令执行，触碰的是法律红线，不是技术问题。我后面提到的所有操作路径，都默认读者是在自己的靶场环境里完成验证。安全意识不是学了几招之后去挑战真实系统，而是清楚地知道哪些边界绝对不能越。

2. 理解弱口令的本源：从认证到授权

2.1 Tomcat的认证体系如何工作

Tomcat的身份认证基于JAAS体系，简化的理解方式是：系统里维护一份用户列表，每个用户拥有若干角色，然后不同的Web应用根据URL规则来要求访问者必须具备某个角色。

用户和角色的配置集中在conf目录下的tomcat-users.xml文件里。这部分配置负责给Tomcat这个服务器本身定义一批“操作员”，包括谁来登录管理页面、谁来发布应用、谁来管理虚拟主机。

Tomcat的管理接口主要有两块。第一块是manager，对应路径是/manager/html，用于管理Web应用的部署、卸载、启动、停止。第二块是host-manager，对应路径是/host-manager/html，用于管理虚拟主机。两个接口的目的完全不同，但许多管理员会为了省事，把用户同时赋予两个接口的权限，这就扩大了攻击面。

manager接口的角色细化也很有意思。Tomcat区分了manager-gui、manager-script、manager-jmx和manager-status四种角色。前两种是日常用得最多的：manager-gui用于网页图形界面操作，manager-script用于通过命令行或脚本调用部署接口。后两种分别面向JMX监控和管理API，一般业务系统用不上。

2.2 所谓“弱口令”，其实是流程问题

在实验环境里我见过很多Tomcat部署，弱口令出现的原因归根结底有两种。第一种是部署阶段图方便。安装完Tomcat之后，开发或运维人员为了调试接口，直接在tomcat-users.xml里加了一个admin用户，密码顺手写成admin或者123456，项目上线后忘了删除。第二种是密码管理混乱，多个服务器共用同一套账号密码，或者把密码写进内部文档、提交到代码仓库里。

这里有一个很多人忽略的细节：Tomcat用户的强度问题往往不是什么技术漏洞，而是配置管理和流程规范的漏洞。明明可以通过角色分离来降低风险，却因为图省事把所有权限捏在一个账号里；明明可以在网络层限制来源IP，却因为懒得上防火墙规则而全部裸奔。我复盘过几次类似问题，几乎没有一次是攻击者用了多么高深的技术，都是利用管理员的疏忽。

2.3 管理权限与普通访问权限的差异

为什么Tomcat弱口令如此危险，根本上是因为管理接口的权限等级太高。

普通Web用户访问的是一个应用里的具体页面，能调用的只是这个应用暴露出的业务功能。但如果你能登录manager接口，那么你看到的是整个Tomcat服务器上部署的所有应用清单，包括它们的路径、运行状态、内存消耗，以及一个“部署新应用”的入口。

这就相当于一个普通访客拿到了物业总控室的钥匙。钥匙本身可能只是一把普通的钥匙，但对应的是整个楼宇的配电房、网络机房和设备层。同样道理，Tomcat的弱口令账号如果被赋予了manager-script或者manager-gui权限，攻击者就可以通过管理接口放置一个应用包，然后用这个应用包在服务器上执行自己的代码。

这个逻辑一定要想清楚：不是密码太弱导致getshell，而是“密码太弱”加上“管理接口暴露”再加上“部署权限过大”三个条件同时成立，最终才形成了getshell的完整通路。三个条件缺一个，整条链路的风险等级都会明显下降。

3. 搭一个模型靶场，观察问题路径

3.1 用容器快速升起Tomcat

要在授权环境里观察这条攻击链，最快的方式不是找一台物理机去装JDK、解压Tomcat、配环境变量，而是直接用容器在本地拉起一个隔离的实验环境。

我用docker的方式做过很多次，好处是快、可重复、用完即毁，不会污染本机环境。大致操作流程是这样的：

docker run -d -p 8080:8080 --name tomcat-lab tomcat:9.0 docker exec -it tomcat-lab bash

执行完这两条命令之后，容器内部的Tomcat就跑起来了。默认情况下，Tomcat镜像里的webapps目录下会有examples、docs、ROOT等自带应用。对于实验来讲，这些自带内容先留着没问题，等后面观察完整条链路之后，再按照加固方案去清理。

这里有一个特别值得说的点：容器的端口映射只把8080暴露出来，千万不要顺手把8009和8006那些内部端口也映射出去。因为Tomcat有内部通信端口，暴露在多网卡环境下会导致一些协议级别的探测风险。做实验环境也要养成最小暴露面的习惯，这和正式服务器是一个道理。

3.2 生成一个“弱口令环境”

默认的Tomcat镜像里，manager和host-manager应用是存在的，但tomcat-users.xml里通常没有可用的账号。我们需要手工往里面添加用户和角色。

我建议的做法是：进入容器，打开conf/tomcat-users.xml，在<tomcat-users>标签内部添加一个角色和用户，让它贴近真实环境里最常见的错误配置。这一步添加出来的账号，就是为了模拟开发调试阶段遗留的弱口令，而不是为了线上环境使用。

添加完配置之后，重启Tomcat容器，直接访问http://127.0.0.1:8080/manager/html，浏览器就会弹出HTTP基本认证的登录框，要求输入用户名和密码。到这里，弱口令场景就构造完成了。

我自己的习惯是，在这个阶段先不急着进行任何尝试，而是把容器当前的配置、端口状态、默认应用列表全部截图或者记录下来。这样后面做完整个流程复盘，才能清楚每一步改动带来的变化。

3.3 网络隔离与数据记录

实验环境的网络隔离看起来是小事，但出过问题的次数反而不少。我见过有人在自己电脑的Docker里做了靶场，但是业务网卡走了公司的办公网络，结果扫描行为被安全设备记录下来，最后还得花时间解释来源。

做这类实验，我个人坚持两个原则。第一个原则是端口最小暴露，只对127.0.0.1做端口映射，不对外网暴露。第二个原则是实验环境必须与真实业务环境彻底分开，不在生产机器上装实验工具，不拿生产配置来练习。

数据记录方面，我建议实验过程中打开浏览器开发者模式，把登录请求头、响应状态、后续操作的URL都留底。因为弱口令测试看起来简单，实际排查时要还原当时发生了什么，缺了记录会很痛苦。

4. getShell的实现逻辑，以及为什么它这么经典

4.1 攻击者拿到弱口令后的思维路径

当我们把视角切到攻击者这一侧，整个思维路径是非常清晰的。

第一步是确定目标：通过端口扫描或者服务探测，确认对方这台主机上存在Tomcat服务。Tomcat的默认端口是8080，但如果管理员改过端口，就需要通过HTTP响应头、错误页面特征或者特定路径的返回内容来识别服务指纹。

第二步是找管理入口：对常见的Tomcat路径做访问尝试，比如/manager/html、/host-manager/html。正常情况下，这两个路径会返回401状态码，提示需要认证。这种401响应反而告诉了攻击者：管理后台是存在的，只差有效账号密码。

第三步是弱口令尝试：这一步可以借助自动化工具，也可以手工尝试。常见的管理员账号组合、默认密码、配置文件中暴露过的密码，都是优先尝试的对象。如果tomcat-users.xml里从来没有被清理过，那这里就成了一扇没有上锁的门。

第四步是验证权限：登录成功后，管理页面会展示部署应用的功能。到这一步，攻击者已经拥有了发布和卸载应用的权利。

4.2 管理权限到代码执行的通道

从管理权限到代码执行的关键通道，是Tomcat的WAR包部署机制。

Tomcat部署Web应用最常用的方式，就是把应用打成WAR包，通过manager接口上传，然后Tomcat自动解压并部署到运行环境中。WAR包本来是一个用于发布Web应用的归档格式，里面可以包含Servlet、JSP页面、依赖库和配置文件。

在正常情况下，WAR包里是业务代码。但在异常情况下，攻击者会制作一个包含恶意JSP后门或Servlet的WAR包，通过管理接口上传后，这个恶意应用就成为了Tomcat里的一个合法Web应用。攻击者只要访问这个应用的特定URL，就会触发一段代码，在服务器上执行系统命令。

这整个过程说白了就是：你给了攻击者“部署应用”的权限，等于允许他把代码放到你的服务器上跑起来。getshell就是这样落地的——一个合法的部署功能，被用作非法代码的投递通道。

4.3 自动化工具为什么不能替代手工理解

很多刚入门的朋友会问：既然弱口令可以直接用扫描器跑账号密码，那为什么还要手工理解这条链路？

我的经验是：工具能帮你找到“哪里有问题”，但很难告诉你“为什么有问题”以及“问题波及的范围有多大”。

自动化扫描器通常只会验证某个端口是否存在弱口令，它不会告诉你这个Tomcat上承载了多少业务系统。比如同一个Tomcat下部署了三个应用，登录管理后台后可以分别把三个应用停下来再部署替换版本，这种操作在自动化工具的结果里根本体现不出来。

更关键的是，如果不对整条链路有清晰理解，拿到工具报告之后也不知道下一步该做什么。有人看到一个弱口令结果，只知道把密码改掉，却不知道应该同时检查管理接口的访问来源是否被限制、账号的权限是否过大、日志里有没有已经发生的异常部署行为。所以，工具可以辅助，但替代不了思维。

4.4 在实验靶场里如何安全验证链路

如果要在自己的靶场里完整观察这条链路，建议不要直接在公网环境测试，而是在本地容器环境里操作。

我自己实验时，用的是本地电脑上的Docker容器。先通过网络扫描工具确认8080端口开放，再用浏览器手动请求manager路径获取401响应，然后尝试弱口令登录，登录成功后查看部署页面，最后上传自己打的测试WAR包来验证代码执行是否成立。

这里必须强调：测试WAR包里的内容，只应该包含一条输出系统当前用户或当前路径的简单命令，目的是验证执行能力，不是用来做破坏性的操作。验证完毕之后，容器直接删除重建，所有环境痕迹随之清理。

5. 反制与加固：把风险关回笼子

5.1 账号与角色配置：先解决身份问题

既然弱口令是整条链路的起点，账号加固就是第一道防线。

首先，删除所有不必要的历史账号，尤其是那些只用于调试的临时账号。Tomcat的tomcat-users.xml是纯文本配置，你要养成一个习惯：所有账号增删都要走变更记录，不把明文密码放在配置里。

其次，将不同角色的权限拆开。manager-gui是管理页面的图形化操作权限，manager-script是脚本化部署权限，host-manager是虚拟主机管理权限。实际生产环境里，这三类权限应该分配给不同的人或流程，而不是用一个超级管理员账号全部覆盖。

再次，密码本身要满足复杂度要求。这里说的不是装模作样的14位字符串，而是每台服务器独立生成，不跨环境复用。如果担心忘记，可用密码管理工具来存，不要因为怕麻烦就退回123456。

以下是一个可供参考的tomcat-users.xml加固配置片段：

<role rolename="manager-script"/> <user username="deploy-ops" password="独立强密码" roles="manager-script"/>

这段配置的含义是，只给部署运维人员一个manager-script权限，不开放manager-gui和manager-jmx。这样即使账号泄露，通过页面操作查看整个服务器应用列表的能力也被降低了。

5.2 管理接口的网络层限制

账号加固做得再好，也不能保证密码永远不会泄露。因此网络层必须再设一道闸门。

Tomcat可以通过配置Valve来实现来源IP限制。最简单的方式是在manager应用自己的META-INF/context.xml里配置RemoteAddrValve，只允许运维跳板机的IP访问。

配置思路是这样的：

<Context> <Valve className="org.apache.catalina.valves.RemoteAddrValve" allow="127.0.0.1|192.168.10.0/24" denyStatus="403"/> </Context>

这段配置的效果是：只有来自本机或指定内网网段的请求，才能访问manager应用；其他来源一律返回403。这样即使攻击者拿到了密码，因为来源IP不在白名单里，请求依然会被拒绝。

很多朋友会问，是不是改了默认端口就不用做IP限制了？答案是否定的。端口扫描可以发现非默认端口，指纹识别也能通过HTTP标头抓出Tomcat类型。真正有效的防护不是隐藏端口，而是一层一层地叠加访问控制。

5.3 清理不必要的应用与样例

Tomcat安装后自带的样例应用，被很多人忽略。webapps目录下的ROOT、docs、examples这些目录，原本是用于展示功能和帮助文档的，但里面可能包含一些可以被利用的示例Servlet或JSP文件。

建议在生产环境里，把webapps目录下不需要的样例应用全部删除，只保留自己业务需要部署的实际应用。目录清理之后，如果不需要host-manager，也一并把对应的部署包移走。

清理的过程要记住一个原则：先备份，再清理，最后验证。有些系统对Tomcat路径有相关监考依赖，贸然删除可能导致监控脚本报错。清理完成后，重新访问一次Tomcat默认页，确认哪些路径已经不可用。

5.4 日志审计与异常行为发现

即使做了前面所有加固，日志审计仍然不能省。Tomcat的日志主要分几类：catalina.out是Tomcat运行主日志，localhost.log记录本地应用访问，manager应用的日志单独记录部署行为。

异常行为的发现，核心关注这两个点。第一是登录失败记录，短时间内大量401响应，说明有人在尝试弱口令。第二是部署行为记录，如果有人成功登录manager并上传了WAR包，这个操作会对应一条部署记录，并且webapps目录下会新增一个陌生应用目录。

检查日志不能只看有没有报错，还要看有没有异常的成功操作。我看到过一些案例，攻击者成功部署后会自动删除日志中的敏感记录，但webapps目录里多出来的应用不会被自动清理。所以周期性检查已部署应用清单，是简单而有效的排查手段。

6. 实战中容易忽略的细节

6.1 授权边界是原则问题，不是技术问题

之前我反复提授权边界，这里再展开讲一遍。很多人觉得“我就试试，又不搞破坏”，但未经授权扫描、尝试口令、上传文件，哪怕什么也没发生，本身就已经是越界行为。

在安全行业里，能否守住授权边界，是区分职业操守的关键标准。成熟的从业者会在动手前反复确认测试范围和授权证明，会约束自己不去触碰授权范围之外的设备，会在测试结束后彻底清理自己引入的测试应用和临时文件。

如果你是学习者，最好的做法是把练习场景限定在本地靶场。现在有很多开源的靶场项目，可以一键搭建出包含Tomcat弱口令漏洞的训练环境，完全可以在自己电脑上完成学习需求，不需要去联网探测。

6.2 证据记录与复盘方法

做技术复盘时，很多人容易急躁，想赶着进入下一个步骤，结果回头看时才发现关键细节没有记录下来。

我自己做实验复盘时常用的方式是：在本地记录一个时间线文档，按时间顺序记录每个操作、对应URL、状态码、页面返回内容。比如几点几分请求了manager路径，返回了401；几点几分使用某账号登录成功；几点几分部署了什么应用；几点几分访问了后门页面。

这个习惯在实战排查时极其有用。因为很多问题不是当时就能判断的，等过了一段时间再翻日志，如果没有时间线，很难把分散的记录串联起来。

6.3 由Tomcat弱口令想到的延伸风险

Tomcat弱口令不是孤立的风险。一个Tomcat实例上突发的审计，往往会带出同一网络位置上的其他问题。

比如，同一个服务器上很可能同时运行着其他Web服务，这些服务的管理后台也可能存在类似的弱口令。再比如，如果Tomcat配置了管理员账号，而这个账号在同一个内网里被其他系统复用，那么这次弱口令波及的范围就不仅仅是Tomcat自身了。

所以，处理Tomcat弱口令问题，不能只看Tomcat本身的配置，还要顺带梳理一遍账号复用情况、管理接口暴露范围、网络边界访问控制策略。把单点问题放到全局视角里看，才能避免“堵了一个洞，旁边还有一堆洞”的情况。

7. 常见问题速查表

7.1 忘记本机Tomcat管理密码怎么恢复

这种情况通常出现在开发环境，管理员自己把密码忘记了。操作上可以通过编辑conf/tomcat-users.xml重新设置账号密码，保存后重启Tomcat。但要注意，这只能在自己掌握服务器控制权的前提下进行，并且操作前必须备份原配置文件。

如果是生产环境，还要考虑变更窗口和影响范围。直接重启Tomcat会导致业务中断，应当提前安排维护窗口。更重要的是，恢复密码之后马上检查一下，是否还存在其他残留的调试账号，一并清理。

7.2 改了端口就安全了吗

不安全。端口只是一个网络入口标识，改端口只在最浅层增加了扫描成本。通过访问HTTP响应头、识别Tomcat默认错误页面样式、探测常见路径比如/manager/html的返回状态，仍然可以快速确认目标类型。防护的关键在于身份认证强度和访问控制，而不是端口是否默认。

7.3 日志中出现异常登录，怎么排查

看到日志里出现大量401或者成功登录记录，要先稳住不能慌，按以下顺序排查。

先把manager应用自己的日志打开，查看请求来源IP、时间范围、尝试次数。然后看tomcat-users.xml，检查是否存在不认识的账号，尤其是有manager-gui或manager-script权限的账号。接着查看webapps目录，对比已部署应用清单，看是否出现了陌生目录或者未记录在案的WAR包。最后把相关账号密码立刻轮换，管理员接口的来源IP限制打开，对已发现的异常应用做备份后下线。

整个排查过程要做好记录，形成一份完整的事件说明，而不是改完密码就当没事发生。

这篇笔记写到这里，我最想强调的还是那句话：Tomcat弱口令getshell之所以被称为入门必啃的硬骨头，不是因为它难，而是因为它把攻击链的完整环节压缩到了一个很小的场景里。

我在本地靶场里反复做过很多次类似的验证，最初也犯过只顾着跑工具、不关注链路原理的毛病。后来把认证机制、部署权限、代码执行路径一条条拆开来看，才真正理解为什么一个看起来简单的弱口令，最后会造成那么大的破坏力。

如果你看完这篇笔记准备动手练习，我的建议是先从搭靶场开始，亲手把环境配置出来，再按着管理接口、登录验证、应用部署这条线走一遍。等整条链路在脑子里跑通了，再去研究端口扫描、指纹识别、流量排查这些外围技术，你会发现自己对安全这件事的理解扎实了很多。