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 Filename2. 代码 0消息 Access violation3. 代码 4消息 4额外 1 字节 \x05\x00\x044\x00\x004. 代码 5消息 Illegal TID5. 代码 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致力于与世界分享健康的生活方式理念。[上一篇另一个关于双链路聚合器的故事]