De-bloating OpenWRT?

Blockquote

Blockquote

Blockquote

1 Like

"de-bloating" is kinda rude darling if you want you can compile your own OpenWrt iso with packages you need

3 Likes

Be careful with the word de-bloating. OpenWrt is very lean within the context of a modern routing OS.

That said, see this link if you want to remove packages to save space on your device:
https://openwrt.org/faq/no_space_left_on_device

This really isn't necessary -- OpenWrt is designed to be quite secure. Maybe elaborate on your concerns??

5 Likes

unnecessary packages and "de-bloating" for example?

if you talking the words like surface of attack you at least have master degree in network security and know what packages you need and what you can remove or again, just recompile OpenWrt from scratch to avoid any issues what so ever))0

first of all find and remove all "luci" marked packages through ssh it would be the first step in real security where you would not be needed using bloated software like firefox/chrome or any other of this tribe bro.

2 Likes

im not trolling you, luci packages are not even included in a snapshot builded iso's
you can see it installing any snapshot version of OpenWrt

4 Likes

I understand that. You'll see that the system has very few services except for those that are necessary.

Could you remove services and applications? Sure... but consider that the selection that is currently in there is already about as minimal as possible based on two things:

  1. minimize the storage and memory footprint while providing all the required functionality. This is so that OpenWrt can fit into embedded devices like consumer all-in-one wifi routers that have as little as 8MB flash and 64MB RAM. Things that are not necessary for core operations generally aren't included, although there are some things that some users may not need (for example, PPPoE support is included by default; you can exclude that if your ISP doesn't require it).
  2. OpenWrt is first and foremost designed to be a routing OS. Therefore, security is critical. While the platform isn't hardened to the level that would be expected for enterprise and government level operations, it is considered secure by design for most normal consumer and small business purposes.
2 Likes

In some respect, I can agree on you, that openwrt is somewhat "bloated" (excuse, pls). Thus, I practically always generate my own image, to omit (or include) certain modules. Until 22.03..., at least, also possible to drop the openwrt firewall, using iptables rules instead. Or to get rid of (most of) ipv6. Certain options can be used to reduce image size even further, which is my main goal. But also to simplify certain system setups. When you have a special taste, you need to take special actions. BTW, reducing included modules also reduces probability of having bugs.

You can still swap fw4 for fw3 aka 'firewall' or luci-ssl for luci, or wpad-mbedtls for hostapd-mbedtls. Space savings will be minuscule, but may save the day on 8MB devices.

netfilter more and more replaces iptables. All the PPP stuff I usually drop. Sometimes I also modify the standard Make file for a module, i.e. for squid or nginx, to omit/include certain Make options. But it very much depends upon the requirements.

I also want to point out that you should really evaluate the specific threat vectors from which you are trying to protect yourself. There may be specific packages that you remove out of an abundance of caution, but others that you may handle with additional firewall rules or the like.

I didn't mention LuCI (the web interface) earlier, but that is one that could be removed without difficulty. It would save space and reduce the attack surface by not having a lightweight webserver running (and it's known that this is a webserver that is not explicitly hardened for internet exposure; the firewall is setup to accept input only from the lan zone). The server is sufficiently secure as to be fine in a nominally trusted environment (i.e. your lan), so it's not like it's got known security vulnerabilities. But it's not strictly necessary as long as you're good with CLI or direct file editing for your configs, you could remove LuCI.

But... at the same time, what is your threat landscape? Is it from inside your network or from the internet? If inside, there are other methods you can use to further secure the system (firewall, VLANs, etc.). If it's from the internet, it's already pretty secure, but you could modify the firewall (as long as you know what you're doing) to customize for other scenarios that you feel are risky (the default config is considered secure as it rejects all unsolicited traffic ingress from the wan to the router and the network(s) behind it).

1 Like

Do you trust your own lan devices and users on your lan?

Please define this. What is your actual concern?

Over the internet?
An untrusted user on your lan?
A compromised device on your lan?
Someone hacking wifi?
Access to an Ethernet connection?
Physical access to the router itself?

That is a policy question only you can answer as 'functionality' is underdefined, one man's required functionality is another man's bloat...

Quick note, neither IPv6 nor nftables will go away, so sooner or later you might consider embracing these.... but that does not necessarily needs to be today.

But, what you can do is start by building your own firmware images so you have fine grained control over the features you want. The build system is pretty good in pulling in the required dependencies so make a config and then look at the config before building. Be aware though that with self build firmware you need to also build all packages you may want to install, as the public packet repositories are linked the the official builds.

The main purpose of my original question is to reduce attack surfaces, per removal of unecessary system packages, and system processes. That is it.

This seems to me unlikely to bear much fruit, if any, since the base install is already minimal by design. I think you’d need to compile your own build. You could then, for example, configure busybox to remove the modules you think you might not need. Although even the latter is going to be tricky because you’d need to verify those you think you might not need are not needed or likely to be needed in the future by scripts, since the scripts expect default busybox modules. So even that’s a bad idea.

And you're running in circles here, without actually voicing your real threat scenario, your actual concerns.

As pointed out rather early in this thread, luci (and opkg) is the only thing that's really easy to disable and which might be considered 'bloat', but you dismiss that immediately. While that's valid, it's a good show case that the definition of 'bloat' isn't as clear cut as it seems to be in your mind.

From the definition of a release image, there is no bloat. The OpenWrt images need to be as small as possible, while still providing what a significant chunk of users expect from a wireless router. Everything beyond that is split out into runtime installable packages.

If you're fishing for suggestions what can be removed, there might not actually be anything left - or phrased differently, this question is something only you can define for yourself - if you have to ask, the answer will be 'no'.

1 Like

I am not wanting to remove the GUI or opkg. Removing LuCI would be inconvenient when needing to make quick changes, and opkg would be bad from a security standpoint of not allowing updates.

I have specified the definition of 'bloat' above multiple times. I am not trying to save space, I have 512MB of storage.

I am trying to remove unecessary packages or processes. This reduces attack surface, lowers system utilization, etc. However, I don't know what those would be as I am not familiar with every single package OpenWRT has to offer that is default-installed.

That is a double edged sword, as updates might be a way to introduce compromised binaries as well...

Ambiguous question, as you likely expect a certain (undisclosed) functionality to remain, e.g. if your WAN link uses DHCP you can drop all PPP related packages and modules, but if it uses PPPoE you still might need DCHPv6 depending on your ISP's provisioning. But none of use knows this...

I fear all that is left is trial and error, and building maximally modular (so that everything that can be an installable package becomes one, so you can do trial and error of which components you need quicker without the need to build a fresh image every time).

The biggest reduction in attack surface is to disconnect the wan link and disable WiFi, but that comes with an almost complete loss in functionality.

Mind you, I do not argue that the OpenWrt default set is the minimal required set (it certainly is not as an example it contains PPP and DHCP capabilities) but I do think it is a reasonably balanced set with relative few on-by-default services.

Your assesment that more processes mean more exposure is flawed. It is like you say running nginx on 2 processors presents an unwanted exposure for you.