Tribe Flood Network — the second of this year's notable DDoS tools — has been visibly evolving over the past four months. The version that has been described in recent analyses is meaningfully more capable than the one I first wrote about in summer, and the trajectory is more interesting than any single capability.
I want to write about the evolution because the shape of the change tells us something about how this category will mature.
What TFN was, originally
The original Tribe Flood Network was very similar in architecture to Trinoo: an attacker-controlled master, controlling many compromised daemons, with the daemons performing the actual flood. The differences from Trinoo were modest:
- TFN supported more flood types: ICMP, SYN, UDP, and Smurf-style amplification, where Trinoo was UDP-only.
- The control protocol used ICMP rather than UDP, which made it harder to block at typical firewall configurations.
In practical terms, both tools were equivalent in effect. The choice between them was probably a matter of which the attacker happened to have. The architecture was straightforward and the implementation, by the standards of working malware, was crude — passwords were hard-coded, communication was unencrypted, identifying strings were embedded in the binaries.
What the new variant adds
The analyses circulating now describe a meaningfully more sophisticated tool. The improvements:
Encrypted control channel. Master-to-daemon communication is now encrypted with a symmetric cipher (the analyses suggest Blowfish) using a configurable key. This means firewalls and IDS rules cannot identify TFN traffic by simple pattern-matching; the payload is opaque.
Decoy traffic. The control channel can be configured to send dummy packets at a steady rate, so the volume of master-daemon traffic stays roughly constant whether or not an attack is active. This frustrates the technique of "watch for unusual outbound traffic from the daemon hosts".
Multiple control protocols. The new variant can use ICMP, UDP, or TCP for control. The choice can be configured per daemon, so a single command-and-control deployment can use a mix that adapts to whatever filters are in place.
Better flood techniques. The flood algorithms are more efficient — fewer packets per second produce more impact at the target. There is also support for spoofed source flooding, where each packet's source address is randomised, frustrating any per-source filtering at the receiver.
Stealth installation. The daemon installation process modifies system binaries to hide the daemon from ps, netstat, and similar tools. This is the standard rootkit technique. It means that a victim of the daemon — the operator of one of the compromised hosts — cannot easily detect the daemon's presence with the usual diagnostics.
What the trajectory says
The specific improvements above are interesting individually. The pattern they collectively show is more interesting.
The original TFN was just enough to demonstrate the concept. The new variant has been engineered with the defenders in mind. Every change addresses a defensive technique that was useful against the original:
- Pattern matching ↦ encrypted control channel.
- Outbound-traffic anomaly detection ↦ steady decoy traffic.
- Single-protocol filtering ↦ multi-protocol control.
- Per-source filtering at the receiver ↦ source spoofing.
- Daemon detection on victim hosts ↦ stealth installation.
This is the offensive community in engineering response to the defensive community. The offensive engineers have been reading the Trinoo analysis, the original TFN analysis, the Snort rules being written, and have specifically improved their tool against each defensive measure.
This is, in some sense, the natural shape of any adversarial system. The attackers respond to the defences. The defenders respond to the attacks. The cycle continues.
What is striking about the speed is that it is months, not years. The defensive measures against Trinoo are six months old. The TFN response is here. The next iteration of defensive measures has not yet been deployed and the next iteration of offensive tools is presumably already in development.
What this means for the next 12 months
A few predictions, in the spirit of calibrated humility:
There will be at least one more public DDoS tool by spring 2000. It will be more sophisticated than the current TFN variant. It will probably have a name and a public analysis within a week of emerging.
One of the early-2000 tools will hit a high-profile target hard enough to be news. A major commercial site, taken offline for hours. The threshold for press coverage of these incidents is low and the tools are clearly approaching the capacity to hit it.
The offensive engineering will continue to outpace the defensive engineering. The reasons are structural: offensive tools are built by small teams optimising for one outcome (effective attacks); defensive tools are built by larger teams compromising between many objectives. The asymmetry favours the offensive side.
The defensive response will eventually be at the network and protocol level. Operator-by-operator hardening is not going to keep up. Some kind of coordinated upstream filtering, or protocol-level source-address validation that is actually deployed widely, will become the meaningful defence. This will take years, but the pressure to make it happen is building.
What I am doing about it
For my own infrastructure: nothing new beyond what I already wrote up. The defensive measures I can apply at my scale do not improve much against more sophisticated attack tools — the limit is bandwidth and upstream relationships, not technique.
For the broader question, I am paying attention to two things:
Whether BCP 38 deployment is starting to accelerate. The pressure for source-address validation across major operators is the clearest available lever to make these attacks structurally harder. If the major operators start enforcing it, the tool authors lose their ability to spoof sources, and a lot of attack types become less effective.
Whether some kind of inter-operator coordination protocol emerges. The current model — phone calls between named contacts — does not scale. Some protocol for authenticated, low-latency "these IPs are attacking me, please filter" communication is the obvious next thing. Nothing fits the bill yet. By 2002 something will.
More on this as the trajectory becomes clearer. The discipline I keep returning to is to write predictions down and score them later — not because they are reliable, but because the gap between what I expected and what happened is itself the thing that makes the next prediction better.