Hotdry.
归档
systems-monitoring

archive.today异常行为检测：从恶意JavaScript到爬虫指纹监控

分析archive.today近期嵌入恶意JavaScript的行为，探讨网络存档服务的异常检测方法与分布式监控架构实现。

2026 年 1 月，Hacker News 上出现了一个引人注目的讨论：archive.today 在其 CAPTCHA 页面中嵌入了恶意 JavaScript 代码，每 300 毫秒向一个个人博客发起请求。这一发现不仅揭示了网络存档服务的潜在风险，更凸显了在现代互联网生态中，如何有效检测和应对这类异常行为的技术挑战。

事件回顾：archive.today 的异常行为

用户rabinovich在 HN 上报告，archive.today 最近开始在其验证码页面自动向gyrovague.com发起请求。相关 JavaScript 代码如下：

setInterval(function() {
  fetch("https://gyrovague.com/?s=" + Math.round(new Date().getTime() % 10000000), {
    referrerPolicy: "no-referrer",
    mode: "no-cors"
  });
}, 300);

这段代码每 300 毫秒执行一次，使用随机查询字符串（?s=加上时间戳模 10000000）向目标网站发起fetch请求。值得注意的是，gyrovague.com在 2023 年 8 月发表了一篇题为《archive.today: On the trail of the mysterious guerrilla archivist of the Internet》的调查文章，深入挖掘了 archive.today 运营者的身份信息。

技术分析：恶意行为的特征与影响

1. 缓存破坏与资源消耗

代码中使用的?s=参数是一个典型的缓存破坏技术。每次请求都带有不同的查询字符串，确保浏览器和 CDN 无法缓存响应。对于 WordPress 托管的网站，这种搜索查询会触发完整的数据库搜索操作，导致 CPU 使用率显著上升。

2. 请求频率与带宽消耗

每 300 毫秒一次的请求频率意味着：

  • 每分钟 200 次请求
  • 每小时 12,000 次请求
  • 每天 288,000 次请求

虽然单个请求的带宽消耗不大，但长期累积会对目标服务器的资源造成持续压力。特别是当多个用户同时访问 archive.today 的 CAPTCHA 页面时，这种效应会被放大。

3. 技术实现细节

  • no-cors模式：使用mode: "no-cors"避免跨域限制，但这也限制了响应内容的访问
  • no-referrer策略：隐藏请求来源，增加追踪难度
  • 时间戳随机化：Math.round(new Date().getTime() % 10000000)生成伪随机数，避免简单的模式匹配

archive.today 的技术背景

要理解这一异常行为，需要先了解 archive.today 的技术架构：

运营模式

archive.today 是一个由单人运营的网页存档服务，成立于 2012 年 5 月 16 日。与 Internet Archive 的自动化爬虫不同，archive.today 采用按需存档模式，仅在用户明确请求时创建快照。

技术栈

  • 抓取引擎：自 2019 年 11 月 29 日起使用 Chromium（非无头模式）替代 PhantomJS
  • 存储系统：基于 Apache Hadoop 和 Apache Accumulo，数据存储在 HDFS 上
  • 数据冗余：文本内容在位于欧洲的两个数据中心间复制 3 次，图像复制 2 次
  • 域名策略：使用多个 TLD（.today、.is、.ph、.md、.li、.fo、.vn）绕过审查

争议特性

  • 不尊重 robots.txt：archive.today 认为自己是 "用户的直接代理" 而非搜索引擎爬虫
  • 付费墙绕过：能够存档付费内容，使用从用户处获得的专用登录账号
  • 严格的不删除政策：除儿童色情内容和有效的法律请求外，存档内容永久保留

异常检测的技术挑战

archive.today 的这一行为暴露了网络服务异常检测的几个关键挑战：

1. 爬虫指纹识别困难

archive.today 使用分布式 IP 地址进行抓取，这些 IP 地址的反向 DNS 记录有时会伪装成 Google 爬虫。这种策略使得基于 IP 地址或 User-Agent 的简单检测方法失效。

2. JavaScript 注入检测

恶意 JavaScript 可能被动态注入或仅在特定条件下执行。传统的静态分析工具难以发现这类行为，需要运行时监控和动态分析。

3. 低速率分布式攻击

每 300 毫秒一次的请求频率相对较低，不会触发传统的 DDoS 防护阈值。这种 "慢速攻击" 更难被自动检测系统识别。

4. 合法服务与恶意行为的界限模糊

archive.today 本身是一个合法的存档服务，其核心功能对社会有价值。这使得简单的黑白名单方法不适用，需要更精细的行为分析。

可落地的异常检测方案

基于这一案例，我们可以设计一个针对网络存档服务异常行为的检测框架：

1. 实时 JavaScript 监控

// 客户端监控脚本示例
const originalFetch = window.fetch;
window.fetch = function(url, options) {
  // 记录所有fetch请求
  const requestData = {
    url,
    timestamp: Date.now(),
    referrer: document.referrer,
    userAgent: navigator.userAgent
  };
  
  // 发送到监控端点（节流处理）
  if (Math.random() < 0.01) { // 1%采样率
    navigator.sendBeacon('/monitor/js-requests', JSON.stringify(requestData));
  }
  
  return originalFetch.apply(this, arguments);
};

2. 服务器端异常模式检测

# Python伪代码：异常请求检测
class AnomalyDetector:
    def __init__(self):
        self.request_patterns = {}
        self.normal_baseline = self.establish_baseline()
    
    def detect_anomaly(self, request):
        # 检查请求频率异常
        client_ip = request.remote_addr
        current_rate = self.calculate_request_rate(client_ip)
        
        # 检查URL模式异常
        url_pattern = self.extract_url_pattern(request.path)
        
        # 检查时间分布异常
        time_distribution = self.analyze_time_distribution(client_ip)
        
        # 综合评分
        anomaly_score = (
            self.rate_anomaly_score(current_rate) * 0.4 +
            self.pattern_anomaly_score(url_pattern) * 0.3 +
            self.time_anomaly_score(time_distribution) * 0.3
        )
        
        return anomaly_score > 0.8  # 阈值可调

3. 分布式监控架构

监控系统架构：
┌─────────────────┐    ┌─────────────────┐    ┌─────────────────┐
│   客户端监控    │───▶│   边缘收集器    │───▶│   中央分析器    │
│   (浏览器扩展)  │    │   (CDN边缘)     │    │   (实时处理)    │
└─────────────────┘    └─────────────────┘    └─────────────────┘
                                                            │
                                                    ┌───────▼───────┐
                                                    │  异常告警系统  │
                                                    │   (阈值触发)   │
                                                    └───────┬───────┘
                                                            │
                                                    ┌───────▼───────┐
                                                    │  响应执行器    │
                                                    │ (限流/阻断)    │
                                                    └────────────────┘

4. 检测参数清单

基于 archive.today 案例，建议监控以下参数：

检测维度 具体参数 正常阈值 异常指标
请求频率 同一客户端 IP 的请求间隔 > 1 秒 < 500 毫秒
URL 模式 查询字符串随机性 低熵值 高熵值（如时间戳）
时间分布 请求的时间规律性 符合人类模式 严格周期性
来源页面 Referrer 模式 多样来源 单一来源集中
用户代理 UA 字符串一致性 合理变化 异常组合

5. 响应策略分级

  1. 监控级别（异常分数 0.6-0.8）

    • 记录详细日志
    • 增加采样频率
    • 人工审核队列

  2. 防护级别（异常分数 0.8-0.9）

    • 实施请求限流
    • 添加验证码挑战
    • 临时性 IP 限制

  3. 阻断级别（异常分数 > 0.9）

    • 完全阻断请求
    • 更新防火墙规则
    • 通知安全团队

对网络存档服务的启示

archive.today 的这一事件为整个网络存档行业提供了重要警示：

1. 透明运营的重要性

匿名运营虽然提供了一定保护，但也增加了滥用风险。适度的透明度有助于建立信任。

2. 技术伦理的边界

即使是为了 "存档自由"，也不应使用技术手段进行报复或攻击。技术能力必须与伦理责任相匹配。

3. 监控与制衡机制

重要的公共服务应考虑引入第三方审计或社区监督机制，防止单点决策导致的滥用。

4. 应急响应计划

应有明确的异常行为检测和响应流程，包括技术监控、人工审核和外部报告机制。

实践建议

对于依赖 archive.today 或其他类似服务的用户：

  1. 多重备份策略：重要内容应在多个存档服务（Internet Archive、本地存档等）中保存
  2. 定期验证：定期检查存档链接的有效性和完整性
  3. 技术防护：在可能受影响的网站上实施上述监控方案
  4. 社区协作：参与相关开源监控项目，共享异常模式数据

对于存档服务运营者：

  1. 行为准则：制定并公开技术使用伦理准则
  2. 透明报告：定期发布透明度报告，包括异常请求处理情况
  3. 外部审计：考虑引入第三方安全审计
  4. 应急机制：建立快速响应和安全修复流程

结语

archive.today 的异常行为事件不仅是一个技术安全问题，更是网络生态治理的缩影。在数字化时代，重要的公共服务需要在技术能力、运营透明度和伦理责任之间找到平衡点。

有效的异常检测不是简单的黑白名单游戏，而是需要结合实时监控、模式识别和行为分析的复杂系统工程。通过建立分层的检测和响应机制，我们可以在保护服务可用性的同时，防范潜在的滥用风险。

正如 archive.today 运营者自己所言，这项服务是一个 "脆弱的工具"。正是这种脆弱性，提醒我们在构建和依赖这些数字基础设施时，需要更多的谨慎、透明和责任感。

资料来源：

  1. Hacker News 讨论 "Ask HN: Weird archive.today behavior?" (item?id=46624740)
  2. Edward Kiledjian 的技术分析 "Archive.today: inside the web archiving service" (2025-10-15)
  3. archive.today 运营者的 Tumblr 博客和技术文档
查看归档