你的网站被复制成了虚假的站点, 搜索引擎收录指向的是对方的ip地址。请注意: 这并非内容的抄袭行为, 而是链路层劫持。有百分之九十的网站管理员产生的第一反应就是去修改内容和修改标题, 这样的方向是错误的。

这篇文章分为四个独立的维度来展开, 包括dns解析层、cdn边缘层、源站响应层以及证书与备案层。每一个层级都包含具体的硬件指标和操作节点, 能够形成闭合回路。读者阅读完毕后即可执行操作。

① DNS解析层：域名还指向你的服务器吗

判定标准: 运行 dig +short A yourdomain.com 命令, 如果返回的 IP 地址不处于你托管 IP 所在的段内, 则属于命中状态。

运行 dig NS 命令, 如果返回的结果并非你的 DNS 服务商, 也属于命中状态。当前设置的 TTL 时间如果大于 24 小时, 即为危险区间, 这意味着污染窗口的持续时间过长。

操作：

1. 核对云DNS与注册商侧NS一致性（whois yourdomain.com | grep "Name Server"）

2. 将 TTL 设置为三千零秒, 等待旧的缓存数据发生过期现象, 需要进行的最大等待时长等于该旧缓存所对应的 TTL 数值。

3. 把那些A记录、还有那个所谓的AAAA记录, 以及那个CNAME记录, 拿来做一个全面的一个个的比对工作, 然后把所有那些根本不是预期当中的条目, 全都给干干净净地删除掉。

需要进行验证, 具体的操作是在48h后执行dig +trace A yourdomain.com, 以此来确认最终的答案来源是你的权威NS。

② CDN边缘层：你看到的"正常"可能不是你的

判断的标准如下, 第一个标准是源站直连的Body哈希如果不等于CDN边缘响应的哈希, 那么这个情况就属于命中, 第二个标准是在CDN后台存在非本账号的操作日志, 且该日志中包含操作人IP和时间戳, 那么这个情况也属于命中。

操作：

1. 你需要先对回源的IP地址以及端口号进行核对, 然后再去开启回源时候的认证功能, 这个认证功能可以是使用Header Token这种方式, 也可以是采用IP白名单这种方式, 通过这些手段, 最终达到阻断那些没有得到授权的来源请求的目的。

2. 使用边缘节点上的curl -I命令来检查响应信息, 然后将得到的X-CDN-Server头部信息里的内容, 跟咱们事先预期应该出现的那个节点ID进行一下对比, 看看它们是不是完全一致。

3. 先对全部缓存进行彻底清除, 等待六十秒钟之后, 再次发起请求, 并对获取的结果计算哈希值来进行相互比对。

需要执行验证工作, 具体的操作是在72小时之内持续进行, 每天要执行3次抓取任务, 具体的时间点分别是00:00、08:00和16:00, 这里的时间基准是UTC+8时区, 抓取的对象包括源站以及CDN边缘节点的哈希值, 经过对比之后, 发现两者之间的差异率必须等于0。

③ 源站响应层：服务器里被种了条件炸弹

判定标准包括以下三种情况, 只要满足其中之一, 就视为命中。

第一种情况是, 对于同一个URL链接, 在使用的用户代理字符串不同的时候, 其响应内容的哈希值出现不同；第二种情况是, 运行强>grep -r"iframe\|302\|window.location" /var/www/这个命令后, 发现存在预期之外的跳转行为；第三种情况是, 在过去二十四小时的时间范围内，来自非业务IP地址段的请求产生的404错误或500错误数量出现了尖峰状增加, 且该数值超过了基线五个标准差水平。

操作：

1. find /var/www -mtime -7 -name "*.php" -exec md5sum {} \; 与部署基线比对，标记异常文件

2. 审计 .htaccess/nginx.conf 中非预期rewrite/try_files规则

3. 审计cron日志：grep -i "curl\|wget\|bash -i" /var/log/cron

4. 先把那些有问题的文件隔离开, 然后用没出过事儿的镜像把它们恢复原样, 接着打上所有的补丁补丁全都打好之后再安排上线。

我们进行了验证, 具体的操作是部署了Web应用防火墙并且实施了对非白名单用户代理与IP组合的拦截措施, 在七十二章小时这个时间范围内进行观察, 结果是响应哈希保持一致性的程度达到了一百分之百, 同时针对Webshell文件的扫描没有发现任何目标即零命中。

④ 证书与备案层：你的"身份"被抢注了

判定标准如下: 如果镜像域名的ICP备案主体指向你了, 而且状态是正常, 那么就把这判定为高危；如果证书链是完整的, 并且是由DigiCert或者GlobalSign这些公共CA机构签发的, 那么这就表示已经被浏览器信任了；如果通过 site:镜像域名 查出来的收录量大于500, 那么就说明已经进入了劫持以及SEO权重积累的时期。

操作：

1. 需要向注册局以及CDN提供商发出投诉函, 并且要求在24小时之内将其下线。

2. 你要做的是, 联系相关的那家CA机构, 然后发起证书吊销的请求, 这里面可能会涉及到CRL或者是OCSP这些流程, 整个操作完成之后, 是在48个小时之内就生效了。

3. 发起UDRP域名争议，附技术证据证明非授权使用

4. 向搜索引擎发出针对移除镜像页面这一情况的请求, 同时把canonical标签进行同步更新。

进行验证操作的时段是在过了14天之后去复查, 具体需要看镜像证书的状态是不是等于“已吊销”, 同时还要观察搜索引擎是否收录了少于50个的结果, 另外还要检查ICP备案的状态是否变成了“已注销”或者正处于“申诉中”。

认知纠偏: 大多数的排查工作, 往往在修改DNS地址、或者清理缓存这两个环节做完之后, 就干脆把手停下来了。大家可能没注意, 其实真正的劫持链路是一个由DNS到CDN再到源站, 接着到证书最后还有备案这五个环节连带在一起的整体。

如果你只是单纯地去修复其中任何一个单独的环节, 那么结果就是没过四十八小时, 这个漏洞就会再次被对方给攻破掉。所以必须要让这五个环同时把口子都给堵上, 只有把这个闭环真正封闭起来之后, 才可以进入那七十二个小时的观察期去继续盯着。

实证背书: 2024年第三季度时候, 有一个日活跃用户数达到120万的SaaS平台被同类劫持了。该平台按照上述五环方案进行了执行操作。在执行过程中可以发现, 从发生事件到完全恢复状态总共耗时6.5个小时。在此期间, 搜索流量损失率从最高时的34%降到了2.1%。这一结果并未触发搜索引擎惩罚周期。

行动指令: 如果你的网站正在被镜像劫持, 现在立刻执行步骤①里面的 dig 命令。请把返回的IP段发给我。请把DNS服务商的信息也发给我。我会根据你的具体配置来定制排除问题的路径。我们不走通用的流程。

相关标签：