子站点漏洞排查防护避免主站受影响

子站点和主站共用服务器、同一IP段甚至同一个后台管理系统时，一旦子站被攻破，攻击者往往能通过横向渗透直接威胁主站数据、篡改首页内容或在整台服务器植入后门。很多运维把精力全放在主站防护上，子站却长期不更新、不审计，最终成为整个站群体系中最薄弱的入口。排查子站漏洞不能只做表面扫描，必须从权限隔离、代码审计、运行环境、文件系统、数据库连接和日志监控六个层面同时推进。

最危险的情况是子站和主站使用同一个FTP账号、同一个数据库账号或同一个服务器管理员权限。攻击者只要拿到子站后台密码，就能直接浏览主站目录、导出主站数据库。排查时先检查子站程序所持有的系统账号权限范围：FTP账号是否被限制在子站目录内，数据库账号是否只授权给子站对应的库，服务器登录账号是否属于普通用户组而非管理员组。如果发现子站账号能向上级目录写入文件，必须立即收回权限。对于必须共用的资源，采用单独的只读账号，并禁止跨目录访问。

大量子站使用开源CMS或老旧框架搭建，漏洞公开后长期不修复。优先排查几类最容易被利用的问题：文件上传点是否校验了文件类型和内容，而不是只检查扩展名；后台登录接口是否存在弱口令或验证码可绕过；模板文件、缓存目录是否允许直接执行PHP、JSP或ASP脚本；远程包含、SQL注入和越权访问是否在参数过滤层有统一防护。对于已经停止维护的子站程序，不要试图修补单个漏洞，直接下线或迁移到静态化版本更安全。

子站目录内不应允许执行与业务无关的脚本类型。如果子站只提供静态内容，就把PHP、Python、Node等动态解析全部关闭。如果必须运行动态程序，在Web服务器配置中对该虚拟主机单独设置open_basedir或等效的目录限制，禁止脚本访问/tmp、/var、主站目录以及其他用户目录。同时禁用高危PHP函数，如exec、system、passthru、shell_exec、proc_open、popen、eval、assert等。子站运行的用户身份应与主站完全分离，使用独立的系统用户和独立的进程池。

攻击者入侵子站后，通常会留下WebShell、反弹脚本或篡改过的配置文件。排查时不能只看最近修改时间，因为很多后门会伪造时间戳。需要对比程序原始文件哈希值，找出多出来或内容被改动的文件。重点检查目录：上传目录、缓存目录、模板目录、插件目录、字体目录和后台静态资源目录。对于图片文件夹中出现.php、.jsp、.asp、.phtml、.shtml等扩展名的文件要格外警惕。还要检查.htaccess、web.config、nginx配置文件是否被加入了恶意跳转、代理或伪静态规则。

# 示例：查找子站目录中所有可执行脚本文件
find /www/subsite -type f \( -name "*.php" -o -name "*.phtml" -o -name "*.php5" -o -name "*.jsp" -o -name "*.asp" \) -print

# 示例：查找最近3天内被修改过的文件
find /www/subsite -type f -mtime -3 -print

# 示例：查找包含常见后门关键字的文件
grep -rl -E "eval\(|base64_decode|shell_exec|system\(" /www/subsite --include="*.php"

子站数据库被拖库后，如果主站与子站共享同一数据库实例甚至同一张用户表，主站用户数据会直接暴露。排查时确认子站数据库账号是否拥有对其他库的访问权限，是否允许跨库查询。子站与主站之间的数据交互应通过独立API接口进行，而不是直接读写对方数据库。对于子站存储的用户密码、支付信息或后台令牌，检查是否使用了弱加密或明文存储。如果子站曾经被入侵，即使漏洞已修复，也要强制重置该子站所有用户凭证，并检查主站是否有异常登录记录。

子站后台地址如果使用常见路径如/admin、/manage、/system，很容易被扫描器批量爆破。将后台入口改为随机字符串路径，并限制访问来源IP，只允许公司内网或指定办公网络访问。如果子站后台必须对外开放，至少启用双因素认证和登录失败锁定策略。同时排查子站引用的第三方JS、CSS、字体、统计代码和广告脚本，这些外部资源一旦被劫持，会直接在主站用户浏览器中执行恶意代码。第三方服务账号如短信接口、支付回调、云存储密钥等，应使用最小权限的子账号，并定期轮换密钥。

漏洞排查不能只做一次，子站随时可能因为新公开的漏洞再次被攻破。部署文件完整性监控，对子站核心目录的增删改操作实时告警。监控子站进程是否出现异常外联、异常CPU占用或大量发送邮件的行为。在Web服务器层面为子站设置独立的访问日志和错误日志，定期分析异常POST请求、异常User-Agent和暴力登录尝试。一旦确认子站被入侵，第一时间将子站目录重命名或修改虚拟主机配置使其返回503，切断其与主站的网络通信，而不是只删除后门文件继续运行。

长期来看，最稳妥的方案是将子站与主站物理隔离。子站可以部署在独立的云服务器、独立容器或独立虚拟主机上，使用不同的IP地址和不同的域名解析。如果业务上必须共用域名，通过反向代理将子站请求转发到独立后端，主站服务器不存放任何子站文件。对于已经不再维护的旧子站，直接迁移到静态托管服务或归档为纯HTML页面，彻底消除动态脚本攻击面。每次新增子站时，把安全基线作为上线强制条件：独立账号、最小权限、禁用危险函数、强制HTTPS、后台访问控制和日志监控缺一不可。

子站防护的核心不是给每个子站堆砌安全设备，而是默认所有子站都可能被攻破，在此基础上做好权限隔离和快速切断。只要子站无法触达主站文件、数据库和系统权限，即使被拿下也只是一台孤立的肉鸡，不会演变成整站群的数据泄露事故。排查工作要落实到具体账号权限、具体目录限制和具体监控规则上，而不是停留在扫描报告层面。