Sanity check custom “New not syn” fw4 rules

I’m looking to implement a couple of interesting rules that @lleachii mentioned here but in fw4.

config rule
	option proto 'tcp'
	option name 'Block_In_Not_SYN'
	option src '*'
	option target 'DROP'
	option extra '! --syn -m conntrack --ctstate NEW'

config rule
	option name 'Block_FWD_Not_SYN'
	option proto 'tcp'
	option src '*'
	option dest '*'
	option target 'DROP'
	option extra '! --syn -m conntrack --ctstate NEW'

I used iptables-translate to convert the rules from the linked blog post and added them to /etc/nftables.d/

# We're not behind another router
# https://www.frozentux.net/iptables-tutorial/chunkyhtml/x6249.html

chain not_syn_input {
        type filter hook input priority filter - 1; policy accept;
        tcp flags != syn / fin,syn,rst,ack ct state new counter drop comment "New not syn input"
}

chain not_syn_forward {
        type filter hook forward priority filter - 1; policy accept;
        tcp flags != syn / fin,syn,rst,ack ct state new counter drop comment "New not syn forward"
}
  1. Is this the best/correct way to add such rules in fw4? I don’t see how they can be added via Luci or config now that ‘option extra’ is gone.

  2. Do these rules effectively match up with the fw3 rules above, including the increased priority?

You can make it into prerouting in one rule.
/etc/nftables.d/strict-syn.nft

chain mangle_prerouting {
        type filter hook prerouting priority mangle; policy accept;
        iif != "lo" ct state new tcp flags != syn / syn,fin,ack,rst counter drop
}

(meta examination is faster than skb read)

The problem is nat traversal mechanisms that may need to open connection with synack.

or easier:

sysctl net.netfilter.nf_conntrack_tcp_loose=0 | tee -a /etc/sysctl.conf
2 Likes

Thank you! I think I’ll go with your prerouting suggestion and keep an eye on things. If all goes well I’ll probably go with the sysctl.conf edit.

You can stuff all four to measure nothing slips past sysctl or prerouting.

The sysctl.conf edit should take precedence over the firewall rule, correct? So, if the other rules trigger then it’s insufficient. Is that the idea?

According to documentation it prevents opening connection with synack.

1 Like

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.