worm containment in the internal network

Worm containment in the internal network

a Silicon Defense technical white paper

march 2003

description This document is designed for network security professionals and technical staff. It provides a conceptual overview of worm-based network security issues and describes the types of network worms that have already been unleashed on public and private networks as well as those not yet seen but likely to occur in the future.

Key concepts needed to understand the conditions in which worms spread—in either aggressive or ineffective ways—are examined as are the latest technological solutions that can stop them.

At the end of the paper is a Worm Defense Technical Checklist that security staff can use to immediately increase the effectiveness of existing and new network defenses against worm threats.

Silicon Defense the cyber-war defense company

about Silicon Defense the cyber-war defense company

Silicon Defense provides cyber-war defense solutions for service providers, enterprise and government customers. Silicon Defense’s solutions proactively address network attacks by recognizing and responding to new and unknown network threats thereby protecting digital assets, preventing costly damage and ensuring uninterrupted business operations.

about the authors

Stuart Staniford, Ph.D., Founder and President, Silicon Defense Stuart Staniford founded Silicon Defense in 1998. He has been a researcher and practitioner in computer intrusion detection since 1993 and has written a number of pioneering research papers. Staniford worked in the UC Davis Computer Security Research Lab, which invented network intrusion detection, and is a NSA Center of Academic Excellence in Information Assurance Education. While there he led the team that developed the first large-scale hierarchical intrusion detection system, GrIDS, which was designed explicitly to detect the spread of worms. He has led two intrusion detection standards groups. Staniford received his Ph.D. from UC Davis.

Clifford Kahn, Vice President of Engineering, Silicon Defense Clifford Kahn has 16 years of experience in network security at EMC Corporation, the Open Group (OSF) Research Institute, and DEC. He led the development of an early public-key protocol, a management tool for Distributed Computing Environment (DCE), a security kernel, and a compiler implementation. He has written articles on his computer security research and holds several patents. Kahn received his MS in Computer Science from Stanford University.

Worm Containment on the Internal Network 2


Contents

Introduction ...................................................................................................4 The worst is yet to come..........................................................................4

What is a worm? ...........................................................................................5 Worms versus viruses .............................................................................5

Types of network worms...............................................................................5 The random scan worm—simple and popular.........................................6

Infection vectors ................................................................................6 Spread phases ..................................................................................6 Example: Code Red I, a simple random scan worm.........................7 Example: Sapphire/Slammer, faster than human intervention .........8 Example: Code Red II, localized scans for internal saturation .........9 Example: Random scan worms not yet in the wild .........................10

The flash worm—infecting vulnerable servers in seconds ....................11 Topological worms—clue-driven worm spread .....................................12 Metaserver worms—using host-supplied hit-lists ..................................12 Contagion worms—slow but stealthy ....................................................13 Multimode worms—increased danger and sophistication.....................13

Worm payloads...........................................................................................14 Crossing firewalls........................................................................................14 Key concepts behind worm spread ............................................................15

Calculating compromise rates ...............................................................15 How the Silicon Defense CounterMalice solution stops worms .................16

Adaptive reactions restrict worms to network cells................................16 CounterMalice deployment scenario .....................................................17 Tuning minimizes inappropriate traffic blocks .......................................18 Notes about CounterMalice Version 1...................................................19 Future directions ....................................................................................19

Designing a CounterMalice deployment.....................................................19 Worm Defense Technical Checklist



introduction The most devastating network security incidents of recent years have all been network worms. Code Red, Nimda, Slapper, Grabber, Sapphire/Slammer—the list of malicious worms unleashed on public and private networks continues to grow rapidly. The newest worms can spread across the Internet in a matter of minutes, infecting businesses worldwide and causing countless hours of lost productivity and network downtime. Total damages resulting from each worm run into billions of dollars.

Sapphire: the speed demon The Sapphire/Slammer worm holds the dubious distinction of being the fastest computer worm to date. Doubling in size every 8.5 seconds, Sapphire achieved its full scanning rate—over 55 million scans per second—in roughly 180 seconds and infected 90 percent of vulnerable hosts within 10 minutes. Infected hosts spewed billions of copies of the worm into cyberspace, causing network outages, cancelled airline flights, interference with elections, ATM failures, and 911 emergency center shut downs. Nonetheless, damages could have been much worse and Sapphire serves as a warning for the future.

Security professionals know that current network defenses are inadequate to prevent worm infection. There are thousands of different ways that a worm can infiltrate an organization, making it is nearly impossible to feel complete confidence that any network is, in fact, protected.

the worst is yet to come

Future worms will almost certainly be far more destructive than what has been seen to date. Worms will exploit more widespread vulnerabilities, will be better tested, work on a broader range of systems, use faster spread algorithms, and have more malicious payloads.

worst worm study for the DoD Silicon Defense’s network security experts recently conducted research for the Defense Advanced Research Projects Agency (DARPA) [http://www.darpa.mil/], the central research and development organization for the U.S. Department of Defense (DoD), to determine the nature of the worst worm that could reasonably be anticipated to harm US networks. The study showed that a single worm could:

Infect most of the business computers in the US

Wipe out data on the hard drives on nearly every infected computer

Physically damage hardware in a sizeable fraction of cases

Carry a damage payload that runs into hundreds of billions of dollars.



what is a worm? A worm is, at its most basic, an electronic program that self-propagates across a network, exploiting security flaws in widely used services.

worms versus viruses

Worms and viruses are, in some ways, similar. Both are composed of malicious code that propagates through networks. The key differentiator between worms and viruses is how they activate and spread through computers and networks of computers.

how do viruses and worms differ? A virus requires an action by a user (for example, opening an e-mail message or executing a program) before it is activated. As a result, viruses propagate far more slowly than worms. A worm runs on a host computer and—entirely under its own direction—begins searching for and compromising remote computers where it can activate itself. Because a worm is self-propagating, it spreads faster, is more aggressive, and causes dramatically more damage than a virus.

Most corporations have a number of security measures in place to prevent unwanted inbound connections. In the last decade, viruses have received enormous press coverage and industry focus. As a result, anti-virus companies have developed effective defenses against them. Firewall defenses are also in place in most networks today. However, worms can easily foil firewall mechanisms by targeting web server hosts or entering the enterprise network via incoming e-mail.

Unlike virus and firewall network protection solutions, adequate worm defenses have not been developed until quite recently, primarily because worm attacks have been relatively rare until recently.

types of network worms

Worms can be distinguished from one another based on the spread strategy each employs to search for and infect vulnerable hosts. Whether a worm is spreading across the Internet or within an internal network, the spread strategy does not change substantially (although worms can perform certain optimizations for internal spread, which will be discussed later in this document).

Network worms can be characterized into the following types:

Random scan worms Flash worms Topological worms Metaserver worms Contagion worms



Multimode worms

the random scan worm—simple and popular

The simplest, and by far the most popular, spread strategy used today is the random scanning worm. The core spread operation of a random scan worm can be captured in pseudocode as:

Loop forever doing { Choose a random IP address on the network Try to infect it }

As simple as they are, random scan worms vary in a number of different ways: in the algorithms used to choose random addresses, in the number of threads used to perform the task, and in the method of infection.

infection vectors

The first distinguishing factor is the nature of the infection vector, that is:

The vulnerability the worm exploits (the exploit) The range of release versions of affected software vulnerable to the exploit.

Worms may simply approach every available host or may instead be programmed to probe host addresses first and then exploit only those IP addresses having open ports. Random scan worms also differ in exploit delivery, that is, whether the full worm code is delivered along with the exploit or only in a later network transaction.

spread phases of the random scan worm

Random scan worms have two phases of infection. In the first phase, the size of infection grows exponentially and is characterized by the compromise rate ‘K’.

compromise rate ‘K’ K is the average number of new hosts an infected host can compromise per unit of time in the early stages of an infection. The doubling time of a worm is 1/K (the amount of time elapsed for the number of infected machines to double). Typical doubling times for random scanning worms range from seconds (for Sapphire/Slammer) to days (for worms that scan for open file shares on the Internet).

In the second stage of infection, growth is no longer exponential. At this point, most infectable network hosts have already been located and infected so it takes longer to search for the last few vulnerable IP addresses. Most of the worm’s scanning activity is now directed against addresses that have already been tried by other copies of the



worm. Eventually the worm reaches saturation, meaning that all vulnerable hosts on the network have been found and compromised.1

example: Code Red I, a simple random scan worm

Code Red is a good example of a simple random scanning worm. With a 4KB packet size, Code Red I began spreading across the public Internet in July 2001. Its target was a vulnerability in Microsoft’s IIS web server software and it began with 100 threads, each of which randomly scanned chosen Internet addresses by issuing TCP connect calls to web server (port 80). If connection was successful (i.e., if the TCP three-way handshake completed), Code Red 1 then sent the exploit.

The design of the Code Red I worm was inefficient in the sense that the thread would often hang while attempting to talk to unpopulated IP addresses—or addresses behind firewalls which would not respond to external and unsolicited port 80 connections. Code Red achieved a doubling time of about 40 minutes (a K of approximately 1.6 compromises/hour) in its first outbreak and about twice as long as that during its second outbreak in August 2001.

Figure one shows a graph of the inbound Code Red probe rate to one site in August 2001. The probe rate is proportional to the number of infected addresses on the Internet and thus tracks the infection. The graph shows both the actual probe rate and a simple mathematical model developed by Silicon Defense to predict the spread rate of Code Red.

1 Saturation can be a little fuzzy in that hosts may be turned on or off during or after the initial spread of the worm, resulting in a more complex picture than simple saturation of a fixed list of vulnerable IP addresses.



Figure 1. A graph of the Code Red probe rate inbound to one site in August 2001

example: Sapphire/Slammer, faster then human intervention

Another example of a random scanning worm is the Sapphire/Slammer worm, deployed in January 2003. Sapphire attacked a vulnerability in Microsoft’s SQL server software that could be exploited through a single UDP packet and did not need to wait for a response. Sapphire was a small worm—only 376 bytes—that simply sat in a tight loop, spraying copies of itself to random addresses as fast as possible.

By these means, it achieved a doubling time never before seen—only 8.5 seconds—in the first spread phase. In the second phase of infection, the rate of growth slowed due to bandwidth limitations and the spread curve fell away from the classic random scanning worm form. Figure 2 shows a sample data set of inbound probe rates (together with the prediction of the random scanning theory).



Figure 2. A graph of Sapphire probe rates in January 2003

Sapphire illustrates the importance of automated responses to worms—no human mediated response could possibly have been of value in preventing the spread of this worm. Any signature-based response—that is, a response based on attempting to detect the pattern a particular worm produces—would also have been irrelevant. By the time human intervention occurred, the worm had already reached saturation.

example: Code Red II, localized scans for internal saturation

The Code Red II2 attack began in August 2001 and used yet another spread strategy known as localized scanning. The worm first attempted to infect its first host somehwhere on the Internet. Then, instead of continuing by picking a random address anywhere on the Internet, this worm:

1. Identified the address of the server it infected. 2. Picked an address from the same Class B (with a 38 percent probability rate). 3. Then picked an address from the same class A (with a 50 percent probability rate). 4. Went on to pick an address anywhere on the Internet (with a 13 percent probability

rate).

Because of Code Red II’s localized spread strategy, once a single copy of the worm infected an intranet, the entire intranet could be scanned fairly rapidly. Future worms designed to infect internal networks will almost certainly use some variation on Code


2 Code Red II contained what was actually a completely unrelated codebase to Code Red I but called itself Code Red II in a string inside the code.


Red II’s localized scanning scheme to ensure effective internal propagation and infection.

example: random scan worms not yet in the wild

There are several refinements to the basic random scanning algorithm that have not yet appeared in the wild but are likely to occur in the future.

Simultaneous, multiple-point launching. One future scenario would have worms start from multiple points simultaneously. Prior to worm release, the worm writer would gather what is known as a hit-list, that is, a list of potentially vulnerable addresses. In the simultaneous, multiple-point launch scenario, the worm begins by working its way through this hit-list. As soon as it succeeds in infecting a second machine, the two machines divide the hit-list between them and continue to work through it, dividing and conquering with increasing speed. Once the hit-list has been fully exploited—which could take just a few seconds—the worm begins normal scanning behavior. This strategy greatly accelerates the spread of the worm by accelerating early generations.

Permutation scanning. One of the limitations of simple random scanning is its inefficiency: many addresses are probed multiple times. Similarly, a simple random scan worm has no means to effectively determine at what point all vulnerable machines have been infected. A permutation scanning strategy overcomes these limitations by including capabilities that can detect whether a particular target has already been infected.

With permutation scans, all worms share a common pseudo random permutation (order) of all possible IP addresses. Such a permutation could be efficiently generated using a 32-bit block cipher and a pre-selected key: simply encrypt an index to get the corresponding address in the permutation and decrypt an address to get its index. Any machines infected during the hit-list phase (or local subnet scanning) begin scanning just after their point in the permutation, working their way through the permutation and looking for vulnerable machines. Whenever the worm sees a machine that’s already been infected, it chooses a new, random start point and proceeds from there.

Permutation scanning provides a self-coordinated, comprehensive scan while maintaining the benefits of random probing. Each worm looks like it is conducting a random scan but it is also minimizing duplication of effort. Any time an instance of the worm encounters an already-infected host, it knows that the original infector of the host is already working along the current permutation sequence and is therefore further ahead. Consequently, there is no need for that copy of the worm to continue working the current sequence. Self-coordination keeps the infection rate high and guarantees that the scan will comprehensive. It also allows the worm to make a local decision that further scanning is of little benefit. After any particular instance of the worm sees several infected machines without discovering new vulnerable targets, it assumes that complete infection has occurred and stops the scanning process.



Binary search worms. In a binary search scenario, the worm does not choose random addresses but instead systematically searches the address space. When a binary search worm finds a victim it can infect, it divides the remaining address space to be searched into two parts. One worm instance takes the first half and the other takes the second. Each then iterates the same algorithm.

This algorithm is optimal for a scan worm that does not contain a hit-list. The worm spreads exponentially until it saturates and there is no slow, asymptotic approach to saturation as seen with simple random scanning worms. However, the binary search algorithm is fragile and prone to detection.

the flash worm—infecting vulnerable servers in seconds

A flash worm uses a more precise variant of the hit-list strategy. Before the release of a flash worm, the attacker obtains a hit-list of all or most of the servers that are both 1) vulnerable to the particular exploit being used, and 2) open to attack. This type of flash worm could plausibly infect most vulnerable Internet servers within just a few minutes—or a smaller network in less than ten seconds.

With an attacker who has the determination and foresight to assemble such a comprehensive hit-list, a flash worm could efficiently spread by no other means than simply attacking the addresses on the list. The initial copy of the worm could be programmed to divide the list into blocks and then to find and infect the first address in each block (or perhaps a high-bandwidth address within that block). It then hands off the list of addresses for that block to a child worm. The child worm re-iterates the process to infect all servers within its block. To further maximize parallelization, a threaded worm could even begin infecting hosts before it has received the full host list from its parent and start work immediately to create multiple children in parallel.

flash worm infection trees

A flash worm design can be somewhat fragile, especially if an early copy of the worm is neutralized quickly or if it infects a site from which it cannot perform outbound scans. To mitigate this, flash worm copies could overlap scanning to ensure that all addresses are scanned a small number of times—with every target address being scanned by different paths through the infection tree. This strategy removes the need for further parent-to-child communication after initial infection occurs.

flash worm with pre-assigned blocks

A related design might locate the flash worm hit-list in pre-assigned blocks on a single or multiple high-bandwidth servers that are already well known to the worm. Each copy of the worm would then receive a particular assignment from its parent and the server need only send portions of the hit-list, rather than its entirety. In principle, the server would only need to transmit each address in the hit-list a single time. After the worm has propagated sufficiently, such that a large number of copies are attempting to



fetch their—now quite small—lists, the worm collective could turn its attention to sending the address list along with each new infection, rather than requiring each infectee to contact the server.

topological worms—clue-driven worm spread

Address scans, either random or systematic, are not the only approach worms can use to spread. An alternative strategy involves inspecting infected machines for clues that lead to other hosts that are likely to be vulnerable. For example, a web server worm can search local, on-disk web pages for URL links and then follow the path to find additional web server targets. Or a worm attack could use a peer-to-peer service as the exploit and use the infected computer’s list of peers to propagate itself.

Both of these strategies illustrate a topological spread approach. Major worms have not relied on the topological spread strategy since the 1988 Internet Worm, which was the first major worm incident. The topological approach was useful back then because the Internet address space was still too sparsely populated to support a scanning approach. A few minor worms (for example, Kazaa in 2002) have used of this approach more recently and it is likely that it will be used again in the future, particularly as technological solutions to prevent scanning worms become widespread.

metaserver worms—using host-supplied hit-lists to spread

A hybrid of both the topological worm and the flash worm is the metaserver worm. A metaserver is a central host that holds a list of many other servers. Common examples include game protocols—in which metaservers keep lists of all the other servers on which a game player can find a hosted game—and search engines, which perform a similar function on the web.

A worm can make great use of these metaservers. If a metaserver will supply its entire list on demand, the server’s list essentially becomes a hit-list that the worm uses as its infection spreading mechanism.. For this reason, it is important that metaservers are designed to limit the amount of information given to any one client.

contagion worms—slow but stealthy

Another variant of a topological worm is the contagion worm. This type of worm spreads in a topological manner but differs from typical topological worms in that it does not initiate infection on a rapid schedule of its own choosing. Instead, the contagion worm waits for normal network traffic between servers to occur and then mixes its infection traffic in with the rest.

As a result, contagion worms propagate slowly but are stealthier than other worm types. The traffic generated by a contagion worm is less suspicious (anomalous) than that of a scanning or more aggressive topological worm. For more information about combating contagion worms, refer to the Silicon Defense CounterSleuth™ solution.



multimode worms—increased danger and sophistication

A worm is not bound to use any single infection vector, nor must it use a single spread strategy. As worms become more sophisticated, they will employ multiple strategies to confound network defenses.

For worms designed to harm internal networks, there are three identifiable stages of evolution:

Stage 1: Internet spread—probably in worm mode—to rapidly build a critical infection mass before signatures and anti-viral updates can be distributed.

Stage 2: Network firewall penetration, perhaps using stealthy virus-like modes.

Stage 3: Rapid internal spread throughout corporate networks.

The best example to date of a multimode worm strategy is the Nimda worm (September 2001). Nimda spread rapidly, probably reaching saturation within a few hours. It then maintained itself on the Internet for months after inception and was able to spread extensively behind firewalls.



Nimda is a good illustration of the ferocity and wide reach that a multimode worm can exhibit. The Nimda worm is thought to have used at least six different spread strategies in its attack.

Nimba multimode spread strategy 1. Infect web servers from already infected client machines using active probing

for a Microsoft IIS software vulnerability.

2. Bulk e-mail itself as an attachment, using e-mail addresses found on already infected machines.

3. Copy itself across open network shares.

4. Add exploit code to web pages on compromised servers, so that clients browsing these pages also become infected.

5. Scan for backdoors left behind by both the Code Red II and "sadmind" worms.

6. Infect executable programs on infected machines, which might later be shared or run and so cause further infection.

worm payloads Fortunately, Code Red I, Code Red II, Nimda, Sapphire, and other worms have been relatively benevolent—none carried seriously malicious payloads. Code Red I inflicted a badly-implemented Denial of Service (DDOS) against the White House website, Code Red II installed backdoors, and Sapphire had no payload at all. Nimda included code able to wipe out the hard drives of infected machines but the code was turned off in the distributed worm.

Nonetheless, it is only a matter of time until a worm with a seriously damaging payload emerges.

future worm payload scenarios Wipe out hard drives on all infected machines Damage hardware by reflashing bios, causing computers to

become inoperable Perpetrate DDOS attacks on many targets simultaneously Search infected machines for intellectual property of a particular

or general sort Level stealthy attacks by remote and anonymous control via a

worm distributor Accept new software modules that propagate through the worm

and give it new behaviors at run time. Corrupt data over time and in a subtle and difficult to detect way

crossing firewalls Most networks have firewalls in place to create a protective boundary and prevent unwanted incoming connections. Still, worms work around firewall mechanisms. Both the Code Red and Sapphire worms treated the Internet as a single, flat address space and spread solely via the worm mode for a single exploit. Internal networks were infected because inbound probes were allowed through firewalls and onto the port in



question (TCP 80 for Code Red and UDP 1434 for Sapphire). With these worms, a worm instance on the inside of a firewall spends the great bulk of its time trying to scan out through the firewall and is not as effective as it could be at compromising the internal network. Another worm, Nimba, demonstrated how easy it is to undermine firewall security. Nimba used, as one its strategies, a simple heuristic that didn’t originate new mail but only responded to mail messages the host had previously received. Another strategy to cross firewalls is to exploit known flaws in common web browsers to compromise the browser’s host.

key concepts behind worm spread

The critical variable in controlling the evolution of a worm is the compromise rate ‘K’, explained earlier in this document. Compromise rates of 1/day (meaning an infected machine will find one other machine to infect in a day) cause the slow evolution of many worms and allow for human preventative responses such as signature updates and patch installation. When the compromise rate reaches 1 compromise per minute—as with Sapphire—the worm will reach saturation before network operators are even aware of its existence. It is these rapidly spreading worms that are the most fearsome.

calculating compromise rates

The overall compromise rate of a worm is simply the average of the compromise rate for each worm instance—and rates for each instance vary since some can scan faster because of faster connections, more powerful CPUs, and other means.

The compromise rate (for a scanning worm) is a product of two variables:

The vulnerability density The scanning rate

The vulnerability density. The vulnerability density is the proportion of network addresses that are vulnerable to a particular worm. For example, if an organization has two class B networks with 37 vulnerable servers operational, then the vulnerability density V is 37/(2 x 216), or 2.8 x 10-4. The vulnerability density of the Code Red worm on the public Internet was 8 x 10-5. The larger the vulnerability density is, the larger the size of the infection when the worm saturates. Worms will also spread much faster if the vulnerability density is higher—and will be harder to block.

For well-known vulnerabilities, the vulnerability density can be measured with a vulnerability scanner (e.g. Nessus or the many commercial equivalents). However, worms may also exploit zero-day or near zero-day vulnerabilities—that is, vulnerabilities discovered by an attacker but not yet known to others. Because of this, it is useful to think about a related concept: the service density. The service density is



the proportion of addresses which have some particular service (e.g. http) turned on. The service density is an upper bound on the vulnerability density for a possible future worm that exploits that service. Hence, service density should be also reduced as much as possible.

The scanning rate. The worm’s scanning rate is the other variable used to calculate a worm’s compromise rate. The scan rate is multiplied by the vulnerability density to determine the compromise rate—and hence the doubling time—of the worm. The scanning rate is essentially how fast a given worm copy is able to attempt infection of different IP addresses on the network.

By understanding and taking steps to lower the vulnerability density and thus the scanning rate, security professionals can reduce the worm’s overall compromise rate. Anything that reduces the compromise rate makes other defenses more effective.

how the Silicon Defense CounterMalice solution stops worms

There is no question that worms will find thousands of ways to attempt compromise of internal networks. Silicon Defense’s mission is therefore to prevent worms from spreading throughout an organization once they have already gained access.

Silicon Defense has developed a completely new class of defense against the most rapidly spreading worms that can infiltrate business networks. Silicon Defense’s CounterMalice™ worm defense solution deploys worm containment devices throughout the network and uses them to recognize and block worm traffic. Normal traffic is allowed through unimpeded. However, when the presence of a worm is detected, the CounterMalice solution cuts in to prevent contagion and spread. When protected by CounterMalice, the enterprise network is divided into cells—with a CounterMalice device spliced into each link between cells—to confine and contain worm infection.

adaptive reactions restrict worms to network cells

This patent-pending global worm containment technology works by detecting worm-like behavior and then adaptively restricting the scanning rate of worm instances. The solution represents the first network-layer, anti-worm solution that can go beyond traditional firewall or anti-virus defenses to provide scalable and effective protection against new and unknown worm attacks. By containing malicious code inside a cell, CounterMalice stops the attacker from communicating with its intended victims and prevents the spread of worms.



CounterMalice deployment scenario

When deployed, CounterMalice devices are placed in key locations throughout the network. The enterprise is divided into cells, with CounterMalice devices spliced into physical links between cells. All traffic from one cell to another must pass through a CounterMalice worm defense device. If a worm does breaks into the enterprise, CounterMalice confines it to a single cell, keeping the majority of the enterprise network fully functional. As a result, the CounterMalice solution and its use of the cell containment strategy enables system administrative staff to concentrate cleanup efforts on small network segments, making it possible to restore order more quickly and efficiently.

Figure 3 illustrates an enterprise configured with a network backbone connected to five major offices, with CounterMalice devices located at each connection. One of the offices, Paris, is newly infected.

Figure 3. In this enterprise, a network backbone is connected to five major offices, with CounterMalice worm defense devices located at each connection. The Paris office is newly infected.

Figure 4 illustrates the enterprise after the worm has had some time to spread. The worm has been confined within the Paris cell by the CounterMalice device located on the Paris-to-backbone link. The bar at the bottom of the illustration shows the estimated cost of cleanup and lost service. Without the CounterMalice solution in place, all five offices would have been quickly infected and the total cost of cleanup and lost service would have been far greater.



Figure 4. The same enterprise after the worm has spread. The worm is confined to the Paris cell by the CounterMalice device on the Paris-to-backbone link.

tuning minimizes inappropriate traffic blocks

No matter how one defines suspicious network traffic behavior, an innocent will occasionally appear suspicious. Worm traffic does not carry a red tag, any more than illegal arms traffic does. There is always a degree of educated guesswork. The task of the CounterMalice solution is to block enough of the worm traffic without blocking too much of normal (benign) traffic. Like any behavior-based system, CounterMalice worm defense technology can sometimes overreact, blocking traffic even though no worm is present. It can also underreact, failing to block a worm’s activity before initial infection.

Although these possibilities are inherent in a behavior-based defense, they can be minimized with optimal deployment configuration and tuning. Several mitigating factors are built into the CounterMalice solution to balance the flow and defense of network traffic to achieve optimal levels. CounterMalice can be configured to block traffic only to a particular service under attack by a worm. For example, if a worm is targeting web servers (port 80), CounterMalice can automatically block traffic to all those servers but not others. Whenever possible, CounterMalice blocks traffic only from infected hosts, rather than from all hosts. The effectiveness of a CounterMalice deployment will depend on the type of worm, how the CounterMalice solution is tuned, and the worm’s vulnerability density.



notes about CounterMalice Version 1

CounterMalice devices transmit data at roughly 0.5 gigabits/second total in both directions.

CounterMalice is very effective at blocking fast scanning worms. These worms are among the most commonly seen in the wild today and infect networks faster than any other type of worm. Other worm type defenses are planned.

The CounterMalice solution must observe both client-to-server packets and server-to-client packets in a symmetric routing algorithm.

future directions

Silicon Defense is committed to continually increasing the effectiveness of the CounterMalice worm defense solution. In upcoming releases, innovation will focus on enhancing techniques to provide ever-higher levels of protection, including integrating CounterMalice with the enterprise-wide security infrastructure (including anti-virus products, e-mail worm blocking products, and firewalls) and further technological development to anticipate and develop defenses against additional worm types.

designing a CounterMalice deployment

Central to any CounterMalice deployment design is the concept of dividing the enterprise into cells. Determination of cell boundaries must be based on the protection needs of individual enterprises. Links between cells can be VPN links, provided the CounterMalice device can see unencrypted traffic.

The smaller the size of each cell, the smaller the area in which a worm can be confined and therefore the fewer side effects of a worm defense. These same benefits apply to overreactions: the damage will be less if cells are smaller.



Figure 5 illustrates the preferred configuration, which includes an enterprise backbone that connects to all facilities, with a CounterMalice device located on each backbone connection point.

EnterpriseFirewall

Internet

A cell (facility ornetwor k segment)

Figure 5

Enterprise Backbone

A Counter-Malice

Figure 5. The preferred CounterMalice deployment configuration locates a CounterMalice device on each backbone connection point.

There should be few or no hosts located on the backbone and any hosts that are located there should be particularly well secured. A facility can also have two links but the more alternate paths available for a worm to follow, the less effective CounterMalice defenses will be.

A facility can also be connected to one other facility instead of to the backbone. An alternate configuration is to locate a CounterMalice device between a single facility and the rest of the enterprise, as shown in Figure 6.



EnterpriseFirewall

Internet

Figure 7

Rest of Enterprise

Figure 6. Another deployment design locates the CounterMalice device between a single facility and the rest of the enterprise.

The cell directly connected to the CounterMalice device should be a small set of relatively vulnerable but less critical machines, such as a lab or a desktop area. CounterMalice will do a good job of confining a worm infection to that cell, with a minimum of overreaction. Should the rest of the enterprise become infected, CounterMalice will protect the cell from infection but in doing so will block all traffic to the service under attack. To divide a multi-LAN facility into multiple cells, locate CounterMalice devices on the links between the LANs. To block worms from dial-in machines, place a CounterMalice device between modem banks and the rest of the intranet.

CounterMalice devices must be tuned to minimize overreaction and underreaction. There are two main tuning elements. CounterMalice includes a threshold setting for each service—or destination port representing a service—that is able to govern how much suspicious traffic will be tolerated before it begins blocking traffic to that port. The ideal threshold level depends on how much suspicious traffic normally flows to that service and varies widely from one enterprise to another. For example, an enterprise with many internal web servers will see more suspicious web traffic than an organization with few such servers.

Some hosts will legitimately generate traffic that CounterMalice views as suspicious. File Transfer Protocol (FTP) servers are a good example of this. It is often necessary to give these servers carte blanche to do what they need to do. This approach, though, has its risks. These hosts need to be run with extra security measures in place because if one of them is infected, the worm is free to spread.



For more information, go to www.silicondefense.com

March 2003. CounterMalice and CounterSleuth are trademarks of Silicon Defense. All other product names mentioned herein may be trademarks of their respective companies. Silicon Defense shall not be liable for technical or editorial errors or omissions contained herein. The information is subject to change without notice.

Printed in the U.S.A.

©2003 Silicon Defense


Worm Defense Technical Checklist Silicon Defense is dedicated to protecting public and private networks from intruders and attackers that can cause significant economic and social damage. With more than 80,000 cyberattacks launched worldwide in 2002—at least one-third of those against U.S. sites—the task becomes more and more difficult. We wish to share our knowledge and expertise with the global community of computer scientists in an effort to continually improve defensive strategies that can protect public and private networks against new and malicious worms, denial of service attacks, and other network-based threats. To help the community of security professional manage the sometimes overwhelming task of protecting networks, Silicon Defense makes this useful Worm Defense Technical Checklist available to all.

Setting up the network to impede worms

There are a number of steps any network professional can take to slow worms down—with or without the use of Silicon Defense products. However, these steps will work even better if synergistically deployed with Silicon Defense’s CounterMalice and CounterSleuth defensive solutions.

Step one: Configure servers to be restrictive about releasing information

A worm can query your network servers to determine where other vulnerable servers are likely to be found. Many internal servers are far more open to these queries than is necessary. It is critical that network administrators configure servers to be restrictive about releasing information, as far as your business operation permits.

Specific tasks

Configuration servers to limit the IP address from which a query can arrive

and/or institute a password checking mechanism.

Configure IP traffic routers to give routing information only to other routers,

network administrators, and others who really need the information.

Configure Domain Name Service (DNS) servers to allow zone transfers (bulk

downloads) only by other legitimate DNS servers within the enterprise.

Configure Windows domain controllers and Active Directory servers to give

information only to their local clients and others who really need it.

Ensure that Simple Network Transfer Protocol (SNMP) agents have non-

default community strings.

Ensure that all accounts, even guest accounts, have passwords a worm

author would not know.


Step two: Avoid IP address clustering

Typically, enterprise IP addresses are clustered close together. Unfortunately, this clustering helps worms guess IP addresses in use. Only an in-use IP address can be vulnerable. If you disperse IP addresses, a worm must probe many more times (on average) before it finds a vulnerable host. The specific dispersal tasks listed below will cause a worm to generate more worm traffic and that will give time for other defenses to react before it can spread. Specific tasks

Assign host addresses within a subnet at random rather than going

sequentially from 0 to (for example) 255

Many enterprises have a private address space denoted 10.0.0.0/8 (the

high-order byte of an address is 10 and the other bytes can be any value). If

you have such an address space, you can disperse subnet addresses by

assigning each subnet’s base address at random within your enterprise’s

address space.

Step three: Restrict firewall policies

The enterprise firewall has an essential role in worm defense—it can stop the worm’s entry into the intranet. But to do its work in an optimal way, the firewall must have a restrictive policy. If a single vulnerable server is accessible through the firewall, the worm will infect it and spread from there. Firewalls can also be bypassed. The Nimda worm used e-mail as one of its spread strategies and bypassed the firewall that way. Therefore firewalls do not provide a complete solution but represent a key element in a layered defense. Specific tasks

Avoid firewall configurations that allow outsiders broad access to services

(such as Web servers) within the enterprise

Step four: Use antiviral software

Antiviral software is critical in keeping worms from entering through websites or via e-mail. Specific tasks

Ensure that antiviral software is updated regularly to capture the latest

defenses

Step five: Put Network Intrusion Detection (NID) systems in place

Network Intrusion Detection (NID) systems can detect some kinds of worm activity. While, again, not a complete solution, signature-based NID systems can sometimes detect the activity of worms that attack a known vulnerability. Silicon Defense’s CounterStealth IDS detects low-and-slow surveillance activity that CounterMalice would miss. Specific tasks

II

III

Deploy NID systems—either Silicon Defense Sensors and Managers

products or others—throughout the network.

Maintain NID systems with regular updates to capture the latest defenses

Consider putting defenses designed to defend against low, slow attacks in

place. CounterSleuth from Silicon Defense is the only known solution against

low, slow attacks on the market today.

For more information, go to www.silicondefense.com

March 2003. CounterMalice and CounterSleuth are trademarks of Silicon Defense. All other product names mentioned herein may be trademarks of their respective companies. Silicon Defense shall not be liable for technical or editorial errors or omissions contained herein. The information is subject to change without notice.

Printed in the U.S.A.

©2003 Silicon Defense

worm containment in the internal network

Documents