捕获了一个 .git/config 爬虫

# 抓到一个 `.git/config` 爬虫 —— 信息伪装 来源：https://bruceediger.com/posts/git-config-spider/ 我的无限网站生成器（https://bruceediger.com/posts/anti-seo-infinite-website/）抓到了一个 `\.git/config` 爬虫。 去年十一月，我更新了我的程序 `bork\.php`，使其能更好地生成 `\.git/config` 文件。我在 Apache 日志文件中注意到，一些明显的不良行为者正在请求路径为 `\.git/config` 的 URL。这个文件名包含了 git（https://git-scm.com/）版本控制系统的每个仓库配置信息。由于其优越性，`git` 已成为有史以来最流行的版本控制系统。 仅供参考，下面是我的 Web 服务器对 `\.git/config` URL 请求返回的内容： ``` [core] repositoryformatversion = 0 filemode = true bare = false logallrefupdates = true [remote "origin"] url = [email protected]:yorgi-gromolski/spintronic-tractor-parts.git fetch = +refs/heads/*:refs/remotes/origin/* [branch "main"] remote = origin merge = refs/heads/main [branch "fuck-you-moron"] url = [email protected]:richard-nixon/fartpipe.git remote = origin merge = refs/heads/fuck-you-moron [branch "nRqEtp3gAecLhY"] url = [email protected]:bZPVQxEKkSVAqw0mrnI/TbdQETY1MxUb1ETu8j.git remote = origin merge = refs/heads/sNvilUBPj8xooSTH ``` 最后一个分支的名称是随机选择的，URL 也是随机选择的。每次有人请求 `/\.git/config` 时，它们都会不同。我实际上不知道这是否是 `\.git/config` 文件的有效格式。 2025 年中期左右，人们开始主动收集（https://cybersecuritynews.com/hackers-actively-attacking-git-configuration-files/）`\.git/config` 文件。我对 `git` 不是特别了解，但在我看来，`\.git/config` 的内容本身并没有价值。人们显然会将各种凭证、用户名和密码、TLS 证书等保存在 `git` 版本控制下的仓库中。我发现有一个不良行为者请求了 `/\.git/config`，然后爬取了一个完全虚构的 `git` 仓库。 ### 发现 在 2025 年 3 月到 9 月之间，我让我的 Web 服务器将 Meta（即 Facebook）的爬虫送入了一个无限的垃圾沼泽（https://bruceediger.com/posts/goofing-on-meta/）。我既好奇这对 Meta 爬虫的影响，也担心对我每月 4.37 美元的 VPS 的影响，所以我保留了 Apache 的“combined”格式日志文件。我仍然保留它们，因为这样我可以查看日志，寻找其他异常行为（https://bruceediger.com/posts/104.244.79.113/）。 根据 Apache 日志文件，我制作了一个图表，显示我的 VPS 每天收到的 HTTP 请求数量。 每天 HTTP 请求数量图表，显示 2026 年 6 月有一个惊人的峰值 上图中的日期是 UTC 时间。 注意 2026 年 6 月那个又高又窄的峰值。那是两天，6 月 19 日和 20 日，分别收到了 563057 和 339286 个请求。为了感受一下数量级，2026 年 6 月的其他天数每天请求量在 96,000 到 120,000 之间。Meta 最多每天达到 270,000 个请求。 稍微研究了一下之后，我发现单个 IPv4 地址 195.178.110.18 在 2026 年 6 月 19 日发起了 434039 个请求，在 2026 年 6 月 20 日发起了 220239 个请求。 | 日期 | 请求数量 | |------------|----------| | 2025-12-24 | 4 | | 2025-12-25 | 5 | | 2025-12-28 | 8 | | 2026-01-01 | 8 | | 2026-01-11 | 4 | | 2026-01-12 | 4 | | 2026-01-14 | 4 | | 2026-02-26 | 1 | | 2026-03-04 | 1 | | 2026-03-07 | 1 | | 2026-03-15 | 1334 | | 2026-03-16 | 380 | | 2026-03-24 | 1 | | 2026-03-26 | 1 | | 2026-03-28 | 1 | | 2026-03-30 | 1 | | 2026-04-06 | 212 | | 2026-04-07 | 355 | | 2026-04-10 | 2 | | 2026-04-13 | 2 | | 2026-04-17 | 2 | | 2026-04-23 | 1 | | 2026-04-30 | 2 | | 2026-05-01 | 1 | | 2026-05-16 | 2 | | 2026-05-24 | 110 | | 2026-06-17 | 110 | | 2026-06-19 | 434039 ← | | 2026-06-20 | 220239 ← | | 2026-06-22 | 225 | | 2026-06-24 | 115 | | 2026-06-25 | 108 | | 2026-06-30 | 225 | 我虔诚地希望，对 650K 个请求返回垃圾响应能帮助 195.178.110.18 在其网络犯罪之旅中有所收获。 在看到请求数量后不久，我对 195.178.110.18 进行了 whois 查询。195.178.110.18 是 195.178.110.0/24 的一部分。查看我的 Apache 日志文件，我发现了 59 个属于 195.178.110.0/24 的 IP 地址，它们总共发起了 699,774 个请求。 | IP 地址 | 请求数量 | |----------------|----------| | 195.178.110.2 | 10 | | 195.178.110.15 | 42 | | 195.178.110.18 | 657317 | | 195.178.110.21 | 2 | | 195.178.110.25 | 39 | | 195.178.110.28 | 11 | | 195.178.110.31 | 19 | | 195.178.110.33 | 1474 | | 195.178.110.34 | 748 | | 195.178.110.38 | 5 | | 195.178.110.39 | 2 | | 195.178.110.48 | 557 | | 195.178.110.54 | 19 | | 195.178.110.57 | 1 | | 195.178.110.64 | 9 | | 195.178.110.65 | 1490 | | 195.178.110.68 | 258 | | 195.178.110.75 | 56 | | 195.178.110.100| 12 | | 195.178.110.101| 172 | | 195.178.110.102| 1598 | | 195.178.110.103| 1102 | | 195.178.110.104| 2 | | 195.178.110.108| 3298 | | 195.178.110.109| 4027 | | 195.178.110.125| 1 | | 195.178.110.130| 12 | | 195.178.110.131| 2 | | 195.178.110.132| 6094 | | 195.178.110.133| 672 | | 195.178.110.135| 2108 | | 195.178.110.144| 1 | | 195.178.110.146| 10 | | 195.178.110.152| 87 | | 195.178.110.155| 17 | | 195.178.110.157| 2289 | | 195.178.110.159| 3272 | | 195.178.110.160| 439 | | 195.178.110.161| 633 | | 195.178.110.162| 71 | | 195.178.110.163| 976 | | 195.178.110.164| 429 | | 195.178.110.186| 12 | | 195.178.110.187| 10 | | 195.178.110.190| 70 | | 195.178.110.191| 16 | | 195.178.110.195| 4 | | 195.178.110.199| 8424 | | 195.178.110.201| 200 | | 195.178.110.204| 1 | | 195.178.110.218| 26 | | 195.178.110.222| 4 | | 195.178.110.223| 410 | | 195.178.110.224| 7 | | 195.178.110.228| 12 | | 195.178.110.240| 431 | | 195.178.110.241| 42 | | 195.178.110.242| 261 | | 195.178.110.246| 73 | 195.178.110.0/24 的请求最早可追溯到 2025 年 3 月 13 日（我保留的最早日志文件）。195.178.110.0/24 请求的大部分 URL 看起来像是在钓鱼：各种变体如 `/$SOMETHING/\.git/config`、`/wp-config.php.save`、`/.env`、`/wp-config.php` 以及其他。 阅读日志后，我将这些请求分为 4 类： 1. 一般性漏洞扫描，重点是但不限于 `\.git`、`\.env`、其他配置文件。此类请求在整个日志记录期间都有出现。每天使用 1 或 2 个用户代理。 2. 扫描低垂的 PHP 漏洞 —— `phpinfo.php`、`wp-config.php` 等，出现在 2026 年 3 月 28 日、29 日，2026 年 6 月 26 日、27 日 —— 每天只使用 4 个用户代理。 3. 爬取 `\.git/config` 内容，发生在 2026 年 6 月 19 日、20 日。 4. 读取博客首页，读取帖子和标签的 HTML 内容，尝试解析引用的 URL，并请求其中一些。 —— 2026 年 3 月 15 日、16 日，相对于其他扫描，使用了大量用户代理。 第 3 类包含最初引起我注意的请求。 ### 第 1 类：重点扫描 `\.git/config`、`\.env` 和其他配置文件 在我拥有 Apache 日志文件的整个期间，195.178.110.0/24 中的地址一直在请求 `/\.git/config`、`/wp-config.php`、`/docker-compose.prod.yml` 以及许多其他明显的配置文件。由于我的网站 HTML 并没有链接到这些配置文件，甚至没有提供它们，195.178.110.0/24 请求的 URL 表明它在询问可能存在的 URL，而不是已知存在的 URL。 195.178.110.0/24 甚至猜测较旧的配置文件，例如 `/.env.save` 和 `/.env.backup`。 在很多情况下，扫描器在同一时钟秒内对 `/\.git/config` 发起了两次 GET 请求，显然是通过 HTTP。我的服务器返回了 301 状态码，重定向到 `https:` 模式的 URL，然后 195.178.110.x 立即请求了该 URL。195.178.110.0/24 的探测系统先进行 HTTP，然后回退到 HTTPS。 我与用 PHP 编写的、处于灰色地带的软件（https://bruceediger.com/phparaites/）打过交道，经验告诉我，进行两次冗余调用是一种常见做法。我一直好奇网络罪犯如何区分这些冗余调用的返回结果中该用哪一个。考虑到我的 Web 服务器配置为对 `/\.git/config` HTTP 请求返回不同、随机选择的内容，我惊讶于 195.178.110.0/24 在探测了各种配置文件并得到多个不同结果后还会再次回来。 ### 第 2 类：PHP 低垂漏洞 在 2026 年 4 月 6 日和 7 日，195.178.110.18 请求了一些调试或开发用的 PHP 程序，路径如 `/server_info.php`、`/info.php`、`/phpinfo.php` 和 `/php_info.php`。通常会有这样一个名字的 PHP 文件，调用 PHP 系统函数 `phpinfo()`。该系统函数会生成关于运行 `phpinfo.php` 程序的 PHP 解释器、其配置、已安装模块以及其他可能提供 PHP 漏洞线索的信息的漂亮 HTML。这种程序非常常见，网络爬虫也经常请求它，所以我有一个 `phpinfo.php` 程序，它能生成类似于 `phpinfo()` 函数输出但仅凭巧合才准确的 HTML。一些请求带有“referer”URL，包含混合的 “http://bruceediger.com/”、“http://crudhammer.com/” 和 “http://stratigery.com/”，这三个 FQDN 都解析到同一个 IP 地址，即我每月 5 美元的 VPS。这些是唯一带有 referer 的请求。这可能是一个独立的爬虫，运行在 195.178.110.18 上，专门针对 PHP 和可能的漏洞。 这些请求跨越了 2026 年 4 月 6 日 23:00 到 2026 年 4 月 7 日 01:00，在 1 小时 52 分钟内发起了 377 个请求，大约每秒 0.06 个请求。 在 2026 年 6 月 19 日 03:16:46 UTC，195.178.110.18 对 `/.git/HEAD` 发起了一个 GET 请求。然后它迅速继续。 在这一阶段，195.178.110.18 没有使用任何 referrer，只使用了一个用户代理字符串： ``` Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/85.0.4183.102 Safari/537.36 ``` 之后，我不太确定 195.178.110.18 选择 URL 的依据。随机选择的分支名称确实出现在 HTTP 请求中，例如 `/.git/refs/heads/M4_bNpd2507HvUJ` 或 `/.git/refs/remotes/origin/XHgfqRg6Z`。我不是 `git` 内部的专家，所以这些对我来说有点难以理解。 这一阶段的 `\.git/config` 文件解析也不太好。195.178.110.18 最终请求了一些“重复路径”的文件，例如 `/.git/config/.git/config` 和 `/.git/config/.git/logs/refs/heads/A03DSnrylm1LPT`。“解析不太好”的另一种可能性是解析器被我可能不合法的、随机生成的 `\.git/config` 文件弄糊涂了。 这一特定阶段的扫描器每小时发出略多于 21 万个请求。2026 年 6 月 19 日，所有请求都在 UTC 时间晚上 8 点至 9 点之间发出。2026 年 6 月 20 日，所有请求都在 UTC 时间凌晨 3 点那一小时发出。这大约是每秒 56 个请求，相当多。 ### 第 4 类：首页爬取 2026 年 3 月 15 日，2026 年 6 月 22 日、26 日、27 日，它请求了 `/`、我网站首页上的帖子、一些按主题分组帖子的“标签”URL，以及一些奇怪的、显然是垃圾的 URL，其路径似乎是错误解析的 HTML 元素和错误解析的超链接 URL。 195.178.110.0/24 系统显然会请求可能存在的 URL。我日志中最早的 URL 是对 `/.git/config` 的请求。同样明显的是，它试图解析响应中获得的 HTML。它解析 HTML 的能力并不好，因为它会请求路径为 `//en.wikipedia.org/wiki/Voltage_doubler` 的 URL。它错误地删除了 `a` 超链接 HTML 标签的 `href` 属性中的 `https:` 部分，然后将其作为 URL 路径进行请求。它请求了大量路径以 `//` 开头且是我网站 HTML 中某个超链接一部分的 URL。它还请求了 `/body`、`/dev`、`/h2`、`/form` 以及许多其他 HTML“结束标签”的部分。我敢打赌它使用正则表达式来解析 HTML（https://stackoverflow.com/a/1732454）。 一些请求带有 referrer，全部使用 `http:` 模式。195.178.110.0/24 系统先发起 HTTP 请求，然后回退到 HTTPS。 2026 年 5 月 9 日，195.178.110.0/24 系统发出了 8 个请求，路径为 `//cdn.usefathom.com/script.js`。这是对 Fathom Analytics（https://bruceediger.com/posts/fathom-analytics/）要求你在 HTML 中引用的脚本的引用。我在 Mon Jul 28 22:14:48 2025 -0600 时删除了所有对 `script.js` 的引用。195.178.110.0/24 系统保留了至少 9 个月前一次请求的信息。 ### 那 195.178.110.0/24 呢？ iplocation.net（https://www.iplocation.net/ip-lookup?query=195.178.110.18）显示 195.178.110.18 位于安道尔（https://en.wikipedia.org/wiki/Andorra）。加入互联网，就会遇到新朋友，我想。 根据 2026 年 7 月 1 日的 whois 查询，地址 195.178.110.18 属于 195.178.110.0/24，注册方是位于英国伦敦的 Techoff SRV Limited。195.178.110.0/24 中的任何地址都没有 DNS 记录。 看起来 Techoff 公开以 dmzhost.co（https://dmzhost.co/）的身份出现。195.178.110.18 的 whois 记录列出了滥用地址 [email protected]（mailto:[email protected]），该地址也出现在 dmzhost.co 的联系页面上。 Techoff SRV Limited（https://find-and-update.company-information.service.gov.uk/company/16090235）是公司编号 16090235，根据古雅的英国公司注册处（Companies House）的信息。一家英国公司在安道尔运营服务器似乎很复杂，类似于海峡群岛（https://en.wikipedia.org/wiki/Channel_Islands）的政治和法律安排。确实有一些关于 195.178.110.0/24 IP 地址滥用行为的指控（https://www.abuseipdb.com/check/195.178.110.18）。 dmzhost.co 网站提供“离岸 KVM 私有服务器”，但我找不到实际位置。“DMZHOST 离岸网页托管”页面声称物理位置在“欧盟/俄罗斯”。所有价格以欧元而非英镑标价。最便宜的 KVM VPS 是 5 欧元/月。2026 年 7 月，5 欧元约合 5.70 美元，不算太贵。 ### 总结 我发现 195.178.110.18 在我的每月 5 美元的 VPS Web 服务器上发起了 65 万个 HTTP 请求。几乎所有这些请求都是针对 `/.git/config`、可能根据 `/.git/config` 随机选择的内容组成的 URL，以及明显错误解析 `config` 文件所产生的 URL。 195.178.110.18 属于 CIDR 195.178.110.0/24，由一家英国公司拥有，但分配给了安道尔某数据中心内的机器。195.178.110.0/24 中的所有 IP 地址都因各种滥用行为被多次举报。 使用 195.178.110.0/24 地址的机器对我的 Web 服务器进行了低强度扫描，重点是各种配置文件和凭证的 URL，这些文件经常在网站开发后错误地留下，或者只是被忽视。 偶尔，这些机器会爬取我网站的主页。它们显然使用某种方法解析获取的 HTML，在寻找超链接时经常给出错误的 URL。这种爬取的数据至少会保留数月。 极少情况下，这些机器会寻找 PHP 文件，这些文件在被请求时可能泄露 PHP 解释器配置、WordPress 配置和凭证。 有一次，195.178.110.18（195.178.110.0/24 中的一台机器）请求了 65 万个 URL，这些 URL 显然都是通过最初请求 `/.git/config` 收集的，而我的网站生成程序针对该请求会返回一个看似合理但随机选择的错误 `config` 文件内容。