Bad UI Design Sabotages Security of ASUS SoHo Routers

[L&LD]

Not even then,IMHO. No danger running multiple hardware firewalls in that scenario, and no reason to disable them either.

The reason is for performance. If a service isn't required (and behind another router, it isn't), then it should be disabled.

 

[sfx2000]

unless someone went out of his way to create a weird topology.

And normally we see them show up here

 

[L&LD]

The only potential setup I can think of would be someone who just wants to route two separate segments within his LAN, and does not need to isolate the segments - just route them together, without NAT. But that's not something I'd expect to see in a home network unless someone went out of his way to create a weird topology.

In a home network you can isolate by,
Kids/Games
Parents/Personal
Work/Financial
Guests/Not trusted devices

In an office network you can isolate by,
Guests
Vendors (visiting)
Financial
Sales
Servers, etc.

Using private IP addresses that are in range of each other or not, and selective use of Static Routing, you can build a network that one group doesn't (or cannot) interfere with another. Either in actual access allowed, or inadvertent collisions of network packets.

Having the firewall enabled in these situations in the secondary (and down) routers gives no advantages at all.

 

[sfx2000]

Using private IP addresses that are in range of each other or not, and selective use of Static Routing, you can build a network that one group doesn't (or cannot) interfere with another. Either in actual access allowed, or inadvertent collisions of network packets.

In the Office/Corporate space - VLAN's and binds to different SSID's (CorpWifi, CorpGuest, CorpVOIP as an example) is better handled by switches instead of routers...

 

[L&LD]

In the Office/Corporate space - VLAN's and binds to different SSID's (CorpWifi, CorpGuest, CorpVOIP as an example) is better handled by switches instead of routers...

Corporate maybe, but for mere office use? At what cost?

In either case, binding Wifi isn't the goal with the approach I suggested.

 

[sfx2000]

Corporate maybe, but for mere office use? At what cost?

In either case, binding Wifi isn't the goal with the approach I suggested

We're getting off track... feel free to open a new discussion thread.

Going back to the original purpose of the thread - it's a UI glitch that can potentially expose the router to the public internet...

I'm not seeing the report as a "real issue" other than misconfiguration of the device...

 

[jegesq]

In a home network you can isolate by...

In an office network you can isolate by.....Having the firewall enabled in these situations in the secondary (and down) routers gives no advantages at all.

It may provide no advantage, but it doesn't provide any disadvantage either....

And with all due respect, an enabled service that merely provides redundancy doesn't necessarily create a performance hit.

 

[L&LD]

It may provide no advantage, but it doesn't provide any disadvantage either....

And with all due respect, an enabled service that merely provides redundancy doesn't necessarily create a performance hit.

If a main router (R0) and a few secondary router (R1-R4) are connected as so; R0-P1 (LAN) to R1 WAN and R0-P2 (LAN) to R2 WAN...

Having the firewall enabled does create a performance hit when the packets are travelling through the WAN ports of the secondary routers (R1-R4).

 

[sfx2000]

If a main router (R0) and a few secondary router (R1-R4) are connected as so; R0-P1 (LAN) to R1 WAN and R0-P2 (LAN) to R2 WAN...

Hence, RMerlin's comment about advanced configurations, lol...

Having the firewall enabled does create a performance hit when the packets are travelling through the WAN ports of the secondary routers (R1-R4).

Shouldn't actually be that much - it just complicates things when maintaining configs - and introduces complexity when it's not needed...

 

[kvic]

In Linux routers, it doesn't matter if you have firewall on or off, all packets are going through the "firewall service". For a typical SOHO setup, firewall rules are little to nothing. So zero performance penalty regardless firewall being on or off..

 

[Nullity]

In Linux routers, it doesn't matter if you have firewall on or off, all packets are going through the "firewall service". For a typical SOHO setup, firewall rules are little to nothing. So zero performance penalty regardless firewall being on or off..

If your reply is in response to L&LD's statement that software firewalls create noticeable latency, I would agree. If it's software, regardless of function (firewall, NAT, QoS, AQM, etc), it is "slow" compared to hardware/ASICs, but even ancient CPUs process packets with minimal latency.

Anyone got some related data they could share?

 

[L&LD]

In Linux routers, it doesn't matter if you have firewall on or off, all packets are going through the "firewall service". For a typical SOHO setup, firewall rules are little to nothing. So zero performance penalty regardless firewall being on or off..

Zero penalty? I find that hard to believe. Why have an on/off switch then at all?

These are not desktop processors, these are soc's that lack actual compute power (relatively).

 

[Nullity]

Zero penalty? I find that hard to believe. Why have an on/off switch then at all?

These are not desktop processors, these are soc's that lack actual compute power (relatively).

I think you made the wrong analogy; a desktop CPU processes software just as a SoC CPU does. Hardware processing is a different thing... I think.

I agree with your criticism of "zero penalty" though, as there is surely some additional processing penalty, but whether that additional processing latency is statistically relavent... I dunno, but I think it is not.

 

[L&LD]

I think you made the wrong analogy; a desktop CPU processes software just as a SoC CPU does. Hardware processing is a different thing... I think.

Yes, your distinction is correct. I need to get some sleep time.

 

[kvic]

Maybe people can do experiments at home with a firewall setup for daily use. Benchmark speedtest dot net with firewall on. Then repeat with firewall off. See if there are any difference.

Not very scientific but with a fat pipe (>100 or maybe >500Mbit/s ?) to Internet. The results shall be indicative of firewall penalty..

 

[Nullity]

Maybe people can do experiments at home with a firewall setup for daily use. Benchmark speedtest dot net with firewall on. Then repeat with firewall off. See if there are any difference.

Not very scientific but with a fat pipe (>100 or maybe >500Mbit/s ?) to Internet. The results shall be indicative of firewall penalty..

I would expect the penalty to be within a few milliseconds, so local testing might be more conclusive.

mtr, traceroute, or ping might be useful tools but I dunno if their time measurement granularity is fine enough to get good results.



Back when I was reading about the HFSC QoS/traffic-shaping algorithm (introduced in 1997), the authors measured the the total, per-packet processing overhead to be <10 microseconds (which includes enqueueing, classifying, and dequeueing) on a 200Mhz Pentium Pro.
I am unsure how applicable this information is to the current conversation, but I think it is somewhat related.

 

[kvic]

Back when I was reading about the HFSC QoS/traffic-shaping algorithm (introduced in 1997), the authors measured the the total, per-packet processing overhead to be <10 microseconds (which includes enqueueing, classifying, and dequeueing) on a 200Mhz Pentium Pro.
I am unsure how applicable this information is to the current conversation, but I think it is somewhat related.

That's about 200 cpu cycles on the pentium pro. Quite indicative of the level of efficiency of the software of the same kind.

Netfilter has been in Linux for very long time and survive until now...something extremely efficiently implemented..

 

[Nullity]

That's about 200 cpu cycles on the pentium pro. Quite indicative of the level of efficiency of the software of the same kind.

Netfilter has been in Linux for very long time and survive until now...something extremely efficiently implemented..

Seems true enough.

https://en.m.wikipedia.org/wiki/Network_delay

I surely have an over-simplified understanding of this, but if an algorithm implemented in software can (20 years ago) process & queue/dequeue data in microseconds, that only leaves the delay of the interface's bitrate & time on the wire (or air).

I assume many of us experience quite a bit of "processing" delay with Deep Packet Inspection and Intrusion Detection/Prevention Systems that the ARM-based routers have migrated to. Queueing/bufferbloat probably plays a roll as well, though it's probably negligable on LAN-only traffic.



I do not see firewalling itself, which I define mostly as port blocking/forwarding & stateful NAT, as a big contributor to latency. Data proving otherwise is welcomed though.

 

[kvic]

Seems true enough.

https://en.m.wikipedia.org/wiki/Network_delay

I surely have an over-simplified understanding of this, but if an algorithm implemented in software can (20 years ago) process & queue/dequeue data in microseconds, that only leaves the delay of the interface's bitrate & time on the wire (or air).

I assume many of us experience quite a bit of "processing" delay with Deep Packet Inspection and Intrusion Detection/Prevention Systems that the ARM-based routers have migrated to. Queueing/bufferbloat probably plays a roll as well, though it's probably negligable on LAN-only traffic.



I do not see firewalling itself, which I define mostly as port blocking/forwarding & stateful NAT, as a big contributor to latency. Data proving otherwise is welcomed though.

Maybe DPI/IDP plus other bells and whistles are packaged as firewall products on the market. That's indeed lots of processing work to go through in such firewall service..

The firewall in Asus routers or most other linux home routers is using iptables which builds upon Netfilter framework. Regardless of any rule defined, every packet traverses through the Netfilter hooks when moving up/down the TCP/IP stack. If there is a deny/drop rule hit early in the process, it actually speeds up processing. If there are many rules or poorly written rules, it takes a bit longer.

How many rules do we expect in a typical SOHO environment? I don't know..I checked mine. I have 23 carefully hand-crafted rules in iptables. Ran a speedtest.net with firewall on/off on a 200 Mbit/s WAN.

Firewall ON 188.54/192.00. Firewall OFF 188.38/193.16. I guess it's a failed experiment as it tells me nothing about the overhead of firewall being on..

 

[RMerlin]

That's about 200 cpu cycles on the pentium pro. Quite indicative of the level of efficiency of the software of the same kind.

Netfilter has been in Linux for very long time and survive until now...something extremely efficiently implemented..

And yet, CTF provides a major performance improvement when you bypass the FORWARD chain (among other undocumented things).