Switchport port-security restrict vs shutdown with dynamic or sticky mac?

[NormMuelleman]

Restrict vs shutdown...which is the preferred method of port-security?

I have argued that shutdown is the more secure option. I am having an arguement with a couple people that restrict is better. This goes into the argument that dynamic mac-addresses are better than sticky mac. I disagree...here's my arguement:

By using shutdown, you are creating a more secure environment. To be easy to follow, I'm going to use mac addresses A, B, C. Now, of course I know a mac address is a 48 bit length; i'm just being lazy

So, you have a switch with a PC with Mac Address "A". Under violation "restrict", when the PC is plugged in and traffic is seen on the port, the mac address is going to be dynamically learned on that port. So, there that mac address sits...lets say on Fa0/1. Also, we are using maximum 1 (the default). So in the mac-address table, you'll have:

Fa0/1     Mac address: A

Now, pull the PC off, and replace it with a laptop, with mac address of "B". What happens? While "A" is still dynamically learned, "B" will try and populate the mac table, and a violation will occur, correct? So the security counter increments by 1. So what? An SNMP trap msg will get sent as well. But let's say you dont have a network monitor. How will you know what happened? Sure, packets will be dropped, but the port is still active. A vulnerability is still in play.

Taking the scenario a bit further...same thing. Except this time, you pull the plug on the switch. You unplug the PC with mac address "A". You power up the switch. Now, because the mac address "A" was dynamically learned, there will be nothing in the mac table when the switch reboots. You stick in laptop "B". It's now the new learned mac address.

My argument is to use shutdown mode. Again, same scenario. You pull the PC "A", and put in "B". WHAM! Shutdown the port hard! Then, snmp trap sent. Even if you dont have a monitor tool, the port is shut and someone will eventually be calling to have the net admin reset the port. Of course, questions will be asked...

Now, if you take this scenario further...unless you have sticky mac, you could still get around this by pulling the power on the switch. If this is a dynamically learned mac address, it will be wiped. Hence using sticky mac! You're PC "A" is hard-coded into the running config. Regular system writes and backups will ensure that latest mac address is kept in the startup-config. So A will be in the start-up config. If you pull the PC, power cycle the switch, and try and stick "B" in the same port, you'll get an err-disabled msg, port will hard shut...

Anybody have input on why to stick with restrict? I'm trying to make a point here, and maybe I'm not understanding the reasoning to keep restrict vs shutdown.

[Kyle McKay]

I'm don't think that anyone uses restrict as opposed to shutdown for the reason that it is more secure - I think it is just simpler to manage and provides less administrative overhead. It is not practical in every scenario to shutdown ports when a user may mistakenly connect an additional device. Instead you can restrict traffic from the additional device while allowing the original device to remain unaffected.

As for the sticky/dynamic debate.. It really all depends on what your goal is. Here we are using it to simply restrict the NUMBER of devices at each switchport, we don't care what their MAC is - so dynamic just makes sense.

If your primary goal is to restrict traffic down to only specific MAC addresses - then of course, sticky/static MAC is the way to go.

I think the definition of "better" is up to the specific application of the feature. This is why we have three different options to choose from, it allows us to select the one best for our environments.

[Brett Rabang]

I believe either way works...it's a matter of opinion or preference. For me, port security's purpose is to limit learned macaddresses to prevent the cam table from flooding.

Sent from Cisco Technical Support iPhone App

[Peter Paluch]

Dear friends,

One small remark - perhaps it will be usable.

The main difference between the protect and restrict types of violation reaction is that the restrict causes the violation counter to increase and a message to be logged (Syslog, SNMP, etc.). This may place additional burden on the CPU of the switch. During experimenting with random source MAC flooding on a Port Security-enabled port with restrict, we have found out that a large amount of frames with random source MAC causes the CPU to spike up to nearly 100% (we have used the macof utility under Linux). We attacked just a single port - we haven't even tried to perform an attack using more ports. Thus, while the CAM overflow is prevented, sending an intense stream of frames with a random SMAC can be used as a form of DoS attack. The protect kind of violation reaction does not exhibit this behavior, obviously because the whole event is ignored by the IOS/CPU.

Therefore, the restrict violation reaction is not a good choice into environments where extensive attacks can be expected.

My two cents...

Best regards,

Peter