TFTP 蜜罐运行超一月：七成流量来自信息安全公司扫描，目的几何？
2026 年 7 月 12 日（最后修改：2026 年 7 月 13 日），我的 TFTP 蜜罐已经运行一个多月了。它在我每月 5 美元的 VPS 上持续运行，也会在我的 Dell R530 家用服务器上间歇性运行。现在，我打算看看它捕获了哪些有趣的数据。
运行期间，两台服务器每天都会收到 20 到 50 个 TFTP 数据包，流量情况大致相同。当发现每天都有 UDP 69 端口的流量，且大部分是 TFTP 格式时，我很兴奋。但后来我意识到，大部分流量其实是七家信息安全公司定期进行的扫描，这让我有些失望。
信息安全公司的扫描情况
1.Shadow Servers（官网）
- 会发送 5 个 `ERROR` 数据包，大约每 11 秒一个。具体如下：
1. 代码 4，消息 "Bad Filename"
2. 代码 0，消息 "Access violation"
3. 代码 4，消息 "4"，额外 1 字节 "\x05\x00\x044\x00\x00"
4. 代码 5，消息 "Illegal TID"
5. 代码 4，消息 "Illegal TFTP operation"
- 还会以不同的时间安排请求 `a.pdf` 文件，传输模式为 octet，与 `ERROR` 数据包的突发时间不同。
2.Censys（官网）
- 请求下载 `/a` 文件，传输模式为 netascii。
3.Driftnet（官网）
- 请求下载由 8 个随机字母组成文件名的文件，传输模式为 netascii。文件名格式为 "[a-zA-Z][a-zA-Z][a-zA-Z][a-zA-Z][a-zA-Z][a-zA-Z][a-zA-Z][a-zA-Z]"。
- 有时通过 IPv6 进行请求。
4.Shodan（官网）
- 发送 16 字节的不符合 TFTP 规范的 UDP 有效负载，十六进制表示为：`00000417271019800000000000034925`。
- 大约一半的时间从 UDP 18020 端口发送。
- 会在两分钟内从两个或多个 IP 地址发送 4 - 6 个数据包。
5.神秘的 Palo Alto Networks
- 先请求下载 `/a` 文件，传输模式为 netascii，接着请求下载 `file` 文件，传输模式为 octet。
6.Netscout（官网）
- 请求下载文件名 `ay9mfwq7xxmd4w6c7\xa0` 的文件，传输模式为 octet。
7.Internet Census（官网）
- 请求下载 `/a` 文件，传输模式为 netascii。
- 发送 16 字节的不符合 TFTP 规范的 UDP 有效负载，且没有两个完全相同，十六进制表示为：`000004172710198000000000xxyyzzww`，表面上与 Shodan 的不符合规范的 UDP 有效负载相似。
有三家公司经常请求下载名为 "a" 的文件。梳理这些请求很繁琐，命令行 `whois` 提供的输出也不太规范。我从 `whois` 中获取了这三家公司的 CIDR 数据，并使用 [grepcidr] 根据 CIDR 重新提取日志条目，以确保我捕获了每家公司的所有日志条目，并正确地将日志条目分配给了相应的公司。
这七家公司大多使用注册在自己名下的 IP 地址，其中大部分 IP 地址在 DNS 中没有 A 记录。我通过 `whois` 找到了这些地址的所有者。不过 Shodan 是个例外，它有时使用自己的 IP 地址，有时使用 Digital Ocean 的地址。
除了“大约每天一次”之外，我无法辨别出这些公司的探测有什么固定的时间表。在 35 天里，我一直运行的 TFTP 蜜罐从 Palo Alto Networks 的 IPv4 地址收到了 35 对探测请求。每对请求的到达时间间隔约为 45 秒，每对中的第一个请求的平均间隔时间为 24.09 小时，最短间隔为 14 小时，最长间隔为 33.65 小时。
| 最小值 | 中位数 | 最大值 |
| --- | --- | --- |
|Palo Alto| 14 | 24.2 | 33.7 |
|Netscout| 31.9 | 72.7 | 260 |
|Censys| 0 | 24 | 60 |
以上是三家信息安全公司探测请求之间的时间间隔（以小时为单位）示例。即使对于 Palo Alto Networks 和 Censys 的探测，考虑到探测间隔的范围，24 小时的中位数也几乎没有实际意义。
神秘的探测：不规则或非常罕见
| 数量 | 名称 | 类型 |
| --- | --- | --- |
| 5 | OACK 对 | |
| 1 | `startup-config` | octet |
| 1 | `masscan-test` | netascii |
| 2 | `test.xxx` | octet |
| 2 | `test` | octet |
| 7 | `file_id.diz` | octet |
| 11 | 十六进制：`000010000000000000000000` | 12 字节二进制 |
| 1 | `..\..\..\..\boot.ini` | octet |
| 2 | `test` | octet |
| 6 | `pxelinux.0` | octet |
| 9 | `config` | octet，块大小：1428，传输大小：0 选项 |
| 6 | `a` | octet，[Alpha Strike Labs] |
| 1 | `r7tftp.txt` | octet |
| 1 | 十六进制：`68656c700d0a0d0a` | 8 字节二进制，"help" 后跟 2 个回车换行符 |
| 3 | 十六进制：`00000417271019800000000012101111` | 16 字节二进制 |
还有一种情况不太容易描述：从 199.115.115.137 地址发出的五组请求，分别请求 `y000000000028.cfg`、`000000000000.cfg`、`y000000000000.boot`、`ata192.cfg`、`spa504g.cfg`、`spa112.cfg` 等文件，所有请求的传输模式均为 octet。
这些扫描的目的是什么？
首先，识别监听 UDP 69 端口的 IP 地址似乎是主要目的。Netscout、Internet Census 和 Censys 似乎在寻找 TFTP 服务器。请求下载名为 `/a` 或 8 个随机字符的文件，只能起到识别某个 IP 地址上的端口 69 是否有 TFTP 服务器监听的作用。对 `masscan-test` 的请求，似乎是借助 Robert Graham 的 [masscan]（一个仅支持 TCP 的全网扫描工具）进行的服务器存在性探测。
其中一个 RRQ 请求下载名为 `r7tftp.txt` 的文件，这是 `nmap` 的 TFTP 服务器识别模块会请求的文件。我不认为这个 RRQ 是由 `nmap` 生成的，但这些扫描的目的之一肯定是识别哪个主机上运行着哪种 TFTP 服务器。Palo Alto Networks 先请求 `/a` 文件（传输模式为 netascii），接着请求 `file` 文件（传输模式为 octet），这似乎是在尝试识别响应请求的是哪种服务器软件。由于 `/a` 和 `file` 这两个文件可能都不存在，服务器可能会返回 `ERROR` 数据包，Palo Alto Networks 肯定是在通过这种方式区分不同的服务器软件。我推测，Shadow Servers 发送的 `ERROR` 数据包和 OACK 数据包对，也是通过不同的方式达到相同的目的。
有几个数据包是在探测配置不当的服务器。对 `..\..\..\..\boot.ini` 的单个请求，显然是在尝试查看 Windows TFTP 服务器是否允许目录遍历。对 `pxelinux.0` 的请求以及 199.115.115.137 发出的所有请求都属于这一类。
我不清楚 Shodan 发送不符合 TFTP 规范的数据包有什么作用。
TFTP 服务器的 [CVE] 漏洞很少，我认为这些探测都不是试图利用 TFTP 服务器的漏洞。这次实验的一个讽刺之处在于，大部分 TFTP 流量来自信息安全公司，而不是试图利用小众软件漏洞的“坏人”。
- [internet]
- [cybercrime]
关于 Bruce Ediger
致力于与世界分享健康的生活方式理念。
[上一篇：另一个关于双链路聚合器的故事]
