Personally, I avoid the "default" VLANs of 1 and 2 as some switches consider them "special". As far as I know, there's nothing special about them from an OpenWrt perspective, just long-standing convention of how a "new" install has it's /etc/config/network created.
With "dumb APs", I typically use "the blue port" ("WAN", "Internet", ...) for management, as it's visually different than the ones for LAN.
So, would you redo or relabel VLAN1 and VLAN2? Create two new VLANs and set them up like 1 and 2 and then turn off everything on 1 and 2? Or does my line of questioning show I have no idea about what I am asking?
I wouldn't unless I had a specific known reason to. Jeff's reason is that he uses things like Cisco switches which might by default do all their management on VLAN1 etc. If you don't have that kind of scenario, you probably can leave VLAN1 and VLAN2 alone.
Correct, if your computer sees DNS as proper internet addresses then it will send DNS requests to those addresses and those requests are allowed through.
There are reasons to do all your DNS off the router, like for example you can blacklist certain domains, or you can do caching to reduce the number of DNS requests needed on the WAN per unit time... but the reasons are not 100% compelling, it could be ok to let your clients use WAN based public DNS as well.
Thanks dlakelan, that was helpful.
I was hoping to just leave the VLANs as they are.
As for the DNS, I actually use DNSCrypt locally on the machines (disabled for now as I test all this), but I wanted to figure out the OpenWrt implementation before I started that back up. Thanks to all this help I think I am starting to see how it all works.
Back to the cross talk issue, I have noticed that although I can't ping computers between the VLANs at all, from any computer I can ping any interface. For example, from a computer on VLAN_10, with interface eth0.10 and IP address say 192.168.10.240, I can ping 192.168.20.1 or 192.168.30.1. My reasoning for all this separation is that one computer is for kids who may wind up on a malware infested site (despite all you teach them about Internet security...), and two computers are for different work related things. I want to reduce the chances of one infected computer compromising the other, or the router. So I wonder if there is some risk that malware that infects one computer, and can still ping and get a response from an interface IP address, will that alert them to a place to try to get further in? Should I look to write firewall rules to stop that?
And is ping a good test to see what can be found/accessed, or not? Is there a better way to test this? I can do basic stuff with Wireshark, but have no idea what I would need to look for, if it is even useful here.
A typical Linux-based firewall distinguishes between forwarding packets and accepting packets (destined for its own interface IPs). As long as you don't block the typically critical ones, like DHCP, DNS, IPv6 related to neighbor discovery and routing, NTP, you can also block your router from accepting packets to its own interfaces while still allowing them to be forwarded.
For one reference as to "how it all works" you could try
From that reference, a critical part is
- Incoming packets destined for the local system :
PREROUTING->INPUT- Incoming packets destined to another host :
PREROUTING->FORWARD->POSTROUTING- Locally generated packets :
OUTPUT->POSTROUTING
INPUT and FORWARD are the ones commonly used for "custom" tuning of the OpenWrt firewall.
Thanks for that reference. I've been reading over there since you posted that. I follow some of it, but I may have reached the limits of my ability. Too bad I spent all these years on Windows instead of Linux...
Is this something you think good security practices would call for? Is it something very many users are doing? Or do you feel it's not worth the effort? I'm trying to understand if I should even be pursuing this.
You can chase packets to the end of the earth, and still have them leaking past you. It's a never ending battle unless you make some reasonable decisions about "good enough". Even with "valid" packets, there are nefarious ways that they can carry a backchannel.
Meh, in my opinion, once you're significantly more difficult to attack that other targets of comparable value, you're done. It's like safes. There's no "impenetrable" safe, they're rated in terms of minutes or hours of time before a skilled team can break into them.
Essential, in my opinion:
Challenging with OpenWrt, but important for me:
root, with sudo
root logindropbear (some may argue this one)Reasonable, in my opinion (I'm probably more security-focused than many):
nginx, yes, uhttpd, no)nginx only running as a reverse proxy for your internal webserver)Getting over the top, even for me (though some of these I do implement):
I've certainly missed some, but that should at least be a good idea of one person's opinion.
Note that I don't believe that, for example, "ShieldsUp!" and his suggestions are worth a damn, nor is blocking ping worth the problems when diagnosing network problems, or that putting a service on a non-standard port does anything more than reduce log clutter if you've got strong passwords.
Wow, Jeff, that's quite a reply. Very, very useful. I did have two questions. I am new to having a Linux box, about 3-4 months, but I dabbled over the years. I never use the root account, only a user account. I was advised to not install sudo, but use su instead, which has worked great for me. The reasoning was it was a less vulnerable approach. Can one use a similar approach here, or is sudo required? Also, it seems to me that if I use Luci don't I have to log in as root to make changes? I'm a bit confused because one piece of advice was to change the login name from the default root, but in Linux root has a very specific meaning. I am wondering how to operate in Luci once I set up a non-root account. I suspect you will say Luci is just for beginners so get away from it as soon as you can. Any clarity here would be appreciated because this was on my list of questions that I couldn't find answers to.
Also, I do treat any wireless client as hostile. The 'kids' connection is the wireless, and one of my primary motivations to set all this up. There is only the one wireless client (one computer using it), and there will never be any guest WiFi. Is there anything more I can do outside of what we have been discussing in this thread as far as isolating this wireless client? As far as I can tell I don't attach this to any VLAN (like my 'extra' VLAN_40) because I do not want to tie it to any router port or other device in any way. So as long as all other clients are in VLANs with proper firewall rules (as discussed above) it is 'isolated'? (I also checked the 'Isolate Clients' checkbox hoping that would help if anyone 'hacked' the WiFi.)
I prefer sudo as at least it gets logged and on my boxes, where I can, there is no root login. Not that once someone has root access they can't change the logs on a local Linux machine, but at least you have a chance of seeing failed attempts. I'm sure there's "religion" around su vs. sudo, but it's not one that has convinced me to change my preference. sudo also has saved me a few times from my own stupidity because of its command-by-command style, as long as you're not running sudo sh and blindly typing away.
On LuCI login, it used to be the case that root credentials were used. This may have changed since I last looked into it, but I almost never install LuCI on my OpenWrt boxes, so I haven't followed it closely. I have noticed that, at least on master, LuCI on nginx with OpenSSL is a pre-packaged option. Looking deeper into those if you're using LuCI might reveal more than I have kept up with.
Yes, UID 0 and GID 0 have reserved meaning in Unix-like systems. There's nothing that says the name of the user or users associated with that account needs to be root. FreeBSD, for example, defines one user with those IDs to be root as the "safe, predictably robust" user that (should) always have /bin/csh and a clean environment, and toor as one that can, if one wants, have a different shell, home directory, environment, ...
Thanks. That clears up the Linux questions for me. Especially interesting was that the root account doesn't need to be called 'root'. I didn't realize that, but it makes sense.
This has turned into quite a thread. Your help has been invaluable. Every time I get ready to say 'After this last question I'll mark this one 'Solved'' you show me some more great stuff and I keep asking more questions...
I'll wait to see if you have any comments on my wireless question(s) and then I'll mark it solved. I have one more simple question that I'm going to start a new topic for, and I suspect you'll know the answer to that one.
I haven't looked into the fine details of how client isolation works under OpenWrt. As I recall reading in some of the many threads here on the topic, there is both the isolation within the wireless subsystem that needs to be considered, as well as that once the packets reach the router "proper".
For me, in my setting, VLAN isolation is enough. I generally want clients of the same subnet to be able to communicate with each other. I put all my Brand X IoT devices on their own SSID and subnet so that they can merrily scan and attack each other, if that's what they're up to, but they won't know about my Brand Y devices.
Others find client-to-client isolation very important, especially those that offer public wireless service.
Darn, I was really hoping to let you off the hook here, as you've given more than I could have hoped for. I think I completely understand how you described your setup, but am still trying to understand if I have a wireless interface do I tie it to a VLAN even if I wouldn't have any router ports attached to it (like my VLAN_40). I read something that said not if you are not going to bridge it to a lan port. I just don't want to have it not associated with a VLAN and later find out that that was really stupid. I guess the reason I can't seem to find this answer in the documentation or forum is because few have their wireless not attached to a port? I can't find the reference I mentioned above in my notes...
the only reason to bridge two interfaces like a WLAN and VLAN interface, is to let the different machines connected on those interfaces talk to each other
When a wireless interface comes up, the OpenWrt subsystems look at the option network 'blah' in the wifi-iface section of /etc/config/wireless. It then matches against an interface entry in /etc/config/network. Typically those are set up as bridges. You can bridge a sub-interface, such as eth0.222 to get VLAN 222 on that interface. You then need to configure your switch if you want to trunk that out over the physical wire.
It doesn't really "look at" the config files, but rather an in-memory representation of the current state that they initially set up, and other things might have modified. uci show is one user tool to look at that in-memory content.
As @dlakelan points out, you don't need anything if the clients aren't going to "talk" with anybody not on the same wireless interface (this AP, if you have more than one and that SSID).
Here's one of my (manually configured) bridges
config interface 'vlan123'
option type 'bridge'
option stp '1'
option ifname 'eth1.123 bat0.123'
option proto 'static'
option ipaddr '10.11.12.1'
option netmask '255.255.255.0'
option delegate '0'
In this case, I offer services to the subnet on 10.11.12.1 (through VLAN 123 on eth1) as well as trunking it to my other APs over "bat0" (a mesh interface).
The wiki has some magic-decoder rings for this, if you search on /etc/config/wireless or /etc/config/network
Thanks a lot for all the very detailed responses. I think I can find my way on this now. I can't get over how great the OpenWrt community is. So helpful. I hope someday I can make some kind of contribution...
Spurring these threads is a contribution!
Well, thanks. That makes me feel less like a leech.
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.