企业官网建设流程全解析

1. 先搞清楚Weblogic在业务中到底扮演什么角色

聊Weblogic漏洞之前，得先说说它本身是个啥。Weblogic是某厂商出品的企业级Java应用服务器，说白了就是一套专门跑Java企业应用的“底盘”。很多传统行业的核心业务系统——比如银行、政务、制造、物流、保险——都是跑在它上面的。你去看那些老牌企业的生产环境，十套里至少有四五套跟Weblogic沾边，有的甚至用了几十年没换过。

这套中间件为什么这么多人用？因为它够稳、够重、够“企业级”。集群、事务、消息队列、安全管理这些能力都是内建的，比那些轻量级框架省心很多。但问题也恰恰出在“重”和“老”上面。代码量大、组件多、更新节奏慢，意味着漏洞面宽、补丁周期长。它不像Spring Boot那样能快速迭代，很多老版本甚至有十年以上的技术债摆在明面上。

我在排查过程中发现一个很普遍的现象：很多企业并不是没有安全意识，而是它们根本不知道自己用的是哪个版本、存在哪些漏洞。问一圈下来，很多运维只能报上来一句“我们用的Weblogic”，问具体更新到哪个补丁了，就支支吾吾说不清楚了。这种状态下，系统就是裸奔着跑在公网上的。所以这篇文章我不是来教你怎么攻击的，恰恰相反，我是站在防守方的角度，告诉你攻击者正在盯哪些洞，以及你该怎么自查、怎么堵、怎么修。存量系统的安全加固，很多时候不是技术问题，而是认知问题。

2. 常见漏洞到底是怎么形成的

2.1 反序列化漏洞——最老牌的“重灾区”

一说到Weblogic，第一反应绝对是反序列化。CVE-2015-4852、CVE-2016-0638、CVE-2017-3248、CVE-2018-2628、CVE-2019-2725、CVE-2020-2555……这一串编号，每一个都曾经在网上引发过大规模的扫描和利用。你可以不记得完整的CVE编号，但你一定要理解它们的共同底层原因：Java反序列化机制把一个二进制流还原成对象时，没有对“流的来源和内容”做充分的信任校验。

用生活里的事情打比方，这就像你公司楼下的保安，看到一个穿快递员衣服的人，打开门就放进来了。坏人就利用了这一点：他包裹里装的不是快递，而是一堆恶意指令。Java的很多中间件都有类似机制，但Weblogic的问题在于嵌入了一个叫IIOP的通信协议，这个协议本身就大量依赖反序列化来传递对象。早期的修复方案只堵了T3协议那一层，攻击者一看T3进不去了，就转头去打IIOP，于是又出了CVE-2020-2555这一批新洞。这就是为什么反序列化在Weblogic上持续折腾了五六年——因为一个基础设施级的架构决定，导致修补永远是治标不治本。

理解这个原理之后，你就能明白两个关键点：第一，不是说打了补丁就万事大吉，历史补丁之间的绕过组合太多了；第二，反序列化漏洞危害级别全部是“远程代码执行”，也就是说攻击者一旦得手，就能在服务器上执行任意命令，这一步之后就等于服务器彻底沦陷了。

2.2 未授权访问与后台弱口令——被低估的“前门”

有一类漏洞经常被忽视，但实战中被利用的概率极高——管理控制台的未授权访问和弱口令。Weblogic默认开着一个管理后台，端口一般是7001，路径是/console。这个后台在默认配置下是可以公网访问的。更离谱的是，很多系统上线后根本没改默认密码。

如果你觉得“我们公司不会有人用弱口令挂在公网”，那我可以告诉你实测数据：我在做某次内部安全演练时，随便扫了一批公网IP，命中率能到百分之几。而一旦攻击者进入管理后台，后面的事情就很丝滑了——通过后台可以部署应用、修改配置、查看数据源信息，一条龙操作下来，和拿到服务器shell没有区别。

这类问题在安全圈里被叫做“低垂的果实”，因为攻击者不需要写任何复杂的利用代码，只需要一个浏览器和一份默认密码表就能装进来。配合某些版本的目录遍历漏洞，攻击者连密码都不需要猜，直接访问特定路径就能看到服务器上的敏感文件内容。这又是一种典型的“组合拳”打法：先用信息泄露拿到账密，再用后台功能完成入侵。

2.3 SSRF与信息泄露——攻击者的“情报兵”

远程代码执行固然严重，但更多时候攻击者第一步做的是侦察，这就要用到SSRF（服务端请求伪造）和信息泄露类漏洞。Weblogic的某些组件和服务在处理外部请求URL时，没有严格限制目标地址，导致服务器会帮攻击者去请求内网的其他地址。

想象这样一个场景：你们公司有一台Weblogic暴露在公网，内网里还有一台数据库服务器。数据库服务器没有公网地址，你觉得安全了对吧？但攻击者利用Weblogic的SSRF漏洞，让Weblogic这台主机去探测内网数据库的端口、去访问内网的管理页面。Weblogic成了一座桥，攻击者站在桥上把内网看得清清楚楚。这类漏洞本身不能直接“打死”服务器，但它是整个攻击链路里极其重要的一环。

信息泄露方面，Weblogic比较知名的有/console/css/路径下的目录遍历，以及某些错误页面回显的堆栈信息。前者可以下载服务器上的任意文件，包括配置文件、账密文件；后者会把Java内部的异常信息、类路径、部署结构暴露给攻击者。这些看起来“不是致命伤”的信息，在攻击者眼里全是下一步突破的线索。

2.4 管理后台的远程代码执行路径

这里必须要提醒运维人员正视一个现实：如果攻击者已经拿到了管理后台的权限，那么在任何版本上，他都可以找到一种方式执行命令或部署恶意代码。

在Weblogic后台里，有一个“部署应用程序”的功能。管理员可以上传一个打包好的应用，服务器会解压、部署并执行其中的代码。如果上传的是一个包含了恶意Java类或JSP后门的应用包，部署完成就等于把后门放进了你的生产环境。更隐蔽的做法是修改现有应用的配置，往配置里面夹带私有类。这些操作在后台日志里只显示为常规的部署、修改操作，很难引起注意。

所以我对所有运维人员只有一句话：把后台权限看得比服务器root权限还要重要。后台一旦沦陷，其他的防护措施都失去了意义。

3. 自查与检测实操——怎么知道自己有没有中招

3.1 第一步：先摸清自家的家底

很多运维问我怎么排查漏洞，我永远先反问一句：你先把版本告诉我。因为Weblogic的修复策略和版本直接挂钩，不懂版本就谈漏洞，全是空谈。

Weblogic版本的命名有个小门道。比较常见的有10.3.6、12.1.3、12.2.1、14.1.1这几条线。10.3.6是当年极其经典的一个长期支持版本，但是它的生命周期早就结束了，官方已经不再提供安全补丁。12.1.3在部分行业里还有存量，但也已经进入“建议升级”的状态。12.2.1往上算是近几年的主力版本，相对安全一些，前提是持续打补丁。

查看当前版本的方法很简单。登录管理后台，在主页面的“产品信息”里能看到完整版本号；也可以通过/console/about页面查看。更精确的做法是找到安装目录下的registry.xml文件，里面有一长串版本和补丁信息，记录得比后台更完整。我个人建议运维人员至少每个季度更新一次资产台账，把IP、端口、中间件版本、补丁号、负责人、业务归属这些信息整整齐齐登记好。没有台账，安全排查就是盲人摸象。

3.2 第二步：查看补丁安装情况

得到版本号之后，下一个问题就是这个版本打了哪些补丁。Weblogic的补丁命名有一套自己的规则，比如你会看到p33505814_122130_Generic这样的文件名，其中122130指的就是12.2.1.3版本。你在安装目录下执行opatch lsinventory命令，就能看到当前机器上已安装的全部补丁列表。

这里有个容易被忽略的点：Weblogic的补丁是分层的，某些补丁依赖前一个补丁，跳过依赖直接打新补丁会导致系统启动异常。所以在核对补丁时，一定要看官方补丁说明里的“前置补丁”要求。我在实际加固过程中就遇到过一台机器，对方拿了一个最新的安全补丁往上打，结果应用直接起不来了，最后排查发现是跳过了中间的两个依赖补丁。所以，打补丁这件事，看着简单，实际要按官方文档一步步来。

3.3 第三步：检查端口暴露面

漏洞能不能被利用，一个重要前提是端口能不能被访问到。Weblogic对外暴露的端口主要是7001（管理端口）和7002（SSL端口）。如果这两个端口直接被放出公网，那恭喜你，你已经站在了风口浪尖。

我建议的检查方式是：用一台公网机器，执行telnet 你的IP 7001，能通就说明管理端口暴露了。另一种更精细的方式是用端口扫描工具看端口指纹，判断端口背后的服务是什么。有些企业为了省事，用防火墙把7001放通给“所有人”，结果成了攻击者的突破口。

正确的姿势应该是：管理端口只允许办公网IP或跳板机IP访问，业务端口尽量用负载均衡器转发，不要在防火墙规则里直接暴露出中间件端口。所有云安全组规则、防火墙策略，至少每半年做一次完整复核，删除掉那些“不知道怎么用得上”的放通规则。

3.4 第四步：排查已有告警和日志

如果你的系统曾经被扫描或试探过，日志里一定会留下痕迹。Weblogic的访问日志默认在servers/AdminServer/logs/目录下，里面有access.log和AdminServer.log。重点搜索以下几类关键字：

• 包含JNDI的异常记录，可能是反序列化利用链触发失败的迹象
• 包含IIOP和weblogic开头的堆栈信息
• 包含IOException和Connection reset的大量记录，可能是端口扫描的特征
• 后台登录日志里同一个IP反复尝试失败的记录

我不建议靠人工一行行翻日志，工作量太大人也容易疲惫。直接用命令行工具把日志里的IP提取出来排序，先看访问次数最高的前十个IP，再逐个核查这些IP的开源威胁情报。这一轮排查下来，心里基本能有个底。

4. 修复与加固实战——怎么堵住这些窟窿

4.1 禁用有风险的通信协议

最常见也最有效的一招，是禁掉T3协议的默认端口。Weblogic的反序列化攻击大量走的是T3通道，尤其是老版本。虽然官方补丁修复了已知的利用链，但补丁永远只能针对“已知”的问题，未知的问题只能靠减少攻击面来应对。

具体操作上，在管理后台的“环境-服务器-AdminServer-协议”配置里，把IIOP和T3相关的协议取消勾选。如果业务必须使用这些协议，那就做一层“白名单”，只允许指定IP段发起的T3连接。这层白名单务必仔细配置，我在某个项目上见过一版把0.0.0.0/0都放进去的白名单策略，那跟没配一样。

注意：T3和IIOP协议不是Weblogic的全部通信方式，如果业务用的是HTTP/HTTPS对外提供服务，那么禁掉T3对正常业务影响很小。禁协议之前，最好先跟开发部门确认有没有应用依赖这些协议，避免一刀切之后业务不可用。

4.2 给管理后台加“三道锁”

第一道锁：修改默认端口。把7001改成其他端口，虽然不能阻止内行扫描器识别，但能过滤掉一批自动化扫描脚本。第二道锁：启用后台的锁定机制。Weblogic支持登录失败锁定策略，连续几次失败后锁定账号，这能有效对抗弱口令爆破。第三道锁：网络访问控制做得死死的。管理后台的访问源IP必须是固定办公网段，通过负载均衡或防火墙实现，不要用Weblogic自己的访问控制列表替代防火墙，因为防火墙的可靠性更高。

另外务必重新设置所有账号的密码，特别是weblogic这个默认管理账号。要求密码强度不少于12位，包含大小写字母、数字和特殊字符。安全配置这块不是给谁看的，而是给想进来的坏人看门的。

4.3 打补丁的优先级判断

“要不要把所有补丁都打了”这个问题，我的回答是：不需要全打，但要打到位。真正关键的修复补丁就那么几个，其他那些属于功能增强或者针对非核心模块的修复，可以等规划窗口统一处理。但金融、政务这些监管强相关的业务系统，还是建议把所有安全补丁按官方周期全部打齐，毕竟合规要求摆在那里。

打补丁之前一定先备份域目录和安装目录，在测试环境里完整过一遍启动、登录、业务接口连通性，确认没有回归问题之后再上生产。不要听信“补丁很小不会影响”这种说法——我有一次打一个几十KB的小补丁，结果导致集群会话复制直接失效，业务故障了几个小时，从那以后我再也不敢跳过测试环节。

4.4 部署Web应用防火墙

对于很多暂时无法升级版本、无法停机的老系统，部署一套WAF是能快速兜底的方案。市面上商业WAF和开源自建WAF都有，关键是要能把反序列化攻击特征和Webshell上传特征识别出来。配置WAF规则时，重点关注请求路径中是否包含_async、AsyncResponseService、_jsp等敏感标签，以及请求体里是否带上了Java反序列化的特征头——当然具体特征大家在防护规则库里都能找到现成的。

WAF不是银弹，它的检测也存在漏报和误报。更稳妥的做法是WAF和主机层安全软件搭配使用，主机层监控Java进程的异常行为，一旦出现执行系统命令、反弹shell、下载文件等可疑动作，及时拦截和告警。

4.5 升级替代方案

如果条件允许，我强烈建议逐步规划Weblogic的替代升级。不是说Weblogic一无是处，而是它的安全维护成本已经越来越高，而且老版本的生命周期已经走到尽头。往轻量级框架上迁移是大趋势，尤其是新系统、新业务，不要再往Weblogic上放了。存量系统的迁移可以分阶段做，先把边缘系统迁走，再把核心系统排队，三年到五年内完成整体退出。

迁移的过程中，Weblogic上常见的连接池、JMS消息队列、分布式事务这些能力，都有对应的替代实现，只是需要开发团队重新适配。这中间最容易被忽略的是那些“老程序员手工写的老代码”，它们对中间件特有API的依赖很深，迁移时的改造量比想象中大，必须提前做好代码评估和改造计划。

5. 常见问题与排查实录

5.1 打了最新补丁，是不是就安全了

不是。如果攻击面还是那样敞着——管理端口暴露、弱口令没改、T3协议没禁——那么即便没有已知漏洞可以打进来，后台弱口令和部署恶意应用这两条路依然存在。补丁解决的是已知问题，攻击面管理解决的是未知问题。两者是配套关系，不能互相替代。

5.2 生产环境不能重启，补丁怎么打

Weblogic打补丁通常需要重启服务生效，这对很多7x24小时业务来说很难接受。解决思路有几种：先在集群环境中做滚动升级，一台一台地重启，保证业务不中断；如果单机部署无法滚动，那就用WAF先顶着，等下一个计划维护窗口统一打补丁。但“不能重启”不能成为长期不打补丁的理由——这个问题是管理层需要拍板承担风险的，运维人员至少要尽到风险评估和上报的职责。

5.3 排查中发现服务器已经被入侵，先做什么

第一步不是删文件，而是断网。把服务器从网络里隔离出来，防止攻击者继续横向移动。第二步是冻结现场，保留内存快照和日志副本，这些证据后续会用到。第三步才是评估影响范围，查一下同一网段内还有哪些机器跟这台服务器有登录关系、数据交换关系。切忌不要急着格式化重装，那样反而会把证据毁掉，影响溯源。处理完问题之后，这套流程还要复盘，看入侵路径是什么、检测盲区在哪、后续怎么补监测能力。

5.4 常见告警日志怎么看

有些运维看到日志里出现了java.io.IOException: Connection reset by peer就紧张，其实这条日志大多数时候只是端口扫描后的正常响应，不代表攻击成功。真正需要警惕的是以下几种组合：

• 大量访问/console路径且User-Agent是脚本工具特征的请求，这是后台扫描
• 请求路径中夹带ClassName、ObjectInputStream这些反序列化特征词，这是反序列化利用试探
• 后台登录日志里短时间内多次失败，且来源IP变化，这是分布式爆破
• 访问了/console/css/%2e%2e/这类路径，这是目录遍历攻击

组合起来判断，单条日志没有明显意义，多个特征叠加在一起才需要进入应急响应流程。

5.5 弱口令自查怎么做得彻底

我见过最普遍的情况是运维改掉了weblogic账号的密码，但忽略了其他内置账号。Weblogic里有几个系统内置账号，比如system、operator，有的初始密码为空或者出厂默认值。自查的标准，是要把所有账号全部列出来生成一个清单，然后逐项检查密码策略是否满足要求。不要用复制粘贴的方式在多个系统里用同一个密码，一旦一个系统泄露，牵连就太大了。

我个人的建议是，Weblogic这类基础中间件的账号管理纳入统一身份管理体系，不要每个系统单独维护一套密码。密码文件不要存在安装目录下，更不要为了图省事把密码明文写在启动脚本里——这种问题在排查的时候见过太多次了。

6. 后续还能做些什么

Weblogic的安全加固，说穿了就四个字：收敛面、堵漏洞、看日志、快响应。但如果你问我哪一步最重要，我还是会说先把资产台账建起来。我见过太多企业倒在了排查第一步，不是因为没有工具，而是因为根本不知道自己的服务器里有哪些东西。技术门槛反而没那么高，难的是把基础管理工作扎实落地，这比任何零日漏洞都值得重视。

最后再分享一个实操中的个人经验：我给系统做完Weblogic加固之后，一定会做一次完整的验证测试——用自己的测试工具模拟常见的攻击流量打一遍，看看加固之后是不是真的挡得住。测试完再去后台确认一次日志，把攻击记录留存下来。这个动作叫“验证加固有效性”，很多人忽略了它，结果加固措施部署完才发现配置有误、规则没生效，等于白干。安全没有“差不多就行”这个说法，多花半天时间验证，好过事后花几天时间应急。