Security

IP Spoofing — How It Works, How to Detect It and How to Prevent It

J Jaspreet Singh April 15, 2024 6 min read
Animated diagram for IP Spoofing How It Works, How to Detect It and How to Prevent It, showing traffic arriving at a policy wall where two flows are allowed through and two are dropped at the boundary

IP spoofing is forging the source IP address in a packet header so the packet appears to come from somewhere it did not. The IP protocol was designed with no mechanism to verify that a sender is who it claims to be, the source address field is simply data the sender writes, and nothing in IP itself checks it.

This is not an exotic technique. It is a structural weakness in IPv4 and IPv6 alike, and the entire defence rests on network operators filtering traffic at the edges.

Why Spoofing Works

When a router forwards a packet, it makes its decision using the destination address. The source address is only consulted when a reply needs to be sent. So a packet with a fabricated source address is forwarded perfectly normally, it just cannot receive a reply, because the reply goes to whatever address was written in the header.

That single consequence divides spoofing attacks into two very different families:

  • Attacks that do not need the reply, flooding, reflection, amplification. These work easily.
  • Attacks that do need the reply, session hijacking, impersonating a trusted host in a TCP conversation. These require the attacker to be on the traffic path, or to correctly predict TCP sequence numbers, which modern stacks randomise.

What IP Spoofing Is Used For

DDoS floods

An attacker sends a high volume of traffic with randomised source addresses. The victim cannot filter by source because every packet claims a different one, and cannot trace the origin because the addresses are fictional.

Reflection and amplification

This is the most damaging use. The attacker sends a small request to a public service, DNS, NTP, memcached, SSDP, with the victim’s address as the source. The service dutifully sends its response to the victim. Because the response is far larger than the request, the attacker multiplies their bandwidth:

ProtocolTypical amplification factor
DNS28× – 54×
NTP (monlist)Up to 556×
SSDP~30×
MemcachedUp to 51,000×

Reflection attacks are impossible without source address spoofing. Every one of them depends on it.

Bypassing address-based trust

Any system that authorises based on source IP alone, an ACL, a firewall rule, an “internal network only” restriction, can in principle be fooled by a packet claiming an allowed source. This is why IP-based access control is a coarse filter, never an authentication mechanism.

Man-in-the-middle

On a local segment, spoofing is usually combined with ARP poisoning to put the attacker on the traffic path, at which point the reply problem disappears and they can both read and modify traffic.

Evading logging and blocklists

Spoofed sources make logs useless for attribution and make source-based blocking counterproductive, you end up blocking the innocent address that was forged.

How to Detect IP Spoofing

  • Impossible source addresses. Traffic arriving from the internet claiming a private (RFC 1918) source, a loopback address, or one of your own internal ranges is spoofed by definition.
  • Wrong interface. A packet sourced from a network that lives on your LAN arriving on the WAN interface is spoofed. This is the basis of uRPF.
  • TTL anomalies. The TTL in a spoofed packet reflects the attacker’s real distance, not the claimed source’s. A source that normally arrives with TTL 52 suddenly arriving with TTL 118 is suspect.
  • Half-open connection floods. A large volume of TCP SYNs that never complete the handshake indicates spoofed sources, the SYN-ACKs are going somewhere else.
  • Unsolicited responses. Receiving DNS or NTP replies you never requested means someone is using your address as a reflection target.
  • Flow analysis. NetFlow or sFlow showing traffic volume from sources with no corresponding return path.

How to Prevent IP Spoofing

Ingress and egress filtering (BCP 38)

This is the single most effective control, and it is a responsibility of every network operator. BCP 38 / RFC 2827 says: do not let packets leave your network with a source address that does not belong to your network, and do not let packets in with a source address that does.

If every network implemented it, source spoofing on the internet would largely cease to be viable. The reason reflection DDoS still works at scale is that many networks do not.

Unicast Reverse Path Forwarding (uRPF)

Router(config)# interface GigabitEthernet0/0
Router(config-if)# ip verify unicast source reachable-via rx

Strict mode (rx) drops a packet unless the router’s routing table says the best path back to that source is the interface the packet arrived on. Loose mode (any) only checks that a route to the source exists at all, weaker, but usable on multi-homed edges where asymmetric routing would break strict mode.

Anti-spoofing ACLs on the edge

ip access-list extended ANTISPOOF-IN
 deny ip 10.0.0.0 0.255.255.255 any
 deny ip 172.16.0.0 0.15.255.255 any
 deny ip 192.168.0.0 0.0.255.255 any
 deny ip 127.0.0.0 0.255.255.255 any
 deny ip 169.254.0.0 0.0.255.255 any
 deny ip host 0.0.0.0 any
 permit ip any any

Applied inbound on the internet-facing interface, this drops the obvious cases.

At the access layer

  • IP Source Guard, validates a host’s source IP against the DHCP snooping binding table and drops anything else. This stops spoofing at the port it originates from.
  • DHCP snooping + Dynamic ARP Inspection, the prerequisites, and the defence against the ARP side of local MITM.
  • Port security, limits which MAC addresses may appear on a port.

Design and application-level

  • Never authenticate on source IP alone. Use TLS with certificates, tokens, or mutual authentication. IP can be one factor, never the only one.
  • Encrypt and authenticate in transit, TLS, IPsec, SSH. Spoofing without a path to the traffic gains an attacker very little against authenticated encryption.
  • SYN cookies on public-facing servers to survive SYN floods without holding state.
  • Disable or restrict amplifiers, do not run open DNS resolvers or NTP servers with monlist enabled.
  • DDoS scrubbing upstream, since volumetric spoofed floods must be absorbed before they reach your link.

IP Spoofing vs Related Attacks

AttackWhat is forgedLayerPrimary defence
IP spoofingSource IP address3BCP 38 filtering, uRPF, IP Source Guard
ARP spoofingIP-to-MAC binding2Dynamic ARP Inspection
MAC spoofingSource MAC address2Port security, 802.1X
DNS spoofingDNS response7DNSSEC, DoH/DoT
Email spoofingSender address7SPF, DKIM, DMARC

Frequently Asked Questions

Can IP spoofing be traced?

Not from the packet itself, the source address is fiction. Tracing requires cooperation from upstream providers walking the traffic back hop by hop, which is slow and rarely done outside serious incidents. This is precisely why edge filtering matters more than after-the-fact investigation.

Does a VPN count as IP spoofing?

No. A VPN routes your traffic through a server which then sends it with its own legitimate source address. A VPN router does this for every device on the network at once. Nothing is forged, the packets genuinely originate from the VPN server. Spoofing means lying about the source in the header.

Is IPv6 immune to spoofing?

No. The same header design applies. IPv6 does make some things harder, the address space defeats scanning, and IPsec support is more widely implemented, but source addresses are just as forgeable.

Can a firewall stop IP spoofing?

A firewall at the network edge can drop packets with obviously invalid sources, which handles the crude cases. It cannot detect a spoofed address that plausibly belongs to the internet. Effective prevention has to happen at the source network, which is what BCP 38 asks for.

Why is spoofing still possible after decades?

Because the fix requires action by the network that hosts the attacker, not the network being attacked. There is no direct benefit to the filtering operator, so adoption has remained incomplete, a textbook coordination problem.

JA
Written by

Jaspreet Singh

Hey! I'm Jaspreet Singh and I completed a degree in Bachelor of Computer Applications. I have 7+ years of experience in the Network & Security Domain as well as the Cloud Infra Domain. So I love to explore my technical knowledge with you.

Leave a Reply

Your email address will not be published. Required fields are marked *