Network Flight Recorder

The interesting feature of NFR is that it is not designed to be an IDS. Instead, NFR is a general-purpose network monitoring tool. NFR just happens to include a general-purpose scripting language that can be used to build attack signature recognition routines. Note that Checkpoint adheres to this philosophy in the firewall market by offering its INSPECT language for similar reasons. The argument, and it is a reasonable one, is that passing packets through arbitrary programs provides great flexibility in enforcing a security policy.

As a security officer, knowing that you have complete control over the attack signatures is a compelling thought. However, you must be cautious because you could make a mistake in programming. Relying on consulting services to obtain signatures for well-known attacks, and developing custom signatures for your proprietary applications is a good tradeoff. Although the general-purpose scripting language in NFR is it’s most appealing feature, you probably can expect network IDS vendors to offer similar functionality soon. When NetRanger and RealSecure enables you to easily add your own signatures or adapt the ones delivered with the tools, the appeal of NFR will be challenged.

Earlier versions of NFR did not have the same level of distributed systems management provided with NetRanger and RealSecure. This level probably is supported in the version on the market today. Paging is a standard notification mechanism supported, and the summary reports are exceptional. If you invest in NFR, you’ll also be able to use expertise to watch your network behavior in other ways, such as monitoring performance.

Will Intrusion Detection Be Enough?

It would be wonderful if this chapter could close by claiming victory in the war on intruders. You know by now that perfect security is impossible. You’ve had a chance to see how scanners, system-level tools, and network IDSs are able to catch some hacks but miss others. Your job is to know the types of IDS tools that are available, know what they can do, and know what they cannot do in order to properly rely on them for improving your security. The bad news is that no single type of IDS today will be sufficient by itself. The good news is that you can buy several tools that do give you ample coverage against attacks. Today, not all of the tools will come from the same vendor, nor is it likely that they will interoperate. This situation is changing, though.

Vendors who build each type of tool make design tradeoffs when building a scanner, system, or network IDS. In the recent past, a vendor might focus on one or two of these tools types but not offer solutions covering all three categories. Alliances, acquisitions, and new product offerings by IDS vendors are becoming more inclusive. In 1998, you should see some significant improvements in this area. The final chapter of the book offers some suggestions for what you can do today, and what you can expect from IDSs in the future.

Another issue you will need to contend with is increasingly sophisticated hackers. IDS vendors try to keep abreast of new hacks and modify their tools to detect these. However, a lag always exists between a clever new way to break into a system and the products that try to find hackers.

Much of the material on intrusion detection so far has focused on UNIX systems and TCP/IP. This focus was used to keep the discussions simple. Including NT and UNIX comparisons in each section would have been too confusing. Now that you’re an expert on IDSs and understand how they apply in UNIX environments, you are ready for the next chapter, which examines intrusion detection for NT.