企业官网建设流程全解析

1. 项目概述：一次典型的内部网络安全事件

那天下午，监控平台的告警突然亮起，不是那种常规的扫描告警，而是一条关于某个内部业务系统存在可疑POST请求的日志。系统本身部署在内网，不直接对外暴露，也就是我们常说的“不出网”环境。这种环境下的安全事件，往往更棘手，因为攻击链可能更隐蔽，危害也可能更大。作为安全团队的成员，我第一时间被拉进了应急响应小组。初步排查，目标系统是一个基于Java开发的Web服务，大量使用了Fastjson进行数据序列化与反序列化。结合告警的上下文和近期漏洞情报，一个词立刻浮现在脑海：Fastjson反序列化漏洞。接下来的几个小时，就是一场与时间赛跑的“破案”过程，核心线索不是系统日志，而是网络流量。这篇文章，我就来复盘一下，如何在没有直接外联证据（不出网）的情况下，通过深度分析流量特征，一步步锁定并证实了这次Fastjson漏洞攻击，希望能给面临类似场景的同行一些参考。

2. 应急响应的核心思路与前期研判

面对一个不出网环境的安全告警，常规的“看外联IP、查外发流量”思路行不通。我们的战场被限定在了内部网络。但这并不意味着无计可施，恰恰相反，内网流量往往保留了更原始、更完整的攻击痕迹，因为攻击者通常认为这里“更安全”，会放松警惕。我的核心思路很明确：将攻击行为视为一个“黑盒”输入，而我们的应用和网络就是“传感器”，通过分析这个“黑盒”输入在“传感器”上引发的异常波动，来反推攻击的本质。

2.1 环境隔离与初步信息收集

接到告警后，第一步不是直奔服务器，而是建立信息隔离区。我立即联系了系统负责人和网络团队，做了三件事：

1. 流量镜像：在核心交换机上，对目标服务器的业务网卡入口流量进行全量镜像，保存到独立的分析平台。这是后续所有分析的基石，必须保证流量的完整性和原始性。
2. 系统快照：在确保业务可接受的前提下（当时是非高峰时段），对服务器的内存、关键进程列表、网络连接状态进行了快照保存。对于Java应用，特别关注了jstack（线程栈）和jmap -histo（对象直方图）的输出。
3. 日志拉取：收集了应用日志（如Log4j2）、中间件日志（Tomcat access/error log）、系统日志（/var/log/messages）以及任何现有的安全设备（如WAF、IDS）的告警日志。

注意：在应急初期，切忌直接登录服务器进行“大刀阔斧”的查杀或重启。这可能会破坏现场证据（如内存马、进程信息），让攻击溯源变得困难。我们的原则是“先取证，后处置”。

2.2 基于告警的假设驱动分析

告警信息显示，可疑请求的URL路径是一个正常的业务API接口，但Payload部分异常。这立刻指向了两种可能：1. 业务逻辑漏洞（如越权、注入）；2. 通用组件漏洞（如反序列化）。结合该系统大量使用Fastjson处理JSON请求的背景，以及近期Fastjson 1.2.80及以下版本反序列化漏洞（CVE-2022-25845等）的威胁情报，我初步将调查重心放在了Fastjson漏洞上。

这个假设成为了后续分析的“导航仪”。我需要从海量的流量数据中，寻找能验证或推翻这个假设的证据。不出网环境下的攻击，攻击者目标通常是：植入内存马、窃取内网敏感数据、作为横向移动的跳板。因此，流量特征会围绕“漏洞利用”、“后门通信”、“内网探测”这几个阶段展开。

3. 关键流量特征解析与攻击链还原

有了镜像流量，我使用Wireshark和Zeek（原名Bro）结合自研脚本进行深度分析。不出网流量的分析，关键在于识别“异常”而非“恶意”。因为所有流量源IP都是内网地址，传统IP信誉库失效。以下是我锁定的几个关键特征及其分析过程。

3.1 Fastjson漏洞利用流量的“指纹”

Fastjson反序列化漏洞的利用，其流量特征在HTTP层有比较明显的印记。我在筛选出的可疑时间段的HTTP请求中，发现了以下共性：

1. @type属性指向非常规类：这是Fastjson反序列化的核心特征。攻击者通过@type指定一个目标类，Fastjson会尝试实例化并调用其setter或getter方法。在攻击流量中，我看到了诸如com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl、org.apache.tomcat.dbcp.dbcp2.BasicDataSource这类明显不属于业务逻辑的类名。这些是公开漏洞利用（PoC）中常用的类，用于构造利用链。

   { "@type": "com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl", "_bytecodes": ["yv66vgAAADQA...（base64编码的恶意字节码）"], "_name": "a.b", "_tfactory": {}, "_outputProperties": {} }

   为什么这是关键证据？正常的业务JSON数据，@type（如果使用）指向的应该是业务DTO（Data Transfer Object）类，如com.xxx.service.dto.UserDTO。出现Java标准库或第三方库中的特定类，且包含_bytecodes等敏感字段，基本可以断定是攻击行为。

2. POST数据体结构异常：正常的业务JSON结构相对规整，字段名有业务含义。而攻击Payload为了满足反序列化链的调用条件，结构往往嵌套复杂，会出现大量空对象{}、空数组[]，以及像_outputProperties、_name这类具有特定含义的属性名。通过编写简单的脚本统计JSON的嵌套深度和特定关键词出现频率，可以快速筛选出异常请求。

3. Content-Type与数据体不匹配的“伪装”：部分攻击流量试图伪装。虽然POST请求的Content-Type标头是application/json，但数据体开头却可能包含无关字符或尝试进行编码混淆。不过，在本次事件中，攻击流量相对“原始”，没有做深度混淆。

3.2 漏洞利用成功后的“后门”流量特征

如果Fastjson漏洞利用成功，攻击者下一步通常是在内存中植入Webshell（内存马）或执行系统命令。由于不出网，命令执行结果或Webshell的通信都会在内部网络产生流量。我发现了紧随漏洞利用请求之后的一些异常会话：

1. “冰蝎”型Webshell通信特征：这是内网渗透中最常见的工具之一。其流量特征较为明显：

   • 静态路径，动态参数：存在对某一个特定URL路径（如/upload、/static/xx.jsp）的频繁POST请求，每次请求的URL完全相同，但参数（如pass、c）的值是加密且变化的。这与正常用户访问或API调用模式不符。
   • 固定的HTTP头部：“冰蝎”3.0以后版本，虽然加密能力增强，但其请求头中的Accept、Accept-Language、Accept-Encoding等字段的值长度固定，且每次请求几乎一模一样。正常浏览器的这些头部会因请求内容稍有差异。通过Zeek脚本提取同一源IP的请求头进行对比，很容易发现这种“机器式”的规律性。
   • Content-Type: application/octet-stream：这是“冰蝎”上传文件或执行特定操作时的一个特征。正常的Web应用很少使用这个Content-Type来传输业务数据。

2. “哥斯拉”型Webshell通信特征：另一个常用工具，其特征点有所不同：

   • Cookie尾部异常分号：在部分版本中，哥斯拉Webshell连接的请求Cookie字段，最后一个键值对后面会多一个分号，如Cookie: key1=value1; key2=value2;。而标准HTTP和浏览器实现，最后一个键值对后不应有分号。这是一个非常细微但有效的特征。
   • 长连接保持：为了维持Shell会话，哥斯拉会设置Connection: keep-alive并保持较长时间的TCP连接，与同一内网IP进行多次高频、短间隔的请求-响应交互，模拟“心跳”或持续操作。

3. 命令执行回显的流量模式：攻击者可能不植入Webshell，而是直接通过漏洞执行系统命令（如whoami、ipconfig /all、net user）。其流量特征表现为：

   • 请求与响应的不对称性：一个简短的POST请求（携带了编码后的命令），却收到了一个较长的HTTP响应体。这个响应体内容通常是命令执行结果的输出，经过Base64或URL编码。
   • 响应内容包含系统信息：通过解码响应内容，发现了Windows系统命令行输出的典型格式（如C:\Users\>提示符、中文乱码等），直接证实了系统命令已被执行。

实操心得：在分析这些后门流量时，不要只盯着单个数据包。要建立“会话”（Conversation）视角，在Wireshark中跟踪完整的TCP流（Follow TCP Stream）。这样你能看到一次交互的完整明文（或加密前的原始数据），对于识别加密Webshell的固定头部、尾部特征非常有帮助。例如，冰蝎的流量在TCP流视图下，往往能看到请求体中存在固定的“魔术字节”或结构。

3.3 横向移动与内网探测的痕迹

攻击者进入一台内网机器后，绝不会满足于此。我通过分析该服务器作为客户端向外发起的连接，发现了横向移动的迹象：

1. 对内网端口的扫描：从受害服务器上发现了向大量内网IP的445（SMB）、3389（RDP）、22（SSH）、6379（Redis）等端口的SYN连接尝试。这些连接很多是“半开连接”（SYN_SENT），说明目标端口未开放。这种由内网一台服务器发起的、针对其他内网服务的端口扫描行为，是典型的横向移动前期侦查。
2. 异常协议连接尝试：发现了向其他服务器1433（MSSQL）、3306（MySQL）端口的连接，并伴随有类似SQL语句的TCP载荷。这可能是攻击者在尝试数据库弱口令爆破或利用数据库漏洞。
3. SMB、RDP协议通信：发现了与个别内网主机成功的445端口通信，流量中携带了NTLM认证相关数据。这极有可能是攻击者在尝试传递哈希（Pass-the-Hash）或利用永恒之蓝（EternalBlue）类漏洞进行横向扩散。

如何关联？这里的关键时间线。端口扫描和异常连接请求，都发生在首次Fastjson攻击流量之后几分钟内。这就构成了一个完整的攻击链闭环：外部攻击者通过某种方式（可能是鱼叉邮件、水坑攻击导致的内网用户中招，再由该主机作为跳板）向内网目标服务器发送Fastjson恶意Payload → 利用成功，在服务器上执行命令或植入Webshell → 通过该Webshell作为据点，发起对内网其他主机的扫描和攻击尝试。

4. 深度流量取证与攻击者画像勾勒

仅仅知道被攻击了还不够，应急响应的目标是“抑制、根除、恢复、总结”。通过深度流量分析，我们可以勾勒出攻击者的行为画像，为根除隐患提供精准方向。

4.1 攻击载荷（Payload）解码与工具识别

我将捕获到的Fastjson攻击Payload中的_bytecodes字段（Base64编码）提取出来，进行解码。解码后得到的是一个Java类文件的字节码。通过使用javap -c反汇编，或者直接使用一些在线Java字节码分析工具，可以大致看出这个类的功能。在我分析的案例中，该字节码是一个简单的类，其静态代码块（static{}）中包含了一段通过Runtime.getRuntime().exec()执行系统命令的代码，命令是下载一个远程脚本并执行。

进一步，我分析了该下载命令指向的内网地址（另一个已被攻陷的肉鸡），并从其流量中发现了与公开的“哥斯拉”管理端通信的特征。由此可以推断，攻击者使用的可能是公开的Fastjson漏洞利用工具（如JNDI注入攻击工具），配合哥斯拉进行后续控制。工具链的相对固定，也说明攻击者可能并非高级APT组织，而是利用现成工具的常规黑产或脚本小子。

4.2 攻击路径与入口点推测

这是不出网应急中最难也是最重要的一环。服务器本身不对外，攻击流量从何而来？我通过以下步骤进行推测：

1. 溯源攻击源IP：所有攻击流量的源IP都是一个内网地址（假设为10.1.2.100）。这显然不是最终攻击者，而是一个“跳板机”。
2. 分析跳板机：立刻协调网络团队，获取10.1.2.100主机的信息。发现这是一台运维人员的办公电脑。检查该电脑在攻击时间前后的网络连接和进程历史（通过EDR终端记录），发现其浏览器曾访问过一个被标记为“钓鱼”的外部网址，随后该主机上出现了异常的Java进程网络活动。
3. 还原攻击路径：综合所有信息，最可能的攻击路径是：运维人员办公电脑（10.1.2.100）访问钓鱼网站 → 网站利用浏览器漏洞或诱导下载，在其电脑上植入了一个木马或劫持了浏览器 → 该木马以办公电脑为跳板，对内网服务器（目标）发起了Fastjson漏洞攻击。攻击者利用了内部人员的主机作为“桥头堡”，绕过了网络边界防护。

4.3 影响范围评估

通过分析受害服务器（已沦陷）向外发起的扫描流量，我整理出了一份“潜在感染清单”：

• 直接扫描目标：列出了所有被扫描的IP和端口。
• 成功建立连接的主机：特别是那些有SMB、RDP等成功会话的主机，需要立即进行隔离和检查。
• 内部敏感系统：扫描列表中包含了数据库服务器、版本控制服务器（Git）、文件共享服务器等。这些系统一旦被攻破，后果严重。

这份清单成为了后续“抑制”阶段的关键输入，安全团队据此迅速开展了内网隔离和排查工作。

5. 应急处置措施与长效加固建议

基于流量分析得出的结论，我们迅速采取了行动。

5.1 立即处置（抑制与根除）

1. 隔离网络：立即在防火墙上切断了受害服务器（10.1.2.200）和跳板机（10.1.2.100）与内网的所有非必要通信，只保留管理通道。
2. 清除后门：
   • 对受害服务器，由于发现了内存马特征，我们选择了最彻底的方式：备份业务数据后，直接下线该实例。在隔离环境中对磁盘镜像进行取证分析，确认Webshell文件位置和攻击者创建的后门账户，然后使用干净的镜像重新部署应用。
   • 严禁直接重启：在确认内存马存在的情况下，重启会导致内存马消失，但磁盘上的后门文件可能被设置为持久化（如写入计划任务、服务），重启后会被重新加载。必须先清理文件层面的后门。
3. 排查跳板机：对运维人员的电脑进行全盘杀毒、恶意进程清理，并重置了密码。检查了浏览历史、下载记录和启动项。
4. 扫描潜在目标：根据“潜在感染清单”，对其他被扫描的主机进行漏洞扫描和日志审查，确认是否已被渗透。

5.2 漏洞修复与配置加固

1. 升级与修复：将业务系统使用的Fastjson组件紧急升级到最新安全版本（当时是1.2.83或更高），并确保开启了SafeMode或使用了官方推荐的安全配置（如指定反序列化白名单）。

   // 使用SafeMode是最根本的解决方案 ParserConfig.getGlobalInstance().setSafeMode(true);

2. 网络层面：
   • 细化网络分区：强化VLAN和防火墙策略，遵循最小权限原则。即使在内网，Web服务器也不应能直接访问数据库服务器的管理端口、运维区的SSH端口等。
   • 部署内部IDS/IPS：在核心交换节点部署网络入侵检测/防御系统，配置规则检测Fastjson攻击特征、冰蝎/哥斯拉流量特征、横向移动扫描行为等。
   • 出站流量管控：虽然是不出网服务器，但仍需严格限制其主动向外发起的连接，仅允许访问必要的更新源或依赖服务。
3. 主机与应用层面：
   • 强化EDR部署：确保所有服务器和终端安装有效的终端检测与响应系统，能够检测异常进程、网络连接和文件操作。
   • 日志集中与审计：将所有服务器、中间件、数据库的日志集中收集到SIEM（安全信息与事件管理）平台。针对Fastjson，可以监控日志中是否出现@type属性为非法类的告警。
   • WAF规则更新：在内部的WAF或应用网关设备上，更新规则集，添加对已知Fastjson漏洞攻击Payload的检测和拦截。

5.3 监控与预警优化

本次事件暴露了原有监控的不足。我们后续优化了：

1. 异常流量建模：基于此次攻击的流量特征，建立了内部异常流量基线模型。例如，监控同一内网IP对特定服务端口（如445）的扫描行为；监控HTTP请求中Content-Type: application/octet-stream但URL并非文件上传接口的情况。
2. 威胁情报集成：订阅了Fastjson等相关组件的漏洞情报feed，一旦有新的漏洞或PoC公开，能第一时间在流量和日志层面添加检测规则。
3. 演练常态化：定期组织内部红蓝对抗演练，模拟不出网环境的渗透攻击，检验安全监测和应急响应流程的有效性。

6. 总结与反思：不出网应急的“道”与“术”

这次应急响应让我深刻体会到，对于不出网环境，流量分析是“眼睛”，而正确的安全架构和运维习惯是“免疫系统”。

“术”的层面，要熟练掌握各类攻击工具的流量特征。这需要持续学习，建立自己的知识库。例如，不仅要记得“冰蝎的Accept头长度固定”，还要理解为什么它要这么做（为了绕过基于流量行为异常的检测）。分析时，要结合多种特征进行综合判断，避免单一特征误报。

“道”的层面，必须坚持几条铁律：

1. 假设 breach（假设已被攻破）：不要幻想内网是绝对安全的。零信任架构的理念至关重要，任何访问请求都必须经过验证和授权。
2. 纵深防御：在网络、主机、应用、数据各个层面都部署防护和检测措施。即使攻击者突破了一层，下一层也能提供缓冲和告警。
3. 最小权限：无论是服务器间的访问，还是人员的账号权限，都必须遵循最小化原则。本次事件中，如果运维电脑没有直接访问生产服务器的权限，攻击链就可能中断。
4. 持续监控与响应：安全运营（SecOps）不是一次性的项目，而是持续的过程。需要建立7x24小时的监控和响应能力，对告警进行闭环处理。

最后，我想说，一次成功的应急响应，技术分析只占一半，另一半是高效的团队协作、清晰的沟通和规范的流程。从网络团队提供流量镜像，到系统团队配合下线机器，再到业务团队理解风险接受短暂的业务中断，每一个环节都不可或缺。把这次复盘写下来，既是对自己工作的总结，也希望能成为一个可供参考的案例。安全之路，道阻且长，唯有多看、多练、多思考，才能在与攻击者的对抗中，多一分胜算。