Anomaly detection uses the assumption that unexpected behavior is evidence of an intrusion. Implicit is the belief that some set of metrics can characterize the expected behavior of a user or a process. Each metric relates a subject and an object.

Denning identifies three different statistical models.

The first model uses a threshold metric. A minimum of m and a maximum of n events are expected to occur (for some event and some values m and n). If, over a specific period of time, fewer than m or more than n events occur, the behavior is deemed anomalous.

Determining the threshold complicates use of this model. The threshold must take into account differing levels of sophistication and characteristics of the users. For example, if n were set to 3 in the example above for a system in France, and the primary users of that system were in the United States, the difference in the keyboards would result in a large number of false alarms. But if the system were located in the United States, setting n to 3 would be more reasonable. One approach is to combine this approach with the other two models to adapt the thresholds to observed or predicted behavior.

The second model uses statistical moments. The analyzer knows the mean and standard deviation (first two moments) and possibly other measures of correlation (higher moments). If values fall outside the expected interval for that moment, the behavior that the values represent is deemed anomalous. Because the profile, or description of the system, may evolve over time, anomaly-based intrusion detection systems take these changes into account by aging (or weighting) data or altering the statistical rule base on which they make decisions.

The statistical moments model provides more flexibility than the threshold model. Administrators can tune it to discriminate better than the threshold model. But with flexibility comes complexity. In particular, an explicit assumption is that the behavior of processes, and users, can be statistically modeled. If this behavior matches a statistical distribution (such as a Gaussian or normal distribution), determining the parameters requires experimental data that can be obtained from the system. But if not, the analysts must use other techniques, such as clustering, to determine the characteristics, the moments, and the values that indicate abnormal behavior. Section 25.3.1.1 discusses one such technique. An additional problem is the difficulty of computing these moments in real time.

Denning's third model is a Markov model. Examine a system at some particular point in time. Events preceding that time have put the system into a particular state. When the next event occurs, the system transitions into a new state. Over time, a set of probabilities of transition can be developed. When an event occurs that causes a transition that has a low probability, the event is deemed anomalous. This model suggests that a notion of “state,” or past history, can be used to detect anomalies. The anomalies are now no longer based on statistics of the occurrence of individual events, but on sequences of events. This approach heralded misuse detection and was used to develop effective anomaly detection mechanisms.

Teng, Chen, and Lu used this approach in Digital Equipment Corporation's TIM research system [993]. Their scheme used an artificial intelligence technique called time-based inductive learning. The system is given a type of event to be predicted. It develops a set of temporally related conditions that predict the time that the event will occur with respect to the set.

open read write open mmap write fchmod close

open    read    write   open
open    mmap    write   fchmod
read    write   open    mmap
write   open    mmap    write
write   fchmod  close
mmap    write   fchmod  close
fchmod  close
close

open read read open mmap write fchmod close

The effectiveness of Markov-based models depends on the adequacy of the data used to establish the model. This data (called training data) is obtained experimentally, usually from populations that are believed to be normal (not anomalous). For example, TIM could obtain data by monitoring a corporate system to establish the relevant events and their sequence. Hofmeyr, Forrest, and Somayaji obtained traces of system calls from processes running in a normal environment. If this training data accurately reflects the environment in which the intrusion detection system is to run, the model will work well, but if the training data does not correspond to the environment, the Markov model will produce false alarms and miss abnormal behaviors. In particular, unless the training data covers all possible normal uses of the system in the environment, the intrusion detection mechanism will issue false reports of abnormalities.

Derivation of Statistics

Central to the notion of anomaly detection is the idea of being able to detect “outliers” or values that do not match, or fall within, a set of “reasonable values.” These outliers are the anomalies, but characterizing a value as abnormal implies that there is a method for characterizing “normal” values. This method is statistical modeling. For example, IDES builds its anomaly detection scheme on the assumption that values of events have a Gaussian distribution. If the distribution is Gaussian, the model works well. If it is not, the model will not match the events, and either too many anomalous events will occur (a high false positive rate) or anomalous events will be missed (a high false negative rate). The former will overwhelm the security officers with data and possibly cause them to miss truly anomalous behavior. The latter will simply not report events that should be reported. Experience indicates, however, that the distribution is typically not Gaussian.

Lankewicz and Benard [616] considered the use of nonparametric statistical techniques—that is, statistical models that do not assume any a priori distribution of events. The technique they used is called clustering analysis and requires some set of data to be available (this data is obtained by monitoring the system for some period of time). The data is then grouped into subsets, or clusters, based on some property (called a feature). Instead of analyzing individual data points, the clusters are analyzed. This greatly reduces the amount of data analyzed, at the cost of some preprocessing time (to cluster the data). This approach is sensitive to the features and the statistical definitions of clustering.

EXAMPLE: Suppose an intrusion detection system bases anomaly detection on the number of reads and writes that a process does. Figure 25-1 shows a sample of the relevant data for a system. Rather than deal with six data points, we cluster them. (In practice, the data sample would be many thousands of values.)

Figure 25-1. Clustering. The relevant measure, CPU time, is clustered in two ways. The first uses intervals of 25th percentiles, and the second uses the 50th percentile.

Our first clustering scheme is to group the data into four clusters. The first cluster contains all entries whose CPU times fall into the first 25th percentile of the data; the second, the entries whose CPU times fall into the second 25th percentile of the data; and so forth. Using this grouping, we have four clusters, with only one value in the last quartile. This could be selected as an anomalous cluster.

Our second clustering reduces the number of clusters to two, divided into those events with CPU times above the 50th percentile, and those with the CPU times below it. Here, the two clusters contain three values each, so no conclusions about anomalies can be drawn.

As this example shows, determining how to cluster the data can be tricky. Even more difficult is determining which features are meaningful. For example, the CPU time used may show anomalies but may not indicate violations of the security policy, but the number of I/O requests may indicate a violation if the data falls into a particular cluster. To overcome this problem, systems using clustering require training data in which the anomalous data indicating intrusions is marked. The feature selection program will use this data to derive features and build clusters that will reflect the anomalous data (to some degree of accuracy).

EXAMPLE: Frank demonstrated how feature selection can aid detection of potential problems [369]. He recounts an experiment in which network traffic was classified by features. Normally, network traffic is characterized by its source and destination port numbers, but on many systems the port numbers and services can be remapped, so (for example) the telnet port could be 3925 rather than the traditional 23. This remapping is internal to the system, and is undetectable unless the contents of the traffic are read and analyzed. Frank used 15,947 network connections obtained by monitoring a local area network to test the classification program. He also gathered port numbers to train the classification program (the assumption being that there was not enough illicit port mapping to corrupt the results).

Frank collected the following characteristics about each connection.

• Index in the set of connections

• Length of time of the connection

• Number of packets from the source to the destination, and vice versa

• Number of data bytes from the source to the destination, and vice versa

• Expert system warning, an indication of how likely the NSM (see Section 25.5.1) thought it was that the event was an attack

Initially, each characteristic was considered as a possible feature. Frank then used three types of algorithms to determine the best feature set to use for classifying connections as suspicious. The first was a backward sequential search algorithm, which began with the full set of features, computed error rates, and eliminated one of the features to reduce the error rate. This continued for some number of steps. For Frank's test data, the error rate was roughly 0.011%. The best set of features used all six recorded characteristics (the index was omitted).

The second algorithm was a beam search algorithm. In this algorithm, a metric ordered the possible clusters from best to worst, took the best, and extended the search from that state. As new potential clusters were generated, they were added to the list. This algorithm achieved the same error rate as the backward sequential search algorithm, and produced a best features set of the same size.

The third algorithm selected sequential data beginning at randomly chosen places in the set of network connections. This generated a random feature set, and then both backward and forward analyses were performed. This was the slowest algorithm and had the same error rate and best features set as those of the other two algorithms.

All three of these algorithms found that if the time in seconds, number of packets from the destination, and number of data bytes from the source were the only three features used, the classification error was less than 0.02%. Adding the other features reduced the error even further.

Frank then considered the set of features that would best classify connections as being of a particular type, such as SMTP (electronic mail) connections. He found that for all three algorithms, the best features set had five features (the index and number of data bytes from the destination were unnecessary), with an error rate of 0.007%. If the number of packets from the source and the expert system warning were omitted, the error rate crept to 0.009%. He obtained similar results for remote login connections (four features, with an error rate of 0.001%). When he analyzed remote command sessions, all algorithms found that the best features set was of size four, but the randomly generated sequential search method chose a different set of features (it omitted the number of destination packets and included the time), and halved the error rate obtained by the other two algorithms.

In some contexts, the term “misuse” refers to an attack by an insider or authorized user. In the context of intrusion detection systems, it means “rule-based detection.”

Modeling of misuse requires a knowledge of system vulnerabilities or potential vulnerabilities that attackers attempt to exploit. The intrusion detection system incorporates this knowledge into a rule set. When data is passed to the intrusion detection system, it applies the rule set to the data to determine if any sequences of data match any of the rules. If so, it reports that a possible intrusion is underway.

Misuse-based intrusion detection systems often use expert systems to analyze the data and apply the rule set. These systems cannot detect attacks that are unknown to the developers of the rule set. Previously unknown attacks, or even variations of known attacks, can be difficult to detect. Later intrusion detection systems used adaptive methods involving neural networks and Petri nets to improve their detection abilities.

EXAMPLE: Kumar and Spafford [601] have adapted colored Petri nets to detect both attack signatures and the actions following previously unknown attacks in their system Intrusion Detection In Our Time (IDIOT). They define an event as a change in the system state. The observation that an “event can represent a single action by a user or system, or it can represent a series of actions resulting in a single, observable record”^[5] is key. They have developed a model of attacks on the UNIX operating system based on temporal ordering of events. Their model classified attacks in five ways.

1. Existence; the attack creates a file or some other entity at some time.

2. Sequence; the attack causes several events to occur sequentially.

3. Partial order; the attack causes two or more sequences of events, and the events form a partial order under the temporal relation.

4. Duration; something exists for an interval of time.

5. Interval; two events occur exactly n units of time apart.

In these attacks, the sequence of events may be interlaced with other events. Regular expressions and attribute- and context-free grammars cannot easily capture this. Hence, Kumar and Spafford use colored Petri nets. Each signature corresponds to an automaton called a Colored Petri Automaton (CPA). The nodes represent tokens; the edges represent transitions. The final state of each signature is the compromised state. Each automaton may have multiple start states (see Figure 25-2). At the beginning, a token is placed in each node corresponding to a start state. As events transition the states, the tokens move from one node along the appropriate edge to the next node.

Figure 25-2. The mkdir attack on pages 667–668 described using a Colored Petri Automaton. The circles represent states, and the thick bars represent the commands causing transitions.

Associated with each transition is a set of expressions protected by (possibly empty) guards. The expressions dictate assignments to variables when the transition is taken, and the guards determine whether or not conditions hold for the transitions to be taken. In a guard or expression, the function “this” instantiates itself to the attributes of the last event. In Figure 25-2, the guard for transition t₄ requires that the UID of the process executing the mknod be 0 but that root not be running it (this[euid] == 0 && this[ruid] != 0). If it is, the variable FILE1 is bound to the true name of the object being created, and the transition is made. Similarly, the guard for transition t₁ (the unlink) requires that the UID of the process not be 0 and that FILE1 be instantiated and be the same as the name of the object being unlinked (FILE1 == true_name(this[obj])). If both hold, the token is moved to s₂, which represents transitioning of the system into a new state.

When transition t₅ occurs, it merges the two branches into one. FILE2 obtains its value from the s₁-s₂-s₃ branch, but the restrictions on the user IDs come from the s₄-s₅ branch. If those conditions are met, the transition t₅ occurs, the tokens merge at node s₆, and the system enters the corresponding (compromised) state.

This model has two important features. The first is the ability to add new signatures dynamically. The partially matched signatures need not be cleared and rematched; existing representations of the CPAs maintain their states. Furthermore, the patterns can be prioritized by ordering the CPAs. Even more, sequences that are known to be likely to occur (perhaps because they were recently published) can be prioritized by appropriately ordering the initial branches of the CPAs.

IDIOT monitors audit logs looking for a sequence of events that correspond to an attack. An alternative point of view is to ignore the actual states and focus on the commands that change them. Researchers at the University of California at Santa Barbara have built several systems that analyze the results of commands to breach a security policy.

EXAMPLE: STAT [508] views a computer as being in a particular state, and commands move it from one state to another. The effect of the command is to cause a state transition. Ilgun, Kemmerer, and Porras use this to model attacks. Ilgun developed the first STAT prototype, called USTAT.

Although the notion of “state” encompasses all data stored on the computer, down to the level of caches and registers, the architects of STAT noted that they needed to track only those portions of the state that affected security. For example, suppose that a process is running as the superuser (UID 0) without authorization. The system has been compromised. But rather than detect the compromised state, STAT looks at the manner in which the user obtained the special privileges. This focuses on transitions. All compromises may be described in this way—that is, a process goes from a limited state to a state in which some other right is acquired. The key to STAT is to find how this can happen.

Associated with each state is a set of assertions. Consider an attack on a UNIX system in which an attacker renames a setuid to root shell script so its name begins with “–”. The user executes it. Because some shells have a bug that makes any invocation of the shell beginning with “–” interactive, the attacker gets superuser privileges.

ln target –s
–s

The state transition diagram is

The state diagram is now augmented to capture the result of the attack by placing postconditions under the state. Let USER be the user's effective UID. The transition of the process into a state where it has superuser privileges means that the effective UID is no longer that of the user:

Finally, the state diagram needs to establish conditions under which the state s1 can be entered. In order to enter that state, the new file name must start with “–” and cannot be owned by USER (otherwise, the user could not acquire additional privileges). Furthermore, it must be a script, it must be setuid, and USER must be able to execute the file. This leads to:

USTAT uses records generated by BSM to obtain system information. A preprocessor extracts events of interest and maps them into USTAT's internal representation. It also removes events in which the attempted system calls failed (because such events do not change the system state).

It then uses an inference engine to determine when a state transition compromising a system occurs. The system has a fact base of seven types of transitions. The first type lists files that no unprivileged user should be able to access (read or write). The second type lists files that no unprivileged user should be able to write to. The third and fourth types list executable programs that are authorized to read from files in the first list and write to files in the second list, repectively. The fifth type lists files that are common places for Trojan horses and should not be deleted nor overwritten. The sixth type lists system directories that users should not be able to write to, and the last type lists UNIX files with multiple names. A rule set uses these types of transitions to constrain the actions that should be reported.

The inference engine constructs a series of state table entries corresponding to the transitions. Consider the attack described above, and suppose that the rule base consists of the one state transition rule above. Initially, the table appears as follows:

	S1	S2
1

because there is one state transition rule with two states. After the first command (the ln), all five preconditions of state S1 are satisfied, so the system creates a new row to represent this:

	S1	S2
1
2	X

The first row will be used if another file is created with the same properties as those in the state transition diagram. The second row asserts that a process has already done so. The attacker now executes the file –x and, because the EUID of the process is no longer that of the user, the system enters S₂. The matrix is not augmented, but the violation is noted. The row remains present until something negates the preconditions on S₁ (such as the file not being a shell script or not being setuid).

The load that USTAT places on a system does not increase as the system load increases, because USTAT reopens log files repeatedly to read new records. Nevertheless, its approach is interesting because, unlike other intrusion detection mechanisms, it focuses on the changes of state rather than on the existing state.

One important feature for intrusion detection systems is an interface into which new users and/or maintainers can add new rules or data. Ranum's Network Flight Recorder is a classic example of how this can be done well.

# list of my web servers
my_web_servers = [ 10.237.100.189 10.237.55.93 ] ;
# we assume all HTTP traffic is on port 80
filter watch tcp ( client, dport:80 )
{
        if (ip.dest != my_web_servers)
                        return;
# now process the packet; we just write out packet info
         record system.time, ip.src, ip.dest to www._list;
}
www_list = recorder("log")

Anomaly detection has been called the art of looking for unusual states. Misuse detection, similarly, is the art of looking for states known to be bad. Specification detection takes the opposite approach; it looks for states known not to be good, and when the system enters such a state, it reports a possible intrusion.

For security purposes, only those programs that in some way change the protection state of the system need to be specified and checked. For example, because the policy editor in Windows NT changes security-related settings, it needs to have an associated specification.

Specification-based detection relies on traces, or sequences, of events [582].

Contrast this with the notion of trace in Chapter 8, “Noninterference and Policy Composition.” This definition uses events as elements of the sequence, whereas the definition in Chapter 8 uses inputs and outputs as elements of the sequence.

For example, if U is the system trace for the system, and V is a system trace for one process in that system, then V will be a subtrace of U.

When a distributed process executes, its trace is the merged trace of its components. The merge of traces U and V is written T = U ⊕ V.

The filter allows the monitoring to weed out events that are of no interest.

For example, if the subject s is composed of processes p, q, and r, with traces T_p, T_q, and T_r, respectively, then the trace of s is T_s = T_p ⊕ T_q ⊕ T_r.

A trace policy takes a set of selection expressions and applies them to the system trace of interest.

< ANY, emacs, ANY, bishop >

< ANY, ANY, nobhill, ANY >

Specification-based intrusion detection is in its infancy. Among its appealing qualities are the formalization (at a relatively low level) of what should happen. This means that intrusions using unknown attacks will be detected. Balanced against this desirable feature is the extra effort needed to locate and analyze the programs that may cause security problems. The subtlety of this last point is brought home when one realizes that any program is a potential security threat when executed by a privileged user.

Reflecting on the differences between the three basic types of intrusion detection will clarify the nature of each type.

Some observations on misuse detection will provide a basis for what follows. Definition 25–3 characterizes misuse detection as detection of violations of a policy. The policy may be known (explicit) or implicit. In the former case, one uses the techniques described in Section 24.4.1 to develop the rules for the misuse detection system. In the latter case, one must describe the policy in terms of actions or states that are known to violate the policy, which calls on the techniques described in Section 24.4.2 to develop the relevant rules. This distinction, although subtle, is crucial. In the first case, the rules database is sufficient to detect all violations of policy because the policy itself was used to populate the rule set. In the second case, the rule set contains descriptions of states and/or actions that are known to violate the policy, but not all such states or actions. This kind of misuse detection system will not detect all violations of system policy.

1.SPEC rdist <?, rdist, *, nobhill>
2.  ENV User U = getuser();
3.  ENV int PID = getpid();
4.  ENV int FILECD[int];
5.  ENV int PATHCD[str];
6.  ENV str HOME = "/export/home/U.name"
7.  SE: <rdist>
8.  <rdist> -> <valid_op> <rdist> |.
9.  <valid_op> -> open_r_worldread
    |   open_r_not_worldread
        {    if !Created(F)
             then violation(); fi; }
    |   open_rw
        {    if !Dev(F)
             then violation(); fi; }
    |   creat_file
        {    if !(Inside(P, "/tmp") or Inside(P. HOME))
             then violation(); fi;
             FILECD[F.nodeid] = 1;
             PATHCD[P] = F.nodeid';}
    |   creat_dir
        {    if !(Inside(P, "/tmp") or Inside(P. HOME))
             then violation(); fi;}
    |   symlink
        {    if !(Inside(P, "/tmp") or Inside(P. HOME))
             then violation(); fi; }
    |   chown
        {    if !(Created(F) and M.newownerid = U)
             then violation(); fi; }
    |   chmod
        {    if !Created(F)
             then violation(); fi; }
    |   rename
        {    if !(PathCreated(P) and Inside(M.newpath, HOME))
             then violation(); fi;}
10. END

Now consider the difference between misuse detection and anomaly detection. The former detects violations of a policy. The latter detects violations of expectation, which may (or may not) violate the policy. For example, TIM uses rules that it derives from logs to construct its Markov model. If the training data contain attacks, the Markov model will accept those attacks as normal. Hence, it is an anomaly detection mechanism. By way of contrast, IDIOT does not construct models from data on the fly. It contains a rule base of sequences that describe known attacks. Hence, it is a misuse detection mechanism.

The distinction between specification-based detection and misuse detection is also worth consideration. The former detects violations of per-program specifications, and makes an implicit assumption that if all programs adhere to their specifications, the site policy cannot be violated. The latter makes no such assumption, focusing instead on the overall site policy. Suppose an attacker could attack a system in such a way that no program violated its specifications but the combined effect of the execution of the programs during the attack did violate the site policy. Misuse intrusion detection might detect the attack (depending on the completeness of the rule set). Anomaly intrusion detection might also detect the attack (depending on the characterization of expected behavior). However, specification-based intrusion detection would not detect this attack. In essence, if the specification of a program is its “security policy,” specification-based detection is a local (per-program) form of misuse detection.

An agent obtains information from a data source (or set of data sources). The source may be a log file, another process, or a network. The information, once acquired, may be sent directly to the director. Usually, however, it is preprocessed into a specific format to save the director from having to do this. Also, the agent may discard information that it deems irrelevant.

The director may determine that it needs more information from a particular information source. In that case, the director can instruct the agent to collect additional data, or to process the data it collects differently. The director can use this to cut down on the amount of processing it must do, but can increase the level of information it receives when an attack is suspected.

An agent can obtain information from a single host, from a set of hosts (in which case it may also function as a director; see Section 25.4.2), or from a network. Let us consider the types of information that are available from each, and how they might be gathered.

Feb 12 14:29:53 nob su: root to bishop on /dev/ttyp5

13285 su       CALL  geteuid
13285 su       RET   geteuid 0
13285 su       CALL  stat(0x28114179,0xbfbfd138)
13285 su       NAMI  "/etc/spwd.db"
13285 su       RET   stat 0
13285 su       CALL  open(0x28114179,0,0)
13285 su       NAMI  "/etc/spwd.db"
13285 su       RET   open 3
13285 su       CALL  fcntl(0x3,0x2,0x1)
13285 su       RET   fcntl 0
13285 su       CALL  read(0x3,0x804e000,0x104)
13285 su       GIO   fd 3 read 260 bytes
13285 su       RET   read 260/0x104
13285 su       CALL  lseek(0x3,0,0x4000,0,0)
13285 su       RET   lseek 16384/0x4000
13285 su       CALL  read(0x3,0x8051000,0x1000)
13285 su       GIO   fd 3 read 4096 bytes
13285 su       RET   read 4096/0x1000
13285 su       CALL  close(0x3)
13285 su       RET   close 0

The director itself reduces the incoming log entries to eliminate unnecessary and redundant records. It then uses an analysis engine to determine if an attack (or the precursor to an attack) is underway. The analysis engine may use any of, or a mixture of, several techniques to perform its analysis.

Because the functioning of the director is critical to the effectiveness of the intrusion detection system, it is usually run on a separate system. This allows the system to be dedicated to the director's activity. It has the side effect of keeping the specific rules and profiles unavailable to ordinary users. Then attackers lack the knowledge needed to evade the intrusion detection system by conforming to known profiles or using only techniques that the rules do not include.

The director must correlate information from multiple logs.

Many types of directors alter the set of rules that they use to make decisions. These adaptive directors alter the profiles, add (or delete) rules, and otherwise adapt to changes in the systems being monitored. Typical adaptive directors use aspects of machine learning or planning to determine how to alter their behavior.

Directors rarely use only one analysis technique, because different techniques highlight different aspects of intrusions. The results of each are combined, analyzed and reduced, and then used.

The notifier accepts information from the director and takes the appropriate action. In some cases, this is simply a notification to the system security officer that an attack is believed to be underway. In other cases, the notifier may take some action to respond to the attack.

Many intrusion detection systems use graphical interfaces. A well-designed graphics display allows the intrusion detection system to convey information in an easy-to-grasp image or set of images. It must allow users to determine what attacks are underway (ideally, with some notion of how likely it is that this is not a false alarm). This requires that the GUI be designed with a lack of clutter and unnecessary information.

EXAMPLE: The Graphical Intrusion Detection System (GrIDS) [963] uses a graph-oriented user interface to show the progress of attacks across multiple systems. The hosts are represented as nodes, and as an attack from one system to another is identified, the nodes are connected with edges labeled to show the progress of the attack. Figure 25-5 is an example of one of the user displays of GrIDS. It shows the progress of a worm attack as it progresses through a network.

Figure 25-5. An example of GrIDS output showing the spread of a worm. The left figure shows the graph shortly after the spread has begun. The right figure shows the graph after further spread.

The notifier may send electronic mail to the appropriate person or make entries into the appropriate log files.

EXAMPLE: The Intrusion Detection and Isolation Protocol (IDIP) [887] provides a basis for coordinating intrusion detection systems residing on firewalls to block attacks over a network. Figure 25-6 shows a site with three firewalls monitoring traffic from the Internet. If intrusion detection systems on hosts A and B detect a coordinated attack, they can inform host C, which can then reject packets from the source(s) of the attack.

Figure 25-6. Site with three firewalls, each of which has an intrusion detection system running the IDIP protocol.

Incident response is a type of notification. In addition to any human-intelligible notifications, the intrusion detection system communicates with other entities to counteract the attack. Responses include disconnecting from the network, filtering packets from attacking hosts, increasing the level of logging, and instructing agents to forward information from additional sources.

The Network Security Monitor (NSM) [459] develops a profile of expected usage of a network and compares current usage with that profile. It also allows the definition of a set of signatures to look for specific sequences of network traffic that indicate attacks. It runs on a local area network and assumes a broadcast medium. The monitor measures network utilization and other characteristics and can be instructed to look at activity based on a user, a group of users, or a service. It reports anomalous behavior.

The NSM monitors the source, destination, and service of network traffic. It assigns a unique connection ID to each connection. The source, destination, and service are used as axes for a matrix. Each element of the matrix contains the number of packets sent over that connection for a specified period of time, and the sum of the data of those packets. NSM also generates expected connection data from the network. The data in the array is “masked” by the expected connection data, and any data not within the expected range is reported as an anomaly.

The developers of the NSM quickly found that too much data was being generated during the network analysis. To reduce the overhead, they constructed a hierarchy of elements of the matrix and generated expected connection data for those elements. If any group in the hierarchy showed anomalous data, the system security officer could ask the NSM to break it down into the underlying elements. The groups were constructed by folding axes of the matrix. For example, one group would be the set of traffic between two hosts for each service. It would have the elements { (A, B, SMTP), (A, B, FTP), … }, where A and B were host names. The next group would collapse the service names and simply group all traffic into source-destination pairs. At the highest level, traffic would be grouped into its source. The NSM would analyze the data at the source level. If it flagged an anomaly, the system security officer could have the NSM examine each component of the underlying group and determine which specific source-destination pair had the anomaly. From there, it could be broken into the specific service or services involved.

The NSM's use of a matrix allowed a simple signature-based scheme to look for known patterns of misuse. For example, repeated telnet connections that lasted only as long as the normal setup time would indicate a failed login attempt. A specific rule could look in the matrix for this occurrence (although, as the designers point out, these patterns can be hidden as one moves up the hierarchy).

The implementation of the NSM also allowed the analyst to write specific rules against which to compare network traffic. The rules initially used were to check for excessive logins, a single host communicating with 15 or more hosts, or any attempt to communicate with a nonexistent host.

The NSM provided a graphical user display to enable the system security officer to see at a glance the state of the network. Furthermore, the display manager was independent of the NSM matrix analyzer, so the latter could devote full time to the analysis of the data. The prototype system, deployed at the University of California at Davis, detected many attacks. As with all intrusion detection systems, it also reported false positives, such as alumni logging into accounts that had laid dormant for some time. But its capabilities revealed the need for and feasibility of monitoring the network as well as individual hosts.

The NSM is important for two reasons. First, it served as the basis for a large number of intrusion detection systems. Indeed, 11 years after its creation, it was still in use at many sites (although with an augmented set of signatures). Second, it proved that performing intrusion detection on networks was practical. As network traffic becomes enciphered, the ability to analyze the contents of the packets diminishes, but NSM did not look at the contents of the traffic. It performed traffic analysis. Hence, its methodology will continue to be effective even after widespread deployment of network encryption.

The Distributed Intrusion Detection System (DIDS) [940] combined the abilities of the NSM with intrusion detection monitoring of individual hosts. It sprang from the observation that neither network-based monitoring nor host-based monitoring was sufficient. An intruder attempting to log into a system through an account without a password would not be detected as malicious by a network monitor. Subsequent actions, however, might make a host-based monitor report that an intruder is present. Similarly, if an attacker tries to telnet to a system a few times, using a different login name each time, the host-based intrusion detection mechanism would not report a problem, but the network-based monitor could detect repeated failed login attempts.

DIDS used a centralized analysis engine (the DIDS director) and required that agents be placed on the systems being monitored as well as in a place to monitor the network traffic. The agents scanned logs for events of interest and reported them to the DIDS director. The DIDS director invoked an expert system that performed the analysis of the data. The expert system was a rule-based system that could make inferences about individual hosts and about the entire system (hosts and networks). It would then pass results to the user interface, which displayed them in a simple, easy-to-grasp manner for the system security officer.

One problem is the changing of identity as an intruder moves from host to host. An intruder might gain access to the first system as user alice, and then to the second system as user bob. The host-based mechanisms cannot know that alice and bob are the same user, so they cannot correlate the actions of those two user names. But the DIDS director would note that alice connected to the remote host and that bob logged in through that connection. The expert system would infer that they were the same user. To enable this type of correlation, each user was identified by a network identification number (NID). In the example above, because alice and bob are the same user, both would share a common NID.

The host agents and network agent provide insight into the problems distributed intrusion detection faces. The host logs are analyzed to extract entries of interest. In some cases, simple reduction is performed to determine if the records should be forwarded; for example, the host agents monitor the system for attacks using signatures. Summaries of these results go to the director. Other events are forwarded directly. To capture this, the DIDS model has host agents report events, which are the information contained in the log entries, and an action and domain (see Figure 25-7). Subjects (such as active processes) perform actions; domains characterize passive entities. Note that a process can be either a subject (as when it changes the protection mode of a file) or an object (as when it is terminated). An object is assigned to the highest-priority domain to which it belongs. For example, a file may be tagged as important. If the file contains authentication data and also is tagged, it will be reported as a tagged object. A hand-built table dictates which events are sent to the DIDS director based on the actions and domains associated with the events. Events associated with the NID are those with session_start actions, and execute actions with network domains. These actions are forwarded so that the DIDS director can update its system view accordingly.

Figure 25-7. DIDS actions and domains. The two left columns name the types of action; the right two, the types of domains. The domains are listed in order of priority, from top to bottom.

The network agent is a simplified version of the NSM. It provides the information described above.

The expert system, a component of the DIDS director, derives high-level intrusion information from the low-level data sent to it. The rule base comes from a hierarchical model of intrusion detection. That model supplies six layers in the reduction procedure.

Within the expert system, each rule has an associated rule value. This value is used to calculate the score. The system security officer gives feedback to the expert system, and if false alarms occur, the expert system lowers the value associated with the rules leading to the false alarm.

A later system, GrIDS, extended DIDS to wide area networks. In addition to monitoring hosts and network traffic, the GrIDS directors could obtain data from network infrastructure systems (such as DNS servers). As mentioned earlier (see Figure 25-5), GrIDS deployed a hierarchy of directors, each one reducing data from its children (agents or other directors) and passing the information to its parent. GrIDS directors can be in different organizations. This leads to the ability to analyze incidents occurring over a wide area, and to coordinate responses.

In 1995, Crosbie and Spafford examined intrusion detection systems in light of fault tolerance [248]. They noted that an intrusion detection system that obtains information by monitoring systems and networks is a single point of failure. If the director fails, the IDS will not function. Their suggestion was to partition the intrusion detection system into multiple components that function independently of one another, yet communicate to correlate information.

Crosbie and Spafford suggested developing autonomous agents each of which performed one particular monitoring function. Each agent would have its own internal model, and when the agent detected a deviation from expected behavior, a match with a particular rule, or a violation of a specification, it would notify other agents. The agents would jointly determine whether the set of notifications were sufficient to constitute a reportable intrusion.

The beauty of this organization lies in the cooperation of the agents. No longer is there a single point of failure. If one agent is compromised, the others can continue to function. Furthermore, if an attacker compromises one agent, she has learned nothing about the other agents in the system or monitoring the network. Moreover, the director itself is distributed among the agents, so it cannot be attacked in the same way that an intrusion detection system with a director on a single host can be. Other advantages include the specialization of each agent. The agent can be crafted to monitor one resource, making the agent small and simple (and meeting the principle of economy of mechanism; see Section 13.2.3). The agents could also migrate through the local network and process data on multiple systems. Finally, this approach appears to be scalable to larger networks because of the distributed nature of the director.

The drawbacks of autonomous agents lie in the overhead of the communications needed. As the functionality of each agent is reduced, more agents are needed to monitor the system, with an attendant increase in communications overhead. Furthermore, the communications must be secured, as must the distributed computations.

Ideally, intrusion attempts will be detected and stopped before they succeed. This typically involves closely monitoring the system (usually with an intrusion detection mechanism) and taking action to defeat the attack.

In the context of response, prevention requires that the attack be identified before it completes. The defenders then take measures to prevent the attack from completing. This may be done manually or automatically.

Amoroso [22] points out that multilevel secure systems are excellent places to implement jails, because they provide much greater degrees of confinement than do ordinary systems. The attacker is placed into a security compartment isolated from other compartments. The built-in security mechanisms are designed to limit the access of the subjects in the compartment, thereby confining the attacker.

More sophisticated host-based approaches may be integrated with intrusion detection mechanisms. Signature-based methods enable one to monitor transitions for potential attacks. Anomaly-based methods enable one to monitor relevant system characteristics for anomalies and to react when anomalies are detected in real time.

When an intrusion occurs, the security policy of the site has been violated. Handling the intrusion means restoring the system to comply with the site security policy and taking any actions against the attacker that the policy specifies. Intrusion handling consists of six phases [779].

In the following discussions, we focus on the containment, eradication, and follow-up phases.

Eradication Phase

Eradicating an attack means stopping the attack. The usual approach is to deny access to the system completely (such as by terminating the network connection) or to terminate the processes involved in the attack. An important aspect of eradication is to ensure that the attack does not immediately resume. This requires that attacks be blocked.

A common method for implementing blocking is to place wrappers around suspected targets. The wrappers implement various forms of access control. Wrappers can control access locally on systems or control network access.

EXAMPLE: Wrappers that control local access to resources are usually embedded in the kernel to make them difficult to bypass. In an experiment that used wrappers to improve the security of commercial off-the-shelf programs, Fraser, Badger, and Feldman [372] used loadable kernel modules to place wrappers in the kernels of UNIX systems. When the wrappers were invoked, they waited for some specified event (such as a system call, possibly with particular privilege settings or arguments). When the event occurred, the wrapper would take control of the process and perform a specified action. The action could be to log the call, to deny access (by returning a failure code to the caller), or to generate and process auxiliary data such as system call counts. The wrappers were specified using an extension of the C programming language. The performance impact of using the wrappers was less than 7%.

The researchers noted that the wrappers' uses were varied, ranging from access control and auditing to intrusion detection and response. Others [581] focused on the latter, designing wrappers that would detect intrusions. Their mechanism accepted notifications from multiple wrappers. In one experiment, when two wrappers notified a wrapper monitoring program execution that a process appeared to be launching an attack, the monitoring wrapper terminated the process.

EXAMPLE: Wrappers can also control access from the network. Bina, McCool, Jones, and Winslett [99] describe an application in which a Web server accepts requests for database records and returns the desired records if so authorized. Access to the records is determined by the role of the requester. To determine this, the Web server obtains information from the client (including a public key for authentication) and passes the data to a script that assigns the appropriate role to the request. The role and request are given to the database engine, which returns an appropriate response. The script is a wrapper around the database. It mediates access to the database.

Firewalls (see Section 26.3.1) are systems that sit between an organization's internal network and some other external network (such as the Internet). The firewall controls access from the external network to the internal network and vice versa. The advantage of firewalls is that they can filter network traffic before it reaches the target host. They can also redirect network connections as appropriate, or throttle traffic to limit the amount of traffic that flows into (or out of) the internal network.

EXAMPLE: Because Java applets (see Section 4.5.1) come from (usually) untrusted sources, many organizations want to block the applets from entering their internal networks. A simple method of doing this is to block the applets at a firewall [662]. When an HTTP connection is made through the firewall, the firewall creates a small application (called a proxy) to reassemble the packets and determine if they contain a Java applet. The proxy then may use one of three approaches to block the applet.

First, it can rewrite the HTML tag to something other than “<applet>”. When the page is delivered to the browser, the browser will not recognize the applet and will not run it. This method requires the firewall to determine that the connection is indeed an HTTP connection and to parse the HTML in that connection. Both are nontrivial tasks.

The second approach is to look for incoming files with the hexadecimal sequence CA FE BA BE. All Java class files must contain this four-byte signature in order to be properly recognized and interpreted. If this sequence is found, the file is immediately discarded. The danger here is a false positive. Because ActiveX and Javascript code are different, this approach cannot block those types of applets.

The third approach is to block based on file name, but this is far more problematic because the names do not necessarily represent the contents of the file. Many browsers require Java class files to end in “.class”. The firewall can block these applets. However, more recent browsers allow Java class files to be combined into archives. The names of these archives often end in “.zip”. This is a popular format among users of MS-DOS and Windows, so it is not realistic to block all such files.

Martin, Rajagopalan, and Rubin [662] conclude that the situation is rather bleak for stopping Java applets at the firewall.

An organization may have several firewalls on its perimeter, or several organizations may wish to coordinate their responses. The Intruder Detection and Isolation Protocol [887] provides a protocol for coordinated responses to attacks.

The IDIP protocol runs on a set of computer systems. A boundary controller is a system that can block connections from entering a perimeter. Typically, boundary controllers are firewalls or routers. A boundary controller and another system are neighbors if they are directly connected. If they send messages to one another, the messages go directly to their destination without traversing any other system. If two systems are not boundary controllers and can send messages to each other without the messages passing through a boundary controller, they are said to be in the same IDIP domain. This means that the boundary controllers form a perimeter for an IDIP domain.

When a connection passes through a member of an IDIP domain, the system monitors the connection for intrusion attempts. If one occurs, the system reports the attempt to its neighbors. The neighbors propagate information about the attack and proceed to trace the connection or datagrams to the appropriate boundary controllers. The boundary controllers can then coordinate their responses, usually by blocking the attack and notifying other boundary controllers to block the relevant communications.

EXAMPLE: Kahn and Zurko [535] discuss the use of IDIP to handle network flooding attacks, in which one or more sources spew large numbers of packets to a target. This effectively prevents legitimate traffic from being processed, either because the target is overwhelmed with processing the flooding packets or because the legitimate traffic cannot reach the destination (target).

Consider Figure 25-8. Suppose host f launches a flooding attack against host A along the path f, Z, Y, X, W, a, A. The flood effectively stops all traffic along that path. Host a detects the flood and begins blocking traffic for host A. It also notifies its neighbor W, a boundary controller. W detects traffic targeting A, suppresses it, and notifies its neighbor X. X detects the traffic targeting A, suppresses it, and notifies its neighbors Y and C. W then notices the traffic for A has stopped, and it eliminates its suppression. At this point, A, a, W, and b can again communicate freely, because the traffic formerly saturating the links has been eliminated by X. C detects no traffic for A and so does nothing. Y does detect the traffic, and suppresses it. X detects that the traffic going through it for A has stopped, and X eliminates its suppression. Y then communicates with Z, and Z detects and suppresses the traffic. Y also communicates with D, which detects no relevant traffic. This process continues until all traffic from f to A is suppressed.

Figure 25-8. Example of IDIP. C, D, W, X, Y, and Z are boundary controllers. Host a runs the IDIP protocol but is not a boundary controller. The flooding attack follows the dashed arrows from f to A.

The IDIP protocol is flexible, because if multiple sources attempt to flood a host, the boundary controllers will block the traffic along each path that the sources use. Of course, if any path has no IDIP controllers, the traffic can flow freely along that path. Kahn and Zurko suggest that IDIP, or a similar protocol, should be widely deployed throughout the Internet to handle flooding attacks. They argue that economic and other incentives will encourage Internet Service Providers and other network providers to cooperate in suppressing distributed flooding attacks.

Follow-Up Phase

In the follow-up phase, the systems take some action external to the system against the attacker. The most common follow-up is to pursue some form of legal action, either criminal or civil. The requirements of the law vary among communities, and indeed vary within communities over time. So, for our purposes, we confine ourselves to the technical issue of tracing the attack through a network. Two techniques for tracing are thumbprinting and IP header marking.

Thumbprinting [460, 964] takes advantage of connections passing through several hosts. An attacker may go from one host, through many intermediate hosts, until he attacks his target. If one monitors the connections at any two hosts that the connections pass through, the contents of the connections will be the same (excluding data added at the lower layers). By comparing contents of connections passing through hosts, one can construct the chain of hosts making up the connections.

Staniford-Chen and Heberlein [964] list five characteristics of a good thumbprint.

1. The thumbprint should take as little space as possible, to minimize storage requirements at each site.

2. If two connections have different contents, the probability that their thumbprints are the same should be low. Notice that two connections with identical contents will have the same thumbprint. This is a consequence of the thumbprint being computed over the contents of the connection.

3. The thumbprint should be affected minimally by common errors in transmission. Thus, if traffic between two hosts often has some bits discarded, the thumbprints of the connections at both hosts should be close enough to identify them as belonging to the same connection. (Recall that thumbprints are computed passively, and that the thumbprinting program may not have access to the error correction features of TCP.)

4. Thumbprints should be additive so that two thumbprints over successive intervals can be combined into a single thumbprint for the total interval.

5. Finally, thumbprints should cost little to compute and compare.

There are several possible sources of error (see Exercise 8).

EXAMPLE: Staniford-Chen and Heberlein [964] experimented with thumbprints made up of linear combinations of character frequencies in telnet and rlogin connections. The thumbprints were computed over a set of connections drawn from normal network traffic. First, a control experiment checked that thumbprints were unlikely to match randomly paired connections. Out of 4,000 pairings, only one match was reported. On inspection, the two connections had identical contents over the period of thumbprinting (a prompt and a logout command). Next, they computed thumbprints from connections passing through multiple hosts (one thumbprint per host for each connection) on a local area network. These thumbprints were injected into a collection of thumbprints made at the same time. Comparison identified these thumbprints as belonging to the same connections. Experiments on long haul networks (across the United States and the Atlantic Ocean) also showed that the comparison procedure was able to find the connections correctly.

An alternative approach is to ignore the contents of the packets and examine the headers. IP header marking does just this. A router places extra information into the IP header of each packet to indicate the path that the packet has taken. This information may be examined in order to to trace the packet's route back through the Internet [880].

The keys to IP header marking are selection of the packets to mark, and marking of the packets. Packet selection may be deterministic or probabilistic. Packet marking may be internal or expansive.

Deterministic packet selection means that packets are selected on the basis of a deterministic, nonrandom algorithm. For example, every second packet may have the router's IP address inserted as the marking. In general, deterministic packet selection is too expensive and unreliable. It is unreliable because an attacker can enter false data into the header area and prevent the marking (see Exercise 10). In probabilistic packet selection, packets are selected with some given probability.

Internal packet marking places the router's marking in the packet header without expanding it. For example, Dean, Franklin, and Stubblefield [263] have identified several bits in an IPv4 header that could be used for marking. Expansive packet marking means that the packet header is expanded to include extra space for the marking.

EXAMPLE: Doeppner, Klein, and Koyfman [305] suggest a probabilistic, expansive packet marking scheme. They propose adding space (“slots”) for s markings. The probability that a packet will be marked is p. The following algorithm describes how the router handles an incoming packet.

/* generate random number between 0, 1 */
x = random(0, 1);
/* stamp the packet appropriately */
if x < s * p then
      slot[x/p] = router's stamp;

Note that the slot into which the router's marking is placed depends on the random number generated.

The markings can enable one to trace certain attacks back to their sources. As an example, consider the SYN flood attack [255], in which an attacker generates a large number of TCP SYN packets (see Section 26.4). The target receives them and sends the SYN/ACK packet in the second step of the three-way handshake (see Section 24.4.2). The attacker never sends the third packet, so the connection is pending until it times out. At that point, the target grabs the next incoming SYN packet and repeats the cycle. Because the attacker is flooding the target with SYN packets, the probability of any other host's SYN packet initiating the three-way handshake is very low. The attack therefore denies service to all other hosts.

Consider the network in Figure 25-9. Host E experiences a SYN flood. The administrators identify 3,150 packets that could be a result of the attack. Of these packets, 600 have the route (A, B, D), 200 have the route (A, D), 150 have the route (B, D), 1,500 have the route (D), 400 have the route (A, C), and 300 have the route (C). Counting, there are 1,200 packets with A's mark, 750 with B's mark, 700 with C's mark, and 2,450 with D's mark. Assuming that the probability of marking is the same on each router, the number of packets that D received is more than three times as great as the number that B received. Thus, B is probably the source of the flooding.

Figure 25-9. Example network. Routers A, B, C, and D mark packets. The destination host E is experiencing a SYN flood. The administrators at host E use the markings to identify the flooder.

EXAMPLE: Dean, Franklin, and Stubblefield [263] employ an algebraic technique to encode suffixes of the paths taken by packets. Evaluating an nth-degree polynomial requires n + 1 data points. Consider the packets being sent from host A to host B along path P. The first router in path P labels the jth packet with the integer x_j. Let the routers' IP addresses on path P be a₀, ..., a_n. Then, when the jth packet arrives at B, its marking will be the value of the polynomial f(x) = a₀xⁿ + ^... + a_n at x_j. When n + 1 packets along that path arrive, the coefficients of the polynomial can be determined. Note that the routers can use Horner's rule [578] to evaluate the polynomial, so they need not know the path P. Router a_i needs to know a₀ x_jⁱ + ^... + a_i–1. It then computes (a₀ x_jⁱ + ^... + a_i–1)x_j + a_i.

This approach has several problems. First, recording the entire path requires that a router know it is the first router on path P so that it can assign x_j and begin computing the polynomial. This is infeasible given the current structure of the Internet. One approach is to select a number from a weighted random distribution of integers to determine if the router is the first on P. If so, it assigns x_j; if not, the router evaluates the polynomial as described above. Furthermore, if x_j is assigned, the router assigns similar values to the next k packets (k being a tunable parameter). This increases the number of packets needed to reconstruct the full path. Moreover, an attacker can place arbitrary information into the marking, so if the router does not select the packet for marking, the erroneous information is passed along. Ultimately, the destination will not be able to distinguish the erroneous information from legitimate packet markings.

An alternative approach modifies the scheme so that at most l routers mark the packet. The first router sets this parameter; each marking router decrements it by 1. This scheme records subsequences of P, rather than suffixes of P or the entire path. This keeps the degree of the polynomials small (of degree l – 1 at most).

Dean, Franklin, and Stubblefield used this last scheme to mark packets. The bits of the values of the polynomials were distributed over 11 bits in the IP header. In their simulations, they analyzed 20,000 packets and recovered paths of length 25 more than 98% of the time, demonstrating the efficacy of their scheme.

Counterattacking, or attacking the attacker, takes two forms. The first form involves legal mechanisms, such as filing criminal complaints. This requires protecting a “chain of evidence” so that legal authorities can establish that the attack was real (in other words, that the attacked site did not invent evidence) and that the evidence can be used in court. The precise requirements of the law change over time and jurisdictions, so this first form of counterattacking lies outside the scope of this discussion. The second form is a technical attack, in which the goal is to damage the attacker seriously enough to stop the current attack and discourage future attacks. This approach has several important consequences that must be considered.

1. The counterattack may harm an innocent party. The attacker may be impersonating another site. In this case, the counterattack could damage a completely innocent party, putting the counterattackers in the same position as the original attackers. Alternately, the attackers may have broken into the site from which the attack was launched. Attacking that host does not solve the problem. It merely eliminates one base from which future attacks might be launched.

2. The counterattack may have side effects. For example, if the counterattack consists of flooding a specific target, the flood could block portions of the network that other parties need to transit, which would damage them.

3. The counterattack is antithetical to the shared use of a network. Networks exist to share data and resources and provide communication paths. By attacking, regardless of the reason, the attackers make networks less usable because they absorb resources and make threats more immediate. Hence, sites must protect themselves by limiting the sharing and communication on the network beyond what is needed for their safe operation.

4. The counterattack may be legally actionable. If an attacker can be prosecuted or sued, it seems reasonable to assume that one who responds to the attack by counterattacking can also be prosecuted or sued, especially if other innocent parties are damaged by the counterattack.

Under exceptional circumstances, counterattacking may be appropriate. In general, it should be avoided, and legal avenues of prosecution (either civil or criminal) should be pursued. Improving defenses will also hinder attacks. The efforts used to develop and launch counterattacks could be spent far more effectively in that way.

EXAMPLE: Recall the example of the two versions of the animal game (see page 586). In that case, the new version of animal targeted a specific, older version written by the same authors, and it was unlikely that any organization depended on the existence of that game. Consider moving this example into the world of distributed systems and networks. Imagine a computer worm that enters systems through a widely used network server. The worm spreads rapidly, and despite attempts to eradicate it, systems continue to be reinfected. One company designs a “counterworm.” Whenever a break-in comes from a remote site, the “counterworm” detects the break-in, deletes the connection, and uses the same infection technique as that of the original worm to enter the attacking host. On that host, it deletes all worm processes (except its own). It then waits until that system is attacked, and the cycle repeats.

This response raises several questions. First, how can the “counterworm” be set to ensure that it deletes only those processes belonging to the original worm? Second, what if the invaded machine is gathering data for research or countermeasures? Third, how can the originators of the “counterworm” ensure that it does no damage to any system it is sent to? Fourth, can they be held legally liable for any problems that a site encounters if that site is sent the “counterworm”? The answers to these questions are complex, and illustrate clearly why one needs informed, full consent of a remote site before sending an automated response.