ARP spoofing

ARP has no authentication, and a Linux host updates an entry it already has from any ARP request or reply it hears. An attacker on the same network keeps telling a victim "the gateway's address is at my MAC", and the gateway "the victim is at my MAC", so both send their frames to the attacker, who forwards them on and reads or changes them in passing. It shows as two IP addresses with one MAC in ip neigh; switches stop it with dynamic ARP inspection.

How ARP spoofing works, step by step

ARP (RFC 826) has no authentication: a device believes any ARP it hears and overwrites its cache with it. ARP spoofing (also called ARP poisoning) abuses that to put an attacker between two parties on the same network. In the ARP spoofing lab the victim is 10.0.1.10, the attacker 10.0.1.11 and the gateway 10.0.1.2, all on 10.0.1.0/24; the gateway reaches a secret server 10.0.2.10 on the other side.

1. The attacker learns the real MACs. It pings the victim and the gateway once so its own cache holds both hardware addresses, which it needs as targets for the forged frames.
2. It poisons the victim. A few times a second it sends the victim a forged ARP claiming 10.0.1.2 (the gateway) is at the attacker's MAC. The victim overwrites its entry for the gateway.
3. It poisons the gateway the same way, claiming the victim 10.0.1.10 is at the attacker's MAC. Now both directions of the victim's off-LAN traffic land on the attacker. This two-sided lie is what makes it a man in the middle.
4. The attacker forwards. With IP forwarding on, it relays each frame to the real next hop, so the victim's pages still load and nothing looks broken, while the attacker reads and could rewrite everything in between.
5. The lie must be refreshed. Entries go STALE and the real gateway's own ARP competes, so the attacker keeps re-sending. Stop it and flush the caches and the real MACs return.

The attacker never touches an IP address. Packets still say 10.0.2.10; only the MAC in the frame that carries them is wrong.

What it looks like on a Linux machine

Before the attack the victim resolves the gateway to the gateway's own card. ip neigh prints the ARP cache (its modern name is the neighbour table):

$ ip neigh show 10.0.1.2
10.0.1.2 dev eth0 lladdr 1a:2b:3c:00:00:02 REACHABLE

The attacker forges ARP with nping, naming the gateway's address but its own MAC as sender:

$ nping --arp --arp-type ARP-request --arp-sender-ip 10.0.1.2 --arp-target-ip 10.0.1.10 --dest-mac ff:ff:ff:ff:ff:ff -c 3 10.0.1.10
Raw packets sent: 3 (126B)

Within a few seconds the victim's entry for the gateway flips to the attacker's MAC (10.0.1.11's):

$ ip neigh show 10.0.1.2
10.0.1.2 dev eth0 lladdr 1a:2b:3c:00:00:0b REACHABLE
POISONED: victim thinks gateway is at 1a:2b:3c:00:00:0b (the attacker)

Now the attacker sees the victim's traffic to the server pass through its own card. A capture on the attacker shows the flow it should never see:

$ tcpdump -nn -i eth0 host 10.0.1.10 and host 10.0.2.10
10.0.1.10.51234 > 10.0.2.10.80: Flags [P.], seq 1:78, length 77
10.0.2.10.80 > 10.0.1.10.51234: Flags [P.], seq 1:95, length 94

The traffic should never pass the attacker, yet here it does. The ARP spoofing lab sits in the middle of the same capture and reads the secret token straight out of the plain HTTP.

What goes wrong, and how you see it

One MAC behind two IP addresses. The surest sign: the attacker's MAC appears as the lladdr for both the gateway and the victim. arpwatch logs a changed ethernet address line the moment an entry is overwritten.

The victim loses the network instead of being watched. If the attacker does not enable IP forwarding, it drops what it intercepts: the victim's ping to anything off-LAN starts timing out even though its own card is fine.

A static entry cannot be poisoned. ip neigh replace 10.0.1.2 lladdr 1a:2b:3c:00:00:02 dev eth0 nud permanent pins the gateway's MAC; forged ARP for it is then ignored, and the man-in-the-middle fails for that pair.

The switch drops the forged ARP. With DHCP snooping and dynamic ARP inspection the switch checks each ARP against the lease it recorded; 10.0.1.2 from a desk that leased 10.0.1.13 matches no binding and is dropped, and a drop counter climbs. The layer 2 security lab shows exactly that.

Questions people ask

Is ARP spoofing the same as ARP poisoning? Yes, two names for one attack: sending forged ARP so a victim's cache maps an IP to the attacker's MAC.

Can ARP spoofing work across the internet? No. ARP is link-local and routers do not forward it, so the attacker must already be on the same network segment (or VLAN) as the victim.

How do I detect it? Watch for a MAC claiming more than one IP, or an IP whose MAC changes, with arpwatch or ip neigh; on the switch, dynamic ARP inspection stops it at the port. See also ARP.

See it on real machines