ARP Poisoning Attack: How It Works & How to Prevent It

The Address Resolution Protocol (ARP) maps IP addresses to MAC (hardware) addresses on a local network. When a device needs to communicate with another device on the same subnet, it broadcasts an ARP request asking 'Who has this IP address?'

The device with the requested IP address responds with its MAC address. The requesting device stores this mapping in its ARP cache (a temporary table) and uses the MAC address for subsequent communications on the local network.

ARP was designed in an era when network trust was assumed. The protocol has no authentication mechanism — any device can send ARP replies, and other devices will accept them without verification. This fundamental design flaw enables ARP poisoning attacks.

You can view your system's ARP cache using 'arp -a' (Windows/Linux). Each entry shows an IP address, its corresponding MAC address, and the interface. These entries are typically refreshed every few minutes.

In an ARP poisoning attack, the attacker sends falsified ARP messages to link their MAC address with the IP address of another device (typically the default gateway). This causes traffic intended for the gateway to be sent to the attacker instead.

The attacker typically poisons the ARP caches of both the victim and the gateway simultaneously. This positions the attacker between the two, creating a man-in-the-middle (MITM) position where all traffic between the victim and the network passes through the attacker.

Once in a MITM position, the attacker can passively sniff all traffic, actively modify packets in transit, inject malicious content into web pages, redirect DNS queries, steal session cookies, and capture login credentials.

Tools like arpspoof ('arpspoof -i eth0 -t victim_ip gateway_ip') and Ettercap automate the ARP poisoning process. The attacker must also enable IP forwarding ('echo 1 > /proc/sys/net/ipv4/ip_forward') to transparently relay traffic and avoid disrupting the victim's connectivity.

Session hijacking: The attacker captures session cookies from unencrypted HTTP traffic, allowing them to impersonate the victim on web applications without knowing their password.

Credential theft: Login credentials sent over unencrypted protocols (HTTP, FTP, Telnet, POP3) are captured in plaintext. Even on encrypted sites, the attacker may perform SSL stripping to downgrade HTTPS connections to HTTP.

DNS spoofing via ARP: After establishing a MITM position, the attacker intercepts DNS requests and returns malicious IP addresses, redirecting the victim to fake websites that capture credentials or deliver malware.

Denial of service: By poisoning ARP tables without forwarding traffic, the attacker can effectively disconnect the victim from the network. Alternatively, selectively dropping certain types of traffic can cause subtle and hard-to-diagnose connectivity issues.

Detection methods include monitoring for duplicate IP addresses, watching for unusual amounts of ARP traffic, checking for ARP entries that change frequently, and using tools like ARPwatch that alert on ARP table changes.

Dynamic ARP Inspection (DAI) is a switch feature that validates ARP packets against a trusted database (DHCP snooping binding table). DAI drops ARP packets with invalid IP-to-MAC bindings, effectively preventing ARP poisoning on managed switches.

Static ARP entries eliminate the vulnerability entirely by manually configuring IP-to-MAC mappings that cannot be overwritten by ARP replies. However, this approach is impractical on large networks due to the management overhead.

Encryption (HTTPS, SSH, VPN) is the most practical defense. While encryption does not prevent ARP poisoning itself, it ensures that captured traffic remains unreadable. Implementing HSTS headers prevents SSL stripping attacks on web applications.