What Is IP Spoofing? How Forged Packets Work and What Stops Them

Every packet on the internet carries a return address, and nothing on the way checks that it's true. That one gap feeds the reflection floods behind today's largest DDoS attacks, slips past allowlists that trust an address, and lets someone on your LAN pose as the gateway. This guide explains what IP spoofing is, where it shows up for a small IT team, and the filters that stop it at the edge.

TL;DR

• What it is. IP spoofing is sending packets with a forged source address, so the replies and the blame land on someone else.
• Why it works. The IP header has no field that proves who sent a packet.
• Where it hurts. Reflection and amplification DDoS, address-based allowlists, and LAN hijacks through ARP.
• What stops it. Source filtering at every network edge, plus authentication that never trusts an address on its own.

How IP Spoofing Works

Every IP packet starts with a header. Two of its fields matter here: the destination address, where the packet is going, and the source address, where it claims to come from. The sender's operating system fills in both. Routers read the destination, pick the next hop and move on. None of them look back at the source to see if it's real.

Think of a postcard with a return address written in pencil. The post office delivers it to the address on the front. Whatever is written in the corner is the sender's word, and nobody at the sorting office checks it. If the card needs a reply, the reply goes to the pencilled address, whoever lives there.

That last part shapes everything an attacker can do with a forged source. The replies go to the address in the header, not to the person who sent the packet. So a spoofer is usually working blind: they can send, but they can't read the answers. That limit is why spoofing suits some attacks perfectly and others not at all.

Raw sockets make the forging trivial. Any machine where the attacker has admin rights can build a packet by hand with whatever source address they like, and free tools such as hping3 and Scapy do it in one line. The hard part was never writing the packet. It's getting the network to carry it, and that depends on whether the attacker's own provider checks source addresses on the way out.

CAIDA, the research group that runs the long-standing Spoofer measurement project, explains the mechanism in under four minutes:

Reflection and Amplification: Where Spoofing Does the Most Damage

The attack that makes spoofing matter to everyone is reflection. The attacker sends small requests to thousands of servers on the open internet, each one carrying the victim's address as the source. The servers do exactly what they should and answer. Every answer goes to the victim.

Amplification is the multiplier. Some protocols answer a small question with a much larger reply. A DNS query of a few dozen bytes can trigger a response many times its size. Connectionless LDAP, which Windows domain controllers answer on UDP port 389, does the same. So do NTP, SSDP and memcached when they face the internet. The attacker pays for the small packets. The victim's link pays for the big ones.

Cloudflare's DDoS threat report for the first half of 2026 describes the shift plainly: the attack-vector center of gravity moved from botnet floods to reflection and amplification. Cloudflare mitigated 935 network-layer attacks above 1 Tbps in those six months, and CLDAP floods grew 580% quarter over quarter to become the third most common vector in Q2. The report's explanation is one sentence long: because CLDAP uses UDP, "there's no handshake requirement, which allows attackers to spoof the source IP address."

The uncomfortable part for an IT team is the middle of that chain. The reflectors are ordinary servers that answer anyone: an open DNS resolver someone stood up years ago, a domain controller with port 389 published to the internet, a printer answering SNMP from anywhere. If your network hosts one, your network is part of somebody else's attack, and the abuse reports land on your desk.

Sometimes the reflector is your firewall. In this February 2026 thread, an admin on a business fiber line pulled a day of flow data and found nearly half of it was what looked like port scans from Brazilian ISPs. The replies worked out what was going on. The "scans" were SYN packets carrying the Brazilian providers' own addresses as the source, and every SYN-ACK the firewall sent back was traffic aimed at those providers. The admin wasn't the target. Their firewall was the ammunition, and they switched from answering to dropping.

What a flood looks like from the receiving end, and the order of the response, is covered in our guide to DDoS attacks.

Why TCP Blunts Spoofing and UDP Doesn't

TCP opens every connection with a three-step handshake. The client sends a SYN. The server answers with a SYN-ACK that carries a random sequence number. The client has to echo that number back before any data moves.

Now forge the source. The SYN-ACK goes to the address in the header, which isn't the attacker's. The attacker never sees the sequence number, so they can't complete the handshake, so no session opens. Over the internet, a spoofed TCP connection is a dead end. That's why spoofed TCP shows up as floods, SYN floods and SYN-ACK reflection, and almost never as a forged login.

It wasn't always that safe. In the 1990s some systems picked sequence numbers an attacker could predict, which let them finish a handshake blind. Randomized initial sequence numbers, written down in RFC 6528, closed that door on every modern operating system.

UDP has no handshake. One packet arrives, the service acts on it and sends its reply. DNS, NTP, SNMP, syslog, RADIUS and CLDAP all work this way. A single forged packet is enough to make the service answer someone else, or to accept an instruction from someone it thinks it trusts.

A stateful firewall adds one more brake on the TCP side. It tracks which conversations were opened from inside, so a SYN-ACK arriving for a SYN your network never sent has no matching entry and gets dropped.

When an Allowlist Trusts the Wrong Packet

Plenty of business systems still decide who to trust by address. The SMTP relay that accepts mail from the office's public IP. The switch that takes SNMP from the monitoring server's address. The syslog collector that writes whatever arrives from the firewall's address. The partner VPN rule that opens a management port to one outside IP.

Over the internet, forging a trusted address doesn't get an attacker into a TCP service, for the handshake reasons above. It does get a single UDP packet through. A forged SNMP set request with the right community string, a fake syslog line that buries the real alert, a spoofed RADIUS packet: each one arrives looking like it came from a friend. A stateless rule that permits "anything from 203.0.113.10" will pass every one of them, which is the trade-off in our stateful vs stateless explainer.

The fix is to stop treating the address as proof of anything. Use an address to narrow down who may knock. Use keys to decide who gets in. That means SNMPv3 with authentication instead of community strings, syslog over TLS where the collector supports it, management access through a VPN with certificates and MFA, and mutual TLS between services that talk to each other.

On the LAN: Hijacks and ARP Spoofing

Inside a network segment the rules change, because an attacker on the same switch can often see the replies. That turns spoofing from a blind trick into a man-in-the-middle.

The usual route is ARP spoofing, IP spoofing's cousin one layer down. Devices on a LAN use ARP to ask "which hardware address owns this IP?", and they believe the first answer they hear, even one nobody asked for. An attacker announces that the gateway's IP belongs to their laptop's MAC address. Every machine updates its table, and traffic for the internet now flows through the attacker first.

Managed switches can refuse to play along. DHCP snooping builds a table of which device got which address on which port, and Dynamic ARP Inspection drops ARP replies that contradict it. Port security caps how many MAC addresses one port may present. Splitting guests, printers and staff onto separate segments with VLANs shrinks how far a hijack can reach. And encryption makes the intercepted traffic far less useful: an attacker in the middle of a TLS session sees ciphertext, not passwords.

The Cousins: Email, DNS and Caller ID

The word spoofing covers a family, and the rest of it gets its own guides. Email spoofing forges the From line rather than the IP header, and SPF, DKIM and DMARC at reject are the fix, set up step by step in our email security checklist.

DNS spoofing feeds a resolver a fake answer so a user lands on the wrong server. DNSSEC signs the real answers, and a DNS filtering service keeps users off known-bad domains even when a lookup goes wrong.

Caller ID spoofing is the phone version, and the defense is a process: call back on a number you already had, never the one that called you.

What Stops IP Spoofing

The real fix happens where packets enter the internet. In May 2000 the IETF published BCP 38, RFC 2827, with a simple rule: a network should drop any packet leaving it whose source address isn't one of its own. If every provider did that, a forged packet would die at the first router. BCP 84, RFC 3704, added unicast reverse path forwarding, uRPF, which automates the check. The router looks at a packet's source, asks which interface it would use to reach that address, and drops the packet if it arrived somewhere else. Strict mode demands the exact interface. Loose mode only asks that a route to the source exists at all.

Deployment is the gap. CAIDA's Spoofer project runs tests from volunteers' networks, and over the last year 87 of the 1,611 US client IP blocks it tested, 5.4%, still let spoofed packets out (as of October 2026). The MANRS initiative asks network operators to commit to source address validation for their customers and their own infrastructure, which is the closest thing the industry has to a pledge.

Network engineers trade notes on uRPF here, including why some run loose mode on every edge and others prefer access lists for the routing-table cost:

You can't fix your ISP, but you can apply the same rule at your own edge in both directions. Inbound, drop anything on the WAN that claims to come from your own public range, a private range such as 10.0.0.0/8, 172.16.0.0/12 or 192.168.0.0/16, loopback, or an unallocated bogon block. None of those can legitimately arrive from the internet. Outbound, allow only your own subnets as a source, so a compromised machine inside can't join someone else's flood with a forged address. One admin in the Brazilian thread above put it bluntly: "Never, ever, let a packet leave your infra that you don't own."

How to Spot Spoofed Traffic

Spoofed packets leave tells, mostly in what doesn't add up. A private or internal address arriving on the WAN interface is the clearest one, and firewalls often log it by name: Cisco ASA calls it "Deny IP spoof". Replies with no question are the next: SYN-ACKs, DNS responses or ICMP unreachable messages for traffic your network never sent mean someone used your address as a forged source, and you're seeing the backscatter.

Flow records catch the reflector side. A server that suddenly sends far more bytes than it receives on UDP 53, 123, 161 or 389, to destinations it never talked to before, is answering forged requests. A firewall flow table full of half-open connections to one network, like the thread above, is the TCP version. Flow data from NetFlow or your firewall's own logs is where these patterns show up first, and our indicators of compromise guide covers how to turn them into alerts someone reads.

What a Small Office Can Do in an Afternoon

Most of the protection a small network needs is a few switches on equipment it already owns. In order:

1. Turn on the WAN anti-spoofing options. pfSense and OPNsense call them "Block private networks" and "Block bogon networks"; FortiGate and others offer anti-spoof or uRPF per interface.
2. Add an egress rule. Only your own internal subnets may leave as a source; log and drop the rest.
3. Close the reflectors. No open DNS recursion, and no CLDAP, LDAP, SNMP or NTP answering the internet.
4. Retire address-only trust. Move admin access behind a VPN with MFA and switch SNMP to version 3.
5. Harden the switches. Enable DHCP snooping and Dynamic ARP Inspection where the hardware supports them.
6. Test your ISP. Run CAIDA's free Spoofer client from the office to see whether your provider filters forged packets.

Step three is the one that's easy to get wrong across many sites, because a service listening on UDP 389 or 161 on one forgotten server is enough. A script that lists listening UDP ports on every machine and flags 53, 123, 161 and 389 settles it in one pass. On OpenFrame that's a script run across a client's devices with the output collected in one place.

The Short Version

IP spoofing works because the source address is a claim nobody checks. It powers reflection floods, sneaks single UDP packets past allowlists, and on a LAN it becomes a hijack. Filter forged sources at your edge in both directions, close the servers that would reflect for an attacker, and let keys and MFA decide who gets in. For what to do when a flood reaches you anyway, the DDoS response guide is the next read.