IDS Deconstructed

Two years ago Gartner sounded a death knell for IDSs, saying the technology would be obsolete by 2005. But someone forgot to forward the memo to IT buyers--the intrusion detection system is still very much alive.

Gartner's proclamation spawned valuable debate: Some vendors touted the IDS (and subsequently the intrusion-prevention system) as a magic security wand--much like the firewall before it. That concept of the IDS is indeed dead--and good riddance. Security problems go wide and deep, and many defensive systems, policies and methods must be interwoven. But IDSs do have a place in your enterprise. We also have a plan for a DIY IDS (Download our sample scripts for IDS use).

In essence, an IDS is like a toothless guard dog--it can tell us of possible threats but can't do anything about them on its own. Whether it uses statistical analysis, monitors a host's files or logs, or merely looks for known bad patterns amid the flow of network traffic, an IDS is a passive detection device. An IDS by itself, therefore, is good only for raising alerts. It can't stop the exploits it detects, identify weaknesses in systems pre-exploitation, or cajole system administrators into fixing security lapses that leave you open to security incidents. An IDS is best deployed as a cog in a defensive system.Here, Piggy Piggy

Although the cachet of the reigning open-source security software triumvirate--Nmap, Nessus and Snort--has been reduced slightly by the switch of Nessus 3 to a free but closed-source model, Snort remains a successful open-source and commercial product, and appears to be safe even with Check Point Software Technologies' announced buyout of Snort creator Sourcefire. Likewise, Nmap's open-source future seems secure with Fyodor at the helm. Nessus hasn't received the broad community support needed to make it worthwhile for Tenable to maintain the open-source license, but Snort has a large population of users-cum-contributors. This group forms a knowledgeable community for addressing problems and produces a large volume of contributions in the form of source-code patches and signatures.

This makes Snort a pig of top-notch pedigree for our project (Snort's mascot is a swine with an appropriately prodigious snout). The open-source license means that the only cost for our IDS will be the hardware on which it runs. Although exact hardware specifications will vary depending on your network and level of monitoring, a desktop workstation that's recently been replaced with a newer, faster model should be suitable for most locations. How much power you'll need depends on not just the CPU but also the motherboard, network card, number of signatures enabled, types of signatures enabled, bandwidth on the network, characteristics of the traffic and more. It's useful to have two network interfaces. One will be the sniffing interface on which Snort will be listening, and the other will be the management interface on which it will talk to the world.

Our setup is based on Fedora Core 4, using the source RPMS (Red Hat Package Manager [RPM] Package Management System) available from Snort.com. Once the basic OS was in and updated, we installed the source RPM, built the appropriate RPM and installed it--you'll need the development tools provided during installation for that step. Don't forget to install the additional pcre-devel and mysql-devel packages.

Snort needs minimal configuration at this point; make sure that the appropriate interface is set in /etc/sysconfig/Snort (see "How It's Wired" for more on which interface Snort should listen on), and comment out the line that begins with "ALERT."Although the sensor can run on older hardware, not everyone is comfortable with the Linux command-line interface, so we installed IDSPM (IDS Policy Manager) and the HSC (Honeynet Security Console) from Activeworx on the Windows machine that will act as our management and analysis platform. This box can do double duty as an administrative workstation. Activeworx does have some hardware recommendations (see www.activeworx.org/programs/idspm/ and www.activeworx.org/programs/hsc/).

We then downloaded and installed the Windows Essentials package from Mysql.com and configured the Mysql databases as described in the HSC and IDSPM online documentation. There are potential pitfalls while configuring the IDSPM. Our best troubleshooting technique is to keep checking the Snort logs on the sensor to see if errors are being generated when Snort starts, and determine which settings need to be tweaked accordingly.

Now it's time to make this piggy come alive and do some tricks. We want our IDS to act as a live incident portal, as well as a forensics tool, and be part of an automated response system.

Eye in the Sky

Using an IDS for incident analysis and forensics investigation sound like similar applications. After all, both comb through security data to find problems. There's an important difference, though, that revolves around the oft-maligned false positive. A typical incident analyst watches the IDS console for problems, looking for successful attacks or indications of a worm loose on the interior of a network, for example. For the analyst, a false positive means more work sorting through extra data, only to discover it was a false alarm.

For the forensic investigator, though, every bit of data is useful. We've discovered compromises that were logged in an IDS as false positives. The alert logged wasn't really what happened, and indeed was logged by a detection normally so noisy it was lost in a group of similar alerts when it was first triggered. But days later, when a single host was singled out for closer scrutiny for other reasons, that extra data became extremely useful, showing the method of compromise. Make sure you consider IDS signatures and how you'll use your IDS with both of these perspectives in mind.

To find what's new and worth closer investigation, an analyst first must ignore what's normal--much easier said than done. Although some commercial IDS products contain various intelligent statistical analysis methods, the human mind is still the best tool for determining, "Which one doesn't belong?"

Before we could use our IDS, we had to make sure it had been fed a proper baseline. This can be time consuming, and that investment unfortunately means that IDSs are not used as incident-analysis tools in many environments. We can't really give an exact time span for this--only by spending quality time with the IDS can you recognize a reasonable baseline. Still, expect to spend at least an hour or two every day for a week to get a basic feel for what you'll see. You'll need to spend even more to be completely comfortable, but if you put a good week in, you should start to be familiar with the typical events in your environment.

To help improve your signal-to-noise ratio, check the Snort documentation on writing rules and create variables for hosts that often trigger false positives for a signature. Then, rewrite the signature to inspect all hosts except those in that variable. Additionally, a signature that may trigger occasionally as a false positive--for example, one written to detect Web server port sweeps that generate false positives when a Web page has embedded elements from different servers, causing the browser to connect to many Web servers in a short period of time--might be more useful with an event threshold. That way you can determine the number of simultaneous connections you often see on your network, and set thresholds so that only scans above that threshold trigger the alert.An analyst is only as good as his or her data, so make sure you've got the latest and greatest signatures. Fortunately, IDSPM can directly download signatures from the excellent bleedingSnort.org Web site, giving you access to the previously mentioned rich library of community-created signatures. When you edit your policy, select "Use Bleeding Snort Rules" to download and integrate those rules into your sensor automatically. The downside, as you'll quickly realize, is that not all signatures are useful--you may reach overload on both the amount of traffic the sensor can monitor and the number of alerts an incident analyst can use. Still, the Bleeding Snort rules include a variety of frequently updated and useful signatures. Many IRC (Internet Relay Chat)-related signatures in Bleeding Snort may not seem immediately relevant, for example, but a large percentage of botnet and Trojan infections are remotely controlled over IRC.

Think about writing your own IDS signatures in response to spur-of-the-moment threats. If a new virus is spreading through your environment and isn't being detected by your antivirus software, try to find a sample, submit it to virustotal.com for analysis, and use the behaviors listed on the antivirus vendors' Web sites to develop your own signature. Being able to write your own signatures will increase the usefulness of your IDS dramatically for incident analysis.

To create a new signature: Open the policy, right click on the local signature category, choose "Add new signature name to group," enter your signature name, and define the signature as shown in the screen at right. Make sure to enable the signature and the signature category with the checkboxes. Now, test your signature by browsing over to http://somesite.com/path/to/file/malwareupdater.exe, where the traffic will be monitored by a sniffer. If your signature is not triggered, compare the sniffed traffic to the signature as written to determine what is mismatched.

The best way to learn how to write efficient signatures is by studying existing signatures. The example shown in our screen might be used to create a signature for a new instant messenger-based worm, for example, that spreads by messaging a URL in an attempt to get users to infect themselves. For more information on writing Snort signatures, consult the snort-sigs mailing list.

CSI Silicon ValleySystem- and network-level forensics has always been an interesting field, and with the increased use of root-kit-enabled malware and the sheer number of new nasties released each day, it's only getting more fascinating. The signatures a forensic investigator makes use of aren't always the latest and greatest. Sometimes, they're the simplest and most basic. Consider, for example, the following sigs. All will be nearly useless when looking at a long list of events and trying to determine which are malicious, but they may be critical in discovering more information once a host is found to be compromised:

» All .exe files downloaded from the Internet over HTTP or FTP

» All IRC channels or servers joined

» All NetBIOS connections

» All remote desktop loginsAlthough some of these may be too noisy to even log in an IDS in your environment, or may be irrelevant based on your local policies and filtering mechanisms, the key is that these signatures often do little good as stand-alone alerts. They come into their own when they're joined by another signature that stands out more, or when they provide additional information after a single host or group of hosts are being scrutinized.

Early critiques of IPS technologies often pointed out that if IDSs are so prone to errors, why would someone trust an IPS to run inline and block traffic based on the same detection methods? Long term, we see pure-play IPSs disappearing as IPS functionality is incorporated into network firewalls (see our 2006 Security Survivor's Guide ).

Shorter term, while the technology is being improved, there are some detection techniques that are just plain difficult. Many protocols have to be fully disassembled and analyzed, with different encoding behaviors at each layer slowing the process. To do all that while keeping the false positive rate as close to zero as possible and without introducing appreciable latency into the network is a daunting task. Our advice is to again remember that some signatures are more useful than others--enable only those signatures and detection methods that have proved their accuracy, and leave the ones prone to false positives or spoofing in detection mode. The best candidates for an automatic response are specific. For example, a previously referenced IRC signature might trigger traffic to a specific IP address on Port 6667 with the text of "join #b0tz." That type of signature is so precise and unlikely to trigger anything except a bot (or human) joining a specific botnet IRC channel, that it would make an excellent signature to take automated action on. The University of Florida regularly makes use of such specific botnet signatures to help disconnect infected users from the network automatically.

Our humble IDS can help analyze signature accuracy, as well. Many environments have a border firewall, border router capable of IP-based restrictions, or other mechanisms to block traffic. After you've run your IDS for a while and developed a familiarity with which signatures are the most useful and accurate, why not automate some ties between the IDS and your firewall? You could create scripts to add rules to a firewall to filter hosts, or send pop-up messages to alert infected users, among a variety of actions.We'll demonstrate one possible automatic response by showing how we can interface our IDS with Bluesocket authentication devices to disconnect virus-infected users automatically. Bluesocket WG 1100 authentication gateways are used to authenticate users to wired or wireless networks before allowing access and can be used to deauthenticate users to disallow network access. Similar automatic responses could be used with a firewall, 802.1x networks, or by disabling a port or MAC address. Although the gateways provide a variety of features, the one most useful to us in our IDS is an XML RPC interface available over the embedded Web server that can be sent a variety of commands. We used a simple Perl script to de-authenticate users on that network when they triggered a particular signature (find the script here ).

Of course, there are many more robust methods of achieving our goal, but the provided scripts offer a good basic demonstration of the concept. A fully featured automated response system would be more flexible in handling multiple types of alerts and actions and would survive a reboot (the following example will terminate once the sensor restarts), among other things. One such robust system is SnortSam (www.snortsam.net). That said, the quickest way to automatically take an action on your sensor is to open up our policy in the policy manager and switch to the Settings tab. Then add a custom action that outputs into an alert_csv file called bskill.csv, and change the action for our Web-based-malware signature to "bskill." Apply the changes to the signature, save the policy, and upload it to the sensor.

And watch out SkyNet, our automated system is alive! Any signature whose alert type is set to bskill will generate an entry in bskill.csv, which is monitored by the simple shell script that runs bs-killer.pl on each IP.

Bottom line, there are a lot of ways an IDS can be useless. Legitimate events can be drowned out by false-positives, signatures can be evaded and many threats occur in application levels that are difficult to detect. And of course, an attacker might simply walk right past the most aggressive IDS with a laptop and plug directly into an internal network. Still, with a well-baselined and well-maintained IDS, the tasks of identifying infections, compromises or other problems, and then starting an incident-response process, can be kick-started without human intervention. This continuous automation could mean the difference between a small security blip and a headline-making incident. Think creatively about what other tools and data can be used with an IDS, and you'll find that you can get more than your money's worth whether you run Snort for free, or purchase a commercial product. It's no magic wand, but like a good pair of pliers, an IDS belongs in your toolbox.

Jordan Wiens is a network security engineer at the University of Florida, where he works on IDS/IPS, forensics, vulnerability assessment and system security. Write to him at [email protected].IDS sensors can be deployed and operated in a number of ways. The intended design for our sensor is to monitor traffic for a subnet, but it could monitor just a single host or multiple networks. Depending on the network topology, equipment available and configuration of the hardware used for the sensor, any of the following variations can be used to move the traffic the sensor must monitor within reach of its greedy snout.

An IDS CAN BE A VALUABLE MEMBER of your security toolbox, but it requires care and feeding. To help you make the most of intrusion-detection technology, we show you how to build a system from the ground up using Snort and other free elements.Key things to remember: An IDS can alert you to threats and help with forensics after the fact, but it can't stop an attack on its own. You'll need to feed your IDS a stream of baseline traffic and expect to spend at least an hour a day for a week or two getting a feel for what's normal in your environment. Only then can you hope to pick out potentially dangerous abnormalities.

Find a good source of signatures. We like the bleeding Snort.org Web site. Once you get comfortable with your IDS, take a shot at writing your own signatures. We include some directions and recommend studying existing sigs as a starting point. Finally, consider giving your IDS teeth by implementing a limited number of automated actions. Carefully chosen automated responses can keep a security blip from becoming a blowup.

You can find all our Affordable IT articles here.