connlimit from wiki.nftables.org not working

Hi,

I am trying this (in Fedora 38 and Debian 12):

https://wiki.nftables.org/wiki-nftables/index.php/Meters#Doing_connlimit_with_nft

and I am getting this:

./connlimit-example:14:16-62: Error: Could not process rule: No such file or directory

		ct state new add @my_connlimit { ip saddr ct count over 20 } counter drop
		             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Why?

For the avoidance of doubt, please show the complete ruleset that you are attempting to load.

Additionally, compare the output of "uname -r" to the contents of the /lib/modules directory. Sometimes, people upgrade their kernels then forget to reboot before trying to load a ruleset that requires for one or more kernel modules to be newly loaded.

Kerin Millar

# cat connlimit-example 
#!/usr/sbin/nft -f

flush ruleset

table ip filter {
        set my_connlimit {
                type ipv4_addr
                size 65535
                flags dynamic
        }

        chain output {
                type filter hook output priority filter; policy accept;
                ct state new add @my_connlimit { ip saddr ct count over 20 } counter drop
        }
}

# nft flush ruleset
# nft list ruleset
# ./connlimit-example 
./connlimit-example:14:16-62: Error: Could not process rule: No such file or directory
                ct state new add @my_connlimit { ip saddr ct count over 20 } counter drop
                             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
# nft list ruleset
#
# nft -V
nftables v1.0.6 (Lester Gooch #5)
  cli:          editline
  json:         yes
  minigmp:      no
  libxtables:   yes
#

Everything is up-to-date and rebooted (many times).

# lsmod | grep -E '^nf'
nft_flow_offload       16384  0
nf_flow_table_inet     16384  0
nf_flow_table          40960  2 nft_flow_offload,nf_flow_table_inet
nf_conntrack_netlink    57344  0
nft_limit              16384  0
nf_log_syslog          24576  0
nft_log                16384  0
nft_nat                16384  0
nft_reject_ipv6        16384  0
nf_reject_ipv6         20480  1 nft_reject_ipv6
nft_reject_ipv4        16384  0
nf_reject_ipv4         16384  1 nft_reject_ipv4
nft_reject             16384  2 nft_reject_ipv6,nft_reject_ipv4
nft_ct                 20480  0
nft_masq               16384  0
nft_chain_nat          16384  0
nf_nat                 57344  3 nft_nat,nft_masq,nft_chain_nat
nf_conntrack          167936  7 nf_nat,nft_flow_offload,nft_ct,nft_nat,nf_conntrack_netlink,nft_masq,nf_flow_table
nf_defrag_ipv6         24576  1 nf_conntrack
nf_defrag_ipv4         16384  1 nf_conntrack
nf_tables             307200  11 nft_reject_ipv6,nft_reject_ipv4,nft_flow_offload,nft_ct,nft_log,nft_nat,nft_masq,nft_chain_nat,nft_limit,nf_flow_table_inet,nft_reject
nfnetlink              20480  2 nf_conntrack_netlink,nf_tables

I can only induce the same diagnostic in the case that connlimit support is missing.

# zgrep NFT_CONNLIMIT /proc/config.gz
# CONFIG_NFT_CONNLIMIT is not set

With that in mind, are you able to "modprobe nft_connlimit" at all?

Kerin Millar

Same here.

It returns a fatal error that the module is not found.

All I find when searching is that the module is missing in different distros and some references to CVE-2022-32250 which doesn't clarify much:

https://research.nccgroup.com/2022/09/01/settlers-of-netlink-exploiting-a-limited-uaf-in-nf_tables-cve-2022-32250/#rip-control-by-triggering-garbage-collection

I wonder if distros have deliberately removed the module because of the CVE or if there is something else.

What would you advise?

It is the same because I compiled a kernel with the feature disabled in the course of evaluating my theory.

Consequently, you will not be able to use this feature of nftables.

It would be highly irresponsible of them. For one thing, the removal of a Netfilter feature would result in dependent rulesets outright failing to load upon upgrading the kernel and rebooting. For another, that vulnerability is almost two years old and has long since been addressed.

I'll assume that all of the following holds true.

- the affected distro releases have not yet reached end-of-life
- you are running a standard, vendor-provided kernel package
- all of your packages are up to date

In that case, I would advise you to file bugs against the affected distros and demand that those responsible for their kernel packages rectify this. For any of the CONFIG_NFT_ prefixed options to be disabled in a mainstream distribution is appalling. Rather, they should all be set to "m" so that the functionality of each is made available in the form of a loadable kernel module.

Kerin Millar

I will try. Thanks!