DHCP Snooping Against Ipmac Spoofing Attacks

A switch can use the DHCP snooping bindings to prevent IP and MAC address spoofing attacks. MAC spoofing attacks, as Figure 5-7 shows, consist in malicious clients generating traffic by using MAC addresses that do not belong to them.

The motivation behind a MAC spoofing attack is the potential ability to gain network access when access control is based on MAC information, for example.

Figure 5-7 MAC Spoofing Attack

Received Traffic Source Address 10.1.1.3 MAC B

Traffic Sent with MAC B Source

I gt

Attacker Sends Packets with Spoofed Source MAC Address If Network Access Control Is Based on MAC Address, the Attacker Now Looks Like 10.1.1.2

IP spoofing attacks, as Figure 5-8 shows, are exactly like MAC spoofing attacks, except that the client uses an IP address that isn't his. The goal of such an attack is to harm both innocent bystanders and the initial target by having the destination IP address (the initial target) reply to as many spoofed source IP addresses as possible. The attacker never sees the replies because he spoofs the source IP addresses. This is precisely like DoS attacks of the SYN flood type. This scenario is a reflection attack, which is where a hacker uses a victim's IP address as the source address of packets. Those packets are then sent to a relay, which will be referred to as innocent bystanders. Those innocent bystanders reply to these forged source IP addresses, who then become the victims of the attack because they really have no business dealing with this sudden rush of packets they haven't asked for.

IP spoofing can be used to bypass an ACL based on an IP address. Obviously, the attacker never sees the return traffic because it is sent back to the spoofed IP address. This lack of return traffic prevents some attacks, such as TCP session hijacking, because only one leg of the connection is visible to the attacker. Therefore, predicting the sequence numbers that the victim uses is virtually impossible. Nevertheless, this attack can work with UDP transport, such as sending SNMP set messages through an ACL, or as a plain DoS attack where seeing both legs of the connection isn't desirable

Figure 5-8 IP Spoofing Attack

Received Traffic Source IP 10.1.1.2

• Attacker Sends

MAC C

Packets with the Spoofed Source IP Address

Traffic Sent with IP 10.1.1.2 Source

• Whatever Device the Packet Is Sent to Will Never Reply to the Attacker

(Reflector Attack)

IP+MAC spoofing attacks combine both IP and MAC spoofing attacks, as Figure 5-9 shows. This classic case of impersonation occurs when an attacker inserts himself in the middle of a legitimate conversation between two parties, pretending to be one of the parties.

The use of this combination is required if Dynamic ARP Inspection (DAI)—see Chapter 6—is deployed because, with DAI, the mapping <MAC address, IP address> is fixed and an attacker cannot change it. Therefore, the only way for an attacker to spoof another host is to spoof both the MAC and IP address.

Figure 5-9 IP+MAC Spoofing Attack

Figure 5-9 IP+MAC Spoofing Attack

■I ""I

Attacker Sends Packets with Spoofed IP and MAC Addresses Attacker Looks Like a Device that Is Already on the Network

MAC B

In a typical IP routed network, mitigation techniques, such as Unicast Reverse Path

Forwarding Check (uRPF Check), can come to the rescue.3 To oversimplify things, uRPF verifies that the best path to reach a given source IP address is through the interface on which traffic from that IP address arrived. The check is performed by scanning through the router's forwarding table. In a LAN, it's a different story, because no routing table exists. Traffic forwarding is based on the location of MAC addresses. The LAN counterpart of uRPF is a Cisco feature called IP Source Guard.

Like DHCP snooping, IP Source Guard is configured on untrusted ports. Initially, all IP traffic on the port is blocked except for DHCP packets that are captured by the DHCP snooping process. The port becomes open only after a client accepts a valid IP address from a trusted DHCP server or when a user configures a static IP source binding. The switch controls network access at the port level by means of per-port and VLAN access control lists (PVACL). This process restricts client IP traffic that matches entries in the bindings table; 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. It's sort of a mini per-port IP firewall, if you will!

MAC B

Two levels of IP traffic filtering can be configured per port:

• 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 except DHCP is installed on the port. Similarly, when the IP filter is disabled, any IP source filter PVACL is removed from the interface.

• Source IP and MAC address filter. IP traffic is filtered based on its source IP address and MAC address. Only IP traffic whose source IP and MAC addresses match an IP source binding entry is permitted. When IP Source Guard is enabled in IP+MAC filtering mode, DHCP snooping Option 82 must be enabled. Without DHCP Option 82 data returned from the DHCP server, the switch cannot locate the client host port to forward the DHCP server reply. If Option 82 is not used, the DHCP server reply is dropped, and the DHCP client cannot obtain an IP address. Also, IP Source Guard with IP+MAC actually disables dynamic MAC learning on the port for DHCP and ARP packets; otherwise, MAC spoofing could not be prevented. This is why you need to enable Option 82 so that the switch can populate its bridging table with accurate information for the device connected to the switch.

Continue reading here: Normal ARP Behavior

Was this article helpful?

+1 0