Hidden dangers in port-security

Kevin Dorrell · ‎01-04-2008

Could someone comment on this thought-experiment please?

Consider a network with 3 switches, connected via trunks as A<->B<->C. Consider some servers on switch A, and some clients on switches B and C.

Now, let us introduce port-security on the client access ports, with 1 (dynamic) MAC address allowed per client. For safety, let us also put bpduguard on the client access ports. Let us also have portfast on each client port to allow DHCP to work properly.

Now, suppose we have an office that is short of wall sockets, so we decide to put a cheap-and-nasty dumb switch on a port on switch B. For safety, we remove the portfast from that port, but we keep the bdpuguard. We want to allow up to 8 (dynamic) MAC addresses on the port. In order to allow client workstations to be changed, we put ageing on the secure MAC addresses, say 20 minutes. OK so far.

Now suppose we do that twice, both dumb switches on switch B. So far so good.

Now suppose someone decides it would be a good idea to cross-connect the dumb switches with a cross-cable "for resilience". Of course, that will cause a broadcast storm, but the storm should last for less than 2 seconds until the bpduguard does its work. The bpudguard on switch B will cut the link to one or the other of the dumb switches (whichever gets a BPDU first) ... but not both.

Are our problems over? No, they are not. Suddenly you find that clients on switches B and C can no longer access some of the servers on switch A. What has happened? During the less-than-2-seconds that the loop was active, some servers happened to send a broadcast - an ARP or something. This broadcast went round the loop, and the MAC address of that server got registered as a secure address on the switch-B port where one of the dumb switches was connected. OK, on the port that was cut by the bpduguard, these secure addresses will be discarded. But not on the other one.

Some servers will not be accessible for 20 minutes or so following the loop, in spite of the bpduguard.

Am I right in my analysis? If so, don't the dangers of port-security outweigh the risks that port-security was supposed to mitigate?

Kevin Dorrell

Luxembourg

s.arunkumar · ‎01-04-2008

Interesting analysis.. :)

i think u are right..now if want want to avoid this situation

1.isn't it better to configure a bpdu filter also along with portfast ports(as they are anyway connected to servers or dumb switches).

2.to configure mac-address statically for port-security for th ports connected to servers..

hope this not any blunder :)

Kevin Dorrell · ‎01-04-2008

Thanks for the reply.

I don't think I want to configure bpdufilter because that would make the damage due to a loop even greater. At least with bpduguard the loop gets cut within 2 seconds. With bpdufilter, the bdpuguard would not work at all, and the loop would continue to storm for as long as it is connected.

As for configuring mac addresses statically for the servers, that would be fine in switch A where the servers are connected. But in switches B and C where the clients are connected it would be a bit difficult to maintain. I would have to put port-security on the inter-switch trunks, and then configure every server MAC address on it. Add in some server virtualisation, and failover, and redundant uplinks, and I'm afraid it would not be practicable.

Thanks for the ideas, anyway. So far the best I can do is either remove the port security on any port that can see more than 1 MAC address, or make the ageing very short.

Anyone got any further thoughts on this?

Kevin Dorrell

Luxembourg

(P.S. I shall rate once I have a few more responses.)

Jon Marshall · ‎01-04-2008

Hi Kevin

No need to rate, just my thoughts.

I'm assuming from your description that the dumb switches are sending BPDU's.

Also are your dumb switches connected to access ports ? If so would the server that does the ARP not need to be in the same vlan for that to be registered on one of the ports that the switch is connected to.

Those things aside i'm not sure i would refer to this as a hidden danger as such.

Port security is very good for stopping people just connecting hubs/switches to their floor ports. But if you then go and allow 8 mac-addresses on a port specifically because you are connecting a switch, and then do it again on another port on the same switch then I'm not sure you could call that a danger of port security - there are only so many things Cisco can do to protect us :).

Jon

Kevin Dorrell · ‎01-04-2008

Hi Jon,

Happy new year!

No, the dumb switches don't generate BPDUs. They are the typical unmanaged home switches you buy in the supermarket. The point is that they pass BPDUs transparently. So if you use one (or even two) accidentally to create a loop between two Cisco switchports, then the Cisco switch cuts one of the connections because of bpduguard.

The situation I was thinking about is an office that has, say, 12 computers and only two wall sockets. So you install two dumb switches in the office as access-port concentrators, and use the two wall sockets to uplink each them (independently) to the Cisco switch B in the closet. That's fine. The trouble only starts if some bright spark connects a cross cable between them.

And yes, I am supposing the server and the client ports are in the same VLAN.

Kevin Dorrell

Luxembourg

Jon Marshall · ‎01-04-2008

Kevin

Happy New Year as well !

Yes okay so the switches just pass BPDU's across the cross over.

I think your analysis is correct although it would be interesting to test (no cheap switches in our lab !) but i'm not sure what you could do about it really.

Jon

Kevin Dorrell · ‎01-04-2008

Jon, can I send you an e-mail? I don't remember your address here at work. Mine is Kevin-dot-Dorrell-at-pt-dot-lu.

;-)

Jon Marshall · ‎01-04-2008

Kevin

No problem, just sent you an e-mail.

Jon

nordick26 · ‎01-04-2008

Hi all,

just one idea from my side:

I was thinking about this, so lets take a look :)

If you remove bpduguard from B and C switches and so that there will be normal STP election process and to protect your network from unauthorized STP root, enable "root guard" on appropriate ports.

The problem was, if i understood well, that during the time STP needed to block the ports, port-security has "blocked" the mac addresses you wanted to use after (mac of your server). So what about to decrease STP timers and mainly forwardig timer, during which the learing process (MAC address learning) happens.

If i had some free lab switches, i would try this, but i haven't so maybe you can try if you would like.

Maybe I should wake up :)

Have a nice weekend

Regards

Ivan

Kevin Dorrell · ‎01-04-2008

Ivan,

The problem is not so much to do with STP nor with the bpduguard. None of the STP root topology changes, and the bdpuguard cuts the loop as soon as it sees a BPDU, which it what it is supposed to do.

But during that second-and-a-half that the loop is active, all the broadcasts are storming round the loop SwitchB<->DumbSwitch1<->DumbSwitch2<->SwitchB. The broadcasts include some that originated from servers that are on switchA or switchC. As they storm round the loop, up to 8 of their source MAC addresses get registered as secure addresses on each port of switchB that connects to a DumbSwitch. (The port was in secure restrict mode). From then on, switchB will not forward correctly to those MAC addresses on switchA or switchC - it forwards them to the dumb switch ports instead. It continues to do that until the secure entries age out.

Kevin Dorrell

Luxembourg