I had read that changing the IP address of the router from the well-known 192.168.1.1 to something else provides a tiny bit of extra security since lots of malware just probes all the known default IP addresses used by routers. But many of those routers also use a domain name access that is well-known. So, when I saw I could access my router by http(s)://openwrt.lan, I figured that is known to everyone, and may be used by many malware variants, partly nullifying my change of IP address. I rather suspect if Jeff replies he is going to say changing the IP address, like changing SSH off port 22, is mostly meaningless. If that's the case, then this question is a non-issue.
What I read was that the access domain comes from the hostname, so that can be changed to something obscure. Is the hostname, though, something that can be discovered fairly easily, rendering that change fairly useless? Is there a way to disable the domain access feature via CLI? Or if one was concerned is it best to just set up some firewall rules to block that? Or is this a non-issue? I'm just trying to further my quest for hardening.
That's it.
Your best friends should be firewall, strong authentication methods and cryptography.
And keep your firmware up to date.
Although it isn't clear, what do you want to protect from.
Anyway, start from this:
I'm not seeing the issue. Finding the router IP for malware is a piece of cake regardless.
The security comes from the fact that it would still need to provide some kind of password to get in.
On many servers for example, where there is a PUBLIC IP which is well-known as they need to serve a website or some other service, the ssh daemons do not even accept user/password, they are set up to accept only known ssh public keys (each user has his own) defined by the server admin.
So an attacker has 0 chances in hell to bruteforce his way through.
But still, if you want to set up a device in a public place, it's a good idea to keep the users in a subnet that has no access to ssh or web interface at all.
Yeah, anything can do a DNS reverse lookup on the router IP address that DHCP hands out and find out what the router is called. Furthermore the router IP address is after all handed out by DHCP and so anything can just look at the default gateway it got and attack that.
LOL, well, in this case I'll tell you to do it, but for different reasons. Any improvement in security is a bonus.
When you've got a bunch of VLANs, you might as well assign meaningful subnets to them. I usually pick a /24 from the Class A private space, 10.X.Y.0/24, and encode X and Y to be something meaningful to me. Maybe X is 0 for infrastructure, 1 for wired desktops, 2 for ... I typically will use the Class B private space, 172.16.0.0 – 172.31.255.255 for non-routed addresses, like those that make up my mesh. I'll throw a "random" Class C address on "guest" networks. It makes it easier to quickly figure out where a packet says it's coming from or going to when I'm using wireshark or tcpdump.
I keep 192.168.1.0/24 for the adapters I have hanging off my desktops since every time I test an OpenWrt build and most times I'm in a boot loader, its on 192.168.1.0/24. That way there's never a conflict with a "real" address.
I can't get worked up about local DNS addresses. Change the name of your OpenWrt box and I believe it will change. There's far more "interesting" traffic on a link these days between Windows boxes and mDNS on so many things announcing not only IP addresses, but what services are being offered. No need for a "hostile" to probe, everybody it shouting it out loud.
and also that there are no known remote vulnerabilities, like "magic packet" attacks that cause buffer overflows and let you bork the router and gain access without a password.
The way to avoid that is to update when new versions of OpenWrt become available.
That kind of attack is exceedingly unlikely on OpenWrt, as the most common vector to compromise a stock firmware is to do some command injection in their web interface. In many cases their web interface is an extremely simple affair that is accessing root shell in some form to do things so even their "login page" asking for a password is in fact a wide open hole for malicious users.
LuCi web interface should be immune to shell/command injection because of its design (it's of course heavier and more complex to develop than just a webserver serving pages that call some shell scripts)
Ssh bugs that allow malicious access are rare as finding the One True Love, so as long as you configure it correctly it should be fine.
Thanks for all the replies. All this info has been immensely helpful. I have a much better handle on what to do now, and a lot more clarity. This is a great community here.