我目前正在测试 netfilter / nftables / nft。作为起点,我制定了一个规则集,几乎可以丢弃所有进出的数据,并编写了规则,以便记录每个丢弃的数据包。
一如既往,而且可能必须如此,我不明白机器尝试做的第一件事以及我在日志中注意到的事情:
... IN= OUT=enp0s3 ARP HTYPE=37 PTYPE=0x90bd OPCODE=21
根据这个文件:
- 操作码 21 表示 MARS-Grouplist-Reply。我既没有听说过它,也没有在网上找到任何对它的引用,除了 RFC 或 IANA 文件之外,但那里没有任何解释。
- HTYPE 37 表示 HFI 硬件。与操作码一样,我从未听说过这样的事情,也没有在网上找到任何解释。我很确定我没有那种类型的硬件。在这种情况下,网络硬件是 QEMU 中的虚拟 NIC。
- PTYPE 0x90bd:在今天的研究中,我看到了协议类型列表;不幸的是,我不记得在哪里。但无论如何,那里肯定没有提到 0x90bd。
有人可以解释一下操作码、硬件类型和协议类型的含义,以及为什么相关系统想要发送此类数据包?
这种情况发生在一个普通的 debian Bullseye 安装中(在撰写本文时是最新的),该安装位于具有虚拟化标准 x64 Intel 硬件和 virtio NIC 的虚拟机中。
答案1
这是 Netfilter 的 ARP 日志中的一个错误。
有一个错误报告关于这个问题。我们发现 ARP 没有使用正确的数据进行记录(它使用的是链路层标头中的数据,而不是 ARP 的网络层数据)。 A补丁致力于解决这个问题几天后,出现在内核 5.19 中:
netfilter:nf_log:网络标头的偏移量不正确
NFPROTO_ARP 期望在网络偏移处找到 ARP 标头。
在 ARP 的特定情况下,HTYPE= 字段显示以太网标头目标 MAC 地址的初始字节。
netdev out: IN= OUT=bridge0 MACSRC=c2:76:e5:71:e1:de MACDST=36:b0:4a:e2:72:ea MACPROTO=0806 ARP HTYPE=14000 PTYPE=0x4ae2 OPCODE=49782
NFPROTO_NETDEV 出口挂钩还期望在网络偏移处找到 IP 标头。
修复:35b9395104d5(“netfilter:添加通用 ARP 数据包记录器”)
报告者:Tom Yan
签署者:Pablo Neira Ayuso
看来此修复程序并未向后移植到普通内核 5.10,可能是因为要修补的文件尚未在其他地方整合,因此位于不同的位置,或者只是由于向后移植而错过了该补丁。
固定后(例如:香草2017年5月19日):
ah = skb_header_pointer(skb, nhoff, sizeof(_arph), &_arph);
当不固定时(例如:原版 5.10.174,所以包括 Debian bullseye,除非打补丁):
ah = skb_header_pointer(skb, 0, sizeof(_arph), &_arph);
必须有人对此进行错误报告。同时,您可以尝试使用 Bullseye-backports 内核(例如当前:6.1.12-1~bpo11+1)保证不再有它了。
在今天的 Bullseye 内核 (5.10.162) 上进行了测试。只记录任何 ARP
table arp t {
chain cout {
type filter hook output priority filter; policy accept;
log
}
}
HTYPE=65535
当尝试访问 LAN 上不存在的 IP 地址时将记录该错误,因为它错误地使用了广播 MAC 地址的开头,而这正是补丁中所描述的使用内容。
应该在包linux-image-6.1.0-0.deb11.5-amd64-unsigned
日志中对内核进行相同的测试。HTYPE=1