I've been thinking more about this problem, and I'd like to raise the level of the discussion.
Before I get to that, I want to set WiFi aside, because it already does a much better job of authenticating access to the network than Ethernet. The networking equipment providers have developed things to the point that there is nearly no such thing as unauthenticated access any more. Even in the case of coffee shop WiFi, you've got things like
HotSpot to tie unauthenticated users to a guest VLAN or similar. For the purposes of this subthread, we can consider the WiFi leg of this problem "solved."
What I want to talk about instead is the problem of randos plugging untrusted equipment into live Ethernet ports.
We've dealt with physical security and disabling ports above. That still leaves a hole in the conversation relative to WiFi: given that there's a practical limit to such measures, how do we prevent those rogue connections from accessing anything important? Either such traffic should be shunted out to a guest LAN, or it should be denied entirely.
Above, I claimed that
RouterOS's dot1x facility is "leaky." The basis for that claim is this quote in the docs:
After client is successfully authenticated, the interface will accept all received traffic on the port. If the interface is connected to a shared medium with multiple hosts, the traffic will be accepted from all hosts when at least one client is successfully authenticated.
That behavior has been
independently verified. All you need to do to break RouterOS's dot1x security is interpose a dumb Ethernet switch. Anyone plugging into one of the spare ports left after the 2 needed to pull this trick off ride along with the lone authenticated connection. Until that's fixed, I consider RouterOS's dot1x implementation a form of
security theater. We can disregard it for the purposes of threads like this one.
On thinking about why this sorry state exists, I realized that it's nearly inevitable. To solve it, you need some way to identify particular clients after they've authenticated. If MAC 11:22:33:44:55:66 does the EAPOL dance for dot1x successfully, what happens? The switch learns that 11:22:33:44:55:66 can send packets, is what. Doesn't that just put us back in the MAC filtering problem brought up at the top of this thread? Sprinkle in a little
ARP poisoning, and now anyone that can connect to the network can claim to be 11:22:33:44:55:66 and ride along with the legitimate host's authentication.
I did some web searching and found that this problem was anticipated and solved back in 2006 with
802.1AE, called MACsec by analogy to IPsec. Basically, it establishes an encrypted L2 tunnel, rather than the normal L3-L4 tunnels of VPNs. Unfortunately, RouterOS doesn't appear to support 802.1AE.
That got me to thinking: couldn't you use one of RouterOS's
many VPN technologies to solve this?
Above, I dismissed the option of IKEv2/IPsec/L2TP on an intra-LAN basis as "overkill." Not only is it more complicated to set up and manage than any other VPN technology, it's likely to break any protocol based on broadcast or multicast.
Thankfully, that family of over-engineered tech isn't our only option. In particular, RouterOS is getting a
ZeroTier Controller feature in 7.3. Doesn't that solve both sets of problems? That is, the wish for authenticated wired network access and simplicity of configuration?
To those that would dismiss this solution because ZeroTier runs only on MikroTik's ARM devices at the moment, observe that the best alternative we have so far is physical security. For the price of a single custom-made sheet steel box fitted to an Ethernet-equipped device, you can get one of
several RouterOS products fit to this purpose.
For the OP's case, I think the PCIe card version of the CCR2004 might work nicely: put it in the office's main server, and turn off the insecure motherboard Ethernet ports in the UEFI config so all of its services bind to the internal virtual interfaces instead, forcing all the traffic through the RouterOS layer. Configure RouterOS on the card to block anything that isn't ZeroTier, so that until the server's ZeroTier client connects to RouterOS, it offers no services.
Regardless of the device you choose, if you use ZeroTier as your intra-LAN security layer like this, unauthenticated clients see nothing but a bunch of pseudorandom noise flying by, just as with modern secure WiFi. It isn't until you authenticate with the ZeroTier controller that you can see the "real" network services.
This is also good psychology: anyone going to the effort to hijack an open Ethernet port most likely just wants to screw off on company time, surfing the Internet or whatever. If their duties are light enough to let them get away with this, for the purposes of this technical forum, why not let them? The ZeroTier layer inoculates the business network from their infections, so the two parties can share the medium in peace. Any perceived problem beyond this is a local people management issue, thus off-topic here.
What am I missing here? Have I cracked the problem?
I do realize that none of this solves the problem of malware worms and such coming in over "secure" channels. If a trusted client gets pwned, it's on the secure network, and bad things can still happen. I intend this solution only to solve the problem of untrusted hosts doing the same type of thing.