TFTP蜜罐结果

# TFTP蜜罐结果 - 信息伪装 来源：https://bruceediger.com/posts/tftp-honeypot-results/ 我的 TFTP 蜜罐(https://bruceediger.com/posts/tftp-honeypot/) 已经运行超过一个月了，持续运行在我每月5美元的VPS上，并间歇运行在我的 Dell R530(https://bruceediger.com/posts/homelab/) 家庭服务器上。现在该看看它捕获到了哪些惊喜了。 当 TFTP 蜜罐运行时，两台服务器每天都会看到 20 到 50 个 TFTP 数据包。两台服务器看到的流量大致相同。当我每天收到 UDP 端口 69 的流量（大多数是 TFTP 格式）时，我非常兴奋。但当我意识到大部分流量来自七家信息安全公司的定期扫描时，我很失望。 #### 信息安全公司扫描 1. Shadow Servers (https://www.shadowserver.org/) - 5 个 `ERROR` 数据包，大约每 11 秒一个 1. Code 4，消息 "Bad Filename" 2. Code 0，消息 "Access violation" 3. Code 4，消息 "4"，额外 1 字节 "\\x05\\x00\\x044\\x00\\x00" 4. Code 5，消息 "Illegal TID" 5. Code 4，消息 "Illegal TFTP operation" - 针对 `a.pdf` 的 RRQ，octet 模式，时间与 `ERROR` 数据包爆发不同。 2. Censys (https://platform.censys.io/home) - 针对 `/a` 的 RRQ，netascii 模式 3. Driftnet (https://driftnet.io/) - 针对文件名由8个随机字母组成的 RRQ，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 (https://www.shodan.io/) - 16 字节非标准 UDP 负载 - 十六进制表示：`00000417271019800000000000034925` - 大约一半时间从 UDP 端口 18020 到达 - 两分钟内爆发 4-6 个数据包，来自两个或更多 IP 地址 5. 神秘的 Palo Alto Networks - 针对 `/a` 的 RRQ，netascii 模式，随后针对 `file` 的 RRQ，octet 模式。 6. Netscout (https://www.netscout.com/arbor) - 针对文件名 `ay9mfwq7xxmd4w6c7\xa0` 的 RRQ，octet 模式 7. Internet Census (https://www.internet-census.org/home.html) - RRQ，文件名 `/a`，netascii 模式 - 16 字节非标准 UDP 负载，没有两个完全相同的 - 十六进制：`000004172710198000000000xxyyzzww` - 表面类似 Shodan 的非标准 UDP 负载 是的，有三家公司定期请求下载名为 "a" 的文件。我觉得理清这些请求很繁琐。命令行 `whois` 的输出并不十分规范。我从 `whois` 中获取了这三家公司的 CIDR 数据，然后使用 grepcidr(https://github.com/jrlevine/grepcidr3) 根据 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** | 3 | 1.97 | 2.72 | 260 **Censys** | 0 | 24 | 60 以上是三家信息安全公司探测间隔（小时）的示例。即使对于 Palo Alto Networks 和 Censys 的探测，考虑到探测间隔范围，中位数 24 小时也几乎毫无意义。 #### 神秘探测：不规则或非常不频繁 | 计数 | 类型 | 文件名 | 传输模式 | | --- | --- | --- | --- | | 5 | OACK 对 | | | | 1 | RRQ | `startup-config` | octet | | 1 | RRQ | `masscan-test` | netascii | | 2 | RRQ | `test.xxx` | octet | | 2 | RRQ | `test` | octet | | 7 | RRQ | `file_id.diz` | octet | | 11 | 非标准 | hex: `000010000000000000000000` 12 字节二进制 | | | 1 | RRQ | `..\\..\\..\\..\\boot.ini` | octet | | 2 | RRQ | `test` | octet | | 6 | RRQ | `pxelinux.0` | octet | | 9 | RRQ | `config` | octet，blksize:1428，tsize:0 选项 | | 6 | RRQ | `a` | octet，Alpha Strike Labs(https://www.alphastrike.io/about/) | | 1 | RRQ | `r7tftp.txt` | octet | | 1 | 非标准 | hex: `68656c700d0a0d0a` 8 字节二进制，"help" 带 2 个 CRLF 换行 | | | 3 | 非标准 | hex: `00000417271019800000000012101111` 16 字节二进制 | | 还有一个不容易描述的： 五次针对以下文件的 RRQ 爆发：`y000000000028.cfg`、`000000000000.cfg`、`y000000000000.boot`、`ata192.cfg`、`spa504g.cfg`、`spa112.cfg`，各种组合，全部 octet 模式，全部来自 199.115.115.137。 ### 这些扫描的目的是什么？ 首先，最主要的目的似乎仅仅是识别监听 UDP 端口 69 的 IP 地址。Netscout、Internet Census 和 Censys 似乎是在寻找 TFTP 服务器。对名为 `/a` 或 8 个随机字符的文件执行 RRQ 只能识别出某个 IP 地址上有 TFTP 服务器监听端口 69。针对 `masscan-test` 的 RRQ 似乎是一种服务器存在探测，隐藏在 Robert Graham 的 masscan(https://github.com/robertdavidgraham/masscan) 之后，而 masscan 是一个仅支持 TCP 的全互联网扫描器。 其中一条 RRQ 请求名为 `r7tftp.txt` 的文件，这是 `nmap` TFTP 服务器识别模块请求的文件。我不认为那个 RRQ 是由 `nmap` 生成的，但这些扫描的目的之一肯定是识别哪个 TFTP 服务器在哪个主机上运行。Palo Alto Networks 的成对请求，先用 netascii 模式请求 `/a`，再用 octet 模式请求 `file`，似乎是为了识别哪个服务器软件响应了请求。`/a` 和 `file` 很可能都不存在，因此服务器可能会用 ERROR 数据包响应。Palo Alto Networks 必定是在区分不同的服务器软件。我假设 Shadow Servers 的 ERROR 数据包爆发以及 OACK 数据包对也是用不同的方式服务这一目的。 少数数据包探测配置不当的服务器。请求 `..\\..\\..\\..\\boot.ini` 显然是为了检查 Windows TFTP 服务器是否允许目录遍历。请求 `pxelinux.0` 以及所有来自 199.115.115.137 的文件请求都属于此类。 我不知道 Shodan 通过发送不符合 TFTP 标准的数据包爆发能得到什么。 只有少数几个与 TFTP 服务器相关的 CVE(https://app.opencve.io/cve/?vendor=tftp)。我不认为任何探测是为了利用 TFTP 服务器漏洞。这个实验的讽刺之处在于，大多数 TFTP 流量来自信息安全公司，而不是试图利用小众软件的"坏人"。