cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
12219
Views
5
Helpful
5
Replies

change from dynamic auto to access mode will disable DTP effectively ?

AdamBudzinski
Level 1
Level 1

Hello all,

"n a basic switch spoofing attack, the attacker takes advantage of the fact that the default configuration of the switch port is dynamic auto. The network attacker configures a system to spoof itself as a switch. This spoofing requires that the network attacker be capable of emulating 802.1Q and DTP messages. By tricking a switch into thinking that another switch is attempting to form a trunk, an attacker can gain access to all the VLANs allowed on the trunk port."

My question is. Does configuration of an port from dynamic auto to access port shutdown DTP? Or would it still require the switchport nonegotiate command to be executed for the port in question ? 

EDIT: 

  • switchport nonegotiate- Prevents the interface from generating DTP frames. You can use this command only when the interface switchport mode is access or trunk. You must manually configure the neighboring interface as a trunk interface to establish a trunk link.

I think it answers my question but can someone please confirm 

Thank you and best regards

Adam 

1 Accepted Solution

Accepted Solutions

Peter Paluch
Cisco Employee
Cisco Employee

Hi Adam, Mark,

Please allow me to join.

As far as I know, a port set to static access mode has DTP deactivated by default. Using switchport nonegotiate on a static access port is not harmful but does not really affect anything, as DTP would have been deactivated anyway.

Check out the following output. I have two ports, one static access, one static trunk. In the show interfaces switchport output, the access port says "Negotiation of Trunking: Off" (which refers to DTP) while the trunk port reports this feature as On. When I deactivate DTP on the trunk using switchport nonegotiate, the trunk reports the trunking negotiation as Off, identical to what the access port has had all the time:

HQ(config)# do show run int fa0/10
Building configuration...

Current configuration : 58 bytes
!
interface FastEthernet0/10
 switchport mode access
end

HQ(config)# do show run int fa0/11
Building configuration...

Current configuration : 95 bytes
!
interface FastEthernet0/11
 switchport trunk encapsulation dot1q
 switchport mode trunk
end

HQ(config)# do show int fa0/10 switchport
Name: Fa0/10
Switchport: Enabled
Administrative Mode: static access
Operational Mode: down
Administrative Trunking Encapsulation: negotiate
Negotiation of Trunking: Off
[ ... cut ... ]
        
HQ(config)# do show int fa0/11 switchport
Name: Fa0/11
Switchport: Enabled
Administrative Mode: trunk
Operational Mode: down
Administrative Trunking Encapsulation: dot1q
Negotiation of Trunking: On
[ ... cut ... ]
        
HQ(config)# int fa0/11
HQ(config-if)# switchport nonegotiate
HQ(config-if)# do show run int fa0/11
Building configuration...

Current configuration : 119 bytes
!
interface FastEthernet0/11
 switchport trunk encapsulation dot1q
 switchport mode trunk
 switchport nonegotiate
end

HQ(config-if)# do show int fa0/11 switchport
Name: Fa0/11
Switchport: Enabled
Administrative Mode: trunk
Operational Mode: down
Administrative Trunking Encapsulation: dot1q
Negotiation of Trunking: Off
[ ... cut ... ]

I do not personally believe that an access port listens to DTP frames anymore. Yes, it can receive them (it is up to the connected link partner to send or not send these frames, right?) but it will drop them right away.

Even if the an attacker connects to a switch port that is configured as an access port it doesn't really matter because even if the neighboring  interface is set to dynamic auto/ dynamic desirable / trunk it will end up as an access port.

This is true but an attacker wouldn't be using an ordinary Cisco switch that is well-behaved. The attacker would use a PC and a DTP message injector tool to try to force the other port to become a trunk, regardless of what is the other port's response. Of course, if the port at the other end is a static access port, the attacker is out of luck.

Best regards,
Peter

View solution in original post

5 Replies 5

Mark Malone
VIP Alumni
VIP Alumni

Hey

Yes you have that right when that command is on place you have to manually specific the trunk it will not automatically form when you connect a switch to it that's already set to trunk

If its set as an access port it wont send DTP frames but can still receive them , in saying that I don't think once its configured as an access port could a hacker connect that way , when you check the port show in x/x switchport you will see it as access only so it should not form even if DTP messages are received from the rogue switch and non negotiate is not in place

DTP is proprietary so if you ever need to connect another vendor switch this is where you will need it as you will have to turn if off as for example a Dell/HP switch would not understand DTP protocol

Thank you Mark. 

If its set as an access port it wont send DTP frames but can still receive them , in saying that I don't think once its configured as an access port could a hacker connect that way

I think you are right.

Even if the an attacker connects to a switch port that is configured as an access port it doesn't really matter because even if the neighboring  interface is set to dynamic auto/ dynamic desirable / trunk it will end up as an access port.

BR

Adam 

Peter Paluch
Cisco Employee
Cisco Employee

Hi Adam, Mark,

Please allow me to join.

As far as I know, a port set to static access mode has DTP deactivated by default. Using switchport nonegotiate on a static access port is not harmful but does not really affect anything, as DTP would have been deactivated anyway.

Check out the following output. I have two ports, one static access, one static trunk. In the show interfaces switchport output, the access port says "Negotiation of Trunking: Off" (which refers to DTP) while the trunk port reports this feature as On. When I deactivate DTP on the trunk using switchport nonegotiate, the trunk reports the trunking negotiation as Off, identical to what the access port has had all the time:

HQ(config)# do show run int fa0/10
Building configuration...

Current configuration : 58 bytes
!
interface FastEthernet0/10
 switchport mode access
end

HQ(config)# do show run int fa0/11
Building configuration...

Current configuration : 95 bytes
!
interface FastEthernet0/11
 switchport trunk encapsulation dot1q
 switchport mode trunk
end

HQ(config)# do show int fa0/10 switchport
Name: Fa0/10
Switchport: Enabled
Administrative Mode: static access
Operational Mode: down
Administrative Trunking Encapsulation: negotiate
Negotiation of Trunking: Off
[ ... cut ... ]
        
HQ(config)# do show int fa0/11 switchport
Name: Fa0/11
Switchport: Enabled
Administrative Mode: trunk
Operational Mode: down
Administrative Trunking Encapsulation: dot1q
Negotiation of Trunking: On
[ ... cut ... ]
        
HQ(config)# int fa0/11
HQ(config-if)# switchport nonegotiate
HQ(config-if)# do show run int fa0/11
Building configuration...

Current configuration : 119 bytes
!
interface FastEthernet0/11
 switchport trunk encapsulation dot1q
 switchport mode trunk
 switchport nonegotiate
end

HQ(config-if)# do show int fa0/11 switchport
Name: Fa0/11
Switchport: Enabled
Administrative Mode: trunk
Operational Mode: down
Administrative Trunking Encapsulation: dot1q
Negotiation of Trunking: Off
[ ... cut ... ]

I do not personally believe that an access port listens to DTP frames anymore. Yes, it can receive them (it is up to the connected link partner to send or not send these frames, right?) but it will drop them right away.

Even if the an attacker connects to a switch port that is configured as an access port it doesn't really matter because even if the neighboring  interface is set to dynamic auto/ dynamic desirable / trunk it will end up as an access port.

This is true but an attacker wouldn't be using an ordinary Cisco switch that is well-behaved. The attacker would use a PC and a DTP message injector tool to try to force the other port to become a trunk, regardless of what is the other port's response. Of course, if the port at the other end is a static access port, the attacker is out of luck.

Best regards,
Peter

Peter, you're more than welcome to join !

You're answers make perfect sense to me! 

All doubts are sorted out right now. 

Thank you and best regards

Adam 

AdamBudzinski
Level 1
Level 1

Hallo Peter,

this just came to my mind, if it's still ok for you to answer the following question in this thread that would be great ! 

"This is true but an attacker wouldn't be using an ordinary Cisco switch that is well-behaved. The attacker would use a PC and a DTP message injector tool to try to force the other port to become a trunk, regardless of what is the other port's response. Of course, if the port at the other end is a static access port, the attacker is out of luck." 

So that means that the attacker's device (whatever it is) should (I'm not sure if it's the right wording) emulate ? simulate ? a switch and it's port connecting to the real switch port (in dynamic auto state) , should be sending DTP frames as if it would be in dynamic desirable / trunk state , is this correct? 

Best regards

Adam 

Review Cisco Networking for a $25 gift card