What Is IP Spoofing? | How Source Address Forgery Enables DDoS

IP spoofing is a network technique in which an attacker forges the source IP address field of a packet to make it appear as though it originates from a different host than the one that actually sent it, which allows the attacker to hide their identity, impersonate a trusted host, or redirect responses toward a third party. It is a building block for reflection and amplification DDoS attacks, SYN flood, and certain on-path traffic manipulation techniques.

TL;DR: IP spoofing forges the source address of an IP packet so responses go to a victim instead of the sender. It works because IP itself performs no source authentication — that check, if any, happens in upper-layer protocols or at the network edge. Spoofing enables reflection/amplification attacks (DNS, NTP, SSDP, CLDAP) and SYN floods with unreachable half-open connections. Mitigation is primarily upstream: BCP38/uRPF ingress filtering at ISPs and edge routers, since a network that blocks its own customers from sending spoofed packets removes the attack at its source.

Last updated: 2026-08-27

IP spoofing has been a known weakness of the Internet Protocol since its early design. The technique was formally described in security literature as early as 1985, and it underpinned some of the first documented DDoS incidents, including the 1996 SYN flood attacks against Panix that led to the CERT/CC advisory CA-1996-21. Despite being nearly four decades old, spoofing remains viable today because IP source address validation was never mandatory in the core protocol — it depends on cooperation from networks that originate traffic, and that cooperation is incomplete.

How IP Spoofing Works

IP is a best-effort, connectionless protocol. Every IP packet carries a header with a source address field and a destination address field, but nothing in the protocol itself verifies that the source address matches the address of the sending interface. A host — or more precisely, the operating system’s network stack, or a raw-socket-capable program bypassing it — can set that field to any 32-bit (IPv4) or 128-bit (IPv6) value it chooses before the packet leaves the network.

Normal packet:
Host A (203.0.113.10) ──IP packet──▶ Host B
  [src=203.0.113.10, dst=Host B]     Host B replies to 203.0.113.10 (Host A)

Spoofed packet:
Attacker (198.51.100.50) ──IP packet──▶ Host B (reflector)
  [src=192.0.2.77 (victim), dst=Host B]

Host B replies to the address in the src field:
Host B ──response──▶ 192.0.2.77 (victim)
  [The attacker never receives the response; the victim does]

Routers forward packets based on the destination address only. Under normal operation, no router along the path inspects or validates the source address against the topology it was received from — that verification is the entire point of ingress filtering, described later, and its absence is precisely what makes spoofing possible from unfiltered networks.

Why UDP is more exposed than TCP

TCP requires a three-way handshake (SYN → SYN-ACK → ACK) before any application data flows. If an attacker spoofs a TCP SYN with a victim’s address, the SYN-ACK goes to the victim, not the attacker — the attacker never sees it and cannot complete the handshake or read a response. This makes spoofed TCP useful for denial-of-service (the victim receives unsolicited SYN-ACKs, and the real sender’s half-open state lingers on the responding server) but not for reading data back, since the connection state needed to carry data never completes on the attacker’s side.

UDP has no handshake. A single spoofed UDP datagram can trigger a full response sent directly to the forged source address, with no verification step in between. This is the mechanical basis for reflection and amplification attacks like DNS Amplification, NTP Amplification, SSDP Amplification, and CLDAP Amplification — all of which depend on a spoofable, connectionless transport carrying a query that produces a larger response.

On-path versus off-path spoofing

The vast majority of DDoS-related IP spoofing is off-path: the attacker never needs to see the response, because the goal is to direct it at a victim, not to read it. This is an important distinction from classic session-hijacking spoofing, which requires blind or observed sequence-number prediction and is largely mitigated today by randomized initial sequence numbers (RFC 6528) and connection-oriented protocols with cryptographic integrity.

IP Spoofing in Reflection and Amplification Attacks

Spoofing is the mechanism, not the attack itself — it is the piece that redirects an amplified response to a victim who never made the original request. The general pattern:

Step 1: Attacker sends small query to an amplifying server, spoofing victim's IP as source
Attacker → Reflector: query (spoofed src = victim IP)

Step 2: Reflector sends large response to the spoofed source
Reflector → Victim: response (much larger than query)

Step 3: Attacker repeats via thousands of reflectors simultaneously
Victim receives an aggregate volume far exceeding the attacker's own uplink capacity

Every entry in this table depends on IP spoofing as a precondition. Without the ability to forge the source address, none of these reflectors would direct their responses anywhere but back to the actual requester — which would be the attacker’s own infrastructure, defeating the purpose.

IP Spoofing in SYN Flood

SYN flood uses spoofing differently: not to amplify volume, but to prevent the attacker’s own address from ever completing a TCP handshake, so that the half-open connection state on the target server persists until timeout instead of being torn down by an RST from the (nonexistent or uninvolved) source.

Attacker sends: TCP SYN (src = spoofed IP, dst = target server)
Target server: allocates TCB, sends SYN-ACK to spoofed IP
Spoofed IP: does not exist, or exists but never sent the SYN — ignores or does not respond
Target server: TCB remains in SYN_RECV state until the SYN timeout expires

If the attacker used its own real address instead, the target’s SYN-ACK would arrive at the attacker’s machine, and the OS network stack — having no record of initiating that connection — would typically respond with an RST, closing the half-open state almost immediately and defeating the attack. Spoofing removes that self-correcting behavior.

Detection Signals

Spoofed traffic leaves several observable fingerprints, though no single signal is conclusive on its own — spoofing detection generally requires correlating multiple sources of telemetry.

# Check whether your own router would forward a packet back out the interface it arrived on (loose uRPF concept)
ip route get <source-ip>

# Inspect NetFlow for UDP responses with no matching outbound query (example using nfdump)
nfdump -r flows.nf 'proto udp and src port 123' -o extended

# Capture and inspect TTL distribution for a suspect source range
tcpdump -n 'src net 198.51.100.0/24' -v

Mitigation Techniques

BCP38 / Network Ingress Filtering (RFC 2827)

BCP38 (RFC 2827) is the foundational anti-spoofing practice: an ISP or edge network should drop, at its own border, any outbound packet whose source address does not belong to the IP block it has allocated to that customer or segment. If every network implemented BCP38 correctly, IP spoofing directed at arbitrary internet destinations would not be possible — a spoofed packet would never leave the network it originated from.

Adoption remains incomplete. The CAIDA Spoofer Project has measured for years that a meaningful share of Autonomous Systems still permit some form of source spoofing, though the trend has generally improved over time. Because BCP38 has to be deployed by the network the attacker’s traffic originates from — not by the victim — the victim organization cannot enforce it directly; the practical defense burden shifts to detection and absorption downstream.

Unicast Reverse Path Forwarding (uRPF, RFC 3704)

uRPF is one concrete implementation of ingress filtering at the router level, defined in RFC 3704:

• Strict mode requires that the best return route to a packet’s source address point back out the same interface the packet arrived on. This is precise but breaks on asymmetric-routing or multihomed topologies where inbound and outbound paths legitimately differ.
• Loose mode only requires that some route to the source address exist in the routing table, regardless of interface. It is more compatible with asymmetric routing but catches fewer spoofed packets — an attacker using any routable address, including someone else’s real address, can pass a loose check.

SYN Cookies as a spoofing-tolerant defense

Rather than trying to prevent spoofing, SYN cookies (RFC 4987) neutralize its effect on TCP handshake exhaustion by not allocating connection state until a valid ACK returns — which a spoofed source, by definition, will never send. This is covered in depth in What Is SYN Flood?.

Rate limiting and response correlation at DNS/NTP/reflector operators

Operators of potential reflectors (DNS resolvers, NTP servers, LDAP directories, UPnP-enabled devices) reduce their usefulness as amplifiers by restricting who can query them, applying response rate limiting, and disabling legacy features like NTP’s monlist. This does not stop spoofing itself but removes the amplifying infrastructure attackers depend on.

Edge scrubbing and distributed absorption

Because spoofed reflection/amplification traffic can arrive at volumes far exceeding a single organization’s uplink, the practical mitigation for a target is upstream: a distributed network or scrubbing provider with enough aggregate capacity to absorb the traffic before it reaches the origin. See Blackhole Routing vs. Scrubbing for a comparison of approaches.

Common Mistakes

How to Implement on Azion

Azion’s distributed network can help absorb and filter the effects of IP-spoofing-dependent attacks before they reach an origin, even though spoofing itself is a network-ingress problem that must ultimately be addressed upstream by the networks originating the traffic.

• DDoS Protection provides always-on detection and mitigation for volumetric traffic generated by spoofed reflection and amplification attacks, absorbing it across Azion’s distributed infrastructure rather than at your origin.
• Network Shield can apply network-level rules to filter anomalous UDP/TCP traffic patterns consistent with reflected or amplified attacks, depending on configuration.
• Firewall enables custom rules for rate limiting and traffic filtering based on protocol, port, and behavioral patterns.
• WAAP combines network and application-layer protections for organizations facing multi-vector campaigns that pair spoofed volumetric attacks with application-layer abuse.

Because TCP connections are terminated at Azion’s edge, spoofed SYN packets targeting your application never establish a false sense of state on your own origin infrastructure — only validated, completed connections are forwarded.

Related Resources

• What Is a DDoS Attack?
• DDoS Attack Types
• What Is SYN Flood?
• What Is DNS Amplification?
• Azion DDoS Protection

Frequently Asked Questions

What is IP spoofing? IP spoofing is the practice of forging the source IP address field of a packet so it appears to come from a different host than the one that actually sent it. It exploits the fact that IP itself performs no source authentication — routers forward packets based on destination address only, with no built-in check that the source field is truthful.

Is IP spoofing illegal? Spoofing itself is a technique, not exclusively a crime, and has limited legitimate uses in testing environments. In the context of unauthorized attacks against third-party systems, using spoofed addresses to conduct DDoS, reflection, or amplification attacks is illegal in most jurisdictions under computer-crime statutes such as the US Computer Fraud and Abuse Act.

Why can’t a firewall on the victim’s network stop IP spoofing? A firewall on the victim’s network only sees packets after they have already traversed the internet and arrived at the victim’s border — it has no way to verify whether the source address is genuine, because the forgery happened upstream, closer to or at the attacker’s own network. Effective anti-spoofing filtering (BCP38/uRPF) has to be applied at the network where the traffic originates, not at the destination.

Does IPv6 eliminate IP spoofing? No. IPv6 does not include mandatory source-address authentication any more than IPv4 does. The same BCP38-style ingress filtering principle applies to IPv6 networks, and operators must apply it deliberately — it is not automatic simply because the address space is larger.

How does IP spoofing enable DNS, NTP, SSDP, and CLDAP amplification attacks? In each of these attacks, the attacker sends a small request to an open server (resolver, NTP daemon, UPnP device, or LDAP server) with the victim’s IP address forged as the source. The server, unaware of the forgery, sends its (much larger) response directly to the victim. Without the ability to spoof the source address, the amplified response would return to the attacker instead of the victim, defeating the purpose.

What is the difference between on-path and off-path IP spoofing? An on-path attacker can observe or intercept return traffic because they share a network segment or a position along the routing path, enabling more advanced attacks like session hijacking. An off-path attacker cannot see the response at all and does not need to — this is sufficient for denial-of-service purposes like reflection attacks and SYN floods, where the goal is simply to direct unwanted traffic at a victim.

Can BCP38 completely eliminate IP spoofing? Wide, correct adoption of BCP38 across all networks would prevent spoofed packets from leaving the network they originated from, effectively eliminating internet-scale spoofing. In practice, adoption remains incomplete — some networks still fail to filter outbound traffic for spoofed source addresses — which keeps spoofing available as a vector, even though the trend has generally improved over time according to projects like CAIDA’s Spoofer Project.

What is the difference between strict and loose uRPF? Strict uRPF requires that the router’s best route back to a packet’s source address use the same interface the packet arrived on, which is precise but can drop legitimate traffic in asymmetric-routing or multihomed environments. Loose uRPF only requires that some route to the source address exist anywhere in the routing table, which is more permissive and compatible with asymmetric routing but catches fewer spoofed packets.

Can SYN cookies prevent IP spoofing? SYN cookies do not prevent spoofing itself — an attacker can still forge a SYN packet’s source address. What SYN cookies prevent is the resource-exhaustion consequence of that spoofing: because the server does not allocate connection state until a valid ACK returns, and a spoofed source will never send that ACK, the half-open-connection attack fails without requiring the server to know whether the source was genuine.

How do I detect spoofed traffic on my network? Correlate multiple signals: UDP responses arriving with no matching outbound query, packets with bogon or reserved source addresses, uRPF check failures logged by routers, and anomalous TTL values inconsistent with the claimed source’s typical distance. No single signal is conclusive on its own; NetFlow, sFlow, and router logs combined with historical baselines give the clearest picture.

Sources:

• IETF. “Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing.” RFC 2827 (BCP38). 2000.
• IETF. “Ingress Filtering for Multihomed Networks.” RFC 3704. 2004.
• IETF. “Defending Against Sequence Number Attacks.” RFC 6528. 2012.
• IETF. “Defending Against SYN Flood DoS Attacks with SYN Cookies.” RFC 4987. 2007.
• CERT/CC. “Advisory CA-1996-21: TCP SYN Flooding and IP Spoofing Attacks.” 1996.
• CAIDA. “Spoofer Project Results.” caida.org, 2024.
• CISA. “Understanding and Responding to Distributed Denial-of-Service Attacks.”
• NIST SP 800-94. “Guide to Intrusion Detection and Prevention Systems (IDPS).”