LogoENEnglish

Layer 2 Attack Mitigation: DHCP Snooping and Dynamic ARP Inspection

The MAC-learning and ARP mechanisms that make Ethernet networks function are also fundamentally trusting, creating openings for attacks that redirect or intercept traffic without ever touching a firewall. This article explains how a rogue DHCP server or ARP spoofing attack works, and covers how DHCP Snooping and Dynamic ARP Inspection work together to close these Layer 2 vulnerabilities.

DHCP SnoopingDynamic ARP InspectionRogue DHCP Server

~6 دقیقه مطالعه · آخرین به‌روزرسانی ۱۹ شهریور ۱۴۰۵

Why Layer 2 Trust Creates Security Gaps

The DHCP process and ARP resolution discussed earlier in this series were both designed decades ago under the assumption that every device on a local network segment could be trusted. Neither protocol includes any built-in authentication, meaning any device connected to a switch port can pretend to be a legitimate DHCP server or claim ownership of any IP address — a switch has no native way of knowing this is happening.

The Rogue DHCP Server Attack

Since DHCP relies entirely on client broadcasts, discussed earlier in this series, any device on the network can respond to a DHCP discovery message with its own offer, and the client accepts whichever offer it receives first.

Rogue DHCP attack scenario:
1. An attacker connects an unauthorized DHCP server
   to the network
2. A legitimate client broadcasts a DHCP discover
3. Both the real DHCP server AND the rogue server
   respond with offers
4. If the rogue server's offer arrives first, the
   client accepts it, receiving an attacker-controlled
   default gateway and DNS server
5. All of that client's traffic now flows through
   the attacker's device, enabling interception
   or manipulation of everything the client sends

This attack can occur completely by accident — an employee plugging in a personal wireless router with its own DHCP server enabled can unintentionally cause exactly this disruption, without any malicious intent at all.

DHCP Snooping: Establishing Trusted and Untrusted Ports

DHCP Snooping solves this by having the switch inspect DHCP traffic and classify each port as either Trusted (permitted to send DHCP server responses) or Untrusted (permitted only to send client requests, never server responses).

Switch(config)# ip dhcp snooping
Switch(config)# ip dhcp snooping vlan 10,20

-- Trust only the port connecting to the
-- legitimate, known DHCP server
Switch(config)# interface gigabitethernet 1/0/24
Switch(config-if)# ip dhcp snooping trust

-- All other access ports remain untrusted by
-- default once DHCP snooping is enabled on the VLAN

With this configuration, if a DHCP server response (an Offer or Acknowledge message) is received on any untrusted port, the switch drops it immediately — the rogue server's responses never reach legitimate clients, regardless of how quickly they arrive.

The DHCP Snooping Binding Table

As a byproduct of monitoring DHCP traffic, the switch builds a DHCP Snooping Binding Table, recording which IP address was legitimately assigned to which MAC address on which port.

Switch# show ip dhcp snooping binding

MacAddress        IpAddress     Lease(sec)  Type          VLAN  Interface
00:50:56:aa:11:22 192.168.1.11  86400       dhcp-snooping 10    Gi1/0/5

This binding table becomes far more valuable than a simple attack-prevention log — it serves as the trusted reference data source for Dynamic ARP Inspection, described next.

The ARP Spoofing Attack

ARP (Address Resolution Protocol) resolves an IP address to a MAC address, and like DHCP, it operates entirely on trust — any device can send an ARP reply claiming to own any IP address, whether or not that claim is true.

ARP spoofing (also called ARP poisoning) attack:
1. An attacker sends a forged ARP reply, falsely
   claiming their own MAC address corresponds to
   the network's default gateway IP address
2. Nearby devices update their ARP tables to
   point the gateway IP at the attacker's MAC
3. Traffic intended for the real gateway is now
   sent directly to the attacker instead
4. The attacker can silently forward this traffic
   onward after inspecting or modifying it,
   a classic man-in-the-middle position

Dynamic ARP Inspection: Validating ARP Against Known-Good Data

Dynamic ARP Inspection (DAI) solves this by intercepting every ARP packet on untrusted ports and validating its claimed IP-to-MAC mapping against the DHCP snooping binding table built above — an ARP message that does not match a known, legitimate binding is dropped.

Switch(config)# ip arp inspection vlan 10,20

-- Trust the same ports trusted for DHCP snooping,
-- since a legitimate DHCP server's associated
-- infrastructure should also be trusted for ARP
Switch(config)# interface gigabitethernet 1/0/24
Switch(config-if)# ip arp inspection trust

Because DAI relies directly on the DHCP snooping binding table, DHCP snooping must be enabled first — attempting to configure DAI without an active, populated binding table would leave it with no legitimate data to validate ARP messages against, causing it to drop legitimate traffic.

Handling Devices with Statically Configured IP Addresses

Devices with static IP addresses, discussed earlier in this series, never generate a DHCP transaction, meaning they never appear in the DHCP snooping binding table, and DAI would incorrectly drop their legitimate ARP traffic by default.

Switch(config)# arp access-list STATIC-DEVICES
Switch(config-arp-nacl)# permit ip host 192.168.1.5 mac host 0050.56cc.5566

Switch(config)# ip arp inspection filter STATIC-DEVICES vlan 10

-- This manually permitted entry supplements the
-- dynamic DHCP snooping bindings for devices that
-- legitimately never go through DHCP

Verifying DAI Operation

Switch# show ip arp inspection interfaces

Interface     Trust State   Rate (pps)  Burst Interval
Gi1/0/5       Untrusted     15          1
Gi1/0/24      Trusted       none        N/A

Switch# show ip arp inspection statistics
Vlan   Forwarded   Dropped
10     1204        3

A non-zero Dropped count is worth investigating — it may reflect legitimate attack prevention working correctly, or it may indicate a legitimate statically configured device that still needs to be added to the ARP access list described above.

Why These Two Features Work Best Together

DHCP Snooping and Dynamic ARP Inspection are deliberately designed to be deployed together: DHCP Snooping's binding table provides the trusted reference data that makes DAI effective, and DAI in turn closes the ARP-based attack vector that DHCP Snooping alone does not address. Implemented together, they close two of the most common and consequential Layer 2 attack vectors in switched networks, protecting against threats that traditional Layer 3 ACLs and firewalls, discussed earlier in this series, cannot see or prevent, since these attacks never leave the local Layer 2 segment.

نوشته و پژوهش‌شده توسط دکتر شاهین صیامی

مقالات مرتبط

Systematic Network Troubleshooting: A Methodology Tying Everything Together

Every protocol and technology covered throughout this series is only useful if a problem involving it can actually be diagnosed and fixed efficiently under real-world pressure. This article presents a systematic troubleshooting methodology built around the OSI layers, walks through applying it to a realistic connectivity problem, and shows how the specific verification commands covered throughout this entire series fit into a structured diagnostic process.

ادامه

NETCONF, YANG, and Python: Programmatic Network Configuration at Scale

The REST APIs and JSON/YAML formats covered earlier in this series represent one approach to network automation, but NETCONF and YANG provide a more structured, standards-based alternative purpose-built for network device configuration. This article explains what distinguishes NETCONF from a simple REST API, covers how YANG models define exactly what configuration data looks like, and walks through using Python to programmatically interact with network devices.

ادامه

IPsec VPN Fundamentals: Securing Traffic Across Untrusted Networks

Connecting two sites across the public internet exposes traffic to interception unless it is properly encrypted, and IPsec provides the standard framework for building secure, authenticated tunnels between sites. This article explains the two-phase IKE negotiation process, covers the distinction between AH and ESP protocols, walks through configuring a basic site-to-site IPsec VPN, and covers essential verification commands.

ادامه

MPLS Fundamentals: Label Switching Explained

Traditional IP routing requires every router along a path to perform a full routing table lookup on every packet, but MPLS takes a fundamentally different approach by making that forwarding decision once and attaching a simple label that every subsequent router can use instead. This article explains the core label-switching concept, walks through how the Label Distribution Protocol builds the label forwarding tables that make this possible, and covers the practical benefits MPLS provides in real provider networks.

ادامه

BGP Route Reflectors and Confederations: Scaling iBGP Beyond Full Mesh

The iBGP full-mesh requirement, briefly mentioned earlier in this series, becomes a serious scaling problem as an autonomous system grows, requiring a number of sessions that increases quadratically with router count. This article explains exactly why full mesh does not scale, walks through how route reflectors solve this by relaxing BGP's normal route-propagation rules, and covers confederations as an alternative approach that divides a single AS into smaller sub-autonomous systems.

ادامه

OSPF Area Types Deep Dive: Stub, Totally Stubby, and NSSA

Multi-area OSPF, covered earlier in this series, already reduces database size by separating a network into areas, but OSPF offers further specialized area types that reduce routing table size even more aggressively by filtering out unnecessary external routes entirely. This article explains the LSA types that must be suppressed to create each specialized area type, walks through configuring stub, totally stubby, and not-so-stubby areas, and covers the specific trade-offs each design choice involves.

ادامه
مقاله‌ی قبلیمقاله‌ی بعدی