子站点漏洞防护避免主站遭受连锁攻击

子站点被攻破后拖垮整个主站，这类事件在近两年明显增多。很多运维把精力全放在主站防护上，却把子站当成“边缘资产”，结果攻击者根本不碰主站，而是从子站植入代码、窃取数据库、横向渗透，最后通过内网或共享权限直接打进主站核心系统。要解决这个问题，必须先把子站和主站的关系从“信任”改成“隔离”，再从部署架构、权限控制、代码审计和实时监控四个层面做硬性切割。

攻击者很少一开始就正面突破主站。子站往往使用老旧CMS、长期不更新的插件、测试功能或外包开发留下的后门，这些薄弱点极易被自动化扫描工具发现。一旦拿到子站Webshell，攻击者会先收集配置文件，里面通常写着数据库账号、缓存服务地址、对象存储密钥，甚至主站后台API调用凭证。如果子站和主站共用同一套数据库账号，或者子站服务器能直接访问主站内网网段，攻击者就能在短时间内从子站跳到主站数据库、文件服务器或内部管理后台。另一种常见情况是子站和主站部署在同一台物理机或同一组容器集群里，子站被植入挖矿或DDoS木马后，CPU、内存、带宽被耗尽，主站即使没被入侵也会因资源争抢而瘫痪。

子站和主站最忌讳部署在同一台服务器、同一个容器Pod或同一个虚拟主机账号下。正确的做法是给每个子站独立分配虚拟机或容器，并划分到不同的网络区域。如果条件允许，子站应放在独立的VPC或至少独立的子网中，通过防火墙规则限制子站与主站之间的访问。主站所在的网段默认拒绝来自子站网段的所有入站流量，只有明确需要同步数据的接口才放行特定端口和IP。对于使用云服务的团队，可以为子站单独创建云账号或子账号，避免共享同一组访问密钥。子站域名解析也要独立管理，不要和主站共用同一个DNS控制台权限，否则攻击者篡改子站DNS记录后可能利用泛解析或CNAME指向主站进行钓鱼。

子站被入侵后泄露数据库凭证是最常见的横向渗透起点。因此子站数据库账号必须与主站完全独立，且权限最小化。子站账号只授予自身库的增删改查权限，禁止拥有跨库查询、文件读写、执行系统命令等高级权限。主站数据库账号同样不应出现在子站配置文件中。如果业务上确实需要子站读取主站某些数据，应该通过独立的API接口进行，接口只返回必要字段，并做频率限制和签名校验，而不是让子站直连主站数据库。缓存服务、消息队列、对象存储也要按子站维度拆分Bucket或命名空间，避免一个子站被攻破后读取到主站的缓存键或上传文件。

大量子站被攻破的入口是过期组件和自研代码漏洞。子站使用的CMS、框架、插件必须纳入统一资产管理，定期扫描版本漏洞。对于已经停止维护的子站，要么下线，要么用反向代理将其静态化，只保留展示功能，去掉所有表单、登录、搜索等动态交互点。自研代码上线前要做基础安全扫描，至少覆盖SQL注入、命令执行、文件上传、越权访问四类高危问题。子站后台管理地址不要使用常见路径，例如/admin、/manage、/system，并强制启用双因素认证。后台登录接口要限制来源IP，只允许办公网或堡垒机访问。文件上传目录必须禁止执行脚本权限，上传文件统一存储到独立对象存储或独立目录，与代码运行目录物理分开。

子站同样需要接入Web应用防火墙，规则可以比主站更严格，因为子站业务逻辑通常更简单，误伤率低。针对子站的访问日志要单独采集，重点监控Webshell特征、异常POST请求、短时间内大量扫描行为、数据库错误回显等。一旦检测到子站有异常文件写入或可疑进程启动，应立即触发告警并自动隔离该子站所在容器或虚拟机，阻断其与内网其他资源的通信。监控系统要覆盖子站的资源使用率，如果某个子站突然CPU飙高或外联流量异常，大概率已被植入恶意程序。对于子站与主站之间的API调用，要记录完整日志并设置基线，偏离基线的调用模式需要人工复核。

发现子站被入侵后，第一动作不是删除Webshell，而是先切断子站与主站之间的网络通路。如果子站和主站在同一网段，立刻在防火墙上阻断子站IP访问主站网段；如果共用数据库账号，立即禁用该账号并检查主站数据库是否有异常查询记录。确认隔离完成后，再对子站做取证和清理。清理时不要直接在原环境修补，应该用干净镜像重建子站环境，并从备份中恢复数据，因为攻击者可能已经植入多处后门或修改了系统计划任务。恢复上线前要重新审计子站代码和配置，确认没有残留的恶意账号、SSH密钥或定时任务。

很多子站是活动页、临时推广页或外包项目遗留产物，上线后无人维护，最终变成安全隐患。企业应建立子站资产台账，明确每个子站的负责人、技术栈、部署位置和下线时间。活动类子站到期自动关闭，长期不更新的子站每季度复查一次。对于必须保留但技术栈陈旧的子站，考虑用静态化方案替代动态程序，或者将其迁移到与主站完全隔离的低权限环境中。安全团队应定期从外部视角对子站做渗透测试，模拟攻击者从子站突破后能拿到什么、能跳到哪，用实际结果倒逼隔离策略落地。

子站防护的核心不是给每个子站堆更多安全设备，而是从架构上默认不信任子站。子站被攻破是大概率事件，但只要网络、凭证、权限、监控四层隔离做到位，攻击者即使拿下子站也只能停留在一个低价值孤岛上，无法触达主站核心资产。这种“假设子站必被攻破”的思路，比事后修补更能有效避免连锁攻击。