Is MAC address filtering the most suitable option to prevent someone connecting their own device to the network by plugging into Ethernet wall sockets? What if they unplug a device and clone its MAC?
MAC address filtering itself does not provide much protection. As you pointed out, a MAC address can be cloned. That doesn't mean it can't be part of the overall defense strategy, but it can be a lot of work for very little return.
You need a comprehensive security policy which can include such things as:
- Physical access limitations
- 802.1X as @robut mentioned, albeit this can be complex and require supporting hardware/software infrastructure, while frustrating legitimate users
- Port security on switches can be set up to only allow a single (or limited number of) MAC address at any given time, or in any given time period, to prevent connection of hubs, switches, APs, etc., including a port disable for a given time period if violations are detected (care needs to be taken for things like VoIP phones where PCs are connected to the phone since the phone itself will have one or more MAC addresses)
- You could also implement a policy that requires any switch ports that are not currently used to be disabled (including, perhaps, making sure that unused network cables are not cross-connected in the data closet)
As a locksmith friend of mine once told me, "Locks only keep honest people honest." The bad guys will always find a way; your job is to make it not worth their efforts. If you provide enough layers of protection, only the most determined bad guys will spend the time and effort.
You have to weigh the risks with the resources (primarily time and money, but lost productivity, too) that you are willing to put into securing your network. It may not make much sense to spend thousands of dollars and many man hours to protect that garage-sale bicycle you bought for $10. You need to come up with a plan and decide how much risk you can tolerate.
Answer to your question = No.
I dont think there is one complete answer. The closest would be to have defence in depth.
Start as Ron Maupin suggested as having Physical access restricted. Then have 802.1x using EAP-TLS to have authentication to the port.
After that you can still have a firewall on the access/ditribution layer. If you are talking more about internal web systems then make sure everyone is authenticated through a proxy also.
If your only requirement is to just block users (intruders), you can simply write a couple of lines of EEM script.
If the current state of the interface is up, the script would shutdown this interface when it goes down.
If the current state is down, the script would shutdown the port when it goes up.
Then, the user calls to verify his identity and the "no shut" is applied on verification and demand.
There is no way to prevent this, but this not what you should worry about. What you need to worry about are the guys scanning your networks, patiently building knowledge on cracks in your network.
What you need to do is to prevent exploitation, use a very strict access control, bring in pen tester, find things that are misconfigured, understand perfectly your network, and train people (not to click on well crafted emails, not to go on weird web sites, be cautious about removable devices, etc.).
This is somewhat orthogonal to the OP's intent, but I have found that being very restrictive on wired ports while at the same time creating and opening up a guest wifi AP eliminates all the casual accidents (e.g. a visitor plugging in) and at the same time makes the company environment more welcoming to visitors. So you get two benefits for the price of one, or, putting it another way, you can deliver a benefit to your management while getting a security benefit as a side effect.
My other observation is that attackers are very smart, and the work/payoff reward calculation is tilting against direct intrusion over the network and in favor of just leaving a USB stick on a desk and waiting for someone to find it and plug it into their (legitimate, on the authorized LAN) PC. Yikes.