我对 Packetbeat 有一个有趣的问题。Packetbeat 安装在 Debian 10 系统上。它是最新版本的 Packetbeat（本周从 Elastic 下载区域全新安装），并将数据发送到同样安装在 Debian 10 系统上的 Elastic v7.7。
我在 Elastic 日志中看到了 DNS 数据（使用 Kibana-->Logs gui 查看它们时）。但是，我还在日志中看到了在运行 tcpdump 的数据包分析器上没有看到的其他 DNS 数据包，这些数据包来自运行 packetbeat 的同一系统。
这是显示客户端 (10.5.52.47) 的 DNS 调用的数据包分析器。wireshark 捕获过滤器设置为“端口 53”，显示过滤器设置为“ip.addr==10.5.52.47”。它与 packetbeat 在同一系统上运行（用于解决此问题）。 Wireshark 截图
1552 2020-06-04 20:31:34.297973 10.5.52.47 10.1.3.200 52874 53 DNS 93 Standard query 0x95f7 SRV
1553 2020-06-04 20:31:34.298242 10.1.3.200 10.5.52.47 53 52874 DNS 165 Standard query response 0x95f7 No such name SRV
1862 2020-06-04 20:32:53.002439 10.5.52.47 10.1.3.200 59308 53 DNS 90 Standard query 0xd67f SRV
1863 2020-06-04 20:32:53.002626 10.1.3.200 10.5.52.47 53 59308 DNS 162 Standard query response 0xd67f No such name SRV
1864 2020-06-04 20:32:53.004126 10.1.3.200 10.5.52.47 64594 53 DNS 84 Standard query 0xaaaa A
1867 2020-06-04 20:32:53.516716 10.1.3.200 10.5.52.47 64594 53 DNS 84 Standard query 0xaaaa A
2731 2020-06-04 20:36:34.314959 10.5.52.47 10.1.3.200 53912 53 DNS 93 Standard query 0x2631 SRV
2732 2020-06-04 20:36:34.315058 10.1.3.200 10.5.52.47 53 53912 DNS 165 Standard query response 0x2631 No such name SRV
我从这些数据包中删除了实际的 DNS 查询信息，因为它与本主题无关。从 wireshark 输出中，您可以看到 20:32:53 从 10.5.52.47 到 DNS 服务器 10.1.3.200 的 DNS 查询。服务器在下一个数据包中响应此查询。此外，在同一时间之后，服务器还有另外两个响应。
客户端 10.5.52.47 的下一个 DNS 查询发生在 20:36:34。这也得到了服务器的即时响应。
这与 packetbeat 发送的 Kibana-->log 输出不同。在 Kibana 日志中，它显示以下内容： Kibana 日志的屏幕截图，显示实际的 DNS 调用和多个不存在的 DNS 调用（以黄色突出显示）
All the above info as captured in the packet capture
plus the following:
20:33:00.000 destination IP of 10.5.52.47 destination port of 53
Same thing at
20:33:10.000
20:33:20.000
20:33:30.000
20:33:40.000
然后在 20:36:34 显示数据包捕获显示的 DNS 查询。
因此，这些在分钟后 00/10/20/30/40 秒结束的端口 53 似乎是凭空捏造的。此外，这些条目的弹性日志中没有填充其他字段。client.ip 为空，client.bytes、client.port 以及这些日志条目的所有 DNS 字段也是空的。数据包捕获和 Kibana 中列出的所有 DNS 条目的所有预期字段都填充了正确的数据。
有谁知道为什么会这样？上面的这个例子是一个小样本。多个系统每隔 10 秒就会出现这种情况。例如，在一分钟后的 10 或 20 或 30 或 40 或 50 或 60 秒，我看到这些日志条目中有 10 到 100 个（估计值），其中除了destination.ip、destination.byte 和destination 之外的所有字段都是空白的.port - 这些错误记录的字段中不包含客户端信息和 DNS 信息。
“正常”的 DNS 记录包含 Kibana 日志中列出的大约 20 个信息字段，而这些错误的只有四个字段（上面列出的字段和时间戳）。
这是来自这些 10 秒间隔之一的日志示例...
timestamp Dest.ip Dest.bytes Dest.port
20:02:50.000 10.1.3.200 105 53
20:02:50.000 10.1.3.200 326 53
20:02:50.000 10.1.3.200 199 53
20:02:50.000 10.1.3.200 208 53
20:02:50.000 10.1.3.201 260 53
20:02:50.000 10.1.3.200 219 53
20:02:50.000 10.1.3.200 208 53
20:02:50.000 10.1.3.200 199 53
.
.
Plus 42 more of these at the same second
.
.
20:02:50.000 10.1.3.201 98 53
报告问题的 Kibana 日志视图 - '真实' dns 调用以黄色突出显示，不存在的 dns 调用由红线标记 - 记录的不存在 DNS 调用比真实 DNS 查询多得多
这是 packetbeat.yml 文件（仅显示未注释的行）
packetbeat.interfaces.device: enp0s25
packetbeat.flows:
timeout: 30s
period: 10s
packetbeat.protocols:
- type: dhcpv4
ports: [67, 68]
- type: dns
ports: [53]
include_authorities: true
include_additionals: true
setup.template.settings:
index.number_of_shards: 1
setup.dashboards.enabled: true
setup.kibana:
host: "1.1.1.1:5601"
output.elasticsearch:
hosts: ["1.1.1.2:59200"]
setup.template.overwrite: true
setup.template.enabled: true
感谢您对可能导致此问题的原因的想法。
==================================================== ======================
20 年 6 月 8 日更新
由于这个问题，我不得不关闭 packetbeat，直到找到解决方案。一个单一的 packetbeat 系统在周末生成了 1 亿个文档，仅用于 DNS 查询。其中 98% 是由 packetbeat 创建的，并不是真正的 DNS 查询。
我今天早上在捕获这些 DNS 查询的 linux 机器上停止了 packetbeat 服务，并删除了这个索引。然后我重新启动了 packetbeat 实例并让它运行了大约 60 秒。然后我停止了 packetbeat 服务。在 60 秒内，有 22,119 个 DNS 文档被添加到索引中。当我删除创建的文件 packetbeat（不是真正的 DNS 查询）时，它删除了 21,391。给我留下了 728 个实际的 DNS 查询。在这种情况下，97% 的文档是由 packetbeat 创建的，还有 3% 是由我们的系统进行的由 packetbeat 捕获的“真实”DNS 查询创建的。
关于为什么这个系统会表现出这种行为的任何想法？
谢谢