Ah, sorry I was not clear, my question is what fraction odf routers in the wild are still using the default passwords (secure or insecure).
That should probably brought up as an issue with that ISP's security team... but that is outside of the scope of this list
Not sure, I believe they also sell abroad, but I really brought them up as an example for a commercial router manufacturer.
This is completely out of scope IMHO. Let's skip going down that tangent, please.
I am sure the next tie you will come prepared... over here most routers come with >= 1 ethernet cable in the box... but that might different in other places.
I am just an OpenWrt user, so I am not the right party to address such proposals towards, but personally I really really like the current design, where there is zero chance of rooting one's router over the air, while those with physical access can do everything.
It is also slightly bad news as it implies that your facts might not be as recent/up-to-date as desirable
??? All you need is a VPS with either a fixed IP address and/or sufficient flexible (dynamic)-DNS, as I see this this is a question of $$$ more than on whether side of the "law" you operate, no?
Well, but we talking about this in the context of a new application/service you develop and that users need to "know about" in some way or the other, so maybe adding how to deal with firewalls in different levels of restrictiveness to the place users finds out about how to use your application would solve this conundrum?
Again, my argument is that even a bug-free, working as designed upnp might be considered an unacceptable security compromise, independent to the fact that software rarely is bug-free even after years of use and debugging (hopefully the un-handled corner-cases get rarer over time though).
Yes, the onus is on those trying to deploy apps/services that require changes to the default configuration, but once you accept that pressing one button in a GUI more does sound manageable to me, no?
I have no idea, in your case I would propose you test the different ones and simply describe how to configure those to cooperate with your application. Bonus points for explicitly spelling out the security<->convenience trade-off this entails, so that users can make an informed decision.
Yes, and I fully accept that from your perspective this seems a reasonable trade-off. I do question however if that assessment generalizes to all existing or potential OpenWrt users.
For sure, as you seem to only look at the part where an upnp system might be exploitable by working out of spec, while ignoring the concerns that upnp even according to spec can be considered a security problem.
Maybe, maybe not, but without consent from the core developers (to be clear, that is not me, I am merely a normal user) this whole thing is not going to go far...
IMHO that would be an argument against installing it by default if it might cause people to casually enable it without researching the issue sufficiently to be able to make an informed decision about the involved trade-off.
Go wild, develop and offer something ;). Feature request, make it so that the network admin needs to grant any request (either forever of for 24 hours) and make such grants as restrictive as possible (linking to MAC address?)....
Well ATM it will be:
1: click on update sources
2: type in luci-app-upnp
3: click install
that seems not that much harder, no?
Not sure this would be any worse than commercial router interfaces... (but I tend to only help install OpenWrt for users that explicitly ask for it).
Maybe you spould have put the rest of the family on omnia's/mox's as well, as turris OS aims to being a secure by default OpenWrt-based distribution that caters to non-expert users.... (disclaimer, happy turris omnia user myself, still running TOS, since the automatic updates were the main attraction and these require TOS).
Compare to disabling a stateful firewall completely? Yes, compared to not allowing holes? No. Compared to manually poked holes? Debatable.
You are missing the point, all applications on the allow-list or even on all internal hosts can now poke arbitrary holes into the firewall, all in that name of convenience...
No, in the first case there is only one limited hole and an mischievous application on the same host will have to search and find that before abusing it, in the second case all it needs to do is ask nicely...
Engineering by wishful thinking? This does nothing for the case of malevolent internal application abusing the capability.
Except that the whole functionality is an attack vector.
Except it is the network admin that needs to be asked here... by all means implement that functionality and then ask for it to be installed and enabled....