Suggestions on securing x86/64 22.03rc5 router?

I would like to secure the routers from script kiddies, bots, remote exploitations and attacks and also keep a reasonable sense of privacy as well (limiting telemetry and website tracking).

A little about the setup:

  • This is home network, lan only.

  • some ports in the future will be opened for gaming.

  • I have not setup it up yet, but do have a managed switch which will be handling vlans to isolate devices (consoles, tv, computers, other devices).

  • The openwrt version is 22.03rc5

  • The device is a Dell Micro 7050 running 22.03rc5.

  • Device specs are:

    • CPU: IntelĀ® Coreā„¢ i5-6500T Processor with AES support.
    • Ram: 16GB Kit (2 x 8GB) DDR4 2400MHz PC4-19200 CL16 Unbuffered Non-ECC 1.2V SODIMM
    • Ethernet: IntelĀ® i219-V Gigabit1 Ethernet LAN 10/100/1000 (Remote Wake Up, PXE and support)
    • Ethernet 2: USB 3.0 Port TP Link UE300 ( Realtek RTL8153 Chipset )

Things I have done:

  • Generated a long root password with random letters, numbers, and symbols.
  • Created sshkeys for login and restrict SSH access to the local network.
  • Restrict Luci/uhttpd access to the local network, access over HTTPS
  • Installed BCP38, used luci to enable it.
  • Installed kmod-usb-net-rtl8152
  • Firewall DROP external connections

Things I still need to do:

  • Install and setup ad guard home

banip is not comptabile with this image.
Please see @slh explanation for this link

Fail2ban would not install. Something about dependencies issue.

What packages and configurations would you use?

Suggestions on securing x86/64 22.03rc5 router?

What makes you believe that there would be a tangible difference between a bog standard router with OpenWrt or x86_64?

There is only one, the temptation to use it for more than that. Just because the hardware would have the performance to do more, doesn't imply that it would be a good idea to overload it as a general purpose server in addition.

AES_NI is largely irrelevant for a router, you won't do filesystem encryption here, maybe OpenVPN (but -where possible- wireguard is easier, faster and won't profit from AES_NI)

I would be rather surprised if (without WLAN cards) you'd ever exceed 200 MB RAM usage - and if you do, it's usually for the wrong reasons (using it as general purpose server).

good.

o.k.

I usually wouldn't recommend that, as it's more likely to mess things up, than to fix things - the firewall will reject access anyways.

same here

good.

This is only mitigating a low risk in the real world, fine to do, but last I checked (admittedly a while ago), this wasn't ported over to nftables/ fw4 yet - if so, this might cause more trouble (in 22.03.x) than gains.

obviously necessary.

The default would be to reject, rather than to drop - while both are possible, dropping might cause more trouble with future debugging of $things.

Keep it simple, single purpose, secure.

2 Likes

Was not aware that it would cause things to be more difficult.

Should probably get rid of that package then. thank you.

Honestly I was following the https://austindw.com/harden-openwrt/ tutorial.

that guide is confusing: stating that ssh, uhttp service ports are exposed to public internet then later making a note that risk is low because firewall wan zone restricts ingress traffic ... well, that's the whole point of firewall, so no, not any port is exposed to public internet unless user allows it. there is no risk here.

securing can mean lots of things, what kind of threat you have in mind? you want to protect router from inside threats (as external is protected by firewall)? then probably you should use VLANs to separate your users and prohibit cross vlan traffic.

privacy: you want to use adguard home,that's ok, it allow you to use a) secure DNS; b) support adblock/tracking filtering c) you can enforce secure search d) support parental control e) can disable popular but potentially harmful services like tik-tok, twitter, facebook etc.

also there is crowdsec project, which may or may not work with 22.03-rc5, not sure to be honest. it supposed to monitor your services/network and alarm/mitigate in case of harmful activities based on behavioral data patterns collected from "crowd".

Port forwarding in the future, may be needed, keeping that option open is necessary but it would be not be used for accessing the router remotely.

Would like to protect my computers and devices from outside and inside threats as much as possible.
Recently purchased a managed switch for vlans, waiting to set it up until the router is done being secured.

What DNS would you recommend for security? I've heard about cloud fair dns.

This will be perfect. Will look into this thank you.

check https://adguard-dns.io/kb/general/dns-providers/ for upstream DNS for example.

Thank you :slight_smile: quad nine seems good but will have do more research on my end and compare.

I am now understanding what @slh means by k.i.s.s.

The more software you install, its harder to keep things easy to manage and use.

I researched and now understand that how it could make debugging difficult, also came across one of thing that seems like a good point to have drop.

I thought it important because pfsense requires or at least recommends AES support. It's also talked about a lot among some of friends to make sure aes support when choosing a x86 router .

OpenVPN can use AES_NI so there is no harm if your CPU supports it. But as @slh explained Wireguard not. It is your choice if and which VPN solution you may want to use. They have different strengths. Then your choice can drive if you want a beefy CPU with more power usage vs a less beefy but more economic.

? I am basically a noob, so with that said,

Common sense/thinking, I would have thought that restricting to local network would be a good thing, since most would not administer their routers from remote/WAN? Barring remote access would also eliminate another possible point of attack.
Am I missing/overlooking something? :confused:

The recommendation is to restrict ssh access to the local network only, eg ssh only available on the lan and nowhere else

My interpretation of @slh post is that firewall will automatically drop these connections, so the firewall plus a long admin password is more then enough and using other methods could possible (just guessing here) cause conflicts (probably with firewall rules) and make things more difficult for most users.

1 Like

Thanks jdwl1o1
I'm curious about slh response, NOT recommending that ...
Mess something up ... :confused:

My thinking is to eliminate connection availability, so that firewall doesn't even have to use resources for that. :confused:

You easily get into trouble when changing subnet addresses, adding more VLANs (as indicated here for the immediate future), etc., locking yourself out - without actually improving security that much (either the firewall works - and it does, or you'd be in a world of trouble beyond that).

Hello slh,
So for users like me who do not implement/use VLANs nor change subnets ... basically using a router almost with complete defaults, it would not cause trouble limiting SSH access to local network only?
Also, I only administer locally anyway via typically network cable connection; I would guess that I would not lock myself out.
Thanks.

Generally speaking, you could change the ssh and http/https listen interface to limit it to only the subnet of your LAN and it would be fine... but that works until it doesn't. While you may say you don't use VLANs and won't change your subnet address, the day that you do and you don't remember you've changed these settings, you suddenly are faced with a more complex (although not insurmountable) troubleshooting and resolution process.

The way the firewall works (and as @slh has said, it does work), there is literally no reason to change the behavior of the ssh and web server listen interfaces. If there was any real-world risk, changes would have already been made by the OpenWrt (core) dev team -- a group that takes the security of OpenWrt very seriously.

That is not correct... yes, administering via ethernet is more reliable than wifi because wifi is disabled by default on fresh installs (and thus ethernet is required), but you absolutely can lock yourself out even when connected by ethernet.

2 Likes

Hi, I would be grateful if you could please expand more on what you mean by changing subnet addresses. Specially with VLANS as vlans will be implemented in my setup by using a managed switch.

Sorry,
You lost me there. :confused:
Is there some design bug or situations or such that would cause lock out?

Misconfiguration, easily done by accident, especially if you edit config files by hand. Or a misunderstading about the meaning of some config options.

For example, you harden the router to listen connections only at IP 192.168.1.1 and then change the router's IP to 192.168.1.2 (no subnet change, but the router's IP changes).

Or you make a mistake in bridge config, so that the LAN ports (or the switch itself) is not part of the lan interface any more.

Or you make a small typo in lan interface's config causing uci to fail to parse the config properly.

Or you change the VLAN/device config inadvertly. That was the most common soft-brick reason years ago, until the default network config was changed so that VLAN functionality was enabled both for wan and lan (in style of eth0.2 and eth1.1 in pre-DSA times.)

So, there are several ways how you can easily config yourself out of the router with a wired connection.

LuCI has had for some years now a protection so that if the browser does not get a re-connection soon after the config changes committed, the changes are rolled back in order to restore the earlier situation. But there is no similar protection for manual edits.

2 Likes

Thanks hnyman :smile:

Appears I'm off the hook, no worries there, since I basically use the routers at defaults.

Have not found any in-depth tutorials for noobs regarding VLANs, manually configurations and so forth. Number of tutorials were out of date, skipping number of steps ... Got tired off non-functioning routers after my failed configuration attempts and having to re-flash/reconfigure routers each time :slight_smile: