This post is now deleted
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
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".
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? 
The recommendation is to restrict ssh access to the local network only, eg ssh only available on the lan and nowhere else
Thanks jdwl1o1
I'm curious about slh response, NOT recommending that ...
Mess something up ...
My thinking is to eliminate connection availability, so that firewall doesn't even have to use resources for that.
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
Sorry,
You lost me there.
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 
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 
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.