TFTP蜜罐结果 - 伪装信息

我的TFTP蜜罐已经运行了一个多月，在我每月5美元的VPS上持续运行，并在我家的Dell R530服务器上间歇运行。是时候看看它捕获了哪些意外情况。

当TFTP蜜罐运行时，两台服务器每天都会收到20到50个TFTP数据包。两台服务器看到的流量大部分是相同的。当我开始每天收到UDP端口69的流量时，我非常兴奋，其中大部分是TFTP格式的流量。当我意识到大部分流量是来自七家信息安全公司的定期扫描时，我感到有些失望。

1. Shadow Server的5个ERROR数据包，大约每11秒一个 Code 4，消息“Bad Filename” Code 0，消息“Access violation” Code 4，消息“4”，额外1个字节“x05x00x044x00x00” Code 5，消息“Illegal TID” Code 4，消息“Illegal TFTP operation” RRQ请求文件a.pdf，octet，其时间安排与ERROR数据包的突发不同
2. Censys RRQ请求文件/a，netascii
3. Driftnet RRQ请求一个由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字节不符合规范的UDP载荷十六进制表示：00000417271019800000000000034925 大约一半时间从UDP端口18020发送 在两分钟内发送4-6个数据包的突发，来自两个或更多IP地址
5. Secretive Palo Alto Networks RRQ请求文件/a，netascii，随后是请求文件，octet
6. Netscout RRQ请求文件名ay9mfwq7xxmd4w6c7xa0，octet
7. Internet Census RRQ，文件名/a，netascii 16字节不符合规范的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 Networks和Censys的探针，24小时的中位数在探针间隔范围面前也几乎毫无意义。

还有一个不太容易描述的：

五次突发的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地址上是否存在监听端口69的TFTP服务器。对masscan-test的RRQ请求似乎是一种隐藏在Robert Graham的masscan背后的服务器存在探测，而masscan是一个仅TCP、全网扫描工具。

其中一个RRQ请求一个名为r7tftp.txt的文件，这是nmap TFTP服务器ID模块请求的文件。我不相信这个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流量来自信息安全公司，而不是试图利用小众软件的“坏人”。