updating iptables/ipset to current versions

[vtol]

Can iptables/ipset be updated to current versions and remain after firmware update or do they have to come (pre-)compiled with the firmware?

Asus-Merlin
iptables v1.4.15 (2012)
ipset v6.32

Source
iptables-1.6.2
ipset v6.36

 

[ColinTaylor]

They are part of the firmware. They cannot be updated independently.

 

[vtol]

Ach well, one would expect Asus to keep crucial firewall components up to date...

Makes me wondering just how reliable the Asus firewall really is...

 

[vtol]

How about nftables, can those be installed?

https://www.netfilter.org/projects/nftables/index.html
https://wiki.nftables.org/wiki-nftables/index.php/Why_nftables?

 

[Martineau]

How about nftables, can those be installed?

https://www.netfilter.org/projects/nftables/index.html
https://wiki.nftables.org/wiki-nftables/index.php/Why_nftables?

Nftables

 

[ColinTaylor]

Ach well, one would expect Asus to keep crucial firewall components up to date...

Makes me wondering just how reliable the Asus firewall really is...

iptables/ipset are just userland interfaces into the kernel, so the version of those components is irrelevant from a security point of view.

 

[vtol]

Nftables

I c, Asus is not really into modern kernels then

 

[vtol]

iptables/ipset are just userland interfaces into the kernel, so the version of those components is irrelevant from a security point of view.

I am not sure to concur on that statment by looking at the changelogs of iptables and related libraries for those 5+ years.

And it does not boost confidence that Asus is deploying kernel version 2.6.36 which is deprecated and generally considered as obsolete and out of date. And that I would consider relevant from a security point of view however.

 

[Martineau]

I c, Asus is not really into modern kernels then

Well clearly not for 'legacy' routers, but the RT-AC86U which ironically does have a newer kernel, doesn't (currently) support SNMP/IPTraffic - so developers have a real headache in supporting the Asus design decisions.

 

[ColinTaylor]

And it does not boost confidence that Asus is deploying kernel version 2.6.36 which is deprecated and generally considered as obsolete and out of date. And that I would consider relevant from a security point of view however.

The kernel version has been discussed many times in these forums. The short answer is that it's not down to Asus, Netgear, et al. because they can only work with the SDK provided by the hardware designer, in this case that's Broadcom.

However, IIRC the RT-AC86U is a new platform and has a newer kernel.

 

[vtol]

The kernel version has been discussed many times in these forums. The short answer is that it's not down to Asus, Netgear, et al. because they can only work with the SDK provided by the hardware designer, in this case that's Broadcom.

However, IIRC the RT-AC86U is a new platform and has a newer kernel.

Appreciate the input. Perhaps time to shop for a new router then, something like the Turris Omnia

 

[RMerlin]

Ach well, one would expect Asus to keep crucial firewall components up to date...

Nothing critical about the iptables user-space tools, what matters is the kernel portion. That portion cannot be upgraded.

The userspace tools are only used to create and manage kernel entries, so they're not a security liability.

 

[RMerlin]

Well clearly not for 'legacy' routers, but the RT-AC86U which ironically does have a newer kernel, doesn't (currently) support SNMP/IPTraffic - so developers have a real headache in supporting the Asus design decisions.

The problem lies in the Broadcom proprietary drivers, not the kernel version itself. net-snmp causes syslog to be flooded with MDIO errors on the RT-AC86U. Whether it's Broadcom's API being non-standard or net-snmp not being able to deal with newer hardware (net-snmp barely had any development over the past 5 years), I don't know.

As for IPTraffic, that code is old and badly written. It pokes into opaque kernel structures, something no longer possible since 3.x. Even the 2.6.36 support was broken, and I had to fix it at the time. To fix it for kernels newer than 3.x would require a complete rewrite of that module.

 

[RMerlin]

I am not sure to concur on that statment by looking at the changelogs of iptables and related libraries for those 5+ years.

And it does not boost confidence that Asus is deploying kernel version 2.6.36 which is deprecated and generally considered as obsolete and out of date. And that I would consider relevant from a security point of view however.

This is Broadcom's call, not Asus's. Broadcom's SDK is based on 2.6.36 for those models, because that SDK dates back to 2012. Manufacturers cannot upgrade the kernel.

Every single router out there based on the same SDK is also using 2.6.36, be it from Netgear, Linksys or anyone else.

Broadcom's new HND platform is based on 4.1.21, so once again every manufacturer releasing products based on the same platform will also be using 4.1.21.

 

[vtol]

Nothing critical about the iptables user-space tools, what matters is the kernel portion. That portion cannot be upgraded.

The userspace tools are only used to create and manage kernel entries, so they're not a security liability.

Duly noted with thanks. Being stuck with an obsolete and outdated kernel though got me worried and thinking of procuring another router, perhaps without Broadcom components.

 

[RMerlin]

Duly noted with thanks. Being stuck with an obsolete and outdated kernel though got me worried and thinking of procuring another router, perhaps without Broadcom components.

Qualcomm will have the same "issues". Broadcom's HND is on 4.1.21, while Qualcomm's newest is still on 3.something.

 

[vtol]

Why those wireless chipset manufacturers are dictating the OS kernel version is beyond my grasp. Instead their driver development should keep pace with the kernel development. It is not like the OS is run on the wireless chipsets.

Again, thanks for the all the valuable input/insight/clarification

 

[RMerlin]

Why those wireless chipset manufacturers are dictating the OS kernel version is beyond my grasp.

Making kernel changes requires complete revalidation from all of their partners. You can absorb that extra cost when selling a 300$ router, but not when it's a 100$ model.

In Asus's specific case (since it's the one I'm most familiar with), a kernel change would imply:

1) Broadcom needs to update their wireless driver to deal with any API changes - there were a few in 2.6.39 for instance
2) Broadcom needs to update the rest of their SDK to deal with the change (for instance, might require a newer iptables or iproute2 package)
3) Broadcom need to test all of their SDK, before pushing it to their partners.

Then from Asus:

1) Asus need to merge any change to the driver into their own copy of the wireless driver (which they might have customized)
2) Asus need to update iptables/iproute2/etc... if necessary
3) Asus need to ask TrendMicro for new kernel modules for their DPI engine
4) Asus need to ask Tuxera for new kernel modules for their ntfs/hfsplus driver

Then from Trend Micro:

1) Update API
2) Test changes
3) Push to their partners

Then from Tuxera:

1) Update API
2) Test changes
3) Push to parnters

Then back to Asus:

1) Test new Trend Micro DPI engine, adjust their code if necessary
2) Test new Tuxera driver, adjust their code if necessary
3) Test everything together


I would guess that going through all of this would take several months, at which point the model might no longer be a mainstream one and be moved to maintenance mode. In addition to how much it would cost the engineers from all these companies to deal with that work.

In short: it's not realisticaly possible.


Note that this is the same thing with smartphones. When smartphones get a new Android release, they generally keep the same kernel version that they had with the previous version. That's why my Nexus 5X running Android 8.1 still runs the 3.10.73 kernel for instance.

 

[RMerlin]

Additional note: while using an LTS kernel release greatly helps (since they are fewer major changes), they still might require changes from everyone involved, as kernel structures can possibly change. I took a look at possibly upgrading 4.1.21 to the latest 4.1 release for instance, and the length of the changelog scared me from even attempting it...

So what manufacturers generally do is they backport specific patches. I've myself backported a number of kernel security patches over the years. The kernel version might not change, but you can often still patch security issues that way. The 2.6.22 kernel used by Asus's Broadcom MIPS models for instance has received a LOT patches over the years (most of them coming from the Tomato community, and a few from myself in my own firmware).

 

[vtol]

Sure, that is the development (time/cost) involved, which they seems to be happy to spend (on updates) when it is Windows though. MS is changing lot of things bi-annular since the inception of W10.

Not sure about MacOS/IOS but since it has spread during the past few years it might be a similar picture to the Windows arena, also considering that Apple releases basically a new OS annually.

Good that there are at least such enthusiast providing patches but that can hardly be the future - to be stuck in stone age (which 5 years IT accounts for these days).

What would be the development of the Linux kernel worth if not being utilized properly and in a rather timely manner? But that is perhaps rather a philosophical question than a practical one.

I am glad that my Android 8 is at least at 4.4.78-perf+ kernel, now that you mentioned it

N.B. When starting this thread I did not mean to steal/occupy your valuable time.