Port Security

NightShade03NightShade03 Member Posts: 1,383 ■■■■■■■□□□
I think I'm missing something here....

I'm trying to configure port security on my switch to mitigate layer 2 attacks (specifically someone plugging in a rouge switch). Assuming I have a 24 port switch I do the following:

SW1(config)# interface range FastEthernet0/1 - 23
SW1(config-if-range)# switchport mode access

SW1(config)# interface range FastEthernet0/24
SW1(config-if)# switchport mode trunk
SW1(config-if)# switchport nonegotiate

My understanding now is that ports 1 - 23 are now access only and they can't give the rouge switch any access to other VLANs. What I'm missing is what prevents the attacker from plugging into port 24 and messing with the trunking there?

The best defense I can see is if he unplugs the trunk cable from port 24 users will start complaining they can't access things...meaning something is up and someone will check the switch (hopefully). Am I on the right track here? I know that you can also go deeper into port security with access violations and such as well.

Comments

  • captobviouscaptobvious Member Posts: 648
    The best way to stop someone from plugging in a switch to fa0/24, lock the switch in a room.
  • josunin75josunin75 Member Posts: 44 ■■□□□□□□□□
    You can use bpduguard.

    that would prevent the ports from getting bpdus from other switches.
    =============================
    on to BCMSN ^=============^

    <Lab>
    2 x 3550 EMI
    2 x 2950
    2 x 3640
    1 x 2621
    =============================
  • dtlokeedtlokee Member Posts: 2,378 ■■■■□□□□□□
    It is a difficult question to answer, it depends on how paranoid you really are. In your example what is plugged into port fa0/24? Also your configuration you have provided will not prevent somone from connecting a switch to the network but rather it will prevent somone from VLAN hopping because the ports are configured as access. BPDUGuard along with port security to limit the number of MAC addresses in the CAM would be a better choice.
    The only easy day was yesterday!
  • Daniel333Daniel333 Member Posts: 2,077 ■■■■■■□□□□
    Well, I am not a networking guy... (but I play one on TV)

    Seems to me your access ports will have runs out to the desk out of the server room. Your trunk port won't leave the rack for the most part. So you really don't need to worry about it. Physical layer security has you covered. BUT then again, that isn't really defense in depth...

    I am not in front of a switch, but I think you can also place a stickie on the trunk. Here is a sample of code I stole from cisco.com. So you configure your alerts anytime I new Mac address is on the port.
    code
    This example shows how to configure a secure MAC-address and a maximum limit of secure MAC
    addresses on interface g1/1:
    Switch(config)# interface g1/1
    Switch(config-if)# switchport trunk encapsulation dot1q
    Switch(config-if)# sw mode trunk
    Switch(config-if)# switchport port-security
    Switch(config-if)# switchport port-security maximum 33
    Switch(config-if)# switchport port-security mac-address sticky
    Switch(config-if)# vlan 2-6
    Switch(config-if-vlan-range)# port-security maximum 3
    Switch(config-if-vlan-range)# port-security mac-address 1.1.1
    Switch(config-if-vlan-range)# port-security mac-address sticky 1.1.2
    Switch(config-if-vlan-range)# port-security mac-address sticky 1.1.3
    Switch(config-if-vlan-range)#
    [/code]
    -Daniel
  • Ryan82Ryan82 Member Posts: 428
    I don't think I would set port-security on the trunk interface. Think of all the source mac-addresses that may possibly traverse that trunk from your network in transit to other areas. I may be wrong, but I haven't seen it done.

    Bpduguard is a good feature to enable on your access ports, specifically if you have portfast enabled on them. Bpduguard isn't going to have any effect obviously if a user plugs a d-link switch, but the port-security would catch the extra mac's.

    Another good idea would be to set your trunk native vlan to a vlan not used in your network. Just make sure you configure it on both ends of the link so you don't receive the annoying native vlan mismatch messages.
  • NightShade03NightShade03 Member Posts: 1,383 ■■■■■■■□□□
    Thanks for all the responses, wanted to clarify another fact to for the exam. I understand that with root guard you can block other switches from knocking out the root bridge, and while this is probably helpful against attacks, doesn't this really affect the STP convergence? What happens in the root bridge fails and root guard is enabled?
  • AlexMRAlexMR Member Posts: 275
    Thanks for all the responses, wanted to clarify another fact to for the exam. I understand that with root guard you can block other switches from knocking out the root bridge, and while this is probably helpful against attacks, doesn't this really affect the STP convergence? What happens in the root bridge fails and root guard is enabled?

    Very good question! I wanted to ask it and have it in my notes...somebody please, the answer...:D.
    Training/Studying for....CCNP (BSCI) and some MS.
  • Ryan82Ryan82 Member Posts: 428
    Root guard is used in order to have more control over which switch in your network is the root.

    A root switch and secondary root switch are selected. Say you have 3 different switches in a triangle. A is the root B is secondary root and c is the other switch. First by setting any ports as hard coded access ports, they won't form a trunk with another switch but in addition to that if you had a port set as dynamic desireable or trunk on say switch C and you wanted to prevent anyone from plugging in a switch that would preempt your root bridge with a lower bridge priority to become the root, then you would turn on root guard on that port and so when that port receives a superior bpdu (lower priority) it would put that port into a error inconsistent state.

    Hope that makes sense.
  • dtlokeedtlokee Member Posts: 2,378 ■■■■□□□□□□
    The implementation of root guard is straight forward, if it's a port connected to a trusted switch (one that you have configured correctly) then don't use root guard, if it's a port that could be connected to an untrusted switch then you use it.

    In order for a new switch added to the network it needs to have a lower bridge ID which in the world of Cisco is the priority and mac address but on other switches may just be the mac address and that could cause an issue even if you set your preferred root switch to priority 0.
    The only easy day was yesterday!
Sign In or Register to comment.