Secure Access -

Secure Access


Switch Access

Error Conditions

    By default, a Catalyst switch detects an error condition on every switch port for every possible cause. If an error condition is detected, the switch port is put into the “errdisable” state and is disabled.

Switch(config)# [ no ] errdisable detect cause [ all | cause-name ]
  • all - detects every possible cause
  • arp-inspection - detects errors with dynamic ARP inspection
  • bpduguard - detects when a spanning-tree bridge protocol data unit (BPDU) is received on a port configured for STP PortFast
  • dhcp-rate-limit - detects an error with DHCP snooping
  • dtp-flap - detects when trunking encapsulation is changing from one type to another
  • gbic-invalid - detects the presence of an invalid GBIC or SFP module
  • inline-power - detects an error with offering PoE inline power
  • l2ptguard - detects an error with Layer 2 Protocol Tunneling
  • link-flap - detects when the port link state is “flapping” between the up and down states
  • loopback - detects when an interface has been looped back
  • pagp-flap - detects when an EtherChannel bundle’s ports no longer have consistent configurations
  • pppoe-ia-rate-limit - detects errors with PPPoE Intermediate Agent rate limiting
  • psecure-violation - detects conditions that trigger port security configured on a port
  • psp - detects an error related to protocol storm protection
  • security-violation - detects errors related to 802.1X security
  • sfp-config-mismatch - detects errors related to SFP configuration mismatches
  • small-frame - detects errors when VLAN-tagged packets are too small and arriveabove a certain rate
  • storm-control - detects when a storm control theshhold has been exceeded on a port
  • udld - detects when a link is seen to be unidirectional (data passing in only one direction).

Automatically Recover from Error Conditions

Switch(config)# errdisable recovery cause [ all | cause-name ]
Switch(config)# errdisable recovery interval seconds

Port Security

    Control port access based on MAC addresses. By default, port security will make sure that only one MAC address will be allowed access on each switch port.

Switch(config-if)# switchport port-security
Switch(config-if)# switchport port-security maximum max-addr

    If the switch reboots for some reason, port security will have to relearn a new set of MAC addresses. To make the learned addresses persistent across a switch reboot, you can enable “sticky” MAC address learning.

Switch(config-if)# switchport port-security mac-address sticky

    To define one or more MAC addresses on an interface.

Switch(config-if)# switchport port-security mac-address mac-addr

    Define how each interface using port security should react if a MAC address is in violation.

Switch(config-if)# switchport port-security violation {shutdown | restrict | protect}
  • shutdown - the port is put into the errdisable state 
  • restrict - the port is allowed to stay up, but all packets from violating MAC addresses are dropped. The switch keeps a running count of the number of violating packets and can send an SNMP trap and a syslog message as an alert of the violation
  • protect - the port is allowed to stay up, as in the restrict mode. Although packets from violating addresses are dropped, no record of the violation is kept

    If an interface is undergoing the restrict or protect condition, you might need to clear the learned MAC addresses so that a specific host can use the switch port. You can clear a MAC address or the complete port cache.

Switch# clear port-security {all | configured | dynamic | sticky} [address mac-addr | interface type member/mod/num]

Port-Based Authentication (IEEE 802.1X)

    For port-based authentication, both the switch and the end user’s PC must support the 802.1X standard, using the Extensible Authentication Protocol over LANs (EAPOL). Only RADIUS is supported for 802.1X.

Switch(config)# aaa new-model
Switch(config)# radius-server host { hostname | ip-address } [ key string ]
Switch(config)# aaa authentication dot1x default group radius
Switch(config)# dot1x system-auth-control
Switch(config)# interface type mod/num
Switch(config-if)# dot1x port-control {force-authorized | force-unauthorized | auto}
  • force-authorized - the port is forced to always authorize any connected client. No authentication is necessary. This is the default state for all switch ports when 802.1X is enabled
  • force-unauthorized - the port is forced to never authorize any connected client. As a result, the port cannot move to the authorized state to pass traffic to a connected client
  • auto - the port uses an 802.1X exchange to move from the unauthorized to the authorized state, if successful. This requires an 802.1X-capable application on the client PC.

    If the switch should expect to find multiple hosts present on the switch port use:

Switch(config-if)# dot1x host-mode multi-host

Types of RADIUS Messages

    The client/server packet exchange consists primarily of the following types of RADIUS messages:

  • Access-Request - sent by the client (NAS) requesting access

  • Access-Reject - sent by the RADIUS server rejecting access

  • Access-Accept - sent by the RADIUS server allowing access

  • Access-Challenge - sent by the RADIUS server requesting more information in order to allow access.    

     When you use RADIUS accounting, the client and server can also exchange the following two types of messages:

  • Accounting-Request - sent by the client requesting accounting

  • Accounting-Response - sent by the RADIUS server acknowledging accounting

Storm Control

Switch(config-if)# storm-control { broadcast | multicast | unicast } level { level [ level-low ] | bps bps [ bps-low ] | pps pps [ pps-low ]}

    “unicast” actually means unknown unicast; otherwise, the threshold would limit the volume of normal unicast frames passing through the interface. 

Switch(config-if)# storm-control action { shutdown | trap }

Best Practices

  • secure passwords - use the enable secret, service password-encryption configuration command to automatically encrypt password strings that are stored in the switch configuration
  • system banners - use the banner motd command to define the text that is displayed to authenticated users
  • web interface - no ip http server, or use the HTTPS interface - ip http secure server, ip http access-class
  • secure the switch console, vty
  • SSH - ip ssh version 2 global configuration command
  • SNMP - use SNMPv3, snmp-server community string rw, use access lists to limit the source addresses that have read-only access
  • unused switch ports - shutdown, switch-port mode access, switchport host interface configuration command as aquick way to force a port to support only a single PC
  • STP - BPDU guard feature
  • CDP and LLDP - no cdp enable.

Securing VLANs


Switch(config)# vlan access-map map-name [ sequence-number ]
Switch(config-access-map)# match ip address { acl-number | acl-name }
Switch(config-access-map)# match mac address acl-name
Switch(config-access-map)# action { drop | forward [ capture ] | redirect type mod/num }
Switch(config)# vlan filter map-name vlan-list vlan-list

Private VLANs 

    VLAN can be logically associated with special unidirectional, or secondary, VLANs. Hosts associated with a secondary VLAN can communicate with ports on the primary VLAN (a router, for example), but not with another secondary VLAN.-

  • isolated - any switch ports associated with an isolated VLAN can reach the primary VLAN but not any other secondary VLAN. In addition, hosts associated with the same isolated VLAN cannot reach each other. They are, in effect, isolated from everything except the primary VLAN
  • community - any switch ports associated with a common community VLAN can communicate with each other and with the primary VLAN but not with any other secondary VLAN.

    VLAN Trunking Protocol (VTP) does not pass any information about the private VLAN configuration. Therefore, private VLANs are only locally significant to a switch. Each of the private VLANs must be configured locally on each switch
that interconnects them.

  • promiscuous - rules of private VLANs are ignored
  • host -  the port communicates only with a promiscuous port or ports on the same community VLAN
Switch(config)# vlan vlan-id
Switch(config-vlan)# private-vlan { isolated | community }

    Define the primary VLAN 

Switch(config)# vlan vlan-id
Switch(config-vlan)# private-vlan primary
Switch(config-vlan)# private-vlan association { secondary-vlan-list | add secondary-vlan-list | remove secondary-vlan-list }

    Associate ports with private VLANs 

Switch(config-if)# switchport mode private-vlan { host | promiscuous }

    For a nonpromiscuous port 

Switch(config-if)# switchport private-vlan host-association primary-vlan-id secondary-vlan-id

    For a promiscuous port

Switch(config-if)# switchport private-vlan mapping primary-vlan-id secondary-vlan-list | { add secondary-vlan-list } | { remove secondary-vlan-list }

    Associate secondary VLANs to a primary VLAN SVI

Switch(config)# vlan 40
Switch(config-vlan)# private-vlan isolated
Switch(config-vlan)# vlan 50
Switch(config-vlan)# private-vlan community
Switch(config-vlan)# vlan 200
Switch(config-vlan)# private-vlan primary
Switch(config-vlan)# private-vlan association 40,50
Switch(config-vlan)# exit
Switch(config)# interface vlan 200
Switch(config-if)# ip address
Switch(config-if)# private-vlan mapping 40,50

VLAN Hopping

    Force all 802.1Q trunks to add tags to frames for the native VLAN, too. The double-tagged VLAN hopping attack will not work because the switch will not remove the first tag with the native VLAN ID.

Switch(config)# vlan dot1q tag native

Spoofing Attacks

DHCP Snooping

    Any DHCP replies coming from an untrusted port are discarded because they must have come from a rogue DHCP server. In addition, the offending switch port automatically is shut down in the errdisable state. A DHCP snooping database contains informaition about untrusted hosts with leased ip addresses.

Switch(config)# ip dhcp snooping

    Identify the VLANs where DHCP snooping should be implemented

Switch(config)# ip dhcp snooping vlan vlan-id [vlan-id ]

    Identify only the ports where known, trusted DHCP servers are located 

Switch(config)# interface type member/module/number
Switch(config-if)# ip dhcp snooping trust

    For untrusted ports, an unlimited rate of DHCP requests is accepted. If you want to ratelimit DHCP traffic on an untrusted port use:

Switch(config)# interface type member/module/number
Switch(config-if)# ip dhcp snooping limit rate rate

    You also can configure the switch to use DHCP option-82, the DHCP Relay Agent Information option, which is described in RFCs 3046 and 6607. When a DHCP request is intercepted on an untrusted port, the switch adds its own MAC address and the switch port identifier into the option-82 field of the request. The request then is forwarded normally so that it can reach a trusted DHCP server.

    Adding option-82 provides more information about the actual client that generated the DHCP request. In addition, the DHCP reply (if any) echoes back the option-82 information. The switch intercepts the reply and compares the option-82 data to confirm that the request came from a valid port on itself. This feature is enabled by default. 

Switch(config)# [ no ] ip dhcp snooping information option

IP Source Guard

    IP Source Guard does this by making use of the DHCP snooping database and static IP source binding entries. If DHCP snooping is configured and enabled, the switch learns the MAC and IP addresses of hosts that use DHCP. Packets arriving on a switch port can be tested for one of the following conditions:

  • The source IP address must be identical to the IP address learned by DHCP snooping or a static entry. A dynamic port access control list (ACL) is used to filter traffic. The switch automatically creates this ACL, adds the learned source IP address to the ACL, and applies the ACL to the interface where the address is learned.
  • The source MAC address must be identical to the MAC address learned on the switch port and by DHCP snooping. Port security is used to filter traffic.

    For the hosts that do not use DHCP, you can configure a static IP source binding.

Switch(config)# ip source binding mac-address vlan vlan-id ip-address interface type member/module/number

    Next, enable IP source guard

Switch(config)# interface type member/module/number
Switch(config-if)# ip verify source [port-security ]

    The ip verify source command inspects the source IP address only. You can add the port-security keyword to inspect the source MAC address, too. 

    When an IP Source Guard policy is applied to a Layer 2 port, and then you change that port to be a Layer 3 port, the IP Source Guard policy no longer functions but is still present in the configuration. When the port is changed back to a Layer 2 port, IP Source Guard policy becomes effective again.

Dynamic ARP Inspection (DAI)

    When an ARP reply is received on an untrusted port, the switch checks the MAC and IP addresses reported in the reply packet against known and trusted values. A switch can gather trusted ARP information from statically configured entries or from dynamic entries in the DHCP snooping database. In the latter case, DHCP snooping must be enabled in addition to DAI.

    If an ARP reply contains invalid information or values that conflict with entries in the trusted database, it is dropped and a log message is generated.

Switch(config)# ip arp inspection vlan vlan-range
Switch(config)# interface type member/module/number
Switch(config-if)# ip arp inspection trust
Switch(config)# arp access-list acl-name
Switch(config-acl )# permit ip host sender-ip mac host sender-mac [ log ]
[Repeat the previous command as needed]
Switch(config-acl)# exit
Switch(config)# ip arp inspection filter arp-acl-name vlan vlan-range [ static ]

    When ARP replies are intercepted, their contents are matched against the access list entries first. If no match is found, the DHCP snooping bindings database is checked next. You can give the static keyword to prevent the DHCP bindings database from being checked at all. In effect, this creates an implicit deny statement at the end of the ARP access list; if no match is found in the access list, the ARP reply is considered invalid.

    By default, only the MAC and IP addresses contained within the ARP reply are validated. This does not take the actual MAC addresses contained in the Ethernet header of the ARP reply. To validate that an ARP reply packet is really coming from the address listed inside it:

Switch(config)# ip arp inspection validate {[src-mac] [dst-mac] [ip ]}
  • src-mac - check the source MAC address in the Ethernet header against the sender MAC address in the ARP reply
  • dst-mac - check the destination MAC address in the Ethernet header against the target MAC address in the ARP reply
  • ip - Check the sender’s IP address in all ARP requests; check the sender’s IP address against the target IP address in all ARP replies. 

Switch Users

  • authentication - who is the user?
  • authorization - what is the user allowed to do?
  • accounting - what did the user do?

    Two protocols to communicate with AAA servers:

  • Terminal Access Controller Access Control System+ (TACACS+) - a Cisco proprietary protocol that separates each of the AAA functions; communication is secure and encrypted over TCP port 49.
  • Remote Authentication Dial-In User Service (RADIUS) - a standards-based protocol that combines authentication and authorization into a single resource; communication uses UDP ports 1812 and 1813 (accounting), but is not completely encrypted.

    In the AAA client role, a switch is often called a network access device (NAD) or network access server (NAS).

Configuring Authentication

Switch(config)# aaa new-model
Switch(config)# username username password password
Switch(config)# radius-server host { hostname | ip-address } [ key string ]
Switch(config)# tacacs-server host { hostname | ip-address } [ key string ]
Switch(config)# aaa group server { radius | tacacs+ } group-name
Switch(config-sg)# server ip-address

    Define a list of authentication methods to try. List each method or protocol type in the order that it should be tried

Switch(config)# aaa authentication login { default | list-name } method1 [ method2 ...]

    The methods refe:

  • tacacs+
  • radius
  • local
  • line - the line passwords authenticate any connected user. No usernames can be used.

    Apply a method list to a switch line.

Switch(config-line)# login authentication { default | list-name }

Configuring Authorization

Switch(config)# aaa authorization { commands | config-commands | configuration | exec | network | reverse-access } { default | list-name } method1 [ method2 ...]
  • command - the server must return permission to use any switch command at any privilege level
  • config-commands - the server must return permission to use any switch configuration command
  • configuration - the server must return permission to enter the switch configuration mode
  • exec - the server must return permission for the user to run a switch EXEC session. The server also can return the privilege level for the user so that the user immediately can be put into privileged EXEC (enable) mode without having to type in the enable command.
  • network - the server must return permission to use network-related services
  • reverse-access - the server must return permission for the user to access a reverse Telnet session on the switch.

    You can identify the method with a descriptive name ( list-name) if you are configuring more than one list.

  • group group-name  - requests are sent to the servers in a specific group
  • group { radius | tacacs+ } - requests are sent to all servers of this type
  • if-authenticated - requests are granted if the user already is authenticated
  • none - no external authorization is used; every user is authorized successfully.
Switch(config)# aaa authorization exec default group tacacs+ if-authenticated

    In the case where the router can not communicate with the TACACS server the router will authenticate the user and then the router will say the user is authorized (because he was previously authenticated) and the user login is successful.

    You can apply an authorization method list to a specific line on the switch.

Switch(config-line)# authorization { commands level | exec | reverse-access } { default | list-name }

    To configure a switch to use AAA authorization for all lines.

Switch(config)# aaa authorization exec default group myauthservers none

Configuring Accounting

Switch(config)# aaa accounting { system | exec | commands level } { default | list-name } { start-stop | stop-only | wait-start | none } method1 [ method2 ...]

    The function triggering the accounting can be: 

  • system - major switch events such as a reload are recorded
  • exec - user authentication into an EXEC session is recorded, along with information about the user’s address and the time and duration of the session
  • commands level - information about any command running at a specific privilege level is recorded, along with the user who issued the command.

    You can specify that certain types of accounting records be sent to the accounting server:

  • start-stop - events are recorded when they start and stop
  • stop-only - events are recorded only when they stop
  • none - no events are recorded.

    To apply an accounting method list to a specific line (console or vty) on the switch:

Switch(config-line)# accounting { commands leve | connection | exec } { default | list-name }
Leave a Comment: