Summary
Solutions Fast Track
Introduction
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 suspi- cious, 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 unautho- rized 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 notrunning 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 secu- rity policy and other internal threats.
You are likely to encounter several kinds of IDSes in the field. First, it is possible to dis- tinguish 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 func- tioning as remote sensors and reporting to a central management station are known as dis- tributed 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 net- work 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 prede- fined concepts about “normal” and “abnormal” system activity (called heuristics) to distin- guish 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 base- lines 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 auto- mated 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)
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 under- stand 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 pos- sible), 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 pro- tocol 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, 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.
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 signa-
ture 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 capa- bility 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 com- puting 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 supple- ment 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 net- work 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 devel- opment 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.
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 intru- sion 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.This capability adds immense customiza- tion 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 dis- tinctive 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.
Snort also has signatures that match the network behavior of known network reconnais- sance 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.
Snort System Requirements
Before getting a system together, you need to know a few things. First, Snort data can take up a lot of disk space, and, second, you’ll need to be able to monitor the system remotely.The Snort system we maintain is in our machine room (which is cold, and a hike downstairs).
Because we’re lazy and don’t want to hike downstairs, we would like to be able to main- tain it remotely andsecurely. For Linux and UNIX systems, this means including Secure Shell (SSH) and Apache with Secure Sockets Layer (SSL). For Windows, this would mean Terminal Services (with limitation on which users and machines can connect and Internet Information Servers [IIS]).
Hardware
It’s difficult to give hard-and-fast requirements on what you’ll need to run Snort because the hardware requirements are tremendously variable depending on the amount of traffic on your network and how much of that you’re trying to process and store. Busy enterprise net- works with thousands of active servers are going to have much greater requirements than a poky home network with one client machine on it. However, we can provide general guidelines.
At a bare minimum level, Snort does not have any particular hardware requirements that your OS doesn’t already require to run. Running any application with a faster processor usually makes the application work faster. However, your network connection and hard drive will limit the amount of data you can collect.
One of the most important things you’ll need, especially if you’re running Snort in NIDS mode, is a really big, reasonably fast hard drive. If you’re storing your data as either syslog files or in a database, you’ll need a lot of space to store all the data that the Snort’s detection engine uses to check for rule violations. If your hard drive is too small, there is a good chance that you will be unable to write alerts to either your database or log files. For example, our current setup for a single high-traffic enterprise Snort sensor is a 100GB parti- tion for /var (for those of you not familiar with Linux/UNIX systems, /var is where logs, including Snort data, are most likely to be stored). Some high-end deployments even use RAID arrays for storage.
You will need to have a network interface card (NIC) as fast or faster than the rest of your network to collect all the packets on your network. For example, if you are on a 100MB network, you will need a 100MB NIC to collect the correct amount of packets. Otherwise, you will miss packets and be unable to accurately collect alerts. A highly recom- mended hardware component for Snort is a second Ethernet interface. One of the interfaces is necessary for typical network connectivity (SSH, Web services, and so forth), and the other
interface is for Snorting.This sensing interface that does the “snorting” is your “Snort