I wrote last week about Trinoo, the first widely-discussed distributed denial of service tool. Reading the analysis carefully, one thing stood out: many of the attack types Trinoo can launch — including the UDP floods I described — are made possible by spoofed source addresses. The daemons send packets that claim to come from random IPs, often from inside reserved or unallocated ranges, to make filtering at the receiver side impossible.
The defence against this is so cheap and so simple that the fact we do not do it more widely is genuinely surprising. It is called egress filtering, or sometimes BCP 38. I want to write about what it is, why it works, and why every operator's network ought to do it.
What egress filtering is
Ingress filtering — what most people mean when they say "firewall" — is filtering packets coming in to your network. You decide what is allowed and what is not, based on source, destination, port, protocol, and so on.
Egress filtering is the same idea applied to packets going out of your network. You decide what your own users are allowed to send to the internet.
The simplest, most useful form of egress filtering is source-address validation. Any packet leaving your network with a source IP that does not belong to your network is dropped. If your block is 192.0.2.0/24, only packets with source addresses in 192.0.2.0/24 are allowed out.
This sounds trivial, and in implementation it is. A typical ipchains rule for it on a single-block site is:
ipchains -A output -i ppp0 -s ! 192.0.2.0/24 -j DENYFor a larger ISP, the rule is similar but the address ranges are bigger and possibly there are several. The principle is identical.
What it prevents
Several things, all of them important.
Spoofed-source DoS. Most denial of service tools, including Trinoo's UDP-flood variants, rely on the ability to use any source address they like. The defender cannot identify or filter the source. Egress filtering at the attacker's network would force the attacker to use real, traceable source addresses — which makes the attack vastly less useful for them and vastly easier to defend against.
Smurf and reflection attacks. A smurf attack sends ICMP Echo requests to a broadcast address with a spoofed source set to the victim. Every host on the broadcast domain replies to the spoofed source. The victim is hit with thousands of replies for each request the attacker sends. The amplification factor is typically 50x to 200x. Smurf does not work if the attacker cannot spoof the source. Egress filtering prevents the spoof.
Source-spoofing for stealth. Some attacks rely on the attacker's source being wrong so that defenders cannot track them. A scanning attack that uses random source addresses is harder to identify and block than one that uses a real address. Egress filtering forces real addresses.
In each case, the attacker's network is the right place to apply the filter, because that is where the attacker's address is known. The attacker's ISP, more than anyone else on the internet, knows that this packet really did come from the customer it claims to come from — they assigned the IP and they handle the routing. The filter is one rule. It costs effectively nothing to apply.
Why we do not do it
The technique has been documented for years. RFC 2267 and its successor BCP 38 spell out the recommendation in detail. Adoption is patchy. The reasons are:
It is the operator's cost for someone else's benefit. The operator who applies egress filtering bears the (small) operational cost of the rule, but the benefit accrues to other operators on the internet who no longer get spoofed-source attacks from this one's customers. The operator gains no direct value. There is no commercial pressure on them to do it.
It can occasionally break things. A customer's network with multiple uplinks might legitimately use source addresses from outside the local block, depending on routing. A filter that requires source addresses to match the local block can break those configurations. This is rare and easily diagnosed, but "rare and easily diagnosed" still means support tickets, which means costs.
It is invisible when working. A correctly applied egress filter that prevents a spoofed-source attack produces no visible signal. The attack does not happen. The operator never knows. There is no positive feedback loop.
The standard does not have teeth. BCP 38 is a recommendation. There is no enforcement mechanism, no certification, no contractual obligation between ISPs to apply it. Each operator is free to ignore the recommendation, and many do.
What an individual operator can do
For your own network, the answer is straightforward: apply egress filtering. The cost is one firewall rule. The benefit is that you are not contributing to the problem.
For a multi-homed network, the rule has to allow the source-address ranges from all your uplinks; the filter is still simple, just slightly larger.
For a network that hosts third-party services (a co-location facility, for instance), the filter has to be more careful — you do not want to block legitimate traffic from hosted customers — but the principle is unchanged. The filter should allow exactly the source addresses assigned to each customer, and reject everything else.
The operational discipline is positive specification: filter against the address space you have assigned, not against "obviously wrong" sources. If you start writing rules to drop packets from the broadcast addresses, the loopback addresses, the reserved Class E ranges — you have a list that gets longer and is always incomplete. Filter for the addresses you expect; drop everything else.
What needs to change at the protocol level
For egress filtering to become universal, something would need to change. The most likely paths:
Peering pressure. Larger ISPs could start requiring smaller ISPs to apply egress filtering as a condition of peering. This is a contractual mechanism. It would work if the larger ISPs were willing to enforce it.
Reputation systems. Networks that emit spoofed-source traffic could be identified and given lower priority by other networks. This requires measurement infrastructure that mostly does not exist.
Regulatory pressure. In some jurisdictions, ISPs are starting to face questions about their role in attacks originating from their networks. This is an early-stage trend; it might mature into a real obligation over time.
None of these are fast. The quickest is the first, and even that depends on the largest operators making it a priority.
A small reflection
The interesting thing about egress filtering is that it is cheap, well-documented, and not adopted. The same is true of many small security improvements. Default-deny firewall rules. Strict argument validation. Disabling unused services. Patching promptly. Each is a small cost; each is a meaningful improvement; the aggregate of all of them, applied universally, would change the internet's threat landscape considerably.
The gap between what we know to do and what is actually done is, I increasingly think, the most interesting question in security. The technical answers are usually known. The organisational and economic mechanisms by which those answers are or are not implemented are where the discipline gets hard.
For egress filtering, the cost is so low that the only excuse is inertia. I would like, over the next year, to see some of the larger operators take it up as a public commitment. The commitment would matter more than the rule.