I want to isolate the infrastructure, like NFS and LDAP, to improve security. VLAN isn't exactly a security measure per-se, but does improve overall security by significantly limiting access routes (e.g. NFS) a.k.a attack surface. It's also critical to separate infrastructure space from userspace.
Every switch aware of VLAN requires admins to allocate VLAN IDs to each and every ethernet port.
For each port, there are three possible behaviors for each VLAN:
Don't send packets of this VLAN throught this port.
Tag packets with its VLAN ID before sending through this port.
Send packages without VLAN tag through this port. (Native VLAN)
Any network configuration is possible by combining these behaviours, ethernet ports, VLAN IDs, and routing rules. In OpenWRT, all of these are easily configurable through its Luci interface. clap clap
I've tried many, spent lots of time designing, but concluded not to think to much about it. Over-provisioned security requires 10-times more efforts, but provides no benefit.
LPT: Even when equipments do all the work, you have to understand them, configure them, manage them, and document them. It's no free.
So my setup looks like this (from Switch section of OpenWRT):
| VLAN | ETH0 | ETH1 | PORT1 | PORT2 | PORT3 | PORT4 | WAN | | ---- | ---- | ---- | ----- | ----- | ----- | ----- | --- | | 11 | TAG | | NAT | NAT | NAT | NAT | | | 12 | TAG | | TAG | TAG | TAG | TAG | | | 13 | | TAG | TAG | TAG | TAG | TAG | | | 14 | TAG | | | | | | NAT |
note 1: TAG=tagged, NAT=native(untagged), empty=disabled. No trunk ftw.
note 2: wan port is repurposed as a dedicated console port.
note 3: notice the difference b/w ports and
ethinterfaces. ports are connected to a dedicated network switch chip, whileeths are CPU-side chips. You can have traffic switched without going through CPU, but w/o routing.
... and some more details of each VLAN:
| VLAN | Name | Can Access | Members | | ---- | ---------- | ------------ | -------------------------------- | | 11 | Management | WAN | Proxmox, Backup NAS | | 12 | Private | WAN | LDAP, File server, Proxy, ... | | 13 | Public | WAN, Private | Desktops, Git, Printer, ... | | 14 | Console | all | A dedicated machine (my X61!) |
NOTE: All subnets can access WAN, while WAN can only access Public. The outer network has a static route to Public subnet burnt into it.
You get the feeling, right?
So, I was a cybersecurity "expert" in military. I call myself "expert" even though my position is a research position, because I don't qualified myself as a security researcher. I'm a programmer, and even more of a computer scientist than an engineer in that. I did have my prior knowledge in security, picked up from random places or my own experience, but never had received any sort of education. Anyways, I wanted to tell you that I know how things are like in actual field, and that I'm having fun applying it to my own little server cluster.
The first thing to notice is Management. I applied the general wisdom of
isolating virtualization servers from the rest of the network. Their management
interface is so powerful that taking control of it means taking control of the
entire infrastructure. At the same time, even when your entirety of VMs are
scrubbed, you can recover all of them through few clicks in the management
interface. As long as you keep them safe, you don't "lose".
So, if you run a VM cluster, you MUST secure VM servers at all costs no matter the cost: network isolation, communication encryption, centralized pubkey authentication, physical access control, etc. There should be no internet access, too, but this is a homelab, which is not worth the effort.
The Private part of the network is mostly for internal services, like
authentication and base file servers, used only by me myself and published
services in `Public'. The goal of the separation b/wis to limit the initial attack
surface, so that hardening efforts can be concentrated more on exposed parts.
In fact, the correct method for separation is port mapping. It's undoubtably better to manage every service through a centralize security interface. You can choose who can access what, but it requires static-IP configuration. That's an overkill, so I'm just dropping external access.
What you're seeing here is the basic strategy of cybersecurity: hardended shell and layered core. The only missing part is behavioural monitoring, but it's clearly outside of the scope of "homelab". There are many AI/ML based solutions, but most homelabs simply don't have enough traffic to properly train and use them.
ufw and firewalld.