3

I am currently testing netfilter / nftables / nft. As a starting point, I have made a ruleset that drops nearly everything in and out, and have written the rules so that every dropped packet is logged.

As always, and as it probably has to be, I don't understand the very first thing the machine tries to do and that I notice in the logs:

... IN= OUT=enp0s3 ARP HTYPE=37 PTYPE=0x90bd OPCODE=21

According to this document:

  • Opcode 21 means MARS-Grouplist-Reply. Neither did I ever hear of it, nor did I find a single reference to it on the net, except in RFCs or IANA documents, but it is nowhere explained there.
  • HTYPE 37 means HFI hardware. As with the opcode, I have never heard of such a thing, nor did I find any explanation on the net. I am pretty sure that I don't have that type of hardware. In this case, the networking hardware is a virtual NIC in QEMU.
  • PTYPE 0x90bd: During today's research, I have seen a list of protocol types; unfortunately, I can't remember where. But anyway, 0x90bd for sure was not mentioned there.

Could somebody please explain what the opcode, the hardware type and the protocol type mean, and why the system in question wants to send such packets?

This happens in a vanilla debian Bullseye installation, up to date at the time of writing, in a virtual machine with virtualized standard x64 Intel hardware and virtio NIC.

Improve this question
0

1 Answer 1

Reset to default
2

This is a bug in Netfilter's ARP logs.

There was a bug report about this problem. It was discovered that ARP didn't log using the correct data (it used data from link layer header instead of ARP's network layer). A patch was committed to fix this a few days later and appeared in kernel 5.19:

netfilter: nf_log: incorrect offset to network header

NFPROTO_ARP is expecting to find the ARP header at the network offset.

In the particular case of ARP, HTYPE= field shows the initial bytes of the ethernet header destination MAC address.

 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 egress hook is also expecting to find the IP headers at the network offset.

Fixes: 35b9395104d5 ("netfilter: add generic ARP packet logger")
Reported-by: Tom Yan
Signed-off-by: Pablo Neira Ayuso

It appears this fix was not backported to vanilla kernel 5.10, possibly because the file to patch was not yet consolidated elsewhere so was in a different place, or this patch was just missed for a backport.

When fixed (eg: vanilla 5.19.17):

 ah = skb_header_pointer(skb, nhoff, sizeof(_arph), &_arph);

When not fixed (eg: vanilla 5.10.174, so including Debian bullseye's unless patched):

 ah = skb_header_pointer(skb, 0, sizeof(_arph), &_arph);

Someone has to make a bug report about it. Meanwhile you could try a bullseye-backports kernel (eg currently: 6.1.12-1~bpo11+1) which is guaranteed to not have it anymore.

Tested affected on today's bullseye kernel (5.10.162). Just logging any ARP

table arp t { chain cout { type filter hook output priority filter; policy accept; log } }

will log HTYPE=65535 when trying to reach a non-existent IP address on the LAN because it incorrectly uses the start of the broadcast MAC address and that's what is used as described in the patch.

The same test done with the kernel in package linux-image-6.1.0-0.deb11.5-amd64-unsigned logs instead HTYPE=1 as should be.

Improve this answer
5
  • Thanks a lot, +1 and accepted. I have come to the same conclusion in the meantime. I also had sent three bug reports (noticed a few more problem than in my question above) to the debian maintainers, but that was a waste of time, as usual. This is a catastrophic fail, and I can prove that it not only logs wrong data, but doesn't execute rules as it should, surely because of the same problem; this definitely is impacting security. However, as expected they didn't condescend to answering, and probably won't. I'll leave debian now after 15 or twenty years. Commented Mar 15, 2023 at 20:37
  • For later readers: In the meantime, I also had tried debian testing (bookworm) and can confirm that the issue is fixed there. However, I surely won't install testing, unstable or whatever on a machine that should act as firewall, and second, I have lost trust in debian, because a) I am pretty sure they already knew about the problems, but didn't care about it although it affects security (see comment above), and b) they obviously don't care about bug reports. Commented Mar 15, 2023 at 20:41
  • Two last, quick questions if you don't mind :-) Does the backports kernel you mentioned receive timely security updates? I'm a bit hesitant because the machine in question is a firewall, and because I've read that the testing branch does not receive timely security updates. Second, will the old userspace tools from the stable branch, especially nft, play well with the backported kernel? Please excuse the dumb questions, but I didn't work with backports before. Commented Mar 15, 2023 at 20:52
  • 1
    No, backport packages are not receiving any timely updates and surely accumulate security issues before a new one is out. As for testing, it's now frozen. Even sid stops behaving like a rolling-release during freeze, but is here to assist with testing becoming the next stable. (some information there: release.debian.org/bookworm/freeze_policy.html ) Commented Mar 15, 2023 at 21:33
  • Thanks a lot again. I had already read some of the relevant pages on the debian website, but missed the link you gave. Eventually I could use the backports kernel with security updates from unstable (at least for users of testing, debian recommends that security updates from unstable should be enabled; I haven't understood the rationale yet, but I'll look into it that evening). Commented Mar 16, 2023 at 18:49

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.