0

I am migrating rules from iptable's to nftable's by following Moving from iptable to nftable

I now have few IPs and ports block rule in place along with a string based iptable rules but by using the built-in iptable translation rule I am able to covert the rules from iptable to nftable but the string based rules which were in place in iptable are commented in nftables after translation. Below is the nftable rule after translation

    add rule ip filter INPUT tcp dport 1024-65535 counter accept
    add rule ip filter INPUT udp dport 1024-65535 counter accept
   65535 -j DROP
    # -t filter -A INPUT -p udp -m udp --dport 234 -m string --string abc.exe --algo bm --to 65535 -j DROP
    # -t filter -A INPUT -p udp -m udp --dport 234 -m string --string def.exe --algo bm --to 65535 -j DROP
    # -t filter -A INPUT -p udp -m udp --dport 234 -m string --string hij.exe --algo bm --to 65535 -j DROP
    add rule ip filter INPUT icmp type echo-reply ct state new,related,established  counter accept
    add rule ip filter INPUT icmp type echo-request ct state new,related,established  counter accept
    add rule ip filter INPUT icmp type destination-unreachable ct state new,related,established  counter accept
    add rule ip filter INPUT icmp type time-exceeded ct state new,related,established  counter accept

Need help on how to convert string based iptable rules to nftable rules, and if it fails like above which log do I refer to.

1 Answer 1

0

There is currently no equivalent in nftables, the string match is currently in the list of unsupported extensions. All these unsupported extensions (and probably also some supported ones) won't be translated into nftables since they use a special feature that cannot be expressed just with nftables bytecode (try nft -a --debug=netlink list ruleset to see bytecode) nor is implemented in kernel as native nftables module, so the translating tool won't even try.

If you know more about the protocol and can expect to find the string at a fixed location in the packet there are workarounds to do the same using raw payload expressions with an example there.

Else you can just mix nftables and iptables (including iptables-nft) rules as long as you use different table names in nftables to not clash with iptables-nft (which is probably in use). There is yet no plan to phase out iptables (at least the iptables-nft implementation, perfectly able to use the various xtables modules like string).

Here the table t is chosen, so it won't clash with the table filter. nftables gets its input chain (arbitrarily called c_in) at priority 10 so iptables's INPUT chain which hooks in the same place takes precedence at its fixed priority 0. Leaving priority at 0 gets an undefined order between which chain (iptables' or nftables') runs first. It doesn't matter for dropping/accepting rules between tables. The cases where it does matter is when splitting the rules like is done here (but for this specific case, there's nothing special about the order so it's fine), and for altering rules or rules with side effects: adding an element in an nftables set or an iptables companion ipset and then dropping the packet isn't the same as dropping the packet first (and then nothing).

nft add table ip t
nft add chain ip t c_in '{ type filter hook input priority 10; policy accept; }'

nft add rule ip t c_in tcp dport 1024-65535 counter accept
nft add rule ip t c_in udp dport 1024-65535 counter accept
nft add rule ip t c_in icmp type echo-reply ct state new,related,established  counter accept
nft add rule ip t c_in icmp type echo-request ct state new,related,established  counter accept
nft add rule ip t c_in icmp type destination-unreachable ct state new,related,established  counter accept
nft add rule ip t c_in icmp type time-exceeded ct state new,related,established  counter accept

iptables -t filter -A INPUT -p udp -m udp --dport 234 -m string --string abc.exe --algo bm --to 65535 -j DROP
iptables -t filter -A INPUT -p udp -m udp --dport 234 -m string --string def.exe --algo bm --to 65535 -j DROP
iptables -t filter -A INPUT -p udp -m udp --dport 234 -m string --string hij.exe --algo bm --to 65535 -j DROP

Sorry I don't know what to do about:

   65535 -j DROP

which looks like a typo or a translation error by the tool.

When interaction between both worlds is needed, "messages" can be passed by using marks . That's a case where priority matters. For example, if the drop action should be done only in nftables for rule management reasons, this could be used instead, keeping in mind that iptables' filter/INPUT gets priority over nftables' t c_in here:

iptables -t filter -A INPUT -p udp -m udp --dport 234 -m string --string abc.exe --algo bm --to 65535 -j MARK --set-mark 0xdead
iptables -t filter -A INPUT -p udp -m udp --dport 234 -m string --string def.exe --algo bm --to 65535 -j MARK --set-mark 0xdead
iptables -t filter -A INPUT -p udp -m udp --dport 234 -m string --string hij.exe --algo bm --to 65535 -j MARK --set-mark 0xdead

And insert this nftables rule before the short-circuiting ...established... rules at the place the string rules were initially:

nft add ip t c_in meta mark 0xdead drop
2
  • Thank you @AdminBee Commented Aug 28, 2021 at 15:55
  • @user17833 doesn't matter but for the record, A.B != AdminBee
    – A.B
    Commented Aug 28, 2021 at 15:59

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .