我的TFTP蜜罐已经在我的每月5美元的虚拟专用服务器（VPS）上运行了一个多月，并且在我的戴尔R530家庭服务器上间歇性运行。是时候看看它捕获了什么惊喜。当TFTP蜜罐运行时，两个服务器每天看到20到50个TFTP数据包。两个服务器看到的流量大部分是相同的。当我看到每天的UDP 69端口流量时，我非常兴奋，其中大部分是TFTP格式。但当我意识到多数流量是来自七个信息安全公司的定期扫描时，我感到失望。信息安全公司扫描Shadow Servers 5个错误数据包，大约每11秒1个，代码4，信息“坏文件名”，代码0，信息“访问违规”，代码4，信息“4”，1个额外字节“\x05\x00\044\x00\x00”，代码5，信息“非法TID”，代码4，信息“非法TFTP操作”；针对a.pdf的RRQ，八进制格式，时间表与错误数据包的爆发不同；Censys针对/a的RRQ，网ASCII格式；Driftnet针对以8个随机选择字母命名的文件的RRQ，网ASCII格式；文件名第一个模式为“[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；Shodan的16字节不符合标准的UDP有效载荷十六进制表示：00000417271019800000000000034925；大约一半的时间通过UDP端口18020到达，2分钟内4-6个数据包的爆发，来自两个或更多IP地址；秘密的Palo Alto Networks针对/a的RRQ，网ASCII格式，随后是对文件的RRQ，八进制格式；Netscout针对文件名ay9mfwq7xxmd4w6c7\xa0的RRQ，八进制格式；Internet CensusRRQ，文件名/a，网ASCII格式；16字节不符合标准的UDP有效载荷，没有两个完全相同的十六进制格式：000004172710198000000000xxyyzzww。表面上看，似乎与Shodan的不合规UDP有效载荷相似。是的，这三家公司定期请求名为“a”的文件下载。我发现理顺这些请求非常乏味。命令行whois并未提供非常规律的输出。我从whois中检索到这三者的CIDR数据，并基于CIDR使用grepcidr重新提取日志条目，以仔细核对我是否捕捉到了每家公司所有日志条目，并正确地将日志条目分配给这些公司。这七家公司主要使用注册给他们自己的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小时几乎毫无意义，考虑到探测间隔的范围。神秘的探测：不规则或非常少见的计数名称类型 OACK对 5 RRQ 1 startup-config 八进制 RRQ 1 masscan-test 网ASCII RRQ 2 test.xxx 八进制 RRQ 2 test 八进制 RRQ 7 file_id.diz 八进制 不合规 11 十六进制：000010000000000000000000 12字节二进制 RRQ 1 ..\..\..\..\boot.ini 八进制 RRQ 2 test 八进制 RRQ 6 pxelinux.0 八进制 RRQ 9 config 八进制，块大小：1428，文件大小：0 选项 RRQ 6 a 八进制，Alpha Strike Labs RRQ 1 r7tftp.txt 八进制 不合规 1 十六进制：68656c700d0a0d0a 8字节二进制，“help”后跟2个换行符；不合规 3 十六进制：00000417271019800000000012101111 16字节二进制；还有一个不那么容易描述的：五个RRQ爆发请求y000000000028.cfg，000000000000.cfg，y000000000000.boot，ata192.cfg，spa504g.cfg，spa112.cfg的各种组合，均为八进制类型，均来自199.115.115.137。这些扫描的意义何在？首先，似乎识别UDP 69端口上监听的IP地址是一个主要用途。Netscout，Internet Census和Censys似乎在寻找TFTP服务器。针对名为/a或8个随机选择的字符文件的RRQ不会导致其他结果，仅能识别特定IP地址上是否有TFTP服务器监听69端口。针对masscan-test的RRQ似乎是隐藏在Robert Graham的masscan后面的服务器存在探测，该工具是一款仅支持TCP的全互联网扫描器。一个RRQ请求文件名为r7tftp.txt，这是nmap TFTP服务器ID模块请求的文件。我不相信那个RRQ是nmap生成的，但当然这些扫描的目的之一是识别哪个TFTP服务器运行在哪个主机上。Palo Alto Networks将/a与类型“netascii”的请求成对，并以类型“octet”跟随另一个文件请求，似乎是试图识别哪个服务器软件响应了请求。/a和文件都不大可能存在，因此服务器可能会以错误数据包进行响应。Palo Alto Networks必须在不同的服务器软件之间进行区分。