8.3 Protecting Against Spoof Attacks
8.3.1 Describing a DHCP Spoof Attack
One of the ways an attacker can gain access to network traffic is to spoof responses that would be sent by a valid DHCP server. 
The DHCP spoofing device replies to client DHCP requests. The legitimate server may reply as well, but if the spoofing device is on the same segment as the client, its reply to the client may arrive first. The intruder’s DHCP reply offers an IP address and supporting information that designates the intruder as the default gateway or Domain Name System (DNS) server. In the case of a gateway, the clients forward packets to the attacking device, which in turn sends them to the desired destination. This is referred to as a “man-in-the-middle” attack, and it may go entirely undetected as the intruder intercepts the data flow through the network.
Figure 
describes the DHCP spoofing attack sequence.
8.3.2 Describing DHCP Snooping
DHCP snooping is a Cisco Catalyst feature that determines which switch ports can respond to DHCP requests. Ports are identified as trusted and untrusted. Trusted ports can source all DHCP messages, while untrusted ports can source requests only. Trusted ports host a DHCP server or can be an uplink toward the DHCP server. If a rogue device on an untrusted port attempts to send a DHCP response packet into the network, the port is shut down.
Untrusted ports are those not explicitly configured as trusted. A DHCP binding table is built for untrusted ports. Each entry contains the client MAC address, IP address, lease time, binding type, VLAN number, and port ID recorded as clients make DHCP requests. The table is then used to filter subsequent DHCP traffic. From a DHCP snooping perspective, untrusted access ports should not send any DHCP server responses, such as DHCPOFFER, DHCPACK, or DHCPNAK.
With the DHCP option-82 feature enabled on the switch, port-to-port DHCP broadcast isolation is achieved when the client ports are within a single VLAN. During client-to-server exchanges, broadcast requests from clients connected to VLAN access ports are intercepted by a relay agent running on the switch and are not flooded to other clients on the same VLAN. The relay agent inserts additional information inside the DHCP request packet, such as which port the request originated from, and then forwards it to the DHCP server. During server-to-client exchanges, the DHCP (option-82 aware) server sends a broadcast reply that contains the option-82 field. The relay agent uses this information to identify which port connects to the requesting client and avoids forwarding the reply to the entire VLAN.
8.3.3 Configuring DHCP Snooping
To enable DHCP snooping, use the commands in Figure . Figure describes the steps to configuring DHCP snooping.
Figure 
shows how to display the DHCP snooping configuration for a switch.
Only ports that are trusted or that have a rate limit applied are shown in the output. All other ports are untrusted and are not displayed.
IP source guard is a security feature that prevents IP source address spoofing. 
This feature is enabled on a DHCP snooping untrusted Layer 2 port. All IP traffic on the port is blocked, except for DHCP packets that are allowed by the DHCP snooping process. When a client receives a valid IP address from the DHCP server, a per-port VLAN Access Control List (PVACL) is installed on the port. This process restricts the client IP traffic to those source IP addresses configured in the binding. Any IP traffic with a source IP address other than that in the IP source binding is filtered out. This filtering limits a host’s ability to attack the network by claiming a neighbor host’s IP address.
Note:
If IP source guard is enabled on a trunk port with a large number of VLANs that have DHCP snooping enabled, you might run out of ACL hardware resources and some packets might be switched in software.
IP source guard supports only the Layer 2 ports, including both access and trunk. For each untrusted Layer 2 port, there are two levels of IP traffic security filtering, as follows:
Source IP address filter: 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 is recalculated and reapplied in the 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 is removed from the interface.
A static IP source binding may be configured on a port via the following global command:
Switch(config)#ip source binding ip-addr ip vlan number interface interface
Source IP and MAC address filter: 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 are permitted.
Figure 
describes IP source guard commands. Figure 
describes the procedure for enabling IP source guard.
Note:
The static IP source binding can only be configured on Layer 2 switch ports. If you issue the ip source binding vlan interface command on a Layer 3 port, you receive this error message: “Static IP source binding can only be configured on switch port.”
8.3.4 Describing ARP Spoofing
In normal ARP operation, a host sends a broadcast to determine the MAC address of a host with a particular IP address. The device at that IP address replies with its MAC address. The originating host caches the ARP response, using it to populate the destination Layer 2 header of packets sent to that IP address. By spoofing an ARP reply from a legitimate device with a gratuitous ARP, an attacking device appears to be the destination host sought by the senders. The ARP reply from the attacker causes the sender to store the MAC address of the attacking system in its ARP cache. All packets destined for those IP addresses are forwarded through the attacker system.
Figures and illustrate the sequence of events in an ARP spoofing attack.
8.3.5 Dynamic ARP Inspection
Dynamic ARP Inspection (DAI) determines the validity of an ARP packet based on the MAC address-to-IP address bindings stored in a DHCP snooping database. Additionally, DAI can validate ARP packets based on user-configurable ACLs for hosts that use statically configured IP addresses.
To prevent ARP spoofing or “poisoning,” a switch must ensure that only valid ARP requests and responses are relayed. To ensure that only valid ARP requests and responses are relayed, DAI takes the following actions:
Forwards ARP packets received on a trusted interface without any checks
Intercepts all ARP packets on untrusted ports
Verifies that each intercepted packet has a valid IP-to-MAC address binding before forwarding packets that can update the local ARP cache
Drops, logs, or drops and logs ARP packets with invalid IP-to-MAC address bindings
Generally, all access switch ports should be cofigured as untrusted and all switch ports connected to other switches as trusted. All ARP packets traversing the network from an upstream distribution or core switch could bypass the security check requiring no further validation.
You can also use DAI to set the rate limit of ARP packets and then err-disable the interface if the rate is exceeded.
8.3.6 Configuring Dynamic ARP Inspection
Figure lists the commands used to configure Dynamic ARP Inspection, and Figure describes the commands.
The following example shows how to configure DAI for hosts on VLAN 1, where client devices are located for switch 2. All client ports are untrusted by default. Only port 3/3 is trusted, because this is the only port where DHCP replies would be expected.
Switch S2(config)#ip arp inspection vlan 1
Switch S2(config)#interface fastethernet 3/3
Switch S2(config-if)#ip arp inspection trust
8.3.7 Protecting Against ARP Spoofing Attacks
To mitigate the chances of ARP spoofing, the following procedures are recommended:
Step 1 Implement protection against DHCP spoofing.
Step 2 Enable dynamic ARP inspection.
shows a frequent configuration error. The native VLAN configured on each end of an 802.1Q trunk must be the same. Remember that a switch receiving an untagged frame assigns it to the native VLAN of the trunk. If one end is configured for native VLAN 1 and the other to native VLAN 2, a frame sent in VLAN 1 on one side is received on VLAN 2 on the other. VLAN 1 and 2 have been segmented and merged. There is no reason this should be required, and connectivity issues will occur in the network.
describes the mitigation of 802.1Q native VLAN issues.
It is a VTP client with a configuration revision of 2 and knows of seven VLANs.
