Sunday, February 28, 2016

SWITCH Study Notes – Securing The Switches & Tunneling


  • The enable password can be set using “enable password” or “enable secret” commands
    • SW2(config)#enable password yourpassword
    • SW2(config)#enable secret yoursecretpassword
      • The “enable secret” command encrypts the password in the configuration without the “service password-encryption” command.
      • The “enable secret” command supersedes the “enable password” command and this password will be used instead.
  • All passwords appear in the configuration in clear text by default except the enable secret.
    • The command service password-encryption will encrypt the remaining passwords.
  • When configuring VTY lines be sure to enable “login” and set a password or else they will not be able to log in via telnet, ssh, etc
    • SW2(config)#line con 0
    • SW2(config-line)#login
      % Login disabled on line 0, until ‘password’ is set
    • SW2(config-line)#password lbsser
  • Cisco switches have more VTY lines than routers. Routers allow up to five simultaneous Telnet sessions, switches allow more – 0-15 (16) typically
  • Any user who telnets in to a switch will be placed into user exec mode, and will then be prompted for the proper enable mode password.
    • If neither the enable secret nor the enable password has been set, the user will not be able to enter enable mode
To place users coming into the switch via telnet straight into enable mode, use the command “privilege level 15” under the VTY lines.
  • SW2(config)#line con 0
  • SW2(config-line)#privilege level 15
To place some users in user user-exec mode and some into privileged-exec mode create a local user database, set the appropriate privilege levels and set the VTY login to use the “local” database (remove any passwords configured on VTY lines as good habit and housekeeping):
  • SW2(config)#username lbsources privilege 15 password CCIE
    • Configures the user for privilege level 15 – will be placed into privilege-exec mode on login
  • SW2(config)#username joeshmoe password CCNP
  • SW2(config)#username ricosuave password CCNA
    • No privilege level set – will be placed into global configuration mode and be required to enter the enable password to enter privilege-exec mode.
  • SW2(config)#line vty 0 15
  • SW2(config-line)#login local
Introduction To AAA
You can use RADIUS and TACACS+ to support AAA (Authentication, Authorization, and Accounting) on Cisco routers/switches
  • RADIUS (Remote Authentication Dial-In User Service) uses UDP
  • TACACS+ Terminal Access Controller Access Control System) uses TCP
Authentication
  • To enable AAA:
·          
    • SW2(config)#aaa new-model
  • Basics to configure a RADIUS server
·          
    • SW2(config)#radius-server host 172.1.1.1
  • Basics to configure TACACS+
·          
    • SW2(config)#tacacs-server host 172.1.1.1
  • Configure methods of authentication
·          
    • SW2(config)#aaa authentication login default local group radius <- This command would check the local database first, then the RADIUS server(s)
      • Login = Set lists for authenticating login
      • Default = The default authentication list that will be created with the methods of AAA
      • Local = Use the loca username database for authentication
      • Group = Use the following server group
      • Radius = Use list of RADIUS groups defined
  • Apply to VTY lines:
·          
    • SW2(config)#line vty 0 15
    • SW2(config-line)#login authentication default
      • Default = use the default authentication list
Authorization
  • RADIUS is limited in the different levels of authorization
  • TACACS+ can be configured to force the user to be authenticated for any of the following tasks:
·          
    • SW2(config)#aaa authorization ?
      auth-proxy For Authentication Proxy Services
      commands For exec (shell) commands.
      config-commands For configuration mode commands.
      configuration For downloading configurations from AAA server
      exec For starting an exec (shell).
      network For network services. (PPP, SLIP, ARAP)
      reverse-access For reverse access connections
  • Authorization is applied in the same way Authentication was.
Accounting
  • Accounting will use a RADIUS or TACACS+ server to track user activity
  • The more accounting you do, the more resources it takes from your router/switch.
  • Basics to configure accounting:
·          
    • SW2(config)#aaa accounting ?
      commands For exec (shell) commands.
      connection For outbound connections. (telnet, rlogin) exec For starting an exec (shell).
      nested When starting PPP from EXEC, generate NETWORK records before EXEC-STOP record.
      network For network services. (PPP, SLIP, ARAP)
      send Send records to accounting server.
      suppress Do not generate accounting records for a specific type of user.
      system For System events.
      update Enable accounting update records.
  • Apply the methods list:
·          
    • SW2(config)#line vty 0 15
    • SW2(config-line)#accounting ?
      arap For Appletalk Remote Access Protocol
      commands For exec (shell) commands
      connection For connection accounting
      exec For starting an exec (shell)
Port Security
  • Port security uses a host’s MAC address as a password, and if a device with a different MAC address sends frames to the switch on that port, the port will take action – by default, it will shut down.
  • To enable port security:
·          
    • SW2(config)#int fast 0/5
    • SW2(config-if)#switchport port-security
      Command rejected: Fa0/5 is not an access port. <– Port must be made an access port. Ports security can’t be enabled on a port that can possibly form a trunk
·          
    • SW2(config-if)#switchport mode access
    • SW2(config-if)#switchport access vlan 10
    • SW2(config-if)#switchport port-security ?
      aging Port-security aging commands
      mac-address Secure mac address <– Identify the secure MAC address for this port – static option
      maximum Max secure addresses <– the maximum number of secure MAC addresses allowed on the port. This number can vary.  These addresses can be configured statically with the mac-address option, or they can be learned dynamically
      violation Security violation mode
      <cr>
·          
    • SW2(config-if)#switchport port-security violation ?
      protect Security violation protect mode <– Protect mode drops the offending frames
      restrict Security violation restrict mode <– Restrict mode drops the offending frames and will generate both an SNMP trap notification and syslog message regarding the violation.
      shutdown Security violation shutdown mode <- DEFAULT – the port is placed into error-disabled state, an SNMP trap message is generated and manual intervention is needed to reopen the port
  • Output from a port running in default “shutdown” mode when the receiving frames from a different MAC address than the one configured:
    05:06:04: %PM-4-ERR_DISABLE: psecure-violation error detected on Fa0/7, puttingFa0/7 in err-disable state
    05:06:04: %PORT_SECURITY-2-PSECURE_VIOLATION: Security violation occurred, caused by MAC address 000f.f773.ed20 on port FastEthernet0/7.
    05:06:05: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/7, changed state to down
    05:06:06: %LINK-3-UPDOWN: Interface FastEthernet0/7, changed state to down
·         SW1#show int fast 0/7
FastEthernet0/7 is down, line protocol is down (err-disabled) <– That port must now manually be reopened
  • When you specify the number of secure MAC addresses, and you specify secure MAC addresses – if you allow for more secure MAC address than you actually configure manually the remaining secure MAC address will be dynamically learned. This means a rogue host can connect to the port and it will be allowed to communicate.
·          
    • SW1(config-if)#switchport port-security
    • SW1(config-if)#switchport port-security maximum 3
    • SW1(config-if)#switchport port-security mac-address aaaa.aaaa.aaaa
    • SW1(config-if)#switchport port-security mac-address cccc.cccc.cccc
  • To verify your port security configuration, run show port-security interface.
·          
    • SW1#show port-security interface fast 0/2
      Port Security : Enabled
      Port Status : Secure-up
      Violation Mode : Shutdown
      Aging Time : 0 mins
      Aging Type : Absolute
      SecureStatic Address Aging : Disabled
      Maximum MAC Addresses : 3
      Total MAC Addresses : 2
      Configured MAC Addresses : 2
      Sticky MAC Addresses : 0
      Last Source Address:Vlan : 0000.0000.0000:0
      Security Violation Count : 0
  • Port security cannot be configured on the following types of ports:
·          
    • trunk ports
    • ports placed in an Etherchannel
    • destination SPAN port
    • 802.1x ports
Dot1x Port-Based Authentication
  • Based on the IEEE 802.1x standard
  • The Cisco authentication server must be RADIUS, TACACS+ is not supported.
  • Major difference between dot1x port-based security and port security:
·          
    • With Dot1x port based authentication, host(s) and switch ports must be configured for 802.1x EAPOL (Extensible Authentication Protocol over LANs).
  • Until the user is authenticated, only the following protocols can travel through the port:
·          
    • EAPOL
    • STP
    • CDP
      • By default, once the user authenticates, all traffic can be received and transmitted through this port.
  • To configure dot1x, AAA must be enabled and a method list must be created.
·          
    • SW2(config)#aaa new-model
    • SW2(config)#aaa authentication dot1x ?
      WORD Named authentication list.
      default The default authentication list.
·          
    • SW2(config)#aaa authentication dot1x default ?
    • SW2(config)# aaa authentication dot1x default group radius local
  • To enable dot1x on the switch:
·          
    • SW2(config)#dot1x ?
      system-auth-control Enable or Disable SysAuthControl
  • Dot1x must be configured globally, but every switch port that’s going to run dot1x authentication must be configured as well.
·          
    • SW2(config-if)#dot1x port-control ?
      auto PortState will be set to AUTO
      force-authorized PortState set to Authorized
      force-unauthorized PortState will be set to UnAuthorized
  • Force-authorized – forces the port to authorize any host attempting to use the port, but authentication is not required. Basically, there is no authentication on this port type.
  • Force-unauthorized – literally has the port unable to authorize any client – even clients who could otherwise successfully authenticate
  • The auto setting enables dot1x on the port, which will begin the process as unauthorized. Only the necessary EAPOL frames will be sent and received while the ports unauthorized. Once the authentication is complete, normal transmission and receiving can begin. This is the most common setting.
SPAN Basics
  • SPAN allows the switch to mirror the traffic from the source port(s) to the destination port to which the network analyzer is attached. (In some Cisco documentation, the destination port is referred to as the monitor port.)
  • The number of simultaneous sessions you can run differs from one switch platform to another
  • There are several versions of SPAN, the differences depend on source ports – its’ the location of the source ports that determines the SPAN version
·          
    • Local SPAN – Destination and source ports are all on same switch
    • VLAN-based SPAN – Source is a VLAN rather than a collection of physical ports.
Local SPAN
  • To enable SPAN:
·          
    • SW2(config)#monitor session 1 source interface fast 0/1 – 5 <– Configure source ports/VLANs
    • SW2(config)#monitor session 1 destination interface fast 0/10 <– Configure destination port
  • Verify the SPAN configuration with show monitor
·         SW2#show monitor
Remote SPAN
  • When traffic to be monitored is on one switch, but the only vacant port available is on another switch or there is a switch in between the switch you wish to monitor, you must use Remote SPAN (RSPAN)
  • All switches along the path to the destination port will need to be configured for RSPAN
  • Considers when configuring RSPAN:
·          
    • If there are intermediate switches between the source and destination switches, they would all need to be RSPAN-capable.
    • VTP treats the RSPAN VLAN like any other VLAN. It will be propagated throughout the VTP domain if configured on a VTP server. Otherwise, it’s got to be manually configured on every switch along the intermediate path. VTP Pruning will also prune the RSPAN VLAN under the same circumstances that it would prune a “normal” VLAN.
    • MAC address learning is disabled for the RSPAN VLAN.
    • The source and destination must be defined on both the switch with the source port and the switch connected to the network analyzer, but the commands are not the same on each.
Configuring RSPAN
  • Create the VLAN first, and identify it as the RSPAN VLAN with the remote-span command.
·          
    • SW2(config)#vlan 30
    • SW2(config-vlan)#remote-span
  • SW2 is the source switch, and the traffic from ports 0/1 – 0/5 will be monitored and frames mirrored to SW1 via RSPAN VLAN 30.
·          
    • SW2(config)#monitor session 1 source interface fast 0/1 – 5  <– Define source ports on source switch
    • SW2(config)#monitor session 1 destination remote ?
      vlan Remote SPAN destination RSPAN VLAN
  • SW2(config)#monitor session 1 destination remote vlan 30 ?
    reflector-port Remote SPAN reflector port
  • SW2(config)#monitor session 1 destination remote vlan 30 reflector-port fast 0/12 <– Define the port that will be copying SPAN traffic onto VLAN 30
  • SW1(config)#monitor session 1 source remote vlan 30 <– Define the RSPAN VLAN.
  • SW1(config)#monitor session 1 destination interface fast 0/10 <– SW1 will receive the mirrored traffic and will send it to a network analyzer on port 0/10.
  • Run show monitor to verify the configuration.
·          
    • SW1#show monitor
SPAN Limitations
  • Source port notes:
    • A source port can be monitored in multiple, simultaneous SPAN sessions.
    • A source port can be part of an Etherchannel.
    • A source port cannot be configured as a destination port.
    • A source port can be any port type – Ethernet, FastEthernet, etc.
  • Destination port notes:
    • A destination port can be any port type.
    • A destination port can participate in only one SPAN session.
    • A destination port cannot be a source port.
    • A destination port cannot be part of an Etherchannel.
    • A destination port doesn’t participate in STP, CDP, VTP, PaGP, LACP, or DTP.
  • Trunk ports can be configured as source and/or destination SPAN ports; the default behavior will result in the monitoring of all active VLANs on the trunk.
  • ESPAN – Enhanced SPAN. This term has been used to describe different additions that the term has lost meaning. It doesn’t refer to any specific addition or change to SPAN.
VLAN Access Control Lists
  • An ACL can filter traffic traveling between VLANs, but cannot prevent hosts in a VLAN from communicating from another host in the same VLAN.
  • ACLs on switches:
    • Multilayer switchs can use an ACL to filter traffic for hosts on different VLANS
    • Multilayer switchs must use a  VACL to filter traffic for hosts on the same VLAN
  • An ACL must be written in combination with a VACL. The ACL will be used to as the match criterion within the VACL.
    • SW2(config)#ip access-list extended NO_123_CONTACT
    • SW2(config-ext-nacl)#permit ip 171.10.10.0 0.0.0.3 172.10.10.0 0.0.0.255
  • VLAN access-map – any traffic matching the ACL to be dropped and all other traffic to be forwarded.
    • SW2(config)# vlan access-map NO_123 10
    • SW2(config-access-map)# match ip address NO_123_CONTACT
    • SW2(config-access-map)# action drop
    • SW2(config-access-map)# vlan access-map NO_123 20
    • SW2(config-access-map)# action forward
      • You must add the final “action forward” statement in order to pass unmatched traffic. Same theory holds when writing a VLAN access-map as with a route-map. Any traffic that doesn’t match the specific clause in the ACL will be dropped.
  • Apply the VACL
    • SW2(config)# vlan filter NO_123 vlan-list 100
  • VACL notes:
    • Bridged traffic, as well as non-IP and non-IPX traffic, should be filtered with VACLs
    • VACLs run from top to bottom, and run until a match occurs
    • VACLs have an implicit deny at the end. The VACL equivalent of “permit all” is an “action forward” clause with no match criterion, as shown in the previous example. If traffic is not expressly forwarded, it’s implicitly dropped!
    • Only one VACL can be applied to a VLAN
    • The sequence numbers allow you to go back and add lines without rewriting the entire VACL. They are still active while being edited.
    • A routing ACL can be applied to a SVI to filter inbound and/or outbound traffic just as you would apply one to a physical interface, but VACLs are not applied in that way – they’re applied in global configuration mode.
    • On L3 switches, if there’s a VACL configured, and a “normal” ACL affecting incoming traffic that is applied to a routed port that belongs to that same VLAN. Packets entering that VLAN will be matched against the VACL first; if the traffic is allowed to proceed, it will then be matched against the inbound ACL on that port.
Dot1q Tunneling
  • Dot1q tunneling allows a service provider to transport frames from different customers over the same tunnel – even if they’re using the same VLAN numbers. This technique also keeps customer VLAN traffic segregated from the service provider’s own VLAN traffic.
  • Dot1q tunneling configuration takes place on the service provider sending and receiving data to customer switches:
    • MLS_1(config)#int fast 0/12
    • MLS_1(config-if)#switchport access vlan 100
      • The VLAN number that the customer is using.
    • MLS_1(config-if)#switchport mode dot1qtunnel
    • MLS_1(config-if)#vlan dot1q tag native
  • STP, VTP and CDP (service provider accepts CDP, but doesn’t send them through the tunnel) frames will not be transmitted over the dot1q tunnel (this gives the customer only a partial and inaccurate picture of this network). To transmit such frames, a Layer 2 Protocol Tunnel must be built on the service provider edge switches.
Ethernet over MultiProtocol Label Switching
  • Another approach to solve the requirements of STP, VTP and CDP packets to be received and sent over the service providers network to far-end switches.
  • Service providers must have an MPLS core to support this option.
  • With EoMPLS, the service provider cloud consists of two router types.
    • Edge Label Switch Routers (ELSR)
    • Label Switch Routers (LSR)
  • The Edge Label Switch Routers (ELSR) are found at the edge of the cloud, and these routers place a MPLS tag, or label, onto incoming traffic that meets predefined criteria. Inside the cloud, Label Switch Routers (LSR) will route the traffic looking only at the MPLS label. Once the remote ELSR receives the packet, the MPLS label is removed and the data can be forwarded normally. The original VLAN value is kept intact.
Transparent LAN Service
  • Another approach to solve the requirements of STP, VTP and CDP packets to be received and sent over the service providers network to far-end switches.
  • Transparent LAN Service is basically a LAN interconnection technology that hides the connecting WAN from the end users
  • One drawback to TLS is that broadcasts will be treated as a broadcast on any VLAN – they’ll be sent to every host in the VLAN
Private VLANs
  • Hosts placed into secondary VLANs may have one of the following configurations:
    • The host will be able to communicate with other hosts in the secondary VLAN and with the primary VLAN, but not with hosts in other secondary VLANs – this is a community private VLAN
    • The host can communicate with the primary VLAN, but with no other hosts, including other hosts in its own secondary VLAN — this is an isolated private VLAN
  • As an example, a router located off a switch port that has been configured as a private VLAN port – The following are options:
  • Promiscuous mode: The device connected to the private VLAN port can communicate with any device connected to any primary or secondary VLAN – This is the recommended mode for ports connected to gateway devices, such as the router
  • The host connected to the port is on either type of private VLAN (isolated or community), and can communicate with devices found off other promiscuous ports. If the host is configured as part of a community private VLAN, the host can also communicate with other hosts in that private VLAN.
  • Configuring Private VLANs
    • MLS(config-vlan)#private-vlan ?
      association Configure association between private VLANs
      community Configure the VLAN as a community private VLAN
      isolated Configure the VLAN as an isolated private VLAN
      primary Configure the VLAN as a primary private VLAN
      twoway-community Configure the VLAN as a two way community private VLAN
·          
    • MLS(config-vlan)#private-vlan community
Private VLANs can only be configured when VTP is in transparent mode
·          
    • MLS(config-vlan)#exit
    • MLS(config)#vtp mode transparent
Setting device to VTP TRANSPARENT mode.
  • Now the primary VLAN must be configured as the “associate” of the private VLAN.
    • MLS(config)#vlan 20
    • MLS(config-vlan)#private-vlan community
    • MLS(config-vlan)#private-vlan association ?
      WORD VLAN IDs of the private VLANs to be configured
      add Add a VLAN to private VLAN list
      remove Remove a VLAN from private VLAN list
·          
    • MLS(config-vlan)#private-vlan association 30
  • Now place the ports into the private VLAN:
    • MLS(config)#interface f0/4
    • MLS(config-if)# switchport mode private-vlan 20 host
      • If this were the port connected to a router, we’d need the promiscuous option configured instead of host.
DHCP Snooping
  • DHCP Snooping allows the switch to serve as a firewall between hosts and untrusted DHCP servers. DHCP Snooping classifies interfaces on the switch into one of two categories – trusted and untrusted.
  • DHCP messages received on trusted interfaces will be allowed to pass through the switch.
  • DHCP messages received on untrusted interfaces be dropped by the switch, the interface itself will be placed into err-disabled state.
  • When DHCP Snooping is enabled, all ports are considered untrusted
  • Enable DHCP Snooping on the entire switch:
    • SW1(config)#ip dhcp snooping
  • Identify the VLANs that will be using DHCP Snooping.
    • SW1(config)#ip dhcp snooping ?
      database DHCP snooping database agent
      information DHCP Snooping information
      verify DHCP snooping verify
      vlan DHCP Snooping vlan
      <cr>
·          
    • SW1(config)#ip dhcp snooping vlan ?
      WORD DHCP Snooping vlan fist number or vlan range, example: 1,3-5,7,9-11
·          
    • SW1(config)#ip dhcp snooping vlan 4
  • Assuming we have a trusted DHCP server off port 0/10, we would then trust that port with the following command:
    • SW1(config-if)#ip dhcp snooping trust
  • DHCP Snooping is verified with the show ip dhcp snooping command.
    • SW1#show ip dhcp snooping
Dynamic ARP Inspection
  • ARP Cache Poisoning / ARP Spoofing: A rogue host responds to an ARP request intended for another hose with its own MAC address. The rogue host will acquire the true MAC address of the intended host and possibly relay (after reading) packets from the originating host to the intended host – through itself – creating a man in the middle scenario
  • Cisco’s recommended trusted/untrusted port configuration is to have all ports connected to hosts run as untrusted and all ports connected to switches as trusted.
  • Since DAI runs only on ingress ports, this configuration scheme ensures that every ARP packet is checked once, but no more than that.
  • There is no problem with running DAI on trunk ports or ports bundled into an Etherchannel.
  • Enabling Dynamic ARP Inspection (DAI) prevents this behavior by building a database of trusted MAC-IP address mappings – using the same database that is built by the DHCP Snooping process.
  • DAI uses the concept of trusted and untrusted ports, just as DHCP Snooping does. However, untrusted ports in DAI do not automatically drop ARP Requests and Replies.
  • Once the IP-MAC address database is built, every single ARP Request and ARP Reply received on an untrusted interface is examined.
    • If the ARP message has an approved MAC-IP address mapping, the message is forwarded appropriately; if not, the ARP message is dropped.
    • If the interface has been configured as trusted, DAI allows the ARP message to pass through without checking the database of trusted mappings.
  • DAI is performed as ARP messages are received, not transmitted.
  • Since DAI uses entries in the DHCP Snooping database to do its job, DHCP Snooping must be enabled before beginning to configure DAI.
  • Configuring Dynamic Arp Inspection:
    • SW1(config)#ip arp inspection ?
      filter Specify ARP acl to be applied
      log-buffer Log Buffer Configuration
      validate Validate addresses
      vlan Enable/Disable ARP Inspection on vlans
·          
    • SW1(config)#ip arp inspection vlan ?
      WORD vlan range, example: 1,3-5,7,9-11
·          
    • SW1(config)#ip arp inspection vlan 4
    • SW1(config)#int fast 0/4
    • SW1(config-if)#ip arp inspection trust
  • DAI “validate” options:
    • SW1(config)#ip arp inspection validate ?
      dst-mac Validate destination MAC address <– compares the source MAC address in the Ethernet header and the MAC address of the source of the ARP message.
ip Validate IP addresses  <– compares the IP address of the sender of the ARP Request against the destination address of the ARP Reply.
src-mac Validate source MAC address ß compares the destination MAC address in the Ethernet header
  • To verify DAI configuration:
    • SW1#show ip arp inspection
IP Source Guard
  • Use IP Source Guard to prevent a host on the network from using another host’s IP address.
  • IP Source Guard works in tandem with DHCP Snooping, and uses the DHCP Snooping database to carry out this operation.
  • As with DAI, DHCP Snooping must be enabled before enabling IP Source Guard.
  • How IP Source Guard works:
    • When the host first comes online and connects to an untrusted port on the switch, the only traffic that can reach that host are DHCP packets.
    • When the client successfully acquires an IP address from the DHCP Server, the switch makes a note of this IP address assignment.
    • The switch will then dynamically create an ACL that will only allow traffic with the corresponding source IP address to be processed by the switch.
    • If the host pretends to be another host on that subnet, or to spoof that host’s IP address — the switch will simply filter that traffic because the source IP address will not match the database’s entry for that port.
MAC Address Flooding
  • A MAC Address Flooding attack is an attempt by a network intruder to overwhelm the switch memory reserved for maintenance of the MAC address table. The intruder generates a large number of frames with different source MAC addresses – all of them invalid. As the switch’s MAC address table capabilities are exhausted, valid entries cannot be made – and this results in those valid frames being broadcast instead of unicast.
  • This has three side effects:
    • As mentioned, the MAC address table fills to capacity, preventing legitimate entries from being made.
    • The large number of unnecessary broadcasts quickly consumes bandwidth as well as overall switch resources
    • The intruder can easily intercept packets with a packet sniffer, since the unnecessarily broadcasted packets will be sent out every port on the switch – including the port the intruder is using.
    • When the switch on the other side of the trunk gets that frame, it sees the tag for VLAN 100 and forwards the frame to ports in that VLAN. The rogue now has successfully fooled the switches and has hopped from one VLAN to another.
  • MAC address flooding can be combated using 2 features:
    • Port-based authentication
    • Port-security
VLAN Hopping
  • One method of VLAN hopping is where double tagging takes place. The intruder will transmit frames that are double tagged with two separate VLAN IDs. Changing the native VLAN and having no hosts on this VLAN usually resolves this issue with this version.
    • When the rogue host transmits a frame, that frame will have two tags. One will indicate native VLAN membership, and the second will be the number of the VLAN under attack.
    • The trunk receiving this double-tagged frame will see the tag for the native VLAN, that tag will be removed and then transmitted across the trunk – but the tag VLAN under attack is still there!
    • When the switch on the other side of the trunk gets that frame, it sees the tag for the VLAN under attack and forwards the frame to ports in that VLAN.
    • The rogue now has successfully fooled the switches and has hopped from one VLAN to another.
  • Circumstances for double tagging attacks to be successful:
    • The intruder’s host device must be attached to an access port.
    • The VLAN used by that access port must be the native VLAN.
    • Dot1q must be the trunking protocol in use, since ISL doesn’t use the native VLAN.
  • Switch Spoofing – Allows the rogue to pretend to be a member of *all* VLANs in your network.
    • A switch in default dynamic desirable mode sends out DTP frames in an aggressive effort to form a trunk
    • When a port is left at this default and placed into “auto” mode, a trunk will still form, though it’s not actively trying to do so.
    • The rogue host will pretend to be a switch and send DTP frames back to the switch and this will lead to a trunk.
    • Once the trunk is formed, the rogue now has access to  all VLANs known to that switch and the network
  • To prevent Switch Spoofing and as best practice turn ports into access ports – this disables the port’s ability to create a trunk.
Any corrections or additions are greatly appreciated! You can download a copy of these notes by clicking the “Printer Friendly” below.
Cheers!