ARP spoofing attack explained: how it works, what it damages and how to spot it in a data center

An ARP spoofing attack, also called ARP cache poisoning, is when a host on a local network sends forged ARP replies so that other hosts write the wrong MAC address into their ARP cache for a given IP, usually the gateway’s. Because ARP has no authentication, any machine on the same layer 2 segment can claim “203.0.113.1 is at my MAC” and most of the segment will believe it. From that moment the victims’ traffic goes to the attacker instead of the real gateway, which lets the attacker drop it, read it, modify it, or send packets from somebody else’s IP. In a colocation or hosting network the source is almost always one compromised server in the same VLAN, and the damage lands on every other customer in that VLAN.

Why ARP can be spoofed at all

ARP (Address Resolution Protocol) maps IPv4 addresses to Ethernet MAC addresses. When host 203.0.113.10 wants to send a packet to its gateway 203.0.113.1, it broadcasts a request to the whole segment: “who has 203.0.113.1? tell 203.0.113.10”. The gateway answers with a unicast reply: “203.0.113.1 is at 00:aa:bb:cc:dd:ee”. The host stores that mapping in its ARP cache and from then on wraps every IP packet for the gateway in an Ethernet frame addressed to that MAC.

The protocol was defined in RFC 826 in 1982 on the assumption that hosts on the same LAN trust each other. That assumption leaves three gaps an attacker can use:

Gap	Protocol behavior	How it is abused
Replies are not verified	A host accepts an ARP reply without checking whether it ever sent a request, and has no way to confirm who sent the reply	Send forged replies to the target without waiting for a request
Newer overwrites older	An existing cache entry is updated by whatever arrives next	Send forged replies continuously so the attacker’s MAC always sits on top of the correct entry
Requests also update the cache	Many IP stacks refresh or create an entry for the requester’s IP and MAC when they receive an ARP request (exact rules vary by OS)	Use broadcast requests to poison every host on the segment with a single packet

So ARP spoofing needs no vulnerability. An ordinary Linux server with arpspoof (from dsniff), ettercap or bettercap, or a few lines of raw-socket code, is enough. All it needs is a machine on the target segment and root privileges, and a compromised server has both.

Two forms: gateway spoofing and host spoofing

The mechanism is the same; what differs is whose IP is forged. Both forms are common in data centers.

Gateway spoofing. The attacker broadcasts “203.0.113.1 is at the attacker’s MAC” to the whole segment. Every host’s outbound traffic now flows to the attacker. If the attacker simply discards it, the whole segment loses connectivity. If the attacker enables IP forwarding and passes it on to the real gateway, everything keeps working but every packet passes through the attacker: a classic man-in-the-middle.

Host spoofing. The attacker sends a unicast reply to the gateway: “203.0.113.20 is at the attacker’s MAC”. The gateway now delivers return traffic for that customer’s server to the attacker, and the victim can send but not receive. If the attacker also sources packets from that IP, this is plain IP theft.

	Gateway spoofing	Host spoofing
Whose cache is poisoned	Every host on the segment	The gateway (sometimes other hosts on the segment too)
Forged packet	Broadcast: gateway IP → attacker MAC	Unicast to the gateway: victim IP → attacker MAC
Scope	The entire VLAN	One or a few servers
Typical goal	Outage, sniffing, hijacking	Stealing an IP, creating conflicts, bypassing IP-based access control
Load on the attacker	Must absorb the whole segment’s outbound traffic; the NIC saturates quickly	Minimal

Doing both at once, pretending to be the gateway to the victim and the victim to the gateway, puts the attacker in the middle of both directions, able to read and rewrite all of that server’s unencrypted communication.

What an ARP spoofing attack does

Damage	How it happens	What the user sees
Outage or intermittent connectivity	Traffic is pulled to the attacker and dropped, or forged and genuine replies alternate and the cache flaps back and forth	Heavy packet loss and wildly varying latency to the gateway; recovers by itself when the attack stops
IP address conflict	The attacker announces an IP that is already in use	Windows shows an IP conflict warning; on Linux, the MAC for the same IP keeps changing
Traffic hijacking and sniffing	Man-in-the-middle forwarding exposes HTTP, FTP, Telnet and unencrypted database sessions	Almost nothing; HTTPS with a swapped certificate triggers a browser warning
Content tampering	Scripts or redirects injected into forwarded HTTP responses	The site appears to serve malicious content, but no file on the server has changed
DNS hijacking	DNS answers rewritten in transit	Domains resolve to the wrong address
IP and bandwidth theft	The attacker sends traffic from someone else’s IP	Unexplained traffic on the victim’s IP, abuse complaints, or the IP gets blocked
Resource exhaustion	A flood of ARP packets with random IP-MAC pairs	Switch CPU spikes; the gateway’s ARP table fills up and legitimate hosts cannot get entries

On office networks ARP poisoning is mostly remembered for outages and injected ads. In a hosting environment the last three rows matter most: one customer’s traffic being read by another customer’s machine in the same facility, a customer’s IP being used to send abusive traffic, and the availability of a whole segment depending on the weakest server in it.

How one compromised server takes down a whole colocation VLAN

Take a typical colocation VLAN: one public /24, the gateway on a layer 3 switch, a few dozen customer servers on access switches, each with static public IPs and no port isolation between them.

1. One customer’s server has a weak password. It gets found by a scanner and infected with malware whose features include ARP spoofing on the local segment, either to harvest credentials from neighbors or to inject ads into web pages passing through.
2. The malware broadcasts dozens of “the gateway is here” replies per second. Within seconds, every host on the segment has a poisoned ARP cache.
3. Outbound traffic from dozens of servers now pours into the infected machine’s single gigabit port. It is forwarding and sniffing at the same time; the NIC and CPU saturate and it starts dropping packets heavily.
4. Customers see latency jump from 2 ms to hundreds of milliseconds, SSH sessions stall and websites time out, while every process and configuration on their own servers looks normal.
5. Tickets arrive in a cluster, all from the same subnet. This is the single most telling sign.
6. The malware runs intermittently, or the real gateway’s gratuitous ARP occasionally refreshes some caches, so the problem comes and goes and is hard to reproduce with a single ping.

The infected customer did not “attack” anyone, yet every paying customer in that VLAN is affected. This is why data centers treat ARP spoofing as a security incident rather than an ordinary fault: the cause is one machine, the loss is service quality for an entire segment.

A quieter variant: a customer’s server silently configures a public IP that a neighboring customer owns but is not currently using, or rotates source IPs with a script. This is host spoofing in practice, usually to get extra IPs without paying or to make attack traffic look like it came from someone else. It causes no broad outage; it shows up only as a conflict when the legitimate owner starts using that IP, or when an abuse complaint arrives.

How to detect ARP spoofing: signs and commands

There is no specific error message for ARP spoofing, but when several of these signals appear together the diagnosis is close to certain:

Sign	How to confirm
Multiple customers in the same subnet report problems at once; other subnets are fine	Group tickets by IP range
The gateway MAC recorded on a customer’s server is not the gateway’s MAC	Compare with the real MAC of the gateway’s VLAN interface
In the switch MAC table, the gateway MAC appears on an access port	The gateway MAC should only ever appear on the uplink
The switch logs MAC flapping	The same MAC moving between the uplink and an access port
An access port shows an abnormal rate of ARP packets	A normal server sends a few per second; an attacker sends tens to hundreds
The MAC for a customer IP changed in the gateway’s ARP table	Compare with the MAC in your asset records
Customers report HTTPS certificate errors or injected ads	Classic man-in-the-middle symptoms

On an affected server, or any host in the same segment, first check who it thinks the gateway is:

# Linux: MAC and state for the gateway IP
ip neigh show 203.0.113.1
# Windows
arp -a 203.0.113.1

Then capture ARP traffic and see who is announcing the gateway address. -e makes tcpdump print the Ethernet header; arp[6:2] == 2 keeps only ARP replies:

tcpdump -nei eth0 'arp and arp[6:2] == 2 and arp src host 203.0.113.1'

Normally only one MAC ever follows “203.0.113.1 is-at”, and infrequently. Two different MACs within a short window, or one MAC announcing dozens of times per second, is spoofing. Compare the source MAC in the frame header with the sender MAC inside the ARP body: attack tools can forge the body, but the switch learns MACs from the frame header, so use the header when locating the port.

With the suspicious MAC in hand, find its port on the switch:

# Cisco IOS
show mac address-table address 0011.2233.4455
show ip arp 203.0.113.1
# Juniper Junos
show ethernet-switching table | match 00:11:22:33:44:55
show arp | match 203.0.113.1
# Huawei / H3C
display mac-address 0011-2233-4455
display arp | include 203.0.113.1

Cisco switches log MAC flapping as something like %SW_MATM-4-MACFLAP_NOTIF: Host 0011.2233.4455 in vlan 100 is flapping between port Gi1/0/5 and port Gi1/0/48, which names both ports outright. Other vendors have equivalent MAC-move detection and alarms; check the vendor documentation for the exact log format. Once you have the access port, your asset records tell you which server and which customer.

ARP spoofing vs IP conflict vs gateway failure

All three can look like “some or all customers in a segment are offline”, but the response is completely different:

Check	ARP spoofing	Ordinary IP conflict	Gateway failure
Scope	Whole VLAN (gateway spoofing) or a single host (host spoofing)	Only the conflicting IP	Whole VLAN
MAC for the gateway IP	Becomes the MAC of a device on an access port	Unchanged	Unchanged, or ARP requests get no reply at all
ARP packet rate	One MAC announcing at high frequency	Two MACs occasionally alternating	No replies from the gateway
Conflicting IPs	Usually the gateway, or several customer IPs at once	Usually one	None
After shutting the suspect port	Recovers within tens of seconds	Conflict disappears	No change

An ordinary IP conflict is almost always a configuration mistake: find the misconfigured side and fix it. A gateway failure is a layer 3 device problem. Only ARP spoofing needs to be handled as a security incident: isolate the port, tell the customer to clean the system, then add switch-side protection.

Where a management system fits

The hard part of catching an ARP spoofing attack is not the commands but the question “whose MAC is this?” With hundreds of servers and thousands of IPs tracked in spreadsheets, answering it means digging through several files. IP address management in Toplink DCIM records which server, customer and VLAN each IP belongs to, and the server list shows which switch and port each machine is connected to, so a suspicious MAC or IP maps to a rack and a customer in one lookup. From there, switch management can shut the port to stop the bleeding; for long-term protection the same page configures ARP binding and source address validation, which lock IP, MAC and port together so forged packets are dropped at the access port.