IP Spoofing

Every IP packet carries a return address—the source IP field that says "I came from here." The Internet believes this field. It has to. Verifying every packet's true origin would grind global networking to a halt.

IP spoofing exploits this trust. An attacker crafts packets with someone else's address in the source field. The packets travel across the Internet, accepted at face value, appearing to come from wherever the attacker claims.

This isn't a bug. It's a consequence of how IP was designed—for speed and openness, not for a world where strangers might lie.

The Fundamental Tradeoff

IP was built on a handshake agreement: I'll believe you are who you say you are. This made the early Internet fast and simple. Routers forward packets based on destination addresses; they don't interrogate where packets claim to originate.

But this trust creates a problem. Nothing stops a system from writing any address it wants in the source field. An attacker at 5.6.7.8 can send packets claiming to be from 1.2.3.4. They can claim to be from the victim's own network. They can use addresses that don't exist at all.

The packets flow through the Internet just fine. Routers don't care. Firewalls often don't check. The destination receives what appears to be legitimate traffic from a legitimate source.

The Catch: You Can Lie, But You Can't Listen

Spoofing has one critical limitation: responses go to the spoofed address, not the attacker.

If you send a packet claiming to be from 1.2.3.4, any reply goes to 1.2.3.4. You never see it. This makes spoofing useless for anything requiring two-way communication—you can't log into a server, download data, or maintain a connection.

But for attacks where you don't need responses? Spoofing is devastating.

How Attackers Weaponize Spoofing

Amplification attacks turn spoofing into a force multiplier. The attacker sends small requests to public services—DNS servers, NTP servers, memcached instances—with the victim's IP as the source address. These services send large responses to the victim. A 60-byte query might generate a 3,000-byte response. Multiply by thousands of reflectors, and a modest attacker can generate overwhelming traffic.

The victim sees a flood of legitimate-looking responses from servers around the world. The attacker's real address never appears.

SYN floods exploit TCP's three-way handshake. The attacker sends connection requests (SYN packets) with spoofed source addresses. The target responds with SYN-ACK packets—to addresses that never complete the handshake. The server's connection table fills with half-open connections, eventually refusing legitimate traffic.

Smurf attacks broadcast ICMP echo requests to entire network segments with the victim's address as source. Every device on the segment responds to the victim simultaneously. One packet becomes hundreds.

Land attacks send packets where source and destination are identical—the victim's own address. Some systems crash when they appear to receive packets from themselves.

Why This Still Works

You might expect the Internet to have solved this by now. It hasn't, for several reasons.

UDP has no handshake. Packets arrive, get processed, and responses go out—no verification that the conversation makes sense. This is why amplification attacks overwhelmingly use UDP-based services.

Many networks don't filter outbound traffic. They'll forward packets with any source address, trusting their customers not to lie. This trust is often misplaced.

Even networks that want to filter may lack the technical sophistication or resources to implement it properly.

And the Internet is global. Even if 90% of networks implement perfect filtering, the remaining 10% provide enough attack capacity for serious damage.

Detection: Finding the Lies

Spoofed traffic often betrays itself through inconsistencies.

TTL analysis examines how many router hops a packet claims to have traversed. A packet claiming to be from a nearby address but with a TTL suggesting it crossed half the Internet is suspicious.

Impossible sources are obvious: packets from private IP ranges (10.x.x.x, 192.168.x.x) arriving from the public Internet, or packets claiming to be from your own network arriving on your external interface.

Behavioral anomalies reveal spoofing indirectly: traffic floods from addresses that are normally silent, connection patterns impossible for the claimed source, or protocol behaviors inconsistent with legitimate implementations.

Stateful firewalls detect spoofing by tracking connections. If a packet claims to be part of an established session but no such session exists, something's wrong.

Prevention: BCP 38 and the Dream of Verified Sources

The solution is conceptually simple: don't let spoofed packets leave networks in the first place.

BCP 38 (Best Current Practice 38) describes source address validation. If a network controls the address range 10.0.0.0/8, it should block any outbound packet with a source address outside that range. Such packets are definitionally spoofed—they claim to be from addresses the network doesn't own.

If every network implemented BCP 38, IP spoofing would be impossible. Spoofed packets would die at birth, never reaching the Internet.

But BCP 38 adoption is incomplete. Implementation requires effort and provides no direct benefit to the implementing network—it protects everyone else. This tragedy of the commons means spoofing remains viable decades after the solution was documented.

Unicast Reverse Path Forwarding

Routers can automate source validation using Unicast RPF. When a packet arrives, the router asks: "If I wanted to reach this source address, which interface would I use?" If the packet arrived on a different interface, it's probably spoofed.

Strict mode requires packets to arrive on exactly the right interface. Loose mode only requires the source address to be routable at all. Strict mode provides better security but breaks legitimate traffic in networks with asymmetric routing.

When IP Addresses Aren't Enough

The deeper lesson: IP addresses were never designed for authentication. They identify where packets claim to originate, not where they actually do.

Robust systems don't trust IP addresses for access control. They use cryptographic authentication—IPsec verifies packet sources mathematically, TLS authenticates servers and optionally clients, and application-layer tokens prove identity regardless of network path.

IP spoofing becomes irrelevant when systems verify identity through credentials rather than addresses. You can claim to be from any IP you want; without the right key, you're still locked out.

The Ongoing Reality

IP spoofing persists because it exploits a design decision made when the Internet was a small network of cooperating institutions. The assumption of honesty made sense then. It doesn't now.

The fixes exist. BCP 38 works. Unicast RPF works. Cryptographic authentication works. But deploying them universally requires coordination across thousands of independent networks with different incentives, capabilities, and priorities.

Until then, the Internet continues to accept packets at their word. And attackers continue to lie.