Putting Attack Tracing in Context

Attack tracing is often a misunderstood and misused concept. This section explores what attack tracing is, the costs versus benefits, and reasons for wanting to trace attacks.

Attack Tracing Versus Intrusion Tracing

Sometimes attack tracing is erroneously equated to intrusion tracing. As mentioned in Chapter 1,"An Introduction to Incident Response," however, an intrusion is just one of many types of security- related incidents. Suppose, for example, that a DDoS attack occurred recently. A victim organization might want to determine where this attack originated. The only intrusions per se that might have occurred are ones in which zombies and handlers have been installed in systems, although many of today's attack techniques do not require any kind of actual break-in to result in the introduction of Trojan horse programs in victim systems. Exploiting bugs in NFS, the network file system, to write-mount a volume and then transfer malicious programs to the victim system is a good example.

Tracing vulnerability scans is a special problem. In most network environments, vulnerability scans occur almost constantly. Tracing scans cannot realistically be considered a type of intrusion tracing per se. The term "attack tracing" fits better (see the following sidebar), but perhaps "scan tracing" is the most appropriate term . Most importantly, however, tracing the source of scans is likely to be extremely unproductive because a large number of scans are initiated from legitimate hosts that have been compromised by attacks. Furthermore, the sheer number of scans that occur every day makes the prospect of tracing the origin extremely unrealistic . Although it is wise to pay attention to the problem of scans, tracing their origin is, in most cases, not a good use of time and resources.

Vulnerability Scans: Intrusions, Attacks, or ???

Vulnerability scans, unfortunately , occur almost incessantly. Users who have a cable modem or DSL connection to their ISP and who use a personal firewall usually discover that their systems are first scanned only a few minutes after they log in. What are scans, anyway? Are they a type of intrusion, simply an attack, or what? This issue is a matter of debate. Scans are usually not considered intrusions, yet some scan tools actually attempt to gain shell access to systems, at least in the process of testing for vulnerabilities in certain services such as FTP. Many information security professionals do not consider scans to be attacks, but rather simply a form of information gathering (parallel in many respects to using a search engine on the Internet). Others (the authors of this book included) consider scans to be attacks but very low-level ones. Regardless of how scans are labeled, their constant occurrence constitutes a clear and present danger. Well-configured external firewalls and commitment to promptly installing patches for known vulnerabilities are two good countermeasures.

Relationship to the PDCERF Methodology

Chapter 3,"A Methodology for Incident Response," covered the PDCERF methodology. How is attack tracing related to this methodology, and to what particular stage(s) is attack tracing most related? The answer is that it is most closely tied in with the detection, containment, and eradication stages. Let's consider why.

Detection

Attack tracing is related to detection because, many times, tracing an event to a particular IP address will help incident response personnel conclude that a connection or flow of packets across the network is not legitimate. Consider, for example, the meaning of a network connection (such as a telnet connection) from a known hostile address. If there is no possible legitimate purpose for such a connection, there is really no logical conclusion other than this connection represents a security-related incident.

Containment

Attack tracing is also related to containment in that knowing the source of an incident can help those involved in handling the incident take corrective measures to limit the spread of an incident. Knowing that an attack on hosts within one's internal network has originated from a particular IP address enables incident response staff or automated mechanisms to change router or firewall filtering rules to block traffic from that address.This course of action can slow down or halt an attack.

Eradication

Knowing the source of an attack can also help eradication efforts. Attackers might, for example, include bogus entries in critical files such as .rhost or /etc/hosts.equiv files in UNIX and Linux hosts, enabling them to gain back-door entrance to victim hosts. Discovering and then deleting these entries can eliminate the access avenue(s) used by attackers.

Considering Costs Versus Benefits

Weighing costs versus benefits is integral to everything done in the practice of computer and information security. Tracing network intrusions is no exception. An organization with extensive computing resources and with extensive connectivity to the outside will experience many hundreds, sometimes thousands, of attacks every day. It is not practical to respond to every attack let alone trace the source of the attack. Tracing the source involves even a greater level of effort and resources. It is important, therefore, to have a policy that specifies when intrusions must (or at least may ) be traced or, perhaps more realistically, to assign priorities related to the need to trace each incident and then trace attacks that have the highest priority when many attacks occur simultaneously. Perhaps tracing lower priority attacks should be attempted when only a few attacks occur simultaneously , or perhaps lower priority attacks do not need to be traced at all. Again, an organization's policy concerning whether attacks should be traced ‚ and, if so, to what extent ‚ is the key.

Motivation for Tracing Attacks

A few organizations have a policy that specifies that attacks must not (except perhaps in extraordinary circumstances) be traced. The normal rationale for such a policy is one (or all) of the following:

• Tracing attacks could result in leakage of information about the incident, something that could potentially embarrass or disrupt the organization.

• Tracing attacks requires more time and resources than are available because the organization in question has a plethora of attacks.

• Tracing attacks represents a violation of the organization's security policy. The policy is to simply close off attacks and get back to normal as soon as possible (see the following sidebar).

Do No Evil, See No Evil?

As just mentioned, certain organizations have adapted the approach that when security-related incidents occur, staff members must not attempt to trace the origin of the attack. When the attack is shut off or discontinued, victim systems and network devices are rebuilt, and any potentially compromised data are restored. This approach is the "Do No Evil, See No Evil" approach.

Although relatively few organizations have such a policy, it is important to understand that one option for dealing with the possibility of tracing attacks is to squelch tracing attacks altogether. Although an often-used approach in the past, the majority of organizations today do not adopt this approach. One major reason is that organizations that adhere to this philosophy do not really learn anything useful from attacks that occur. In most circumstances, it is profitable to at least understand where attacks originate so that firewall and/or filtering rules can be modified. Additionally, this approach virtually precludes efforts to discover the nature of the threat to an organization's systems and networks. This approach also precludes cooperation with law enforcement agencies.