As you might know, OpenWrt switched to nftables based firewall. We were still keeping the iptables to limit the changes during the 7.0 release. We were testing the switch and migrating integration of Turris Sentinel to nftables for some time. Now we believe we are ready to make the switch. We tested that everything works, the only possible problem (that can’t really be solved) is if you have some custom scripts relying on iptables. You have to migrate those by yourself.
The switch is happening now in hbl branch right now and you are welcome to test it. We are looking forward to your feedback! Our plan is to test it in hbl for now, It wouldn’t be hitting hbk this week, but no promises about the next one.
Turris OS 7.1 with switch to nftables will be the last big release before moving to Turris OS 8.0.
one thing I’m pretty sure it will not work after the passage to nftables is port knocking with fwknopd + luci-app-fwknopd because that daemon uses iptables rules and it is not converted to nftables yet (see https://github.com/mrash/fwknop/issues/107. Maybe you should mention it in the release notes if someone is using it.
Port knocking is security by obscurity the same as changing the default port of a service. It doesnt add much security in recent days. Bots will scan and try their best anyway. And its just a hassle for you to knock on your own door.
Hello @AreYouLoco, if it’s worth it or not is not the scope of my post, I’ve report it because the passage to nftables can create unexpected issues with fwknopd, it’s better if people know it in advance. From a security point of view, I consider port knocking another layer on top of the others. The security of your device cannot be based entirely on that alone but it helps to have better security especially with a modern daemon with SPA. In case of a 0-day vulnerability I still prefer my sshd or wireguard ports to appear filtered to a scanner instead of open, maybe I can’t update the device instantly. Is it an hassle ? Yes and no, for example, it’s not a big deal to launch another app before you start your wireguard app on your smartphone, but I agree it’s a scenario not always applicable and can be tedious.
table inet filter {
set fwknop-input { type ipv4_addr . inet_service ; size 10 ; flags timeout ; }
chain INPUT {
type filter hook input priority 0; policy accept;
…
# fwknop port
iifname “eth0” meta l4proto udp udp dport 62201 counter accept
meta nfproto ipv4 ip saddr . tcp dport @fwknop-input accept
# ssh
iifname “eth0” meta l4proto tcp tcp dport 22 ct state established counter accept
# failsafe ssh from a secured host
iifname “eth0” meta l4proto tcp tcp dport 22 ip saddr ip-secure-host counter accept
iifname “eth0” meta l4proto tcp tcp dport 22 counter drop
…
(this is actually on a debian LXC container running inside my MOX)
fwknop is ipv4 only, but not really needed on ipv6: choose a randomly address in you ipv6 range for ssh access (you have at least a /56, do you? or think about changing ISP)
I guess that this topic was more about informing that Turris Team migrated their Sentinel and minipots so they finally work with nftables. Not careing about some random bizzare packages that people use. Also many more openwrt packages are still not compatible. That shouldnt be a show stopper for the release.
If you want to see them working on the issues you are reporting in this thread you need to report them through their Gitlab or send them to their support email.
As per other user’s feedback, I had the switch to nftables via automatic updates on my MOX and everything seems OK. I haven’t done thorough checks though, or looked into Sentinel for example. Everyday use, so far so good. Thanks.