Snort Intrusion Detection and Prevention Toolkit

www.sans.edu

Intrusion Detection Systems

Solutions in this chapter

What Is Intrusion Detection?

How an IDS Works

Why Are Intrusion Detection Systems Important?

What Else Can You Do with Intrusion Detection Systems?

What About Intrusion Protection?

Summary

Solutions Fast Track

Frequently Asked Questions

Introduction

The principle of intrusion detection isn’t new. Whether it’s car alarms or closed-circuit televisions, motion detectors or log analyzers, many folks with assets to protect have a vested interest in knowing when unauthorized persons are probing their defenses, sizing up their assets, or running off with crucial data. In this book, we’ll discuss how the principles of intrusion detection are implemented with respect to computer networks, and how using Snort can help overworked security administrators know when someone is running off with their digital assets.

All right, this might be a bit dramatic for a prelude to a discussion of intrusion detection, but most security administrators experience a moment of anxiety when a beeper goes off. Is this the big one? Did they get in? How many systems could have been compromised? What data was stored on or accessible by those systems? What sort of liability does this open us up to? Are more systems similarly vulnerable? Is the press going to have a field day with a data leak?

These and many other questions flood the mind of the well-prepared security administrator. On the other hand, the ill-prepared security administrator, being totally unaware of the intrusion, experiences little anxiety. For him, the anxiety comes later.

Okay, so how can a security-minded administrator protect his network from intrusions? The answer to that question is quite simple. An intrusion detection system (IDS) can help to detect intrusions and intrusion attempts within your network, allowing a savvy admin to take appropriate mitigation and remediation steps. A pure IDS will not prevent these attacks, but it will let you know when they occur.

What Is Intrusion Detection?

Webster’s defines an intrusion as the act of thrusting in, or of entering into a place or state without invitation, right, or welcome. When we speak of intrusion detection, we are referring to the act of detecting an unauthorized intrusion by a computer on a network. This unauthorized access, or intrusion, is an attempt to compromise, or otherwise do harm, to other network devices.

A body of American legislation surrounds what counts as a computer intrusion, but although the term computer intrusion is used to label the relevant laws, there is no single clear and useful definition of a computer intrusion. Title 18, Part I, Chapter 47, § 1030 of the United States Criminal Code for fraud and related activities in connection with computers contains several definitions of what constitutes a fraudulent criminal computer intrusion. Knowingly accessed a computer without authorization or exceeding authorized access is a common thread in several definitions. However, all the definitions go on to further require theft of government secrets, financial records, government data, or other such things. Knowingly accessed without authorization or exceeding authorized access doesn’t appear to be enough in and of itself. There is also a lack of legislative clarity regarding what access is. For example, a portscan gathers data about which ports on the target computer are listening, but does not attempt to use any services. Nevertheless, some people argue that this constitutes accessing those services. A security scanner such as Nessus or Retina may check the versions of listening services and compare them against a database of known security vulnerabilities. This is more intrusive than a simple portscan, but merely reports the presence of vulnerabilities rather than actually exploiting them. Is this accessing the service? Should it count as an intrusion? Finally, there are the blatant cases where the system is actually compromised. Most people would agree that this counts as an intrusion. For our purposes, we can define an intrusion as an unwanted and unauthorized intentional access of computerized network resources.

An IDS is the high-tech equivalent of a burglar alarm, one that is configured to monitor information gateways, hostile activities, and known intruders. An IDS is a specialized tool that knows how to parse and interpret network traffic and/or host activities. This data can range from network packet analysis to the contents of log files from routers, firewalls, and servers, local system logs and access calls, network flow data, and more. Furthermore, an IDS often stores a database of known attack signatures and can compare patterns of activity, traffic, or behavior it sees in the data it’s monitoring against those signatures to recognize when a close match between a signature and current or recent behavior occurs. At that point, the IDS can issue alarms or alerts, take various kinds of automated actions ranging from shutting down Internet links or specific servers to launching back-traces, and make other active attempts to identify attackers and collect evidence of their nefarious activities.

By analogy, an IDS does for a network what an antivirus software package does for files that enter a system: it inspects the contents of network traffic to look for and deflect possible attacks, just as an antivirus software package inspects the contents of incoming files, e-mail attachments, active Web content, and so forth to look for virus signatures (patterns that match known malware) or for possible malicious actions (patterns of behavior that are at least suspicious, if not downright unacceptable).

To be more specific, intrusion detection means detecting unauthorized use of or attacks upon a system or network. An IDS is designed and used to detect such attacks or unauthorized use of systems, networks, and related resources, and then in many cases to deflect or deter them if possible. Like firewalls, IDSes can be software-based or can combine hardware and software in the form of preinstalled and preconfigured stand-alone IDS devices. IDS software may run on the same devices or servers where firewalls, proxies, or other boundary services operate, though separate IDS sensors and managers are more popular. Nevertheless, an IDS not running on the same device or server where the firewall or other services are installed will monitor those devices with particular closeness and care. Although such devices tend to be deployed at network peripheries, IDSes can detect and deal with insider attacks as well as external attacks, and are often very useful in detecting violations of corporate security policy and other internal threats.

You are likely to encounter several kinds of IDSes in the field. First, it is possible to distinguish IDSes by the kinds of activities, traffic, transactions, or systems they monitor. IDSes that monitor network links and backbones looking for attack signatures are called network-based IDSes, whereas those that operate on hosts and defend and monitor the operating and file systems for signs of intrusion and are called host-based IDSes. Groups of IDSes functioning as remote sensors and reporting to a central management station are known as distributed IDSes (DIDSes). A gateway IDS is a network IDS deployed at the gateway between your network and another network, monitoring the traffic passing in and out of your network at the transit point. IDSes that focus on understanding and parsing application-specific traffic with regard to the flow of application logic as well as the underlying protocols are often called application IDSes.

In practice, most commercial environments use some combination of network-, host-, and/or application-based IDSes to observe what is happening on the network while also monitoring key hosts and applications more closely. IDSes can also be distinguished by their differing approaches to event analysis. Some IDSes primarily use a technique called signature detection. This resembles the way many antivirus programs use virus signatures to recognize and block infected files, programs, or active Web content from entering a computer system, except that it uses a database of traffic or activity patterns related to known attacks, called attack signatures. Indeed, signature detection is the most widely used approach in commercial IDS technology today. Another approach is called anomaly detection. It uses rules or predefined concepts about normal and abnormal system activity (called heuristics) to distinguish anomalies from normal system behavior and to monitor, report, or block anomalies as they occur. Some anomaly detection IDSes implement user profiles. These profiles are baselines of normal activity and can be constructed using statistical sampling, rule-base approaches, or neural networks.

Hundreds of vendors offer various forms of commercial IDS implementations. Most effective solutions combine network- and host-based IDS implementations. Likewise, the majority of implementations are primarily signature-based, with only limited anomaly-based detection capabilities present in certain specific products or solutions. Finally, most modern IDSes include some limited automatic response capabilities, but these usually concentrate on automated traffic filtering, blocking, or disconnects as a last resort. Although some systems claim to be able to launch counterstrikes against attacks, best practices indicate that automated identification and back-trace facilities are the most useful aspects that such facilities provide and are therefore those most likely to be used.

IDSes are classified by their functionality and are loosely grouped into the following three main categories:

Network-based intrusion detection system (NIDS)

Host-based intrusion detection system (HIDS)

Distributed intrusion detection system (DIDS)

Network IDS

The NIDS derives its name from the fact that it monitors the entire network from the perspective of the location where it is deployed. More accurately, it monitors an entire network segment. Normally, a computer network interface card (NIC) operates in nonpromiscuous mode. In this mode of operation, only packets destined for the NIC’s specific media access control (MAC) address (or broadcast packets) are forwarded up the stack for analysis. The NIDS must operate in promiscuous mode to monitor network traffic not destined for its own MAC address. In promiscuous mode, the NIDS can eavesdrop on all communications on the network segment. In addition, the NIDS should be connected to either a span port on your local switch, or a network tap duplicating traffic on the link you want to monitor. Operation of the NIDS’s NIC in promiscuous mode is necessary to protect your network. However, in view of emerging privacy regulations and wiretap laws, monitoring network communications is a responsibility that must be considered carefully.

Figure 1.1 depicts a network using three NIDS. The units have been placed on strategic network segments and can monitor network traffic for all devices on the segment. This configuration represents a standard perimeter security network topology where the screened subnets housing the public servers are protected by NIDS. When a public server is compromised on a screened subnet, the server can become a launching platform for additional exploits. Careful monitoring is necessary to prevent further damage.

Figure 1.1 NIDS Network

The internal host systems are protected by an additional NIDS to mitigate exposure to internal compromise. The use of multiple NIDS within a network is an example of a defense-in-depth security architecture.

Host-Based IDS

HIDS differ from NIDS in two ways. HIDS protects only the host system on which it resides, and its network card operates by default in nonpromiscuous mode. Nonpromiscuous mode of operation can be an advantage in some cases, because not all NICs are capable of promiscuous mode. In addition, promiscuous mode can be CPU-intensive for a slow host machine. Due to their location on the host to be monitored, HIDS are privy to all kinds of additional local information with security implications, including system calls, file system modifications, and system logs. In combination with network communications, this provides a robust amount of data to parse through in search of security events of possible concern.

Another advantage of HIDS is the capability to tailor the ruleset very finely for each individual host. For example, there is no need to interrogate multiple rules designed to detect DNS exploits on a host that is not running Domain Name Services. Consequently, the reduction in the number of pertinent rules enhances performance and reduces processor overhead for each host.

Figure 1.2 depicts a network using HIDS on specific servers and host computers. As previously mentioned, the ruleset for the HIDS on the mail server is customized to protect it from mail server exploits, and the Web server rules are tailored for Web exploits. During installation, individual host machines can be configured with a common set of rules. New rules can be loaded periodically to account for new vulnerabilities.

Figure 1.2 HIDS Network

Distributed IDS

The standard DIDS functions in a Manager/Probe architecture. NIDS detection sensors are remotely located and report to a centralized management station. Attack logs are periodically uploaded to the management station and can be stored in a central database; new attack signatures can be downloaded to the sensors on an as-needed basis. The rules for each sensor can be tailored to meet its individual needs. Alerts can be forwarded to a messaging system located on the management station and used to notify the IDS administrator.

Figure 1.3 shows a DIDS composed of four sensors and a centralized management station. Sensor NIDS 1 and NIDS 2 are operating in stealth promiscuous mode and are protecting the public servers. Sensor NIDS 3 and NIDS 4 are protecting the host systems in the trusted computing base.

Figure 1.3 DIDS Network

The network transactions between sensor and manager can be on a private network, as depicted, or the network traffic can use the existing infrastructure. When using the existing network for management data, the additional security afforded by encryption, or virtual private network (VPN) technology, is highly recommended.

In a DIDS, complexity abounds. The scope and functionality vary greatly from manufacturer to manufacturer, and the definition blurs accordingly. In a DIDS, the individual sensors can be NIDS, HIDS, or a combination of both. The sensor can function in promiscuous mode or nonpromiscuous mode. However, in all cases, the DIDS’s single defining feature requires that the distributed sensors report to a centralized management station.

How an IDS Works

We’ve already touched on this to some degree in our survey of the different kinds of IDSes out there, but let’s take a look at exactly what makes an IDS tick. First, you have to understand what the IDS is watching. The particular kinds of data input will depend on the kind of IDS (indeed, what sorts of information an IDS watches is one of the hallmarks used to classify it), but in general there are three major divisions:

Application-specific information such as correct application data flow

Host-specific information such as system calls used, local log content, and file system permissions

Network-specific information such as the contents of packets on the wire or hosts known to be attackers

A DIDS may watch any or all of these, depending on what kinds of IDSes its remote sensors are. The IDS can use a variety of techniques in order to gather this data, including packet sniffing (generally in promiscuous mode to capture as much network data as possible), log parsing for local system and application logs, system call watching in the kernel to regulate the acceptable behavior of local applications, and file system watching in order to detect attempted violation of permissions.

After the IDS has gathered the data, it uses several techniques to find intrusions and intrusion attempts. Much like firewalls, an IDS can adopt a known-good or a known-bad policy. With the former technique, the IDS is set to recognize good or allowed data, and to alert on anything else. Many of the anomaly detection engines embrace this model, triggering alerts when anything outside of a defined set of statistical parameters occurs. Some complex protocol models also operate on known-good policies, defining the kinds of traffic that the protocol allows and alerting on anything that breaks that mold. Language-based models for application logic also tend to be structured as known-good policies, alerting on anything not permitted in the predefined structure of acceptable language or application flow.

Known-bad policies are much simpler, as they do not require a comprehensive model of allowed input, and alert only on data or traffic known to be a problem. Most signature-based IDS engines work from a known-bad model, with an ever-expanding database of malicious attack signatures. Known-good and known-bad policies can work in conjunction within a single IDS deployment, using the known-bad signature detection and the known-good protocol anomaly detection in order to find more attacks.

Finally, we should consider what the IDS does when it finds an attempted attack. There are two general categories of response: passive response, which may generate alerts or log entries but does not interfere with or manipulate the network traffic, and active response (discussed at length in Chapter 11), which may send reset packets to disrupt Transmission Control Protocol (TCP) connections, drop traffic if the IDS is inline, add the attacking host to block lists, or otherwise actively interact with the flow of dubious activity.

Having outlined these principles in the abstract, let’s take a look at some real network-based attacks.

Where Snort Fits

Snort is an open source network IDS capable of performing real-time traffic analysis and packet logging on Internet Protocol (IP) networks. Snort can perform protocol analysis and content searching/matching, and you can use it to detect a variety of attacks and probes, such as buffer overflows, stealth port scans, Common Gateway Interface (CGI) attacks, Server Message Block (SMB) probes, operating system fingerprinting attempts, and much more. Snort is rapidly becoming the tool of choice for intrusion detection.

You can configure Snort in three main modes: sniffer, packet logger, and network intrusion detection. Sniffer mode simply reads the packets off the network and displays them in a continuous stream on the console. Packet logger mode logs the packets to the disk. Network intrusion detection mode is the most complex and configurable, allowing Snort to analyze network traffic for matches against a user-defined ruleset and to perform one of several actions, based on what it sees.

In addition to the community signatures provided with Snort and the Sourcefire VDB signatures available for download to registered users, you can write your own signatures with Snort to suit the particular needs of your network. We’ll discuss how to do this in Chapter 7. This capability adds immense customization and flexibility to the Snort engine, allowing you to suit the unique security needs of your own network. In addition, there are several online communities where leading-edge intrusion analysts and incident responders swap their newest Snort rules for detecting fresh exploits and recent viruses.

Snort’s network pattern matching behavior has several immediately practical applications. For example, it allows the detection of hosts infected with viruses or worms that have distinctive network behavior. Because many modern worms spread by scanning the Internet and attacking hosts they deem vulnerable, signatures can be written either for this scanning behavior or for the exploit attempt itself. Although it is not the job of the IDS to clean up infected machines, it can help identify infected machines. In cases of massive virus infection, this identification capability can be immensely useful. In addition, watching for the same behavior after supposed virus cleanup can help to confirm that the cleanup was successful. Later in this chapter, we will examine Snort rules that characterize the network behavior of a worm.

Snort also has signatures that match the network behavior of known network reconnaissance and exploit tools. Although for the most part, rule writers make an effort to match the signature of the exploit and not of a particular tool, sometimes it’s helpful to be able to identify the tool scanning or attacking you. For example, there are rules that identify the SolarWinds scanner’s tendency to embed its name in the payload of its scanning Internet Control Message Protocol (ICMP) packets, making for easy device identification. The vast majority of exploits that end up in popular tools such as Metasploit have signatures in the Snort rulebases, making them detectable by their network behavior.

Intrusion Detection and Network Vulnerabilities

Of all the areas of concern for network administrators, two omnipresent threats loom large on the horizon of potential threats: a major virus or worm outbreak, and a successful malicious intrusion. Fortunately, IDSes can assist in identifying and combating both of these situations. Let’s first consider a worm infestation.

Identifying Worm Infections with IDS

The Dabber worm rather rudely exploits a previously-worm-exploited host. Riding on the coattails of the extremely damaging Sasser worm (which exploited the MS04-011 LSASS vulnerability), Dabber scans on TCP port 5554 for Sasser-compromised machines, then exploits the FTP server that Sasser installs and deletes the Sasser Registry keys, replacing them with its own. Several versions of the Dabber worm have been identified in the wild, and many organizations scrambling to patch and clean up Sasser didn’t find all the compromised boxes in time before they were compromised again and differently by a new worm.

At the scene of a crime, one of the first tasks of the forensic evidence technician is to gather fingerprints. These fingerprints can be used to determine the identity of the criminal. Just as in criminal forensics, network forensics technicians gather fingerprints at the scene of a computer crime. The fingerprints are extracted from the victim computer’s log and are known as signatures or footprints. Almost all exploits have a unique signature. When new exploits are released into the wild, incident responders and security administrators collaborate to identify the signature of the exploit, and to write IDS rules that will alert on that signature.

Although we reiterate that it is the job of antivirus software to address virus and worm-infected machines, Snort can help identify which hosts need attention from your friendly local antivirus staffers. Consider the following Snort rules, from the community-virus.rules:

The first rule alerts on the attempted PORT overflow exploit attempt to TCP port 5554, showing the buffer overflow of the vulnerable Sasser-installed server. The second rule shows a similar attempt to TCP port 1023. We’ll get more into rule analysis and writing in later chapters, but the basic structure should be visible from these rules. Note that it is not the Registry keys or file changes that the NIDS rules detect (although a HIDS on the infected host could notice this behavior), but the network-visible traffic of the worm with its distinctive payload.

For a thorough description of the Dabber worm, the associated Registry keys modified, and its behavior, look at www.lurhq.com/dabber.html.

Although worms can be troublesome and bandwidth-clogging, many security administrators are still more afraid of a targeted exploit attempt against a high-value server. Let’s look at an attack against Oracle database servers.

Identifying Server Exploit Attempts with IDS

The Oracle TNS Listener is a central service for Oracle databases. By default, it is not protected by a password in most cases, although a password can be set. On Valentine’s Day 2005, researcher Alexander Kornbrust reported to database giant Oracle that its iSQL*Plus, a Web interface to SQL*Plus, could be used to shut down the TNS Listener. This creates a denial-of-service condition for the database. Oracle confirmed the bug the next day, but didn’t announce the patch for several months. The Oracle Critical Patch Update July 2005 (CPU July 2005) addressed this vulnerability. However, due to the high uptime requirements of many commercial databases, there are still a lot of unpatched servers out there. It seems like madness that one’s most operationally critical servers could be considered too important to patch, but some administrators have exactly that attitude. Others simply aren’t aware of the patches or don’t comprehend the importance of speedy and regular patching. In these cases, IDS can fill the gap and alert you to the attack attempts on your network. If you can’t figure out why your database listener keeps shutting down, IDS alert logs such as that produced by this rule can provide valuable administrative information:

As you can see, this rule will create an alert whenever a TCP connection goes to an SQL server on port 3339 with a command that contains the words isqlplus, COMMAND, STOP, and LISTENER in appropriate places. (Again, we’ll cover rule syntax in depth in later chapters; this rule is here just to illustrate the capabilities of IDSes to match known attack patterns and alert the administrators when that happens.)

For a thorough description of the Oracle TNS Listener vulnerability, look at Kornbrust’s write-up at www.red-database-security.com/advisory/oracle_isqlplus_shutdown.html. Also, note that this URL is helpfully referenced within the preceding Snort rule!

Decisions and Cautions with IDS

With any IDS, there will be some false positives and some false negatives. A false positive is an alert that triggers on normal traffic where no intrusion or attack is underway. A false negative is the failure of a rule to trigger when an actual attack is underway. Most IDSes have many, many false positives out of the box, and that number is gradually reduced through tuning. It’s generally considered worse to have false negatives than it is to have false positives—you can always discard erroneous data, but it’s hard to know what you’re missing when you don’t see it! Signatures that have a high rate of false positives are generally less useful than signatures that fire only when there’s an actual attack, and an integral part of the tuning process is whittling out these false positives by applying knowledge of what’s actually on your network and what the devices are meant to be doing.

Despite the claims made by many vendors and even some experienced intrusion analysts, just because you don’t care about a specific event doesn’t mean it is a false positive! It is okay to say you are getting true positives that are unimportant in your environment or at this time, but don’t be confused about what a false positive or a false negative is. An event is a false positive only if the rule misfired and identified traffic incorrectly.

It is also important to remember that IDSes are not foolproof. In the early days of IDS, a seminal paper by Tim Newsham and Tom Ptacek titled Insertion, Evasion, and Denial of Service: Eluding Network Intrusion Detection brought some of the original shortcomings of IDSes to the widespread attention of the security community. By creatively fragmenting packets, or writing them with overlaps that would be reassembled differently than the individual fragments would suggest, it was possible to send attacks right under the noses of most IDSes of the time. Many of these problems have since been addressed through the introduction and refinement of network flow and stream-aware preprocessors and fragment reassembly tools, but it would be exceedingly optimistic to think that no other flaws could possibly exist in the handling of network traffic by today’s NIDS. One of the strengths of defense-in-depth security design is that flaws in the operation of one defense are more likely to be covered by another part of the defense strategy.

Speaking from a practical business point of view, many CIOs and CSOs will want to know what the expected ROI is for this sort of deployment. Most departments have a limited security budget, and want to spend it as wisely as possible. If the cost of building and deploying a complex IDS is far greater than the value of the information you’re ever likely to protect on that network, you may want to reconsider your security strategy.

Assuming that you do have a network which could benefit from the network monitoring capabilities of an IDS, you now have some design decisions to make. Should your IDS be inline, sitting at the choke point(s) between your network and the world, or not? Does it make sense to drop traffic actively, or do you just want to generate alerts for analysis without touching the network, or perhaps move from the latter to the former? Do you want active response or not? (These questions will be discussed in depth in Chapter 11.) Finally, when considering deploying an inline or gateway IDS, one must account for any encryption, VPNs, or IPsec tunneling of network traffic. Network encryption removes the capability of the IDS to alert on packet payloads reliably, as the content is encrypted and therefore not matchable without a view into the encryption. Although some devices on the market can decrypt encrypted traffic specifically for the purposes of IDS signature matching, in general, encrypted traffic escapes many IDS rules and might trigger false positives randomly with its encrypted payloads. When looking at places to deploy an IDS sensor in your network, be sure to place it on the unencrypted side of encrypted tunnels, and have other ways of analyzing devices which rely on encrypted traffic. We’ll talk about all these factors in greater detail later in the book, but we want you to be aware of the issues early on.

Did I mention that Snort is free? That’s right, free.

Why Are Intrusion Detection Systems Important?

Everyone is familiar with the oft-used saying, What you don’t know can’t hurt you. However, anyone who has ever bought a used automobile has learned firsthand the absurdity of this statement. In the world of network security, the ability to know when an intruder is engaged in reconnaissance, attempted system compromise, or other malicious activity can mean the difference between being compromised and not being compromised. In addition, in some environments, what you don’t know can directly affect employment—yours. With the increasing prevalence of consumer privacy laws in states such as Washington and California, corporations and other institutions are being legally compelled to disclose data breaches and compromises to their affected customers. This can have profound effects upon the compromised company, including bad press, loss of customer trust, and the resultant effects on stock. Needless to say, many executives are keen to prevent this sort of embarrassment to their companies.

IDSes such as Snort can detect ICMP and other types of network reconnaissance scans that might indicate an impending attack. In addition, the IDS can alert the admin of a successful compromise, which allows him the opportunity to implement mitigating actions before further damage is caused, and to take the system offline and getting it ready for forensic analysis to determine the extent of the breach.

IDSes provide the security administrator with a window into the inner workings of the network, analogous to an X-ray or a blood test in the medical field. The ability to analyze the internal network traffic and to determine the existence of network viruses and worms is not altogether different from techniques used by the medical profession. The similarity of network viruses and worms to their biological counterparts has resulted in their medical monikers. IDSes provide the microscope necessary to detect these invaders. Without the aid of intrusion detection, a security administrator is vulnerable to exploits and will become aware of the presence of exploits only after a system crashes or a database is corrupted.

Why Are Attackers Interested in Me?

The Attack of the Zombies—sounds a lot like an old B-grade movie, doesn’t it? Unfortunately, in this case, it is not cinema magic. Zombie attacks are real and cost corporations and consumers billions of dollars. Zombies are computerized soldiers under the control of nefarious hackers, and in the process of performing distributed denial-of-service (DDoS) attacks they blindly carry out the will of their masters.

In February 2000, a major DDoS attack blocked access to eBay, Amazon.com, AOL-TimeWarner, CNN, Dell Computer, Excite, Yahoo!, and other e-commerce giants. The damage done by this DDoS ranged from slowdown to complete system outages. The U.S. Attorney General instructed the FBI to launch a criminal investigation. This historic attack was perpetrated by a large group of compromised computers operating in concert. More recently, the DDoS attack on provider Akamai’s DNS system in May and June of 2004 caused major and well-connected sites such as Microsoft, Google, Yahoo!, and the antivirus update services of Symantec and TrendMicro to become unavailable to the Internet at large. Hundreds of thousands of compromised computers can take down even the biggest networks, and you don’t want your network to be a part of attacks such as these.

The lesson to be learned from these events is that no network is too small to be left unprotected. If a hacker can use your computer, he will. The main purpose of the CodeRed exploit was to perform a DDoS on the White House Web site. It failed, due only to the author’s oversight in using a hardcoded IP address instead of Domain Name Services. The exploit compromised more than a million computers, ranging from corporate networks to home users. It’s also increasingly common for botnets composed of zombie computers to be programmed to crank out spam, earning the ire of angry end users and making the spammer money at your expense. Spamming activity, even if inadvertent, can get your network placed on block lists and blacklists, severely limiting the networks which are willing to receive e-mail from yours. When many major networks aren’t willing to receive your e-mail, you may find that this raises some obstacles in business. As will be detailed in later chapters, Snort has many rules that can alert the system administrator to the presence of zombies and other unauthorized remote access tools. Between the war on terrorism, government-sponsored hacking, and hacktivists taking politics into their own digital hands (such as in the India-Pakistan conflict), the use of an IDS such as Snort can prove crucial in the protection of the world’s network infrastructure.

However, your CPU cycles and bandwidth aren’t the only thing that attackers are after. Free disk space is often handy to digital ne’er-do-wells, allowing them to set up warez servers where they can trade exploits, pornography, and pirated digital media. You don’t want to get slapped with a Digital Millenium Copyright Act law-suit for pirated music that you didn’t even know you were hosting! And if you do happen to run a network that has any sort of sensitive or private corporate data on the servers, well, there’s a thriving black market in industrial espionage.

What Will an IDS Do for Me?

The strengths of IDSes are their capability to continuously watch packets on your network, understand them in binary, and alert you when something suspicious that matches a signature occurs. Unlike human security analysts, the speed of IDS detection allows alerting and response almost immediately, even if it’s 3 a.m. and everyone’s sleeping. (The alerting capability of IDSes can allow you to page people and wake them up, or, if you’re deploying an IDS in inline mode or an intrusion prevention system [IPS], block the suspicious traffic, and potentially other traffic from the attacking host.) An IDS can allow you to read gigabytes of logs daily, looking for specific issues and violations. The potential enhancement of computing and analysis power is tremendous, and a well-tuned IDS will act as a force multiplier for a competent system/network administrator or security person, allowing them to monitor more data from more systems. By letting you know quickly when it looks like you are under attack, potential compromises may be prevented or minimized.

It is important to realize that any IDS is likely to create tremendous amounts of data no matter how well you tune it. Without tuning, most IDSes will create so much data and so many false positives that the analysis time may swamp response to the legitimate alerts in a sea of false alerts. A new IDS is almost like a new baby—it needs lots of care and feeding to be able to mature in a productive and healthy way. If you don’t tune your IDS, you might as well not have it.

Another positive feature of an IDS is that it will allow the skilled analyst to find subtle trends in large amounts of data that might not otherwise be noticed. By allowing correlation between alerts and hosts, the IDS can show patterns that might not have been noticed through other means of network analysis. This is one example of how an IDS can supplement your other network defenses, working cooperatively to enact a defense-in-depth strategy.

What Won’t an IDS Do for Me?

No IDS will replace the need for staffers knowledgeable about security. You’ll need skilled analysts to go through those alerts that the IDS produces, determining which are real threats and which are false positives. Although the IDS can gather data from many devices on a network segment, they still won’t understand the ramifications of threats to each machine, or the importance of every server on the network. You need clever, savvy people to take action on the information that the IDS provides.

In addition, no IDS will catch every single attack that occurs, or prevent people from trying to attack you. The limitations of any kind of IDS and the timing between the development of new attacks and the development of signatures or the ability to hide within acceptable parameters of an anomaly-based system make it exceedingly likely that there will be a small window in which 0-day attacks will not be detected by a given IDS. The Internet can be a cruel and hostile place, and although it’s advisable to implement strong network defenses and prepare to be attacked, IDSes cannot psychically make people decide not to attack your network after all. In most cases, an IDS will not prevent attacks from succeeding automatically, as its function is primarily to detect and alert. There are some mechanisms that do address this problem—inline IDS, or IPS, for example—but in most cases, an IDS will not automatically defeat attacks for you. This is one of the reasons that an IDS should be seen as a complement to your other network defenses such as firewalls, antivirus software, and the like, rather than as a replacement for them.

Notes from the Underground. …

What to Look for in an Intrusion Analyst

We’ve discussed the need for skilled security analysts to address the information that your IDS turns up, but how do you find or assign the right people for the job? Here, we attempt to highlight some of the traits that make for a good intrusion analyst, in order to help you find the right people for the job.

A good intrusion analyst understands networking. Being able to understand and dissect packet captures and determine what triggered them requires an understanding of the basic and not-so-basic principles of Transmission Control Protocol/Internet Protocol (TCP/IP) and networking theory. If your prospective analyst can’t tell an ACK from a RST, are you sure you want him trying to figure out whether that attack succeeded?

A good intrusion analyst understands (or can quickly learn) your network. Tuning is an essential requirement of IDSes, and nothing speeds that up like an understanding of your network and what’s supposed to be happening. That sort of intimate knowledge of the intended use of your network allows the analyst to quickly separate the wheat from the chaff and to remove false positives as quickly as possible, improving the overall quality of IDS alerts.

A good intrusion analyst is detail-oriented. Wading through thousands of alerts can be taxing, and picking out the common threads that tie disconnected packets together into a sinister pattern of scanning and attack takes a close eye to detail. Many packets look alike, and it’s important to be able to distinguish separate network flows.

A good intrusion analyst is persistent. Some threats, such as low-and-slow scans, don’t jump out in your face. Others terminate in mystery machines on the other side of the Internet. Working through the laborious process of identifying endpoints takes time, particularly when one encounters busy and not-always-cooperative system administrators. A good analyst will persist and chase the case down to its root, even when it takes a