Why attackers fake their source addresses
The source IP address in a packet is not verified by the network. A machine can write any value it likes into that field, and unless the operator's upstream performs source address validation, the packet is forwarded anyway. Attackers exploit this constantly, and they do it for two main reasons.
The first is reflection and amplification. To bounce traffic off an open DNS resolver, NTP server, or memcached instance, the attacker sends a small request with the victim's address in the source field. The reflector dutifully sends a much larger reply to the victim. Every packet in that flood necessarily carries a spoofed source, because the whole technique depends on lying about who asked.
The second is evasion. Even in a direct flood, randomizing the source addresses makes the traffic harder to filter. If every packet appears to come from a different IP, a defender cannot simply collect the offending addresses and drop them. The block list never converges.
This is why knowing whether traffic is spoofed is not a detail. It determines your entire mitigation strategy. So the practical question is: when a flood arrives, how do you tell whether the source addresses are real?
TTL, the field that gives spoofing away
Every IP packet carries a Time To Live value. The sending operating system sets it to an initial number, commonly 64, 128, or 255 depending on the OS, and every router along the path decrements it by one. A packet that started at 64 and arrives with a TTL of 52 crossed twelve hops to reach you.
Here is the key insight. An attacker can freely forge the source address of a packet, but the TTL the victim observes is shaped by physical reality: the initial value the real sending machine used, and the number of hops actually traversed. A flood generated by a handful of machines sitting in a handful of networks produces TTL values that cluster tightly, because there are only a few real origins and a few real path lengths, no matter how many fake source IPs are stamped on the packets.
Genuine traffic behaves the opposite way. Real visitors come from many different operating systems, on many different networks, at many different hop distances. The TTL values you observe from real traffic are spread across a wide range. That spread, or the lack of it, is the tell.
A spoofed flood can show you ten thousand different source IPs and only three or four distinct TTL values. Real traffic with the same IP count shows TTL values scattered across dozens of buckets. The source field lies. The TTL distribution does not.
How Flowtriq measures it
To turn that intuition into a detection signal, Flowtriq needs a number that captures how spread out, or how concentrated, the observed TTL values are. The right tool for that is Shannon entropy.
Entropy is a measure of disorder. If every packet you see has the same TTL, the distribution is perfectly ordered and entropy is zero. If TTL values are spread evenly across many buckets, the distribution is disordered and entropy is high. Flowtriq computes the Shannon entropy of the TTL distribution across the source IPs hitting a node, and combines it with one more fact: how many distinct source IPs are involved.
The rule is deliberately simple. When the TTL entropy is below 1.5 and there are more than 100 distinct source IPs, Flowtriq raises a spoofing flag on the incident. Both conditions matter. Low TTL entropy on its own can just be a quiet network. A large number of source IPs on its own can just be a busy day. But a large number of source IPs that nevertheless share only a tiny handful of TTL values is the precise contradiction that spoofing creates: many claimed origins, very few real ones.
A worked example
Consider two incidents, each showing roughly 8,000 distinct source IPs hitting a node. On the surface they look similar. The TTL distribution tells them apart.
Legitimate traffic surge, TTL values spread across many buckets:
TTL bucket share of packets --------- ---------------- 236-255 14% 181-200 11% 116-128 19% 101-115 16% 49-64 22% 33-48 18% => many populated buckets, high entropy (well above 1.5) => 8,000 source IPs, spoofing flag: NOT raised
Spoofed flood, TTL values collapsed into a few buckets:
TTL bucket share of packets --------- ---------------- 51-52 71% 49-50 24% 118 5% => only a few populated buckets, low entropy (below 1.5) => 8,000 source IPs, spoofing flag: RAISED
Both incidents claim thousands of sources. Only the second one is being honest about it. The first is real traffic from a real crowd. The second is a small number of machines wearing eight thousand masks, and the TTL entropy sees straight through the disguise.
What to do once spoofing is detected
The reason this flag is worth surfacing the instant detection fires is that it changes what you should do next.
If the source IPs are real, per-IP mitigation is on the table. You can collect the worst offenders, drop them at the host firewall, or feed them to a block set, and the attack actually shrinks.
If the source IPs are spoofed, per-IP mitigation is a trap. Every address you block was never going to send you another packet anyway, and the addresses you are blocking may belong to innocent third parties whose addresses were borrowed. You will burn time and firewall capacity for nothing. The correct move is to mitigate on properties the attacker cannot cheaply forge:
- Protocol and port. A spoofed UDP amplification flood is still, unmistakably, UDP traffic from a specific reflection port. Rate limit or drop on that.
- Packet rate and shape. Spoofed floods often have a tight, machine-generated profile you can police.
- Upstream filtering. When the volume is a transit problem, escalate to BGP FlowSpec or RTBH so the traffic is dropped before it reaches you, rather than fighting it at the host.
The spoofing flag, in other words, is the signal to stop building a block list and start working the protocol and the path.
Where it fits with the rest of classification
Spoofing detection does not work alone. It sits alongside the other signals Flowtriq attaches to every incident. Per-IP confidence scoring rates how suspicious each individual source looks across eight weighted factors. Botnet detection flags an incident when it sees more than 300 distinct source IPs, which points at a different kind of attack: a real, distributed set of compromised machines rather than a spoofed few.
Read together, these signals describe the adversary. Many sources with high TTL entropy and high confidence scores looks like a genuine botnet. Many sources with low TTL entropy looks like a spoofed flood from a small origin. The mitigation you reach for is different in each case, and the classification tells you which case you are in before you have lost any time guessing.
Know whether a flood is spoofed the moment it starts. Flowtriq classifies every incident with TTL-entropy spoofing detection, per-IP confidence scoring, and botnet identification, within the same second as detection. Start a free 7-day trial at flowtriq.com/signup.