In computer security, a Trojan is a program that contains hidden malicious code. Tools circulating on the Net allow code to be added to any program file to turn it into a Trojan. When the modified program is run, the extra code runs in the background.
Before the Internet, the worst a Trojan (aka virus) could do was to “trash” the infected machine: delete a few files, write rude messages, make some noise. Machines with access to the Internet provide the attacker with much more scope for exploiting the captured machine. Installing a “backdoor” program allows the attacker to control the machine remotely. He can install any program he wants, open or close the CD drawer, or even turn on a video camera to watch the user if there is one.
A machine under control of an attacker is known as a bot. Controlling a bot allows a range of malicious actions to be performed.
Cover their tracks.
Attempt to take over other machines.
Perform a denial-of-service attack.
Send spam.
Perform premium rate fraud.
The scope for malice increases considerably with the ability to control multiple bots. A network of bots is known as a botnet. A problem such as breaking a password that might take a year on one machine can be completed in half a week on a botnet with 100 machines.
Self-described “elite hackers” claim control over networks of thousands or even tens of thousands of machines. Such claims need to be taken with some caution: Although there are certainly some large botnets in existence, most are small, and it is not a trivial matter to create or manage a large botnet.
Gaining control over a machine is only the start. The attacker must fend off attacks from others as well as the owner’s efforts to restore control of his own property. Wars between botnet operators are common.
The commands supported by a common botnet control program give a good indication of their use.
Check a credit card number.
Perform denial-of-service attack on another machine.
Scan another machine for vulnerabilities.
Create an encrypted connection to control another compromised machine.
The use of botnets makes tracing an attacker more challenging. An attack might be distributed over a series of machines rather than coming from a single source. For example, the attacker might try a “port scan,” attempting to connect to each TCP/IP port reserved for system use (port numbers 1 through 1023). An attack coming from a single location is easily detected, and the firewall protecting the target can block further connection attempts from a source after a certain number of failures. The attacker can bypass a limit of 10 connection failures by making the attack through a network of 100 machines (see Figure 9-1).
Biological diversity is an effective protection against biological disease. My parent’s house is on a wooded riverbank. The woods once had horse chestnuts and elms. The horse chestnuts still stand, but there are no elms anymore. Almost every elm in Europe died in less than a decade, killed by Dutch elm, a fungus growing underneath the bark. Unlike most trees, elms do not produce nuts; they spread through shoots that emerge from the roots. This allows the shoots to concentrate on outgrowing their competitors for the light at the roof of the forest. Unlike a tree that grows from a seed, each shoot contains an exact copy of the genetic material of the parent. If one member of an identical population is vulnerable to a disease, then so is every other.
More than nine out of ten computers in use today run a version of the Windows operating system. There is almost no diversity in the computing gene pool, a fact that is sometimes pointed to by advocates of one of the platforms making up the minority 10 percent as being a security issue.
Like many advocacy arguments, the diversity argument is superficial. Every organism produced by sexual reproduction is genetically unique (except for identical twins). Every computer system with the same operating system software installed is essentially identical. A hundred operating system platforms would not come close to matching the diversity of biological systems. The advocates want to move from one platform to two or three, an insignificant change.
Nor is diversity particularly successful as a survival strategy for the individual organism. We get sick; we die. Diversity serves the survival of the species, not the individual. Biological viruses adapt their attack strategies slowly through the process of Darwinian evolution. Computers are not biological organisms, and viruses are the product of human intellect and follow the Lamarkian pattern of evolution, otherwise known as intelligent design.
There is, however, an advantage to using a minority platform, albeit a small and diminishing one. Platforms with few users are a less attractive target for the professional criminal than those with many users.
This was particularly the case with old-style viruses, which spread through the power of exponential growth. A virus infecting twice the number of machines with each successive generation will grow rapidly, reaching a million machines in 20 generations. A virus that spreads to an average of less than one machine per generation will quickly become extinct. A virus attacking a minority platform with one-tenth the market share of the market leader must be ten times more potent.
Modern viruses do not spread exponentially; indeed, they are not analogous to a biological virus in any meaningful sense. Modern virus attacks are blasted out from a botnet at rates of ten million an hour or more. An attacker who targets a minority platform will capture fewer machines, but the machines caught might be more valuable. Users of minority platforms are more likely to have high-power machines connected to fast Internet pipes. After they are captured, it is less likely that the attacker will face competition from another attacker.
Prevention is better than cure. If the botnet problem is to be controlled, we must make it as difficult as possible for the criminals to recruit new machines.
There are two principal strategies for infecting a machine: The attacker can look for a bug that allows him to bamboozle the machine into running code that it should not, or he can try to bamboozle the user into causing the code to run by disguising it as a Trojan.
Computer systems always had bugs and probably always will. Advanced programming techniques called formal methods allow a program to be proven correct with respect to a specification. But this leaves us with the problem of bugs in the specification.
The Internet criminal requires a specific type of bug, a bug that allows him to gain control of a machine by sending it a particular stream of data, not merely the type of error that results in a minor annoyance such as the £2.3 trillion ($4.4 trillion) electricity bill one man recently received in the UK.1[1]
Engineers argue over which computer, which editor, which operating system is best the way sports fans argue over their teams. Inevitably, security is recruited as an argument.
We trust what is familiar to us. I remember when traditional mainframe folk would criticize VMS as lacking the security features necessary for “serious corporate computing.” Later VMS folk derided UNIX in the same terms. The current argument between UNIX and Windows advocates does not differ in either form or substance.
The number of security vulnerabilities is irrelevant; the attacker only needs one to succeed. Much more important is how widely the vulnerability is known and how quickly a vendor fixes known security issues.
Many bugs could compromise security in principle but, in practice, one class of programming error has dominated reports of security vulnerabilities for more than a decade: the buffer overrun.
The basic principle of the buffer overrun was described by Aleph1 in a 1996 article in the hacker magazine Phrack called “Smashing the Stack for Fun and Profit.”[2] The basic idea is to send the targeted computer an unexpectedly long sequence of data. If the programmer has not handled this properly, the sequence of data can be written right past the end of the data storage area, corrupting the memory location where the computer stores a particularly important piece of information, the address of the next program instruction to execute. This allows the attacker to gain control over the machine.
Bugs might be inevitable, but buffer overrun bugs are not. FORTRAN, the programming language of the 1960s and 1970s, had bounds checking built in to prevent buffer overrun conditions. State-of-the-art programming languages such as Java and C# have memory management techniques that prevent buffer overrun conditions.
What is now understood to be common sense was largely ignored during the 1980s until Java appeared in the mid 1990s. All the major operating systems in use today are written in either C or C++, languages that regard preventing buffer overruns to be the task of the programmer rather than the computer.
None of the computer systems we use today has really been designed for use on a global computer network that can be accessed by anyone in the world.
Although buffer overruns are the most common type of exploit, they are not the only type. Programmers like to add features to programs, particularly features that appeal to programmers, such as the ability to write programs. This is the reason that I can in theory write a chess program in Excel or Word, a capability that I find entirely mystifying. Nor is this an area where UNIX fans can claim superiority. It is not only possible to write a chess program in the UNIX program editor emacs, but there are people who consider emacs a natural platform for writing a chess playing program, and emacs users have several to choose from. You can even have two copies of emacs play each other over the Internet.
The problem with programs that provide this level of flexibility is that it is difficult to be sure that it does not provide an entry point for a Trojan. It is a bad thing if you open a spreadsheet and find that everything on your hard disk has been erased.
The only way to be certain that a machine is never compromised by a network attack is to disconnect it from the network entirely and make sure it never sees a USB memory stick or CD-ROM. This provides a high level of security at the cost of significantly reduced functionality. Machines used for exceptionally security-sensitive tasks are often configured this way, but most users need the network to do their jobs.
A firewall provides a better compromise; unnecessary network functionality is disabled and only functions that are necessary and acceptably safe are allowed.
Firewalls use a variety of techniques, but one of the most useful is to differentiate between communications that are initiated inside the protected network and those that are initiated outside.
Acting as an initiator is inherently less risky than acting as a responder. If you are the initiator, you control when you communicate and who you communicate with. If you are the responder, you lose that control. Blocking incoming communications significantly reduces the degree of risk for the user.
Today there are two basic types of firewall in common use. A border firewall is a device that patrols the connection between a local network and the Internet. A personal firewall is a program that runs on a computer and controls the network connections of just that machine (see Figure 9-2).
Firewalls are an effective but not infallible security measure. Some people treat a firewall as if it was a magical amulet that makes the wearer invincible. These people tend to end up in the same sort of situation that a lot of drivers of 4-wheel drive vehicles end up in each winter here in Massachusetts. Each winter, half the cars I pass buried in snow drifts are 4-wheel drive machines driven by overconfident drivers.
Firewalls are a perimeter security measure. A fence can stop the bad guys from getting out (or in) but cannot do anything about the bad guy who manages to sneak around it. Many of the most serious enterprise security problems come from inside the network. The biggest security threat for an enterprise is almost always the disgruntled (or merely corrupt) employee who is upset about not getting a promotion or having alimony deducted from his paycheck or for any other reason he might choose, justified or not.
A firewall is not even a fence; it is more like a gate with a gatekeeper. A gate is only as good as its gatekeeper.
Managing enterprise firewalls is a complex task that is increasingly being outsourced to specialist “Managed Security Services” providers. It is unusual but not exceptional for an engineer auditing the existing firewall configuration at a new customer site prior to bringing the systems under management to discover that a firewall has been configured to allow any traffic through in either direction. Instead of buying a hundred thousand dollar firewall, the customer could have achieved the same effect with a five dollar cable. This is usually the result of the firewall being “temporarily” short circuited to diagnose some sort of network problem, such as deployment of a new project. After the project is up and running, victory is declared, and nobody remembers to restore the firewall.
A high-capacity enterprise firewall installation can cost hundreds of thousands of dollars. For home use, a device called a cable/DSL router, also known as a NAT box, does an adequate if less than ideal job for $50. Most “WiFi” access points used to set up a wireless network support this feature.
If you have a high-speed Internet connection, you should get a NAT box. A NAT box does not provide perfect security, but there is no other security tool that costs less than $50 that does as much. If you have a laptop computer, you can pay a few dollars more for a wireless router that allows you access to the Internet from any room in your house. Just make sure you turn on the encryption feature, for reasons we will return to shortly.
The primary purpose for which cable/DSL routers are sold is to share one high-speed Internet connection among several computers. It is still a good idea to buy one even if you only intend to connect up one machine. When these devices first appeared, several cable Internet providers saw them as a threat to their revenues and tried to discourage use. After a short time, however, the companies realized that reducing the risk of machines being compromised reduced their customer support costs. Most cable companies and virtually all DSL companies in the U.S. now allow them, and many are beginning to encourage use.
With the benefit of hindsight, it is easy to see that it is a bad idea for an e-mail program to run a program file attached to an e-mail message at the click of a mouse.
Unfortunately, hindsight does not fix the millions and millions of e-mail programs still in use that work this way. Even a pop-up message to warn the user against running a program from an unknown source only protects those who take notice of it.
The virus problem would virtually disappear if only we could persuade users not to run programs sent to them as e-mail attachments. But user education is not going to provide a solution to this problem. The dangers of e-mail attachments will never be as readily apparent as, say, the risk of deep frying a turkey in highly inflammable oil using a gas burner on a wooden deck attached to a house. America has a new thanksgiving tradition that has led to several Americans burning their house down each year.
The warning on Martha Stewart’s Web site[3] neatly illustrates the problem with user education, “This recipe should be made outdoors; making it in the kitchen is too dangerous.” The warning does not give the reason for the danger, so a reader who is aware of the risk of carbon monoxide poisoning might reasonably assume this is the only risk and that the wooden deck attached to his house is a suitably ventilated location and thus overlook the risk that hot oil would spill over the edge of the cooking pot, to be ignited by the burner and set fire to first the deck and then the house.
As e-mail programs have tried to close this loophole, the attackers have looked for ways to reopen it. The “Bagel” virus spread itself as an encrypted file attached to a message giving the decryption key. This represents a measure of success because even though this tactic allowed the virus to evade the antivirus filtering mechanisms in place, the method it used to do so made it harder for the intended target to turn himself into a victim.
If it is a bad idea for e-mail programs to allow users to execute programs sent in mail, one would think it a good idea to block executable code in mail. Until recently, the consensus was that this is an excessively draconian measure, which is somewhat odd because I can only remember three occasions in which I have done anything of this sort in the past 30 years. I would not expect most users to try this, let alone decide that they need it. More oddly still, many of the people making the objection work for companies that already have filters in place that block executable programs of any sort and don’t seem to be aware that they have them.
The current default corporate security setting is to scan e-mail using an antivirus product that attempts to detect malicious code using pattern recognition techniques. When the antivirus company engineers detect a new virus, they publish a new virus signature that tells their filtering products how to detect it.
Like the battle between the spammers and the blacklist maintainers, pattern matching is a never-ending game of whack-a-mole. The virus writers are always developing new tricks and techniques to evade the antivirus filters. To be effective, an antivirus filter must be updated with details of the latest attacks. Selling subscriptions for updates is a profitable business model for the antivirus vendors but means that only a small proportion of machines have up-to-date filters.
Business users are generally willing to pay for state-of-the-art antivirus systems. A Trojan that infects a machine in their network is likely to attack their network from within. Persuading consumers to pay for antivirus scanning is much harder. The users who are willing to pay to protect themselves against viruses are the ones who are least likely to cause a problem.
An antivirus filter can help prevent my machine from being infected by a virus but cannot protect me against a denial-of-service attack or spam or a phishing attack from somebody else’s machine that was recruited into a botnet because it had no filtering. If we are going to deal effectively with the botnet problem, we must do more than simply protect our own machines against Trojan infection; we must find a way to protect almost every machine against infection. This is not going to be possible unless the protection is practically free.
As we just saw, old-style viruses spread exponentially. If the virus was identified quickly enough, a pattern could be distributed before the trickle of attacks became a torrent. Modern viruses harness the power of botnets. The attack starts without warning at full strength. By the time a signature is published, the attack is over. We must find a new approach.
Blocking every message that contains a program file is simpler, cheaper, and more effective than trying to distinguish good code from bad. This approach requires no subscriptions, no updates, and provides protection even when the virus has never been seen before.
As Marcus Ranum puts it, we must stop looking for badness and start looking for goodness instead.[4] Only e-mail that is known to be safe should be accepted.
If every ISP made blocking e-mails with executable attachments their default configuration, the virus problem would be limited to code exploits. The blocking system would require minimal maintenance after it was deployed.
I do not accept the objection that blocking program files is an unacceptable restriction on the use of e-mail. Most users never notice. The tiny number of users who notice and object might be allowed to receive program files after paying for a subscription to an antivirus scanning service.
Most forms of executable program are easy to block outright. The mail message has a label called “Content Type” that describes the type of data being transmitted. Unfortunately, there are a number of what protocol designers call “corner cases” because solving them is a bit like the problem of how to cut a tile to fit in the odd-shaped space in the corner of a room.
Document data formats that allow embedded programs create one class of corner case. We can all manage without sending programs in e-mail. Without the ability to send word processor documents, spreadsheets, and presentations, we lose much of the power of e-mail.
Part of the solution is already in place. Most applications that support scripting (programs embedded in a document) warn the user before running a program. Future versions of these programs will support a “sandbox” type of security model allowing scripts that are potentially harmful to be distinguished from those that are harmless.
The robustness of these controls could be improved if the e-mail message processor stamped each potentially hazardous incoming message attachment with a label that signified “received through e-mail; treat with caution.” In a corporate scenario, where users are expected to run only the latest, known-to-be-secure versions of programs, it would not be a problem if adding this label rendered the file unreadable by legacy application programs. This would be so much the better because it would force employees with older programs to upgrade to versions that enforced the restrictions.
Another class of corner case is created by file formats that take a whole collection of files and turn them into a single unit. The main file format used for this purpose on Windows is called ZIP. There is also a UNIX equivalent called tar.
Both the ZIP and tar formats are well-defined standards supported by a large number of software producers. Unpacking the files and examining each one in turn to see if it is a suspicious executable program is only a matter of including the necessary code in the blocking software.
E-mail encryption presents a challenge regardless of whether we are looking for goodness or badness. No filtering system can block dangerous content in content that it cannot read. This is a problem that we will return to when we consider e-mail security in Chapter 13, “Secure Messaging.”
Another trick that viruses use to spread is to copy themselves into any place they can find that is shared between machines. This allows a Trojan that has compromised one machine in a corporate network to spread to other machines. The same trick can also be used on a small scale to compromise a home system through an insecure wireless network—another reason for people to turn on encryption on their wireless network.
Another charming tactic of the shared folder virus is the pornographic filename. It’s not just porn-hound Bob who might look at a file named hotlesbians.sci. When Alice, his boss, finds the file, she is pretty certain that it should not be there, and she opens it to check.
A shared folder virus is like a landmine—it might be days or years before it is triggered. Antivirus scanners provide a measure of protection, but we are still stuck looking for badness.
To deal with the shared folder virus effectively, we need to completely rethink how we go about computer security. Instead of looking for bad code, we need more effective means of identifying legitimate code. We return to this issue in Chapter 17, “Secure Platforms.”
When prevention fails, we must cure the patient.
One of the biggest problems many computer specialists face today is the number of their friends and relatives asking them to clean spyware off their machine. At one time, people assumed the most likely explanation for a computer that was behaving oddly was faulty hardware or buggy software. Today, any computer problem that does not involve black smoke pouring out the sides of the machine is immediately put down to a virus or spyware. If black smoke is involved, a perfunctory examination is performed before spyware is blamed.
Traditional security approaches have considered compromise of the machine to be the worst possible thing that could happen. If the machine is compromised, it is “game over,” and there is no point in considering the situation further.
The typical consumer does not know any state secrets let alone store them on his home computer. Compromise of the machine is not “game over”; it is a recoverable situation if we have the right tools.
When spyware first appeared, it occupied a middle ground between the outright criminal virus and the programs that the user actually wanted to install on his machine. At first, the antivirus vendors did not realize that their customers required them to remove all the unwanted programs from their machines, not just the ones they classified as viruses. This led to a new class of security program called antispyware, which removes unwanted programs after they have installed themselves. Today we recognize no ambiguity; spyware is just another form of crimeware, and the term malware removal is more appropriate.
Antispyware programs have two major challenges. The first is to determine whether a machine is infected. The second is to remove any infection that is found.
The problem of finding out if a machine is compromised became apparent after the notorious hacker Kevin Mitnick attacked Digital Equipment Corporation (DEC) in the late 1980s. DEC had a large corporate network with tens of thousands of machines. Mitnick found a way into DEC’s network before the first firewalls were developed. The only way to be sure that Mitnick had not left a nasty surprise behind was to reinstall the operating system on every machine in the company that was connected to the network. This meant that several thousand DEC system administrators had to spend about a week reinstalling operating systems and dealing with the resulting problems. DEC estimated the cost of this exercise at $4 million, considerably more than the $160,000 cost of direct damage and tracking Mitnick down.
The Mitnick episode led to the development of security architectures that created internal partitions within the corporate network so that an attacker who breached perimeter security would not compromise the whole corporate network.
The episode also led to development of technologies to determine whether a machine had been tampered with. The best known of these programs was Tripwire[5] developed by Dr. Eugene Spafford and Gene Kim at Purdue University. Starting with the system in a known secure state (or at least presumed secure state), the tripwire program is run and calculates a “fingerprint” of every sensitive file on the machine. The tripwire program is then rerun every day or so, and the system manager is warned about any differences in the fingerprints. If an attacker has managed to leave a surprise, the daily status report catches it.
Realizing the idea in practice requires us to deal with the fact that many sensitive files on a computer system have a habit of changing. Few files are as sensitive as the list of usernames and passwords, but this is expected to change on a daily basis as new users are added, old ones deleted, and existing users change their passwords.
Tripwire was designed for use on large computers with full-time system managers running operating systems with security mechanisms that created a sharp separation between system management tasks and ordinary user activities. This separation is much less distinct on a personal computer, where the user is the system administrator. All the major personal computer operating systems—Windows XP, Linux, Mac—allow for separate user and system accounts. Getting nontechnical users to use this feature is rather hard.
On a 1980s-style minicomputer operating system, most if not all of the programs used by the typical user would be installed by the system manager. The only exceptions would be programs that the user wrote himself—if this was even permitted. At my first job writing code for a machine of this type, I would have to call up a system manager to load a magnetic tape containing mere data, let alone a program. Home users are not going to call up their system manager to ask them to load up the CD-ROM to play World of Warcraft.
Spyware detection programs have a much harder job to do than the minicomputer era programs. Modern operating systems provide a lot of places to hide. Fortunately, many powerful antispyware packages are available, each of which scans programs running on the computer and stored on the computer disk looking for the following:
Known malicious programs
Signs of modifications to program files
Unexpected changes to previously detected files
Changes to critical system files such as the registry in Windows
After we have detected the spyware, the next challenge is to get rid of it. This can be hard, because successful spyware programs have many tricks, including corrupting parts of the operating system.
Antispyware programs have a second advantage: They provide an effective means of ridding a machine of unwanted code of any type. There are several programs that are not exactly spyware but refuse to leave after they have outstayed their welcome. A well-known program that plays sound and music clips has a habit of pestering the user to upgrade it to the latest version. After refusing this request, I discovered a blinking icon in the taskbar. Clicking on the icon gave two options: Upgrade now, or be reminded in two weeks. I decided on the third option: Remove the program from the machine, and block access to the distribution site for the software at the firewall to prevent anyone from downloading it again.
If all else fails and the patient cannot be saved, stop the infection from spreading.
If we have failed to protect our own computer, then let’s make sure it is not used to attack the rest of the community. This is not just a courtesy to the rest of the Internet community; reducing the value of a compromised machine to a criminal encourages him to attack a different target.
Stopping transmission can also avoid legal entanglements resulting from a compromise of a machine. There have been several occasions in which the full might of the law has been poised to crush a “hacker” who has turned out to be an entirely innocent home user with a faulty security configuration. At some point, a company that has suffered major damage as a result of an Internet attack is going to file a lawsuit alleging that allowing a machine to be taken over constitutes negligence.
It is much nicer living in a world where people don’t need to lock their doors. Unfortunately, it only takes a few criminals to make locking doors necessary. At one point, it was quite common for people to leave their wireless Internet access points open as a courtesy to people who might just be in the neighborhood and looking to download their e-mail. I used to have an open configuration, but I decided this was a bad idea after reading about the Toronto pederast mentioned in Chapter 1, “Motive.” who was caught using open wireless access points to surf child pornography Web sites.6[6] If the police investigation had started with the seizure of log files kept by the Web site, the innocent owner of the access point might have found himself with some difficult explaining to do to the police.
The Great Wall of China remains the world’s most monumental building feat, requiring more manpower than any other before or since. Hadrian’s wall in Britain marking the northernmost effective extent of the Roman empire is 80 miles long and required a permanent garrison of 9,000 soldiers. The Great Wall is 50 times longer—more than 4,100 miles—and if garrisoned in the same manner as Hadrian’s wall, it would have required almost half a million troops.
The Great Wall began as three separate walls in the third century B.C., which were only joined to form a single fortification several centuries later. The remains that can be seen today are of the wall built during the Ming dynasty in the thirteenth century onward, when the imperial army had only 80,000 troops. Even by committing every soldier in the army to sentry duty and assuming a four-watch rotation, there would be only five soldiers for each mile of wall. The wall could not have been permanently garrisoned, but construction would not have continued over several centuries if it was merely one ruler’s egotistical whim.
The Great Wall had more than one purpose, but it is unlikely that blocking an actual invasion by a foreign army was one of them. The Chinese military classic The Art of War advises commanders not to rely on static defenses. Even a garrison of half a million men would only be enough for one soldier every 40 feet or so—hardly enough to repulse an invasion force.
The likely defensive purpose of the Great Wall was to deter raiding parties that would charge in from the north, pillage a town or city close to the border, and then escape with the loot. The wall could not prevent the raiding parties from entering China, but it could stop them from escaping with the loot. It is one thing for a few hundred bandits to sneak over an unwatched stretch of wall in the middle of the night, but it’s quite another to escape back over a fully guarded wall carrying large quantities of loot with an army in pursuit.
The conventional firewall configuration protects the internal network from external attack. Preventing attacks in the reverse direction reduces the value of a captured machine to an attacker. Botnet “herders” rent out machines according to utility: how powerful the machine is, how fast its network connection is, and whether there are ISP-enforced restrictions on use. The objective of a reverse firewall is to minimize the value of a machine without interfering with normal use.
Fortunately, there is no conflict. Machines in normal use do not remotely resemble a hacked machine. Normal users do not attempt to send a million e-mail messages an hour or send out packets with false source address information or send ten thousand connection requests per second to the same machine or repeatedly perform DNS lookups without trying to establish a connection.
Implementing these types of control does not require a lot of processing power, which is in any case abundant these days. The “cable router” box I bought for $50 contains a 200Mhz RISC processor, which is as fast as the fastest engineering workstations available in the early days of the Web. Adding a reverse firewall feature to the software would have negligible impact on performance. There are also spare cycles that could be put to use in cable and DSL modems. Deployment of reverse firewalls need not add to the cost of setting up a home network.
Inevitably, some people will complain about any limitations on their use of the Net, just as people complain about the fact that most high-performance sports cars have a top speed that is electronically limited to 155 mph. Almost nobody who complains about the speed limiter has the slightest intention of driving close to that speed, and even if they wanted to drive that fast, they probably couldn’t. The objection is not to what they will do; what counts is what they might want to do.
There is an easy solution to this objection: Enable the reverse firewall by default, but let people who really want to turn it off do so. The vast majority of people will leave the reverse firewall enabled. Even most of the people who would otherwise complain about the infringement of their Internet liberties will leave it enabled.
An easy way to make sure that an attacker cannot disable the reverse firewall is to require the user to type in the serial number stamped on the bottom of the device when he disables it. This is easy for the owner but hard for an attacker.
The big difficulty with deploying reverse firewalls is that they are a measure whose principal benefit is to the Internet community rather than to the individual buying a cable modem or router. It is difficult to convince the companies who make networking hardware that the investment is worthwhile.
There are two constituencies with the power to drive deployment of reverse firewalls. The first is broadband ISPs who buy most of the broadband modems and effectively dictate their standards to the manufacturers. The second constituency is government regulators. It is not desirable for governments to micromanage Internet security measures in general, but governments should take a role in encouraging the adoption of measures such as reverse firewalls that are in the general public interest but might not otherwise be adopted.
Securing the local network is the first part of the problem; our next challenge is to provide security at the level of the internetwork, the network of networks that make up the Internet.
If you are in a traffic jam, it is often difficult to see the extent of the problem or its cause. You might be stuck for a few minutes or an hour. If a friend calls to ask what the traffic is like, all you can tell him is that you are stuck; the alternative route might be better or even worse. To understand what is really going on, you need to see more information than is visible from a single point of view.
Responding to an Internet security incident poses the same problem. It is one thing to see a suspicious pattern of activity that might indicate that an attack is in progress, but it’s quite another to be able to do anything about it. Sometimes an impending problem is only visible in a global view.
What we need is a way to communicate intelligence on attacks in progress so that information from the target of an attack can be automatically routed to a party that is capable of cutting off the source.
A recent study estimated that there are more than a million zombie computers on the Internet. It is not difficult to identify a zombie machine with some confidence; a machine that is scanning another system for vulnerabilities is almost certainly compromised but might just be a legitimate security check that the target requested. Only the target knows for sure.
Most of the information needed to identify botnet members already exists at one or more of the companies that provide security services. The problem is that these companies can only use the information to protect their customers when what they would prefer to do is to prevent the machines from being used for further mischief.
Today, the Internet response system works through e-mail and the telephone. Taking down a phishing capture site is expensive, time consuming, and can easily take several hours. A more efficient system is needed, one that takes the human out of the loop for routine reports.
Work on building such a system is currently focused on the IETF incident handling protocol (INCH). As often happens in Internet protocol design, this work is a repurposing of an infrastructure originally designed to meet a different need.
The original INCH working group was set up to allow for automated reports of computer security “incidents” to be reported to a response coordination center such as the CERT at Carnegie Mellon University. CERT was originally set up to coordinate response to computer security incidents in the wake of the Morris worm, which brought down a significant proportion of the Internet in 1988. There are now 170 similar incident response teams around the world.
The emergency response center model works well for the emergencies it was designed to deal with but does not come close to having the resources necessary to track down every attack reported. Most of the “incident response” turns into collecting and analyzing statistics. This is important work—it is the raw material that drives computer security research—but it is not the type of response we require.
We must have an immediate response. This requires the incident report to reach the ISP or other party capable of responding to it. If a bank is targeted by a phishing attack, the incident notification must reach the ISPs hosting the capture site and the botnet sending out the spam.
Meeting this need presents us with a common problem in computer networking. The information we need to solve our task exists somewhere, but we don’t know where. We need to find out which ISP is responsible for a particular IP address or DNS domain name.
Fortunately, we already have an infrastructure that is designed to meet precisely this need: the DNS.
Although the main function of the DNS is to map domain names such as example.com to IP addresses such as 10.2.3.1, we can also use the DNS to state where the INCH server for reporting security incidents involving example.com is to be found.
The DNS also works in reverse, allowing the IP address 10.2.3.1 to be mapped back to the domain name example.com. This aspect of DNS is known as the reverse DNS and allows us to advertise the location of the INCH server for reporting security incidents by IP address.
These mechanisms would be sufficient if every packet sent over the Internet had an authentic source IP address or domain name. Unfortunately, the lax approach to Internet security in the early days means that this is not the case. Most ISPs will route any Internet traffic that their customers present to them unchecked, including packets that have a false “spoofed” source address.
When a message is sent with a spoofed source address, any response will be sent to the spoofed address rather than the actual origin. This does not make a lot of sense unless the objective is to perform a denial-of-service attack against either (or both of) the spoofed source or destination address given.
As we saw in Chapter 1, denial-of-service attacks are used to extort money from businesses that rely on their Internet connection. Spoofed source addresses are almost always used.
Even though the source address of the packet might be forged, there is no such thing as a false destination address. Internet routers always try to forward packets to the destination specified.
When we come under this type of attack, we can’t know where the attack is coming from. However, we do know which of our immediate neighbors is forwarding the traffic to us, and we can notify them. Those neighbors can in turn determine which of their neighbors is forwarding the attack traffic and notify them. If a sufficient number of Internet backbone providers support the notification protocol, the source(s) of the attack can be run to the ground and appropriate measures taken to stop it.
The final piece needed to complete the puzzle is a business model that provides ISPs with an incentive to accept incident notifications. The incentives are clear; responding to security incidents is a major customer support cost for ISPs, automating the response reduces these costs. Vigilance reduces the incentive to attack a network because any bots established will likely be short lived.
Some people worry that ISPs will refuse to accept incident notifications because this would make them liable for responding to them. If this is the case, we need to educate judges to reject this “head in the sand” defense as clearly contrary to the public good. It is, in any case, not a new requirement, because the Internet protocol standards already require ISPs to accept notification of computer abuse via e-mail. All that is being proposed is a means to make it easier and cheaper to act on the information provided.
INCH and protocols like it might also provide an answer to one of the biggest difficulties when tracking down a computer criminal: unraveling the network of zombies that they are hiding behind. Obtaining log files from an ISP almost always requires a subpoena. When e-mail messages are involved, the law might require an ISP to demand a subpoena before providing the information.
Obtaining subpoenas takes time, particularly when multiple jurisdictions are involved. Often the trail leads from one compromised machine to another. If it has taken too long to get the subpoena that identifies a particular link in the chain, the ISP might have already erased the information that is needed. The next ISP in the chain is also a victim of the attacker and also has an interest in catching them and preserving the evidence. But there is nothing they can do until they know about the problem.
What we need is a protocol to allow ISPs to warn the previous link in the chain that an attack has been detected and that they should 1) preserve data relating to the use of specific machines and Internet addresses and 2) if possible, send a notification to the link prior to them. This would allow attacks to be traced back to their source, making it harder for the attacker to wear the cloak of anonymity, which makes Internet crime so hard to police.
Botnets are established by Trojan applications.
There is no longer a useful distinction between Trojans, worms, and viruses.
Computer viruses do not act like biological viruses.
Diversity is not an effective defense.
Evolution is Lamarkian, not Darwinian.
Multiplatform viruses have existed for many years.
Trojans are distributed en-masse through botnets.
Millions of attacks are sent out before an antivirus signature can be compiled.
Bug exploits are a major cause of infection.
Buffer overrun bugs are particularly common.
All platforms are vulnerable.
Executable e-mail attachments are the other major cause of infection.
ISPs should block executable attachments by default.
Reverse firewalls protect the rest of the Internet even if a machine is compromised.
They remove the incentive for the criminal.
We need a mechanism to exchange intelligence peer-to-peer while attacks are in progress.
INCH/RID is currently the most promising candidate.