I have a CSS106-5G-1S switch with SwOS on it. I connected a router and another device to it. The rest of the ports are disabled. I'd like to lock the ports to the predefined MAC addresses as a basic protection, so other devices cannot connect to them.
What I did:
- Verified that the right device is connected to the right port
- Added both the router and the end device MAC addresses, and set VLAN ID 1 for them in the Hosts tab
- The documentation says that I have to select the "forward to" ports, so I ticked only that one checkbox that belongs to the actual device (router MAC address to router port, device MAC address to device port).
- (The router port handles multiple VLANs, so I enumerated them in separate rows here, but I don't think it's relevant currently)
- Turned on "Port Lock" in the Forwarding tab for the end device but not for the router
Symptoms:
- After rebooting the switch (to empty the caches), communication doesn't work anymore to the device in either direction
- If I temporarily enable the router port "forward to" checkbox in the Hosts tab for the device (so the device MAC address row has now two check boxes set), the connection works again.
- If I reboot the switch in this state, after the reboot the connection won't work.
- I tried to add all devices in the path in the Hosts tab (e.g. switches, my PC) until my PC so that it can reach this end-device, but it didn't solve the problem.
- If I remove the port lock check mark, the connection gets reestablished.
My question is: how does this port lock work exactly? My goal is to allow only one device on one physical port. Is it a bug that the behaviour differs before and after reboot?
SwOS version: 2.18
Do you also use “My name is…” party stickers as corporate ID badges?
That’s how secure this feature is. Don’t waste your time.
You couldn't have said it better...
Yes, thanks, I'm aware of its weaknesses, but I considered this solution enough in the threat model I'm applying to, until I create a more robust solution. Basically, something better than nothing until 802.1X arrives. However, in retrospect, I should have spent the debugging time setting that up instead of pouring into this.
Back to topic, just for my curiosity, does this feature work? Am I doing something wrong or is port locking broken on this device?
802.1x is pretty weak on its own, too. It allows free riders by interposing a dumb switch: the lone allowed host authenticates, activating the port, and then everyone else gets to talk from that point forward.
802.1x has to be combined with MACsec and other measures to offer any real security in a world where people are allowed to unplug the cable and plug something else in, which I think we can presume given your initial question. The chances of MACsec being added to SwOS are zero, if we can go by its present and longstanding lack of basics like TLS and SSH.
Better solution: require the client to authenticate with the core using one of the several VPN technologies RouterOS supports. Add firewall rules that prevent unauthenticated clients from connecting to any useful service. I doubt you an prevent them from chatting amongst themselves while still allowing the initial authentication exchange, but that at least is truly better than nothing.
If cheap-and-easy is the only class of solution you are willing to entertain, then may I suggest hot-gluing the cable into place?