I reported this issue on GitHub some time ago, but no one has taken on the task of fixing it or even providing an explanation. Looking at it historically from another perspective — for example, offloading — MediaTek and Realtek unfortunately still have underdeveloped drivers, even on older devices. Because of this, it’s better not to use offloading at all in OpenWrt, and this feature shouldn’t even be visible if it usually doesn’t work 100% as intended.
Another example: downloading an image from:
with only the default packages, without making any changes, flashing it through U-Boot, and then checking with the command:
netstat -tunlp
— reveals that, in various releases, certain services are exposed to the WAN. This should not be the case, because no other networking device behaves like this by default. From a security standpoint, these services should be LAN-only by default, and if someone wants to expose them, they can do so manually. Most people have no need to expose services like NTP, uHTTPd, Dropbear, and so on to the internet, yet they can be exposed by default.
OpenWrt should follow a different policy and prioritize security. I understand modularity and that this is hardware for people who like to dig into the details — but the foundation should be different, with security as the priority.
I apologize if this sounds like nitpicking, but my intention with this additional forum post is to draw attention to what should truly be the top priority — security and well-polished functionality.
If you don’t explicitly bind Dropbear to the LAN interface, it will listen on all interfaces by default, including WAN. This behavior applies to many packages in OpenWrt.
Now that everything is set up, I’m not going to go back and check which exact OpenWrt version this occurred in — sorry.
The statement above:
If you don’t explicitly bind Dropbear to the LAN interface, it will listen on all interfaces by default, including WAN. This behavior applies to many packages in OpenWrt.
— The statement above is based on facts and should give you something to think about.
The default firewall on v24.10 and v23.05 both drop inbound traffic from the wan, so I’ll consider “SSH is open to the public internet”, as well as any other service, moot.
I agree that the firewall in v24.10 and v23.05 blocks inbound traffic from the WAN by default. However, this is not explicitly defined in the packages themselves, so it’s easy to make configuration mistakes if you assume services are bound only to LAN interfaces.
Because of this, you always need to be aware and check each package’s listening interfaces, or manually add configuration lines to restrict them.
That’s why I believe that having services listen on all interfaces by default is risky — it leaves fewer layers of protection and increases the risk of exposure in case of misconfiguration.
You’re right, the security concern is general and not device-specific. However, my experience with the Flint 2 highlighted these particular issues in practice, which prompted me to raise them here.
I agree that opening a broader discussion about security policies in OpenWrt would be valuable, but for now, I wanted to focus on this concrete case to help improve it step by step.
"if you assume that the services are associated only with LAN interfaces." -- why would I assume that when I can read that the default dropbear config says otherwise?
I understand your point — Dropbear's default configuration explicitly states that it listens on all interfaces, so technically, it's documented and users can read it.
However, no other networking device I’ve seen works this way. Most are “secure by default” and bind management services only to LAN, unless explicitly changed. This is the safer approach, as most users never need to change it, and it ensures a secure starting point even if someone didn’t read the documentation. Security-by-default is a widely accepted standard in networking devices.
I don't want to start an argument; I just want to emphasize that security should be a cornerstone of OpenWrt, not something that depends on whether the user reads the documentation. That's why I brought it up as an issue worth considering. Anyway, this isn’t really the topic of this thread, so let’s get back on track.
While I don’t think the concern is cause for change because of default firewall rules I should note I’ve always switched dropbear/SSH to lan as one of the first things I do on clean flashes. I have a whole list of things I change but thats definitely one. As others said it’s moot because of nftables rules.
That’s exactly the point — this default is misleading and counterintuitive when compared to the general principle that a networking device should be secured at every layer.
I agree that changing Dropbear to LAN-only is a good first step after a clean flash.
If experienced users immediately make this change, it’s a clear sign it should be the default — it’s safer for everyone, and experienced users will always change it anyway because they’re aware of the risk.
Firewall rules are an important layer, but they’re still just one layer and as with any single layer of defense, if it fails or is misconfigured, the exposure risk increases.
So why is OpenWrt still stuck with defaults that aren’t aligned with the widely accepted “secure by default” principle used in virtually every other networking device, which everyone changes anyway?
That’s why the entire OpenWrt system should follow the “secure by default” principle consistently at every layer, making security the cornerstone of OpenWrt.
The same principle should apply to other default packages like NTP, uHTTPd, and others to achieve full default consistency across the entire system.
Can someone please close this thread and kick the user.
This is obviously bogus. Because: counter example.
More or less every effing service you install on Linux listens to all interfaces and all addresses by default and a user has to restrict that by them self
This just plain stupid pseudo security concerns are of course ignored because it's a waste of time.
A nicer way to say it is perhaps that his concern has been evaluated and it is not a cause for changing the default config. But yea I’d agree to close the thread rather than start an argument.
Sorry I have to disagree but the OP clearly shows lag of understanding and will to accept that he just don't get it. I have no need to be polite if someone just waste time for everybody else.
And all these wannabe security dudes just annoy me.
Yes, if OpenWrt would be a pure router os. So no switch layer2 stuff, no dhcp no ntp not firewall no nat no nothing. Then and only then yes it would make sense to define a management interface and except for bgp for instance nothing needs to be exposed on (public) interfaces.
But OpenWrt is a generic network os so it makes far more sense to listen on all interfaces and using the firewall zones to restrict that.
What OP also just ignores that the proposed “fix” breaks the moment a user modifies the network config.