Digital Undercurrents

Welcome to Definition Monday, where we define and explain a common technology or security concept for the benefit of our less experienced readers. This week: Intrusion Detection Systems.

An Intrusion Detection System, often referred to with the abbreviated “IDS”, is exactly what it sounds like. It is a piece of hardware or software that listens to data changes or traffic in a particular environment, watching for suspicious or exploitative trends. Think of it like the high-tech version of a motion detector light on a house; it passively monitors the environment until something triggers it, and then performs a specified task. Just like the motion detector will turn on the light, the IDS will log the problem, generate an SMS text message to an administrator, or email an affected user.

Broadly speaking, there are two common classes of IDS – Network-based IDS systems (NIDS) and Host-based IDS systems (HIDS).

Network-based IDS (NIDS)

A NIDS system passively monitors the traffic in an environment, watching for certain patterns that match a defined set of signatures or policies. When something matches a signature, an alert is generated – the action that occurs then is configurable by the administrator.

The most common NIDS in use these days is probably Snort, an open-source solution written by Marty Roesch and maintained by his company, Sourcefire. Snort is capable of acting as either a passive eavesdropper or as an active in-line part of the network topology. In this diagram, the lefthand example is a passive deployment, the right is in-line.

As you can see in the example on the left, the computer running snort is connected to the firewall – the firewall would be configured with a “mirror” or “spanning” port that would essentially copy all of the incoming and outgoing traffic to a particular interface for the snort software to monitor. This way, any suspicious traffic passing the border of the network would be subject to examination.

In the example on the right, the traffic is passing directly through the snort machine, using two Ethernet interfaces. This is an excellent solution for environments where a mirror port is unavailable, such as a branch office using low-end networking equipment that can’t provide the additional interface.

(It is important to note that a NIDS should be carefully placed within the network topology for maximum effectiveness. If two of the client machines in these diagrams are passing suspicious traffic between them, the snort machine will not notice; it only sees traffic destined for the Internet. It is always possible, of course, to run multiple NIDS systems and tie all of the alerts into one console for processing so as to eliminate these blind spots.)

Because of its large install base, rules for detecting new threats are constantly being produced and published for free usage on sites like Emerging Threats. If you want to be alerted when a host on your network is connecting a known botnet controller, for example, the up-to-the-minute rules for this can be downloaded from ET. The same goes for signatures of new worms and viruses, command-and-control traffic, and more.

So a NIDS is an excellent tool for detecting when a host on your network has been compromised or is otherwise producing suspicious traffic. But what about exploits that don’t cause traffic generation? If someone compromises your e-commerce server, for example, and installs a rootkit and starts modifying the code used to generate web pages, your NIDS will be none the wiser. For more careful monitoring of individual high-priority hosts, you would use a HIDS.

Host-based IDS (HIDS)

While a NIDS watches the traffic on a network segment, HIDS watches the activities of a particular host. A common open-source HIDS system is OSSEC, named as a contraction of Open Source Security.

OSSEC will monitor the Windows Registry, the filesystem of the computer, generated logs, and more, looking for suspicious behavior. As with a NIDS, an alert will be generated by any suspicious activity on the host and the results of the alert can be set by the administrator. If a process is attempting to modify the documents on your main web server, for example, OSSEC can kill that process, lock out the account that launched it, and send an email to the system administrator’s cell phone. It’s a remarkably flexible and impressive system.

Much like a NIDS, the placement of HIDS software needs to be carefully planned. You don’t want to receive an alert every time a file is accessed on a file server, for example; your administrator will be overwhelmed, and will simply stop reading alerts altogether. The system has to be carefully configured and the monitored behaviors pruned to as to eliminate false alarms and ensure that true security issues are noticed and alerted properly.