This isn't about real firefighters using the Internet, it's about dealing with our current Internet fires - Spam, Distributed Denial of Service (DDoS), Viruses and Worms. Each of these problems periodically break out in large or small areas, and impact companies and individuals alike.
How and why this happens is well known - a few people, mostly young males, for one or more reasons, will take easily used attack programs and spread them through the vulnerabilities of the Microsoft Monoculture. Fixing this problem through upgrades and patches isn't going to solve the problem anytime soon. More on the Microsoft issues in another article.
Mostly, fighting these outbreaks has been through human monitoring and cooperation between ISPs and companies that are affected. This is a slow process with a high overhead, hard for ISPs to justify unless the problem is large.
Efforts are being made by various companies to provide software to either protect, patch or cure the systems being attacked. Their responses are behind the curve except in rare instances. This is primarily because they must react to new attacks rather than prevent them, not because they fail to make enough effort.
Currently, Internet fires (Spam, Viruses, Worms and DDoS) are being fought by reactive software and actions, and proactive efforts in new software designs that will prevent current firestarter techniques from working. Between the incomplete coverage of reactive techniques and the long lead time of proactive techniques lies a huge gap of vulnerability that we handle on a mostly ad hoc basis. We need to do better.
I've thought about parts of this problem for some time, but not until recently did I see how the big picture might be changed. I learned from the actions of real firefighters. Real firefighting has a much longer history than the Internet and they have developed a system, a strategy, to deal with fires.
In broad terms this is their strategy:
In modern buildings, the first two steps are automatic, and may be supplemented by manual operation. In addition, building sprinklers are also automatic, initiating step 4. These three things are the most important steps in dealing with a fire. We have no automatic equivalents on the Internet.
Early and fast response to a fire is the biggest variable in how much damage is done. Small fires are easily put out, large ones much harder. The primary purpose of sprinklers is to limit the spread of a fire, and put it out if possible. But keeping it small is the critical difference that sprinklers make.
We need to do the equivalent on the Internet. It may not be as difficult as you think.
Fire alarms detect a temperature, smoke or ionization threshold being exceeded. How can we build their equivalents?
The first line of defense on the Internet is the firewall, a dedicated computer that can filter TCP/IP streams and prevent bad packets from getting through, as a minimum. Firewalls can do many other things as well, but that's not the main issue here. Detecting worms and spam is a problem for the mail processing, but DDoS attacks need to be detected at the firewall.
DDoS attacks can be determined by counting bad (and abandoned) packets per unit time and setting a notification when they go over a threshold. This is the fire alarm.
Even though DDoS attacks may come from thousands of addresses, tracking this can be done with 8 bytes for each address - an Internet address and a 32 bit counter. This is the beginning of a sprinkler. When a specific address exceeds another threshold, packets from that address are dropped without further processing. Over time, the top byte or two of the attack addresses will fit in a number of ranges, simplifying the processing and providing the input to the next step.
Once address ranges become clear, the next step is to determine which ISPs manage those addresses, and automatically send a data stream to the appropriate ISP about those addresses which are taking part in the attack. That data stream could, with authorization, automatically disable those addresses which are producing the packets and begin to shut off the attack, system by system, ISP by ISP.
This is step 4 in the firefight - containment. Once contained, owners of the systems can be notified and required to clean out the worm before access to the Internet is restored. That will finally extinguish the fire.
The interesting part of this proposed process is that it can (and probably should) be totally automated. Thus the Internet becomes an adaptive mechanism to misuse of its facilities, quenching attacks quickly in their first stages and preventing big fires.
Clearly this can't be done overnight, and there will be steps taken by the creators of worms to hide their origin, but those problems can be solved.
Viruses and worms are vulnerable in certain stages of their delivery to detection, containment and extinguishing. When mail is delivered to an ISP or IMAP mail system, it is handled as an object regardless of its contents. It must reach the user intact for its payload to work.
This actually has an easy first stage solution. At the incoming mail stage, all mail that is executable, both HTML and attachments, can and should be passivated. The execution capability should be disabled automatically with no exceptions, and a message added at the top that this was done. That message can point to instructions on how to restore the execution, if desired.
HTML can be left turned on, but Javascript, Java and other internal executable or calling processes should be disabled. Obscuring comments should be removed so the remaining text is clear. Background color text, used to confuse spam detectors, should be removed. The passivated email can now be safely delivered.
Since the default email delivery is now harmless without outside assistance, clueless users will stand out from the crowd and either learn better or find less challenging employment. Worm and virus attacks will diminish greatly, mourned only by the malefactors and the antivirus companies.
TCP/IP, designed in quieter times, has an unfortunate loophole. It is quite possible to put a false source address in a packet and disguise the origin of attacks and the controllers of attacks. This loophole can be closed in two steps, the first one quite quickly.
The first step in closing this hole is done at the ISP level. Since the ISP (or company) is the source of all traffic, any packet source address arriving at the ISP that does not match the top 24 bits of the physical equipment that the data came in on can be quietly noted and dropped. If the count exceeds a threshold for bad packets, that subrange can be checked by pinging to see who is on line, and where packets are coming from by elimination.
The second hole is the inability to trace packets back to their origin because the intermediate delivery steps leave no trail. This will take more time to solve, but the solution is, in principle, simple.
We need to add a 'Last Link' to the TCP/IP package, carrying only the previous processing source address. This address can be ignored 99% of the time. When the fire alarm travels out from the source via the process explained earlier, these back trace links get saved on disk.
With supporting software, ISPs can quickly and easily trace this trail of links back to the source of the problem. Corrective actions can be taken and once again, a small fire proves easier to extinguish.
I skipped, but did not overlook, the issues of security and cooperation that will be required to make this scenario work. However, what I want to cover first is the question of coverage.
It is easy to think that this technique will be ineffective until we reach 95% or 100% coverage, and because a number of foreign countries are unlikely to cooperate, we shouldn't bother to start. Not only is this assumption wrong, the failure to start is just plain foolish. Because we can't be perfect, we shouldn't try? Quite the opposite.
Even with 25% coverage, we will have a significant effect. Especially within the US, pressure from users and companies will force cooperation at reluctant operations. The ISPs who openly support spammers and profit thereby will either cooperate of find themselves filtered out of the Internet.
First amendment freedom of speech does not extend to yelling fire in a theater, per the Supremes. I expect this principle will cover the misuse of other avenues of free speech, such as the Internet.
Cooperation is a bit of a red herring. Some of these tools can be implemented by individuals in their own systems, gaining them an immediate advantage. Most technical people and many operational people will see the advantages to be gained and support the building and use of the tools described here.
As these tools become tested and a standard part of the Internet support, usage will broaden to include the majority of companies and ISPs. Then the weight of the majority will speed the reluctant along the same path. Holdouts will find themselves in an increasingly awkward and unprofitable position.
There will be countries who see a benefit in misuses of the Internet, but there won't be much effect if their efforts are filtered, passivated or blackholed out of existence. Futile attacks are not rewarding to the attacker. Time, effort and money expended for no result can only be sustained by fanatics. They can be locked out.
Countries denied access to large segments of the Internet will find it difficult to be competitive and maintain their economy. Ultimately, the economic effects of limited access will force compliance without any other action on our part, except perhaps to point out this fact.
This is something that will need to be part of the design process. Clearly we can't let the proposed tools be hijacked by the people we are trying to control. This should not be a big problem if it is addressed from the start.
Already in standard use are a number of good encryption tools and secure protocols. The critical links are the firewall to ISP and ISP to ISP authentication and authorization. Only those firewalls with validated software and known operators can be enabled to set the ISP alarms off.
This will include operating from a fixed IP address, key operational personnel known to the ISP, specific secure protocols and unique keys assigned and changed on a regular basis. None of this is rocket science, but it does require some careful analysis and good procedures to be put in place.
The potential for misuse of this security is small. It would be possible for the government to use the back trace capability to track anonymous users and others, but they already have much that is needed to do this. It might be easier, but because there will be specific protocols and records, harder to hide. The net tradeoff is unclear.
Neither is firefighting. That doesn't prevent us from trying our best to prevent fires through safety measures, limit their outbreak by early detection and sprinklers, and rally forces for those larger conflagrations. Nor should it prevent us from putting these ideas into practice as soon as possible.
Some of these ideas can be implemented in a week or two. The idea of turning all executable attachments off is a trivial addition to current email scanners. The passivation of HTML mail is already a standard function of the KDE mail agent KMail. It displays HTML as text and adds a warning message plus a key to turn the HTML on.
It doesn't do the other stripping I defined, but that could be added. In place of expecting users to be more careful, making our systems smarter is likely to work better and happen faster.
Those people determined to harass and destroy what they cannot control will take counter actions to defuse the tools, avoid their detection, and deliver payloads past the passivation process. Then we will improve our tools, update our systems and gain control over the new attacks. This cycle will repeat just as the military offense and defense have reacted to each other for millennia.
However, there will be a big difference from the current situation. The good guys are in the position of using muzzle loading rifles against a Gatling gun. Specifically, the creators of worms and viruses are cooperating, using the automation tools of the Internet against it, while the defenders have few tools and little cooperation.
Once the tools gain even a 10% foothold, the tide will start to turn. When we can demonstrate to the sceptical that these things work well enough to weaken the attacks, rapid adoption will follow. This will be pulled by the folks on the front lines - Internet administrators, and pushed by those paying for the damages - the companies.
The troublemakers will find their rewards diminished and the risks substantially increased, and this will deter many of the casual attackers. Reduced attacks from them will make the serious attacks easier to find.
As the leverage passes from the attacker to the defenders, it will accelerate the process of adoption - closing loopholes and prosecuting the attackers, removing them from Internet access. We can and will win this war by building better tools and wide cooperation.
Keep in mind that fires make the news because they are the exception, not the rule.
[30]