Release of nftables version 0.9.2

Took place release of the packet filter nftables 0.9.2, which is being developed as a replacement for iptables, ip6tables, arptables, and ebtables through the unification of packet filtering interfaces for IPv4, IPv6, ARP, and network bridges. The nftables package includes user-space packet filtering components, while the kernel-level functionality is provided by the nf_tables subsystem, which has been a part of the Linux kernel since version 3.13. The necessary changes for the release of nftables 0.9.2 are included in kernel version 5.3.

At the kernel level, only a general interface is provided that is independent of any particular protocol and offers basic functions for extracting data from packets, performing operations on the data, and managing flows. The filtering logic and protocol-specific handlers are compiled into bytecode in user space, after which this bytecode is loaded into the kernel via the Netlink interface and executed in a special virtual machine similar to BPF (Berkeley Packet Filters). This approach significantly reduces the amount of filtering code running at the kernel level and moves all parsing rules and protocol handling logic into user space.

Key innovations:

• The ability to check the port number from the transport layer packet header regardless of the protocol type at the fourth level:

  add rule x y ip protocol { tcp, udp } th dport 53

• Support for expiration time recovery of item sets:

  add element ip x y { 1.1.1.1 timeout 30s expires 15s }

• The ability to check individual options (lsrr, rr, ssrr, and ra) from IPv4 packets:

  add rule x y ip option rr exists drop

  For routing options, it is possible to check the fields type, ptr, length, and addr:

  add rule x y ip option rr type 1 drop

• In expressions, network prefixes and address ranges are now permissible:

  iifname ens3 snat to 10.0.0.0/28
  iifname ens3 snat to 10.0.0.1-10.0.0.15

• Support for using variables in chain definitions:

  define default_policy = accept
  add chain ip foo bar { type filter hook input priority filter; policy $default_policy }

• Specifying the priority of a chain can now be done both in numeric and symbolic form:

  define prio = filter
  define prionum = 10
  define prioffset = "filter - 150"

  add table ip foo
  add chain ip foo bar { type filter hook input priority $prio; }
  add chain ip foo ber { type filter hook input priority $prionum; }
  add chain ip foo bor { type filter hook input priority $prioffset; }

• Support for the synproxy module has been implemented. For instance, to protect TCP port 8888 with synproxy, the following set of rules can be used:

  table ip x {
  chain y {
  type filter hook prerouting priority raw; policy accept;
  tcp dport 8888 tcp flags syn notrack
  }

  chain z {
  type filter hook forward priority filter; policy accept;
  tcp dport 8888 ct state invalid,untracked synproxy mss 1460 \
  wscale 7 timestamp sack-perm ct state invalid drop
  }
  }

• To define expected additional connections related to the current connection in the conntrack table, which are applicable in protocols and scenarios requiring multiple connections, policies can now be defined through standard rule sets. For example, to specify the expected subsequent connections to TCP port 5432 after connections to port 8888, the following rules can be defined:

  table x {
  ct expectation myexpect {
  protocol tcp
  dport 5432
  timeout 1h
  size 12
  l3proto ip
  }

  chain input {
  type filter hook input priority 0;
  ct state new tcp dport 8888 ct expectation set myexpect
  ct state established,related counter accept
  }
  }

Source: opennet.ru