What is IP spoofing?

Every IP packet starts with a header that contains, among other things, a source address and a destination address. Routers read only the destination; they forward the packet toward it and never verify that the source field names the machine that actually sent it. The Internet Protocol was designed in the late 1970s for networks that trusted each other, and the source field is simply whatever the sender wrote there.

IP spoofing is writing something false in that field. A machine at 198.51.100.7 crafts a packet claiming to be from 203.0.113.42 and sends it. The destination, and every router on the way, takes the claim at face value. Any reply goes to 203.0.113.42, which never asked for it. That one property, replies go to the forged address, is what makes spoofing useful to attackers and useless for ordinary two-way communication.

It is worth separating from things that sound similar. Spoofing is not changing your IP address: a VPN, proxy or new DHCP lease gives you a real, routable address that replies can reach. It is also distinct from the other spoofing families, such as email spoofing (a forged From header), ARP spoofing (lying about which hardware address owns an IP on a local network) and DNS spoofing (forged answers to name lookups), which attack different layers.

Crafting a packet with a chosen source address takes a few lines of code and raw-socket access, which any administrator of a machine has. The hard part is not sending; it is that the sender never sees the response.

For UDP that does not matter. UDP has no handshake: a single packet is a complete request, and a DNS server, an NTP server or a game server answers whatever it receives. Spoofed UDP is therefore trivial, and it carries almost all real-world spoofing traffic.

For TCP it matters a great deal. A TCP connection begins with a three-way handshake in which the server sends back a random 32-bit sequence number that the client must echo. An attacker who forged the source address never receives that number and cannot complete the handshake. Modern systems randomize initial sequence numbers (standardized in RFC 6528) precisely to block the blind guessing that made early spoofing attacks possible. What an attacker can still do with spoofed TCP is send the first packet of the handshake, the SYN, over and over: the server allocates resources for each half-open connection and replies to addresses that never answer. That is a SYN flood.

Reflection and amplification DDoS

The attacker sends small requests to thousands of open servers with the source address forged as the victim's. Each server sends its reply, often many times larger than the request, to the victim. The victim is buried under traffic from legitimate servers that are merely answering what they believe are legitimate questions.

How much bigger the reply is than the request is the amplification factor, and the published figures explain which protocols attackers prefer:

Memcached reflection drove the 1.35 terabit-per-second attack on GitHub in February 2018, the largest publicly reported at the time; NTP reflection drove the record attacks of 2014. Both were possible only because spoofed packets could leave the attacker's network.

SYN floods and other direct floods

Spoofing the source of a flood does two things: it hides where the flood comes from, and it defeats the simplest defense, blocking the sender's address, because every packet appears to come from a different random address.

Session hijacking and trust exploitation

The classic case is the 1994 attack on Tsutomu Shimomura's systems, attributed to Kevin Mitnick, which combined predictable TCP sequence numbers with spoofed packets from a trusted host to inject commands into a session. Random sequence numbers and the disappearance of address-based trust (the rlogin and rsh era) have made this impractical on the open internet, though it survives on local networks where ARP spoofing lets an attacker see the traffic.

Evading logs and filters

Port scans and probes sent with a mix of real and decoy source addresses make it harder for the target to tell which address is the actual scanner.

Spoofing cannot be fixed at the victim, because the packets arriving there are indistinguishable from legitimate ones. It is fixed at the source, by networks refusing to forward packets that lie about where they are from.

• Ingress filtering (BCP 38, RFC 2827). Published in 2000, it asks every network to drop outbound packets whose source address does not belong to that network. A home ISP knows which addresses it assigned to its customers; a packet from a customer line claiming to be 203.0.113.42 when that block is not the ISP's should never leave. If every edge network did this, spoofing would be impossible.
• Unicast reverse path forwarding (uRPF, BCP 84). The router-level implementation: for each incoming packet, check whether the router would route a reply to that source address back out the same interface. If not, drop it. RFC 8704 (2020) refined it for networks with multiple paths.
• MANRS and the Spoofer project. The Mutually Agreed Norms for Routing Security ask operators to commit to anti-spoofing, and CAIDA's Spoofer project measures who actually does it by sending test packets from volunteer machines. In the most recent year of its data, roughly one in five tested IPv4 networks still allowed spoofed packets out.

At the receiving end, detection is about anomaly rather than proof: a flood of replies to requests you never sent, TTL values that do not match the claimed source's distance, packets from addresses that should not be routable at all (private ranges, your own addresses arriving from outside). Firewalls drop the obviously impossible ones by default; the rest is handled by DDoS scrubbing services that absorb and filter the volume.

You can also stop your own equipment from being a reflector. Close UDP services that do not need to face the internet, disable SSDP and UPnP exposure on the router's WAN side, and run the port checker against your address to see what still answers from outside.

People searching for how to spoof my IP usually want to appear to be somewhere else, and that is not spoofing. A VPN or proxy gives you a different real address: the server's. Websites can reply to it, your pages load, and the only thing hidden is your original address. Spoofing gives you a forged address that cannot receive replies, so you could not load a single page with it. One is a tool for privacy; the other is a tool for one-way attacks.

The proxy and VPN checker shows whether an address is recognized as a VPN, proxy, Tor exit or data-center address, which is the question services actually ask when they talk about spoofed locations.

If you are seeing traffic from an address you do not recognize, or your own address is being accused of something you did not do, look it up. The IP fraud score combines blocklists, proxy and VPN ranges, hosting ranges and botnet feeds into a 0 to 100 score with every reason listed. A spoofed packet carries a forged source, so the address in your log may belong to an innocent third party; a reputation lookup that comes back clean for an address that is apparently attacking you is itself a hint that the source was forged. The blacklist check covers the abuse lists specifically, and the IP lookup shows the owning network, which is where abuse reports should go.