Network security involves many areas including DHCP snooping which we cover shortly. You need to be able to lock your network down from external and internal threats. This chapter covers many Layer 2 threats and how to protect your network from attacks to your ARP cache, switch ports, trunk links and more.
If you enjoy network security, please look over our CompTIA Security+ SY0-601 course.
Switch Port Security
Typically, the switch will learn the MAC address of the device directly connected to a particular port and allow traffic through. The CCNA exam may ask, “How do you control who and how many can connect to a switch port?”. This is where port security can be of assistance. Cisco switches allow you to control which devices can connect to a switch port or how many of them can connect to it (such as when a hub or another switch is connected to the port).
Cisco have a guide on switch port security.
Enabling Port Security
Port security is disabled by default. Before configuring the port security settings on a port, you have to enable it using the switchport port-security command:
Switch#config terminal
Switch(config)#interface fa0/1
Switch(config-if)#switchport port-security
As soon as port security is enabled, it will apply the default values, which is one host permitted to connect at a time. If this rule is violated, the port will shut down. If you are connected to the actual port you are configuring port security on, you should enable it after configuring other features to ensure that you don’t get locked out unintentionally.
Using the switch port’s port security feature, you can specify:
- Who can connect to the switch port
- How many devices can connect to the switch port
- Violation action
Who Can Connect?
If you know that only a particular host should be connecting to a switch port, then you can restrict access on that port to the MAC address of that host. This will ensure that no one can unplug the authorized host and connect another one. This is a good option for secure locations. This is done using the following command:
switchport port-security mac-address [address]
Example
If you want only the host with MAC address 0001.14ac.3298 to connect to port fa0/1 on your switch, then the commands required will be:
Switch#config terminal
Switch(config)#interface fa0/1
Switch(config-if)#switchport port-security
Switch(config-if)#switchport port-security mac-address 0001.14ac.3298
These commands will not add the MAC address to the CAM table. When a host connects to this port and sends the first packet, the source address of the packet is checked against the configured MAC address. If a match is found, then the address is added to the CAM table. The address is purged in the configured aging time if no traffic is seen for that host.
So, do you have to provide each host’s MAC address manually? That’s a huge task considering the thousands of hosts that a network can have! Well, not really. Port security provides a facility called a sticky address. The switch will use the MAC address of the first host connected to the port as a static MAC address, and only that host will be able to connect to the port subsequently. The command required is switchport port-security mac-address sticky. The learned address is then added to the running configuration (not the startup configuration).
You cannot configure static secure or sticky secure MAC addresses on a voice VLAN.
How Many Can Connect?
Let’s say that you have only one switch port left free, and you need to connect five hosts to it. What can you do? Connect a hub or switch to the free port!
Connecting a switch or a hub to a port has implications. It means that the network will have more traffic. If a switch or a hub is connected by a user instead of an administrator, then there are chances that loops will be created. So, it is best that the number of hosts allowed to connect is restricted at the switch level. This can be done using the switchport port-security maximum command. This command configures the maximum number of MAC addresses that can source traffic through a port. Consider the following examples:
Switch(config-if)#switchport port-security maximum 1
Switch(config-if)#switchport port-security mac-address sticky
The commands above allow only one host to connect to the port. The MAC address of the allowed host is learned automatically, and the learned address is added to the running configuration.
Switch(config-if)#switchport port-security maximum 3
Switch(config-if)#switchport port-security mac-address 001a.14e9.8a7d
The commands above allow three hosts to connect at the same time, of which one MAC address is static and the other two can vary.
Switch(config-if)#switchport port-security maximum 5
The command above allows a maximum of five hosts to connect simultaneously. Hosts can vary. If you add any port security to a voice VLAN, you must enable at least two MAC addresses as a maximum.
Violation Action
What happens if a violation of security occurs on a switch port? What if five hosts are allowed on a port, but six connect to it? The switch can take one of the following three configured actions:
- Shut down the port – The port is shut down, and an SNMP message is sent. The port is put in an err-disabled state and can only be recovered by the administrator.
- Protect – Keep the port up, but do not allow the offending host to send/receive data. No SNMP trap is sent.
- Restrict – Keep the port up, but do not allow the offending host to send/receive data. Notify the administrator through SNMP and/or syslog.
The three modes can be configured using the switchport port-security violation shutdown|protect|restrict command.
Verify the port security configuration using the show port-security interface command:
Switch#show port-security interface FastEthernet0/1
Port Security: Enabled
Port status: SecureUp
Violation mode: Shutdown
Maximum MAC Addresses: 5
Total MAC Addresses: 5
Configured MAC Addresses: 3
Aging time: 20 mins
Aging type: Inactivity
SecureStatic address aging: Enabled
Security Violation count: 0
The output above shows that Fast Ethernet 0/1 has been configured with three static MAC addresses and will allow a maximum of five hosts to connect to it. If a violation is detected, then the port (by default) will go into err-disabled state (see the Error Disable Recovery section below) and shut down the port (switch interface). You can see this happening on the switch below, where an unauthorized MAC address connects to the Fast Ethernet 0/2 port.
Switch#
00:55:59: %PM-4-ERR_DISABLE: psecure-violation error detected on Fa0/2, putting Fa0/2 in err-disable state
Switch#
00:55:59: %PORT_SECURITY-2-PSECURE_VIOLATION: Security violation occurred, caused by MAC address 1234.5678.489d on port FastEthernet0/2.
Switch#
00:56:00: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/2, changed state to down
00:56:01: %LINK-3-UPDOWN: Interface FastEthernet0/2, changed state to down
Another important command is show port-security. This command provides an overview of all the ports that have port security configured.
Switch#show port-security
Port MaxSecureAddr CurrentAddr SecurityViolation Security Action
(Count) (Count) (Count)
——————————————————————–
Fa0/1 8 7 0 Shutdown
Fa0/2 15 5 0 Restrict
Fa0/3 5 4 0 Protect
——————————————————————–
Fine-tuning Port Security Configuration
The Cisco IOS port security implementation is very flexible, and it offers a number of additional ways to customize configurations.
One of the most useful command sets are the aging time and aging type. This is accomplished using the following commands:
Router(config-if)#switchport port-security aging time [value]
Router(config-if)#switchport port-security aging type [type]
The aging time value specifies the time after the learned addresses expire. This allows a new workstation to take the place of the one that has been removed. If the value is set to 0, the aging time is disabled for the specific port.
Aging can be configured to take effect at regular intervals or only during periods of inactivity using the absolute or inactivity keyword in the aging type command. For absolute aging, the addresses expire exactly after the time value configured, while for inactive aging, the addresses expire only if the port does not receive any packets from the secure source address for the specified aging time.
You can verify the aging values using the following commands:
Switch#show port-security interface FastEthernet0/1
Port Security: Enabled
Port status: SecureUp
Violation mode: Shutdown
Maximum MAC Addresses: 5
Total MAC Addresses: 5
Configured MAC Addresses: 3
Aging time: 20 mins
Aging type: Inactivity
SecureStatic address aging: Enabled
Security Violation count: 0
If you want to disable port security aging for all addresses on a port, you can use the following command:
Router(config-if)#no switchport port-security aging time
Error Disable Recovery
When certain errors occur on Cisco switches, the erring ports are put into an err-disabled state. This means that the port has been disabled because of an error. A common cause of this kind of error is the violation of a port security policy. An err-disabled interface would be marked as err-disabled in its show interface output, as shown below:
Switch# show interface f0/10
FastEthernet0/10 is down, line protocol is down (err-disabled)
An error disabled interface can be manually activated by bouncing the interface (issuing a shutdown, and then a no shutdown command). However, waiting for an administrator to manually recover an error disabled interface might take too long. There is a way to automatically reenable an error disabled port using the errdisable recovery cause global configuration command. You need to be able to predict the root cause of the error to use this option. A sample output is shown below:
Switch(config)#errdisable recovery cause ?
all Enable timer to recover from all causes
bpduguard Enable timer to recover from bpdu-guard error disable state
dtp-flap Enable timer to recover from dtp-flap error disable state
link-flap Enable timer to recover from link-flap error disable state
pagp-flap Enable timer to recover from pagp-flap error disable state
rootguard Enable timer to recover from root-guard error disable state
udld Enable timer to recover from udld error disable state
The err-disable root causes can vary based on the switch model, but the most common causes are:
- all
- arp-inspection
- bpduguard
- dhcp-rate-limit
- link-flap
- psecure-violation (port security)
- security-violation
- storm-control
- udld
The default recovery timeout is 300 seconds on most switches. This can be changed using the errdisable recovery interval global configuration command:
Switch(config)#errdisable recovery interval ?
[30-86400] timer-interval(sec)
You can view the status of the automatic recovery of error disabled interfaces using the show errdisable recovery command. A sample output is shown below:
Switch#show errdisable recovery
ErrDisable Reason Timer Status
—————– ————–
arp-inspection Disabled
bpduguard Disabled
channel-misconfig Disabled
dhcp-rate-limit Disabled
dtp-flap Disabled
gbic-invalid Disabled
inline-power Disabled
l2ptguard Disabled
link-flap Disabled
mac-limit Disabled
link-monitor-failure Disabled
loopback Disabled
oam-remote-failure Disabled
pagp-flap Disabled
port-mode-failure Disabled
psecure-violation Enabled
security-violation Disabled
sfp-config-mismatch Disabled
storm-control Disabled
udld Disabled
unicast-flood Disabled
vmps Disabled
Timer interval: 300 seconds
Interfaces that will be enabled at the next timeout:
Interface Errdisable reason Time left(sec)
——— —————– ————–
Fa0/0 psecure-violation 193
Layer 2 Threat Mitigation Techniques
Cisco has really beefed up the new CCNA exam with several items that are also in the CCNP syllabus, which reflects what is now expected from even CCNA-level engineers.
Common layer 2 attacks include:
- CAM table overflow attacks
- ARP spoofing
- Rogue DHCP servers
- VLAN hopping
Layer 2 mitigation techniques to combat these and other threats include the following:
- Port security
- Dynamic ARP Inspection (DAI)
- DHCP Snooping and IP Source Guard
- Securing Trunk Links
- Identity Based Networking
Port security was covered earlier, and we also covered non-default native VLAN and other security steps in the exam syllabus, so we won’t revisit those here. Other common layer 2 security measures, such as the following, have been covered elsewhere in this guide:
- Unused ports should be shut down, put in access mode, and placed in an unused VLAN.
- Avoid using the default VLAN on a switch.
- The native VLAN on trunk ports should be an unused VLAN.
- Disable unused protocols like CDP and DTP.
Dynamic ARP Inspection
ARP is used to resolve IP addresses to MAC addresses. Routers and switches maintain ARP tables to show IP-to-MAC address mappings. ARP spoofing attacks are used to disguise a source MAC address via the impersonation of another host on the network. It is important to understand that an ARP spoofing attack is not the same thing as a MAC spoofing attack. In an ARP spoofing attack, the switch is misguided by poisoning the ARP cache.
In MAC spoofing, the switch is tricked into believing that the same MAC address is connected to two different ports, which effectively poisons the MAC address table. ARP spoofing occurs during the ARP request and reply message exchange between two or more hosts. It is during this exchange of messages that attackers can inject a fake reply message with their own MAC address masquerading as one of the legitimate hosts, as illustrated below in Figure 24.1:
FIG 24.1 – Understanding ARP spoofing attacks
In Figure 24.1, three hosts reside on a shared LAN segment. There are two legitimate hosts, Host 1 and Host 2, and there is also a machine that has been compromised and is now being operated by the attacker. When Host 1 wants to send data to Host 2, it sends out an ARP broadcast to resolve the IP address of Host 2 to a MAC address. This process is illustrated in step number 1.
Before Host 2 can respond to the ARP request from Host 1, the attacker crafts a packet and responds to Host 1, providing Host 1 with the attacker’s MAC address instead. The ARP table on Host 1 is updated and incorrectly reflects an IP-to-MAC address mapping of 10.1.1.2 with the MAC address 1a2b.3333.cdef. Host 1 sends all traffic that should be destined to Host 2 to the attacker’s machine instead. The recommended solution to prevent such attacks in Cisco Catalyst switches is to implement Dynamic ARP Inspection (DAI).
Dynamic ARP Inspection Overview
Dynamic ARP Inspection is a Catalyst switch security feature that validates ARP packets in a network. DAI determines the validity of packets by performing an IP-to-MAC address binding inspection. After this validity has been confirmed, packets are then forwarded to their destination; however, DAI will drop all packets with invalid IP-to-MAC address bindings that fail the inspection validation process. DAI ensures that only valid ARP requests and responses are relayed. When DAI is enabled, the switch performs the following three activities:
- Intercepts all ARP requests and responses on untrusted ports. However, it is important to keep in mind that it inspects only inbound packets; it does not inspect outbound packets.
- Verifies that each of these intercepted packets has a valid IP-to-MAC address binding before updating the local ARP cache or before forwarding the packet to its destination.
- Drops invalid ARP packets. These ARP packets contain invalid or incorrect IP-to-MAC address bindings.
Dynamic ARP Inspection can be used in both Dynamic Host Configuration Protocol (DHCP) and non-DHCP environments. In DHCP environments, DAI is typically implemented in conjunction with the DHCP snooping feature, which allows DAI to validate bindings based on the DHCP snooping database. However, in non-DHCP environments, DAI can also validate ARP packets against a user-defined ARP ACL, which maps hosts with a statically configured IP address to their MAC address. The DHCP snooping feature will be described in detail later in this chapter.
Figure 24.2 below illustrates basic DAI operation in a DHCP environment, on a Cisco Catalyst switch enabled for DAI in conjunction with DHCP snooping:
FIG 24.2 – DAI in environments with DHCP snooping
In Figure 24.2, DAI has been enabled on the switch to which Host 1, the compromised machine, and the file server are both connected. The switch is showing the IP-to-MAC bindings in the DHCP snooping database. Therefore, if the attacker attempts to send a GARP with a spoofed MAC address, DAI will intercept the packet, and because it has an invalid IP-to-MAC address binding, the packet will be discarded.
DAI associates a trust state with each interface on the switch. All packets that arrive on trusted interfaces bypass all DAI validation checks, and those arriving on untrusted interfaces undergo the DAI validation process. In a typical network configuration, all switch ports connected to hosts are configured as untrusted, and all switch ports connected to switches (i.e. trunks) and servers are configured as trusted. With this configuration, all ARP packets entering the network from a given switch bypass the security check, but because they have been validated on the host port, they pose no security threats. No other validation is needed at any other place in the VLAN or in the network. This concept is illustrated below in Figure 24.3:
FIG 24.3 – DAI Trusted and Untrusted interfaces
As shown in Figure 24.3, the trunk link between the two switches is trusted. This means that ARP packets that traverse this link will not be subject to DAI validation. However, the access ports that connect Host 1 and Host 2 to the switches are untrusted. This means that ARP packets that traverse these links will be subject to DAI validation. The respective switches will discard all packets with invalid bindings that are received on these interfaces.
Configuring Dynamic ARP Inspection in a DHCP Environment
Dynamic ARP Inspection is supported on access ports, trunk ports, EtherChannel ports, or private VLAN (PVLAN) ports. Globally, DAI is enabled on a per-VLAN basis using the ip arp inspection vlan [vlan-range] global configuration command.
After DAI has been configured for a specific VLAN or range of VLANs, all ports are untrusted, by default. In this mode, the switch intercepts all ARP requests and responses. It verifies that the intercepted packets have valid IP-to-MAC address bindings before updating the local cache and before forwarding the packet to the appropriate destination. The switch drops invalid packets and logs them in the log buffer according to the logging configuration specified with the ip arp inspection vlan logging global configuration command.
When a switch port is configured as trusted, the switch does not check ARP packets that it receives on the trusted interface. Instead, it simply forwards the packets. To enable the trusted state for ports, the ip arp inspection trust interface configuration command must be configured on the trusted interface. The following output shows how to enable DAI for VLAN 5 and configure interface GigabitEthernet5/1 as a trusted interface:
Switch(config)#ip arp inspection vlan 5
Switch(config)#int gigabitethernet5/1
Switch(config-if)#description ‘Connected To DHCP Server’
Switch(config-if)#switchport mode access
Switch(config-if)#switchport access vlan 5
Switch(config-if)#ip arp inspection trust
Switch(config-if)#exit
Verifying Dynamic ARP Inspection in a DHCP Environment
Dynamic ARP Inspection configuration for a particular VLAN is validated using the show ip arp inspection vlan [number] command, as illustrated in the following output, while trusted interface configuration can be validated using the show ip arp inspection interfaces [name] command as illustrated in the output that follows:
Switch#show ip arp inspection vlan 5
Source Mac Validation : Disabled
Destination Mac Validation : Disabled
IP Address Validation : Disabled
Vlan Configuration Operation ACL Match Static ACL
—- ————- ——— ——— ———-
5 Enabled Active
Vlan ACL Logging DHCP Logging
—- ———– ————
5 Deny Deny
Switch#show ip arp inspection interfaces gigabitethernet5/1
Interface Trust State Rate (pps)
————— ———– ———-
Gi5/1 Trusted None
Configuring and Verifying DAI Validation
With DAI, by default, only the MAC and IP addresses contained within the ARP reply are validated. However, Cisco IOS software allows you to configure the switch to further inspect these ARP packets via the use of the ip arp inspection validate {[src-mac] [dst-mac] [ip [allow zeros]]} command. The options that are available with this command are listed and described below in Table 24-1:
Table 24-1: DAI validation keywords
| Keyword | Description |
| src-mac | This keyword is used to compare the source MAC address in the Ethernet header against the sender MAC address in the ARP body. This check is performed on both ARP requests and responses. When enabled, packets with different MAC addresses are classified as invalid and are dropped. |
| dst-mac | This keyword is used to compare the destination MAC address in the Ethernet header against the target MAC address in the ARP body. This check is performed for ARP responses. When enabled, packets with different MAC addresses are classified as invalid and are dropped. |
| ip | This keyword is used to compare the ARP body for invalid and unexpected IP addresses, which includes 0.0.0.0, 255.255.255.255, and all IP Multicast addresses. Sender IP addresses are compared in all ARP requests and responses. Target IP addresses are checked only in ARP responses. |
| allow zeros | This keyword modifies the IP validation test so that ARPs with a sender address of 0.0.0.0 are not denied by the switch. |
The following output shows how to configure DAI to compare the ARP body for invalid and unexpected IP addresses:
Switch(config)#ip arp inspection vlan 5
Switch(config)#ip arp inspection validate ip
Switch(config)#exit
This configuration is validated using the show ip arp inspection vlan [number] command as illustrated in the following output:
Switch#show ip arp inspection vlan 5
Source Mac Validation : Disabled
Destination Mac Validation : Disabled
IP Address Validation : Enabled
Vlan Configuration Operation ACL Match Static ACL
—- ————- ——— ——— ———-
5 Enabled Active
Vlan ACL Logging DHCP Logging
—- ———– ————
5 Deny Deny
Configuring Dynamic ARP Inspection in a Non-DHCP Environment
In order to configure DAI in a non-DHCP environment, you must first configure ARP ACLs that DAI will use to validate ARP packets. ARP ACLs are configured using the arp access-list [name] global configuration command. Next, configure DAI to validate packets against the ARP ACL(s) via the ip arp inspection filter [arp-acl-name] vlan [vlan-range] global configuration command.
The following output illustrates how to configure an ARP ACL to permit ARP packets from host 10.1.1.1 with a MAC address of 1a2b.1111.cdef and how to configure and verify DAI of ARP packets in VLAN 5 based on this ACL:
Switch(config)#arp access-list VLAN-5-ARP
Switch(config-arp-nacl)#permit ip host 10.1.1.1 mac host 1a2b.1111.cdef
Switch(config-arp-nacl)#exit
Switch(config)#ip arp inspection filter VLAN-5-ARP vlan 5
Switch(config)#exit
Verifying Dynamic ARP Inspection in a Non-DHCP Environment
The show ip arp inspection command is used to validate the DAI configuration. The output of this command based on the configuration above is illustrated in the following output:
Switch#show ip arp inspection vlan 5
Source Mac Validation : Disabled
Destination Mac Validation : Disabled
IP Address Validation : Disabled
Vlan Configuration Operation ACL Match Static ACL
—- ————- ——— ——— ———-
5 Enabled Active VLAN-5-ARP No
Vlan ACL Logging DHCP Logging
—- ———– ————
5 Deny Deny
NOTE: The show arp access-list [name] command can be used to view the configured ARP ACLs. This is illustrated in the following output:
Switch#show arp access-list
ARP access list VLAN-5-ARP
permit ip host 10.1.1.1 mac host 1a2b.1111.cdef
DHCP Snooping and IP Source Guard
DHCP spoofing and starvation attacks are methods used by intruders to exhaust the DHCP address pool on the DHCP sever, resulting in resource starvation where there are no DHCP addresses available to be assigned to legitimate users.
DHCP is used to dynamically assign hosts with IP addresses. A DHCP server can be configured to provide DHCP clients with a great deal of information, such as DNS servers, NTP servers, WINS information, and default gateway (router) information. DHCP uses UDP port 68. Cisco IOS routers and some switches can be configured as both DHCP clients and DHCP servers.
When using DHCP on a network, the DHCP client sends a DHCPDISCOVER message to locate a DHCP server. This is a Layer 2 broadcast because the client has no Layer 3 address, and so the message is directed to the Layer 2 broadcast address FFFF:FFFF:FFFF. If the DHCP server is on the same Layer 2 broadcast domain as the DHCP client, no explicit configuration is needed from a network configuration standpoint.
Upon receiving the DHCPDISCOVER message, the DHCP server offers network configuration settings to the client via the DHCPOFFER message. This is sent only to the requesting client.
The client then sends a DHCPREQUEST broadcast message so that any other servers that had responded to its initial DHCPDISCOVER message, after the first issuing DHCP server, can reclaim the IP addresses they had offered to that client. Finally, the issuing DHCP server then confirms that the IP address has been allocated to the client by issuing a DHCPACK message to the requesting client. Figure 24.4 below illustrates the DHCP exchange between a client and a server:
FIG 24.4 – The DHCP client and server packet exchange
DHCP starvation attacks work with MAC address spoofing by flooding a large number of DHCP requests with randomly generated spoofed MAC addresses to the target DHCP server, thereby exhausting the address space available for a period of time. This prevents legitimate DHCP clients from being serviced by the DHCP server.
After the legitimate DHCP server has been successfully flooded and can no longer service the legitimate clients, the attacker introduces a rogue DHCP server, which then responds to the DHCP requests of legitimate clients with the intent of providing incorrect configuration information to the clients, such as default gateways and WINS or DNS servers. This forged information then allows the attacker to perform other types of attacks. Tools such as MACOF and GOBBLER can be used by attackers to perform starvation attacks.
There are several techniques that can be used to prevent such attacks from occurring. The first is port security, which can be used to limit the number of MAC addresses on a switch port and thus mitigate DHCP spoofing and starvation attacks. The second method is VLAN ACLs (VACLs), which are ACLs that are applied to entire VLANs and are used to control host communication within VLANs. VACLs are described later in this chapter. The third method, which is also the most recommended method, is to enable the DHCP snooping feature.
DHCP Snooping Overview
DHCP snooping provides network protection from rogue DHCP servers by creating a logical firewall between untrusted hosts and DHCP servers. When DHCP snooping is enabled, the switch builds and maintains a DHCP snooping table, which is also referred to as the DHCP binding table, and it is used to prevent and filter untrusted messages from the network.
DHCP snooping uses the concept of trusted and untrusted interfaces. This means that incoming packets received on untrusted ports are dropped if the source MAC address of those packets does not match the MAC address in the binding table. Figure 24.5 below illustrates the operation of the DHCP snooping feature:
FIG 24.5 – DHCP snooping operation
As can be seen in Figure 24.5, an attacker attempts to inject false DHCP responses into the exchange of DHCP messages between the legitimate DHCP client and server. However, because DHCP snooping is enabled on the switch, these packets are dropped because they are originating from an untrusted interface and the source MAC address does not match the MAC address in the binding table.
The exchange between the legitimate client that is on an untrusted interface and the DHCP server is permitted because the source address does match the MAC address in the binding table entry. Figure 24.6 below illustrates the use of the DHCP snooping table, which is used to filter untrusted DHCP messages from the network:
FIG 24.6 – The DHCP snooping (binding) table
In Figure 24.6, packets sourced from trusted ports are not subject to DHCP snooping checks. Trusted interfaces for DHCP snooping would be configured for ports directly connected to DHCP servers. However, all packets from untrusted interfaces are checked against the entries in the DHCP snooping table.
This means that if an attacker attempts to use randomly generated MAC addresses to initiate a DHCP snooping and starvation attack, all packets will be checked against the DHCP snooping table, and because there will be no matches for those specific MAC addresses, all packets will be discarded by the switch, effectively preventing this type of attack from occurring.
Configuring DHCP Snooping
Configuring basic DHCP snooping involves three basic steps, as follows:
- Globally enabling DHCP snooping on the switch by issuing the ip dhcp snooping global configuration command.
- Enabling DHCP snooping for a VLAN or range of VLANs by issuing the ip dhcp snooping vlan [vlan-number|vlan-range] global configuration command.
- Configuring trusted interfaces for DHCP snooping by issuing the ip dhcp snooping trust interface configuration command. It is extremely important to remember that in order for DHCP snooping to function properly, all DHCP servers must be connected to the switch through trusted interfaces. All untrusted DHCP messages (i.e. messages from untrusted ports) will be forwarded only to trusted interfaces.
Optionally, network administrators can configure the switch to support the DHCP Relay Agent Information Option, which is DHCP Option 82, by issuing the ip dhcp snooping information option global configuration command when configuring DHCP snooping on the switch.
After DHCP snooping has been enabled, administrators can use the show ip dhcp snooping configuration to validate their configuration. The following output shows how to configure DHCP snooping for VLAN 100 and how to enable DHCP Option 82 insertion. Interface GigabitEthernet2/24 is connected to a DHCP server and is configured as a trusted interface:
Switch(config)#ip dhcp snooping
Switch(config)#ip dhcp snooping vlan 100
Switch(config)#ip dhcp snooping information option
Switch(config)#int gi 2/24
Switch(config-if)#description ‘Connected to Legitimate DHCP Server’
Switch(config-if)#ip dhcp snooping trust
Cisco IOS software allows you to rate-limit, or specify, the number of DHCP messages an untrusted interface can receive per second via the ip dhcp snooping limit rate [rate] interface configuration command. The specified rate can be anywhere between 1 and 2048 DHCP packets per second. By default, this feature is disabled and there is no rate-limiting of DHCP packets on any interfaces when DHCP snooping is enabled. The following output demonstrates how to set a message rate limit of 150 messages per second on an untrusted interface connected to a host:
Switch(config)#int gi 5/45
Switch(config-if)#description ‘Connected to Network Host’
Switch(config-if)#ip dhcp snooping limit rate 150
Verifying DHCP Snooping
After DHCP snooping has been enabled, the show ip dhcp snooping command can be used to validate the DHCP snooping configuration, as illustrated in the following output:
Switch#show ip dhcp snooping
Switch DHCP snooping is enabled.
DHCP Snooping is configured on the following VLANs:
100
Insertion of option 82 information is enabled.
Interface Trusted Rate limit (pps)
——— ——- —————-
GigabitEthernet2/24 yes none
You can also use the show ip dhcp snooping binding command to view DHCP snooping binding entries that correspond to untrusted ports. This is illustrated in the following output:
Switch#show ip dhcp snooping binding
MacAddress IP Address Lease (seconds) Type VLAN Interface
———– ———– —————- —– —–
0021.8642.0b01 10.1.1.254 1600 dynamic 100 GigabitEthernet5/1
IP Source Guard
The IP Source Guard feature is typically enabled in conjunction with DHCP snooping on untrusted Layer 2 ports. IP Source Guard is a feature that restricts IP traffic on untrusted Layer 2 ports by filtering the traffic based on the DHCP snooping binding database or manually configured IP source bindings. This feature is used to prevent IP spoofing attacks. Any traffic coming into the interface with a source IP address other than that assigned via DHCP or static configuration will be filtered out on the untrusted Layer 2 ports.
Initially, all IP traffic on the port is blocked except for DHCP packets that are captured by the DHCP snooping process. IP Source Guard builds and maintains an IP source binding table that is learned by DHCP snooping or manually configured bindings. Entries in the IP source binding table contain the IP address and the associated MAC and VLAN numbers. When a client receives a valid IP address from the DHCP server, or when a static IP source binding is configured by the user, a per-port and VLAN Access Control List (PVACL) is installed on the port. This filters out any IP traffic received on the interface that contains an IP address other than the address in the IP source binding table, thus preventing IP spoofing attacks.
The IP Source Guard feature is supported only on Layer 2 interfaces, which include access and trunk links. For each untrusted Layer 2 port, there are two modes of IP traffic security filtering, as follows:
- Source IP address filter
- Source IP and MAC address filter
In the source IP address filter mode, IP traffic is filtered based on its source IP address. Only IP traffic with a source IP address that matches the IP source binding entry is permitted. An IP source address filter is changed when a new IP source entry binding is created or deleted on the port. The port PVACL will be recalculated and reapplied in the switch hardware to reflect the IP source binding change. By default, if the IP filter is enabled without any IP source binding on the port, a default PVACL that denies all IP traffic is installed on the port. Similarly, when the IP filter is disabled, any IP source filter PVACL will be removed from the interface.
In source IP and MAC address filter mode, IP traffic is filtered based on its source IP address as well as its MAC address; only IP traffic with source IP and MAC addresses matching the IP source binding entry is permitted. When IP Source Guard is enabled in IP and MAC filtering mode, the DHCP snooping Option 82 must be enabled. Without Option 82 data, the switch cannot locate the client host port to forward the DHCP server reply, and the DHCP server reply is dropped and the client cannot obtain an IP address.
Configuring IP Source Guard
In lower-end switch models, such as the Catalyst 3750 series switch, IP Source Guard is enabled by issuing the ip verify source [port-security] interface configuration command. The [port-security] option is used to enable IP Source Guard with IP and MAC address filtering. If this option is omitted, then only IP Source Guard with IP address filtering is enabled. The following output illustrates how to enable basic IP Source Guard functionality on a Catalyst 3750 series switch:
Switch(config)#ip dhcp snooping
Switch(config)#ip dhcp snooping vlan 100
Switch(config)#ip dhcp snooping information option
Switch(config)#int gi 2/24
Switch(config-if)#description ‘Connected to Network Host’
Switch(config-if)#ip verify source
In higher-end Catalyst switch models, such as the Catalyst 4500 and Catalyst 6500 series switches, IP Source Guard is enabled using the ip verify source vlan dhcp-snooping [port-security] interface configuration command. The [port-security] option may be used to enable IP and MAC mode filtering. The following output illustrates how to enable IP Source Guard on a Catalyst 4500 or Catalyst 6500 series switch:
Switch(config)#ip dhcp snooping
Switch(config)#ip dhcp snooping vlan 100
Switch(config)#ip dhcp snooping information option
Switch(config)#int gi 2/24
Switch(config-if)#description ‘Connected to Network Host’
Switch(config-if)#ip verify source vlan dhcp-snooping
In environments that do not use DHCP, static bindings can be configured using the ip source binding mac-address vlan [vlan-id] [ip-address] interface [name] global configuration command in all Catalyst switch models that support the IP Source Guard feature. The following output illustrates how to configure a static source binding in a Catalyst switch:
Switch(config)#ip source binding 1a2b.1111.cdef vlan 5 10.1.1.1 int gi 2/24
Switch(config)#exit
Verifying IP Source Guard
The show ip verify source command is used to display all interfaces on the switch that have IP Source Guard enabled. The output of this command is illustrated as follows:
Switch# show ip verify source
Interface Filter-type Filter-mode IP-address Mac-address Vlan
——— ———– ———– ———– ————- —–
gi2/24 ip active 10.1.1.1 5
IP Source Guard bindings can be viewed using the show ip source binding command as illustrated in the following output:
Switch#show ip source binding
MacAddress IpAddress Lease(sec) Type VLAN Interface
————– ———– ———- ——— —-
1A:2B:11:11:CD:EF 10.1.1.1 infinite static 5 Gi2/4
Securing Trunk Links
By default, in order for users in different VLANs to communicate, inter-VLAN routing must be employed. This can be done using a one-armed-router, also referred to as a router-on-a-stick, by using sub-interfaces on the router. Alternatively, and more commonly, Multilayer switches, such as the Cisco Catalyst 3750, 4500, and 6500 series switches, are used in the network. These switches have the capability to both route and switch. Inter-VLAN routing is a core concept and will be described in detail later in this guide.
VLAN hopping attacks are methods in which an attacker attempts to bypass a Layer 3 device to communicate directly between VLANs, with the main objective being to compromise a device residing on another VLAN. There are two primary methods used to perform VLAN hopping attacks, as follows:
- Switch spoofing
- Double-tagging
Switch Spoofing Attacks
In switch spoofing, the attacker impersonates a switch by emulating ISL or 802.1Q signaling, as well as Dynamic Trunking Protocol (DTP) signaling. DTP provides switches with the ability to negotiate the trunking method for the trunk link they will establish between themselves.
If an attacker can successfully emulate a trunk, the attacker’s system becomes a member of all VLANs because trunk links forward all VLAN information by default. Switch spoofing attacks attempt to exploit the default native VLAN (VLAN 1) that is used on Cisco Catalyst switches.
By default, when an access port sends a frame to a remote switch, and that packet is encapsulated into 802.1Q format with the native VLAN ID, it will be successfully forwarded to the remote switch without the need to cross a Layer 3 device. Network administrators can prevent switch spoofing attacks by performing the following actions:
- Disabling the DTP on trunk ports by issuing the switchport nonegotiate interface configuration command on trunk links.
- Disabling trunking capability on ports that should not be configured as trunk links by statically configuring them as access ports using the switchport mode access interface configuration command on all non-trunk links.
- Preventing user data from traversing the native VLAN by specifying a VLAN other than VLAN 1, which does not span the entire Layer 2 network. For example, VLAN 5 could be configured as the native VLAN for a trunk using the switchport trunk native vlan 5 and the switchport trunk allowed vlan remove 5 interface configuration commands.
Double-Tagging Attacks
By default, traffic in the native VLAN using 802.1Q trunks is not tagged as frames travel between switches in the Layer 2 switched network. This default behavior means that if an attacker resides on the native VLAN used by the switches, the attacker could successfully launch a double-tagging network attack.
Double-tagging or double-encapsulated VLAN attacks involve tagging frames with two 802.1Q tags in order to forward the frames to a different VLAN. The embedded hidden 802.1Q tag inside the frame allows the frame to traverse a VLAN that the outer 802.1Q tag did not specify. This is a particularly dangerous attack because it will work even if the trunk port is set to off.
The first switch that encounters the double-tagged frame strips off the first tag and forwards the frame. This results in the frame being forwarded with the inner 802.1Q tag out of all ports on the switch, including the trunk ports configured with the native VLAN ID of the network attacker. The second switch then forwards the frame to the destination based on the VLAN identifier in the second 802.1Q header. This double-tagging concept is illustrated below in Figure 24.7:
FIG 24.7 – Double-Tagging attacks
As illustrated in Figure 24.7, an attacker has compromised Host 1 and is trying to access Host 2. The attacker sends a double-tagged frame to Switch 1, which includes the native VLAN (VLAN 1), and the VLAN Host 2 resides in, which is VLAN 200.
When Switch 1 receives the frame, it strips off the first tag and forwards the frame to Switch 2. When Switch 2 receives the frame, it contains only VLAN 200. The switch removes this tag and forwards the frame to Host 2, which resides in VLAN 200. The attacker has successfully managed to traverse the two different VLANs while bypassing any Layer 3 network devices.
To prevent double-tagging attacks, administrators should ensure that the native VLAN used on all the trunk ports is different from the VLAN ID of user access ports. It is best to use a dedicated VLAN that is specific for each pair of trunk ports and not the default VLAN. In addition to this, configuring the native VLAN to tag all traffic prevents the vulnerability of double-tagged 802.1Q frames hopping VLANs. This functionality can be enabled by issuing the vlan dot1q tag native global configuration command.
Identity Based Networking Services
Identity Based Networking Services (IBNS) solution provides identity-based network access control and policy enforcement at the switch port level. The IBNS solution extends network access security based on the 802.1x technology, Extensible Authentication Protocol (EAP) technologies, and the Remote Authentication Dial-In User (RADIUS) security server service.
Cisco IBNS offers scalable and flexible access control and policy enforcement services and capabilities at the network edge (i.e. at switch access ports) by providing the following:
- Per-user or per-service authentication services
- Policies mapped to network identity
- Port-based network access control based on authentication and authorization policies
- Additional policy enforcement based on access level
When the Cisco Access Control Server (ACS) is used as the authentication server in IBNS, the following features are available for network security administrators:
- Time and day restrictions
- NAS restrictions
- MAC address filtering
- Per-user and per-group VLAN assignments
- Per-user and per-group ACL assignments
IEEE 802.1x Overview
IEEE 802.1x is a protocol standard framework for both wired and wireless Local Area Networks that authenticates users or network devices. IEEE 802.1x provides policy enforcement services at the port level in order to provide secure network access control. 802.1x is an IEEE standard for access control and authentication that provides a means for authenticating users who want to gain access to the network and placing them into a pre-determined VLAN, effectively granting them certain access rights to the network.
The 802.1x protocol provides the definition to encapsulate the transport of EAP messages at the Data Link Layer over any PPP or IEEE 802 media (e.g. Ethernet, FDDI, or Token Ring) through the implementation of a port-based network access control to a network device. EAP messages are communicated between an end device, referred to as a supplicant, and an authenticator, which can be either a switch or a wireless access point. The authenticator relays the EAP messages to the authentication server (e.g. a Cisco ACS server) via the RADIUS server protocol.
There are three primary components (or roles) in the 802.1x authentication process, as follows:
- Supplicant or client
- Authenticator
- Authentication server
An IEEE 802.1x supplicant or client is simply an 802.1x-compliant device, such as a workstation, a laptop, or even an IP phone, with software that supports the 802.1x and EAP protocols. The supplicant sends an authentication request to the access LAN via the connected authenticator device (e.g. the access switch) using EAP.
An 802.1x authenticator is a device that enforces physical access control to the network based on the authentication status (i.e. permit or deny) of the supplicant. An example of an authenticator would be the switch illustrated in Figure 24.9 below. The authenticator acts as a proxy and relays information between the supplicant and the authentication server.
The authenticator receives the identity information from the supplicant via EAP over LAN (EAPOL) frames, which are verified and then encapsulated into RADIUS protocol format before being forwarded to the authentication server. It is important to remember that the EAP frames are not modified or examined during the encapsulation process, which means that the authentication server must support EAP within the native frame format. When the authenticator receives frames from the authentication server, the RADIUS header is removed, leaving only the EAP frame, which is then encapsulated in the 802.1x format. These frames are then sent back to the supplicant or client.
The authentication server is the database policy software, such as Cisco Secure ACS, that supports the RADIUS server protocol and performs authentication of the supplicant that is relayed by the authenticator via the RADIUS client-server model.
The authentication server validates the identity of the client and notifies the authenticator whether the client is allowed or denied access to the network. Based on the response from the authentication server, the authenticator relays this information back to the supplicant. It is important to remember that during the entire authentication process, the authentication server remains transparent to the client because the supplicant is communicating only to the authenticator. The RADIUS protocol with EAP extensions is the only supported authentication server; in other words, you cannot use TACACS+ or Kerberos as the authentication server.
Extensible Authentication Protocol Packet Format
802.1x authentication is initiated when the link transitions from a state of down to up. Either the switch or the client (supplicant) can initiate authentication. EAPOL is the encapsulation technique used to carry EAP frames between the supplicant and the authenticator. The frames have a destination MAC of 01-80-C3-00-00-03 whether the packet is to the supplicant or the switch. EAPOL is wrapped in an Ethernet frame as illustrated below in Figure 24.8:
FIG 24.8 – EAPOL frame format
While delving into all the different fields illustrated in Figure 24.8 is beyond the scope of the exam requirements, Table 24-2 below lists and describes common values that may be contained in the Packet Type field:
Table 24-2: EAP Packet Types
| Keyword | Description |
| EAP Packet (0)
|
This packet is sent by both the supplicant and the authenticator. It is used during authentication and contains information required to complete the authentication process. |
| EAPOL Start (1) | This packet is sent by the supplicant when it starts authentication process. |
| EAPOL Logoff (2)
|
This packet is sent by the supplicant when it wants to terminate the 802.1x session. |
| EAPOL Key (3)
|
This packet is sent by the switch to the supplicant and contains a key used during Transport Layer Security (TLS) authentication. |
The Extensible Authentication Protocol Message Exchange
The EAP message exchange is illustrated below in Figure 24.9:
FIG 24.9 – EAP message exchange
The following sequence of steps reference the message exchange illustrated in Figure 24.9:
- The client or supplicant sends the authenticator an EAPOL frame to start the authentication process.
- The switch responds to the EAPOL frame by sending the supplicant a login request, asking for the correct credentials (e.g. username and password pair) to gain network access.
- The supplicant provides the credentials to the authenticator.
- The authentication encapsulates the received credentials in RADIUS format and relays them to the RADIUS authentication server.
- When the RADIUS server receives the authentication request, it checks its database, which can be either internal or external, and then sends a response back.
- The authenticator relays this response to the supplicant.
- The supplicant provides the requested information.
- The authenticator relays this information to the RADIUS server.
- Assuming that the check is successful, and the credentials match and have been validated, the supplicant receives a permit access message. VLAN assignment is added to the access-accept packet from the RADIUS server.
- The authenticator relays this information to the supplicant.
The port then transitions to an authorized state and the supplicant is allowed to send packets on to the network. When the supplicant logs off the network, the port transitions to the unauthorized state and the login and authentication process will start over when the supplicant logs back on. If the credentials are incorrect, the supplicant can also receive a deny message and will not be allowed access to the LAN, and will be blocked at the port level. The authorized and unauthorized port states are described later in this chapter.
Configuring 802.1x Port-Based Authentication
Configuring basic 802.1x port-based authentication is a relatively straightforward process that is comprised of the following five basic steps:
- Globally enable AAA services on the switch by issuing the aaa new-model global configuration command. AAA must be enabled before a switch can be configured for 802.1x port-based authentication services.
- Create or use the default 802.1x authentication method list, and specify RADIUS server information by issuing the aaa authentication dot1x [method-list|default] group [name|radius] global configuration command.
- Configure RADIUS server parameters (e.g. keys and ports) via the radius-server host global configuration command for an individual server or the aaa group server radius global configuration command for a RADIUS server group.
- Globally enable IEEE 802.1x authentication on the switch using the dot1x system-auth-control global configuration command.
- Enable 802.1x port-based authentication on desired switch ports by issuing the dot1x port-control {auto|force-authorized |force-unauthorized} interface configuration command.
When 802.1x is enabled on the authenticator, there are two port states in which the physical ports on the authenticator may be: authorized or unauthorized. Initially, all 802.1x-enabled ports start in an unauthorized state. In this state, no traffic is allowed through the port except for 802.1x message exchange packets.
If a non-802.1x connects to an unauthorized port, the authenticator has no way of knowing that the client does not support 802.1x, so it sends the client a login request asking it for identity credentials. However, because the client does not support 802.1x, it is unable to interpret the received packet, so it does not respond to the authenticator’s request.
Based on this, the authenticator denies all packets on that port and the switch port remains in the unauthorized state. Administrators control the port authorization state by using the dot1x port-control interface configuration command and one of the following keywords:
- The force-authorized keyword—disables 802.1x and causes the port to transition to the authorized state without any authentication exchange required. The port transmits and receives normal traffic without 802.1x-based authentication of the client. This is the default option.
- The force-unauthorized keyword—causes the port to remain in the unauthorized state, ignoring all attempts by the client to authenticate. In other words, the switch cannot provide authentication services to the client through the interface.
- The auto keyword—enables 802.1x authentication and forces the switch port to begin in the unauthorized state, allowing only EAPOL frames to be sent and received. The authentication process begins when the link state of the port transitions from down to up, or when an EAPOL-start frame is received. The switch requests the identity of the client and begins relaying authentication messages between the client and the authentication server. Each client attempting to access the network is uniquely identified by the switch by using the client’s MAC address. This is the recommended mode when enabling 802.1x security.
The following output demonstrates the configuration of 802.1x port-based authentication on the FastEthernet0/23 and FastEthernet0/24 interfaces of a Cisco Catalyst switch. A RADIUS server with the IP address 10.1.1.254 and secret key switchauth will be configured to authentication 802.1x users. This RADIUS server will use UDP port 1812 for authentication services:
Switch(config)#aaa new-model
Switch(config)#aaa authentication dot1x default group radius
Switch(config)#radius-server host 10.1.1.254 auth-port 1812 key
switchauth
Switch(config)#dot1x system-auth-control
Switch(config)#interface range fastethernet0/23 – 24
Switch(config-if-range)#switchport mode access
Switch(config-if-range)#dot1x port-control auto
Switch(config-if-range)#exit
NOTE: It is important to remember to configure the switch port as a static access port before enabling 802.1x port-based authentication; otherwise, the error message illustrated in the following output will be printed on the switch console:
Switch(config)#int f0/15
Switch(config-if)#dot1x port-control auto
% Error: 802.1X cannot be configured on a dynamic port
Verifying 802.1x Port-Based Authentication
To view the 802.1x configuration of an interface, administrators should issue the show dot1x interface [name] command. The output of this command is shown as follows:
Switch#show dot1x interface fastethernet 0/1
802.1X is enabled on FastEthernet0/1
Status Unauthorized
Port-control Auto
Supplicant Not set
Multiple Hosts Disallowed
Current Identifier 2
Authenticator State Machine
State CONNECTING
Reauth Count 2
Backend State Machine
State IDLE
Request Count 0
Identifier (Server) 0
Reauthentication State Machine
State INITIALIZE
For troubleshooting, you can use the show dot1x statistics interface [name] command to view 802.1x statistics on a per-interface basis as shown in the following output:
Switch#show dot1x statistics interface fastethernet 0/1
FastEthernet0/1
Rx: EAPOL EAPOL EAPOL EAPOL EAP EAP EAP
Start Logoff Invalid Total Resp/Id Resp/Oth LenError
0 0 0 0 0 0 0
Last Last
EAPOLVer EAPOLSrc
0 0000.0000.0000
Tx: EAPOL EAP EAP
Total Req/Id Req/Oth
23 13 0
802.1x Multiple Hosts Authentication
In most implementations, a single network host is connected to each individual switch port. This allows 802.1x to be configured on each switch port to support that individual host. However, in some networks, it is possible that multiple hosts may be connected to the same switch port, such as via a hub, for example.
To allow for 802.1x authentication in such situations, the 802.1x multiple hosts feature allows multiple users to gain access to a single authenticated 802.1x port. An initial user is required to go through normal authentication to ‘open’ up the link. Once authenticated, other users on the same link can gain access to the network without going through authentication.
Multiple hosts mode is enabled using the dot1x host-mode multi-host interface configuration command in addition to the five configuration steps listed at the beginning of this section. The following output illustrates how to enable this feature:
Switch(config)#aaa new-model
Switch(config)#aaa authentication dot1x default group radius
Switch(config)#radius-server host 10.1.1.254 auth-port 1812 key
switchauth
Switch(config)#dot1x system-auth-control
Switch(config)#interface range fastethernet0/23 – 24
Switch(config-if-range)#switchport mode access
Switch(config-if-range)#dot1x port-control auto
Switch(config-if-range)#dot1x host-mode multi-host
Switch(config-if-range)#exit
End of Chapter Questions
Please visit https://https://www.howtonetwork.com/ccnasimplified to take the free Chapter 24 exam.
Chapter 24 Labs
Lab 1: Switch Port Security
FIG 24.10 – Port security
Lab Exercise
A PC is connected directly to the Fast Ethernet 0/1 interface on your switch. Apply port security permitting only the LAN Host to connect through the port, as well as a static MAC address. If a violation is detected, the port should shut down. Plug in the Unauthorized Host to check whether the configuration is working correctly.
Purpose
Security is very crucial for any network. Layer 2 security will ensure that no one can compromise the security from inside the network. You will be expected to know how to configure port security for the CCNA exam.
Lab Objectives
- Enable port security on fa0/1 on the switch.
- Configure a static MAC address for port security on fa0/1.
- Configure violation action on the switch port.
- Test the port by connecting a different device.
Lab Walk-through
- Enable port security on fa0/1 on the switch:
Switch#configure terminal
Switch(config)#interface fa0/1
Switch(config-if)#switchport port-security
NOTE: The port to which you apply this command must be an access port and not left as dynamic.
If the interface is connected to another switch, the switch may convert to a trunk. The show interfaces trunk command will display your trunk interfaces:
Switch#show interfaces trunk
Port Mode Encapsulation Status Native vlan
Fa0/1 desirable 802.1q trunking 1
If you attempt to apply the command to a dynamic port, you will see the output below:
Switch(config-if)#switchport port-security
Command rejected: Not eligible for secure port.
To set an interface to access mode, please apply the following command:
Switch#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Switch(config)#int fast0/1
Switch(config-if)#switchport mode access
- Configure a static MAC address for port security on fa0/1. This will be the MAC address that you want to permit to pass traffic through the switch port. You will need to alter the MAC address for your own equipment.
Switch(config-if)#switchport port-security mac-address 000b.cd5d.b11b
NOTE: You have several other options here. You can set the maximum number of MAC addresses permitted through the switch port, hard-set the MAC address, and set the violation action of your settings (see Step 3):
Switch(config-if)#switchport port-security ?
mac-address Secure mac address
maximum Max secure addrs
violation Security Violation Mode
[cr]
- Configure violation action on the switch port. You may choose the restrict (inform the network administrator of the violation), shutdown, or protect (only permit frames from the permitted devices) commands:
Switch(config-if)#switchport port-security violation ?
protect Security violation protect mode
restrict Security violation restrict mode
shutdown Security violation shutdown mode
Set the shutdown command so the port will shut down when it detects a restriction:
Switch(config-if)#switchport port-security violation shutdown
- Now plug the authorized host (LAN Host) into your switch port Fast Ethernet 0/1. After about 30 seconds the switch port light will go from amber to green and show as up. You can then check the port security status with the show port-security command:
Switch#
00:40:32: %LINK-3-UPDOWN: Interface FastEthernet0/1, changed state to up
00:40:33: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/1, changed state to up
Switch#show port-security int fast0/1
Port Security: Enabled
Port Status: Secure-up
Violation Mode: Shutdown
Aging Time: 0 mins
Aging Type: Absolute
SecureStatic Address Aging: Disabled
Maximum MAC Addresses: 1
Total MAC Addresses: 1
Configured MAC Addresses: 1
Sticky MAC Addresses: 0
Last Source Address: 000b.cd5d.b11b
Security Violation Count: 0
- Unplug the LAN Host and plug in the Unauthorized Host. After the frames reach the switch port, it will close down.
Switch#
00:41:04: %PM-4-ERR_DISABLE: psecure-violation error detected on Fa0/1, putting Fa0/1 in err-disable state
00:41:04: %PORT_SECURITY-2-PSECURE_VIOLATION: Security violation occurred, caused by MAC address 0002.a5b8.5acc on port FastEthernet0/1.
00:41:05: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/1, changed state to down
- The interface has been shut down. You can now check the port security status:
Switch#show port-security int fast0/1
Port Security: Enabled
Port Status: Secure-shutdown
Violation Mode: Shutdown
Aging Time: 0 mins
Aging Type: Absolute
SecureStatic Address Aging: Disabled
Maximum MAC Addresses: 1
Total MAC Addresses: 1
Configured MAC Addresses: 1
Sticky MAC Addresses: 0
Last Source Address: 0002.a5b8.5acc
Security Violation Count: 1
- To reenable the interface, plug the authorized LAN Host back in and then add the shut and no shut commands to the Fast Ethernet interface.
One last point: please take some time to use the other port security commands. You can, for example, permit a maximum number of MAC addresses through the port or choose a specific range of allowed addresses.
Running Configuration
Switch1#sh run
Building configuration…
[output truncated]
hostname Switch
!
interface FastEthernet0/1
switchport mode access
switchport port-security
switchport port-security violation shutdown
switchport port-security mac-address 000b.cd5d.b11b
