Between Chapters 18, "Linux and Firewalls," and 19, "Logs and Audit Trails," you probably got your fill of logs. Indeed, Linux keeps logs of nearly everything: logins, logouts, connection requests, equipment failure, denial of service, user commands, packet traffic, and a dozen other things. This is so pervasive that Linux even offers tools to update, rotate, format, merge, and analyze logs.
But while logs are essential, computer security folks have searched long and hard for ways to enhance their value or produce something better. Because, if you think about it, logs by themselves are really nothing but forensic evidence at a murder scene. The crime has already happened, the victim is already dead, and all you can do is gather the clues left behind.
Strides to improve detection and response have led to a new research field: intrusion detection. This chapter examines intrusion detection and how you can benefit from it.
Intrusion detection is the practice of using automated and intelligent tools to detect intrusion attempts in real-time. Such tools are called Intrusion Detection Systems (IDS).
Intrusion detection systems are a relatively new phenomenon that first emerged in the early 1980s. One good example is a study that was conducted at Stanford Research Institute from July 1983 to November 1986. Known as Project 6169, Statistical Techniques Development for an Audit Trail System, the study used
…a high-speed algorithm… that could accurately discriminate between users based on their behavior profiles. The project demonstrated that users can be distinguished from one another by their behavior profiles. These statistical procedures are potentially capable of reducing the audit trail by a factor of 100 while demonstrating a high degree of accuracy in detecting intrusion attempts.
Pretty highbrow stuff, but with obvious practical applications. Since then, thousands of IDS studies have been conducted, and today hundreds of intrusion detection systems exist (although most are unavailable for use by the general public).
Without getting deeply entrenched in definitions, two basic types of intrusion detection systems exist:
Rule-based systems—. These rely on libraries and databases of known attacks and attack signatures. When incoming traffic meets a particular criteria or rule, it is labeled as an intrusion attempt. The chief drawback of rule-based systems is that they depend on timeliness (the attack database must be current) and diligent maintenance. Moreover, sometimes there can be an inverse relationship between rule specificity and assured detection rates. That is, if a rule is too specific, attacks that are similar but not identical to it will slip through.
Adaptive systems—. These employ more advanced techniques, including artificial intelligence, to not only recognize known attack signatures but learn new ones. The chief drawbacks of adaptive systems are that they're expensive, they're deployed chiefly in research environments, they're difficult to maintain, and they require that you have advanced knowledge of math and statistics.
In this chapter, we'll deal primarily with rule-based systems.
In rule-based intrusion detection systems, there are two approaches: preemptory and reactionary. The difference is all about time:
In the preemptory approach, your intrusion detection tool actually listens to network traffic. When suspicious activity is noted (a flood of particular packets, for example), the system takes appropriate action.
In the reactionary approach, your intrusion detection tool watches your logs instead. Again, when suspicious activity is noted, the system takes appropriate action.
This distinction may seem like hairsplitting, but there is a major difference. The reactionary approach is simply one step up from standard logging; it alerts you to the fact that an attack has just taken place, even if that means 3.5 seconds ago.
In contrast, the preemptory approach actually allows your system to respond while an attacker is mounting his assault. Also, certain systems allow live operators to witness and track an attack in progress.
You can achieve a reactionary model simply by using standard Linux security tools in concert. For example, theoretically you could construct a pseudo-intrusion detection and response system like this:
This is quick-and-dirty intrusion detection and response. The attacker gets one shot, so he has to make it work. However, this approach has many shortcomings. One is that source addresses aren't reliable (as you saw in Chapter 9, "Spoofing"). They're easily forged, so an attacker can keep trying, using a different source address each time.
But preemptory models have shortcomings, too. One is that they're resource-intensive. This actually represents two problems, one due to the inherent interactivity of such systems and the other due to hardware and software limitations.
First, if an attacker knows that you're running a preemptory intrusion detection system, he can make several assumptions. One is that your IDS will undertake an identical action when met with an identical attack. Hence, by flooding your host with multiple instances of the same attack from different addresses, he can perform a process saturation attack and perhaps crash or incapacitate your IDS. For example, what if your IDS invokes a shell to execute commands when under attack? How many shell processes does it take before your system will mal- function?
Second, depending on your processor power and memory limitations, you may be forced to choose traffic analysis over content analysis. Traffic analysis is less resource-intensive because you're processing packet headers and not content. This protects against many attacks, but not all. Not by a long shot. A substantial number of attack signatures are buried in packet content, and simple traffic analysis is insufficient for these.
Finally, both approaches can generate false positives, which can have serious consequences. For example, many folks instruct their intrusion detection systems to beep them when an attack is under way. After enough false positives, technical staff members will begin to ignore such warnings. Or even worse, what if you instruct your IDS to actually perform some evasive or proactive countermeasure?
I had a recent experience with this. Approximately six months before I wrote this book, my ISP installed a well-known IDS product. To bolster its capabilities, the system administrator added some scripts he'd picked up from a popular UNIX sysadmin publication. The scripts generated an alert whenever an non-privileged user attempted to use a resource owned by root.
During one late-night writing session, while logged on to one of their shell boxes via SSH, I launched a find search, looking for various utilities across the entire drive. To my astonishment, after hitting several non-readable items, the search terminated and the box rebooted. My accounts were frozen and remained that way until the following Monday.
I later learned that the system administrator had instructed his IDS to terminate all processes, lock out offending accounts, and reboot whenever it detected an attack. The problem, of course, was that his IDS was far too gung ho and would undertake these actions on any read access violation. Eventually, after this happened several more times, he backtracked and loosened the trigger criteria. That experience is a perfect example of why intrusion detection is by no means a perfect science.
Indeed, intrusion detection is still in its infancy. Therefore, no matter what system you choose, you may find that it has one or more of these problems. Moreover, most publicly available intrusion detection systems are more toolkits than they are final solutions. Hence, you may be forced to define your own rules, responses, and reporting conventions.
Finally, you should know that intrusion detection systems are difficult to implement and demand considerable commitment on your part. You may find that deploying such a system doesn't really measure up in a cost-benefit analysis.
The remainder of this chapter focuses on various intrusion detection tools for Linux, how they operate, and where to obtain them. The tools listed go from simple to extremely complex, in ascending order.
chkwtmp is a tool that analyzes wtmp and reports deleted entries.
Required: C
Config Files: None
Security History: chkwtmp has no significant security history.
Notes: None
As discussed in Chapter 19, crackers use many tools to alter your log files. chkwtmp is one program that detects log file alterations. As explained on the manual page:
chkwtmpanalyzes entries with no information (these are entries containing only null-bytes). If such entries are found the program prints the time window for the original entry (by displaying the timestamps of thewtmpentries before and after the deleted entry).
chkwtmp may not alert you to actual edited entries. Also, the time window reported by chkwtmp is more revealing on hosts that have significant traffic because it offers you the chance to narrow the intrusion time to minutes—or possibly seconds. Notwithstanding these limitations, however, chkwtmp is quite useful. Get it at http://sunsite.ics.forth.gr/pub/systools/chkwtmp/chkwtmp-1.0.tar.gz.
Note
If you want to test chkwtmp's effectiveness, use one of the log-altering utilities in Chapter 19 to delete log line entries. Then, run chkwtmp and see what it finds.
tcplogd detects stealth scans.
Required: C
Config Files: tcplogd.init
Security History: tcplogd has no significant security history.
Notes: None
Scanners have come a long way since the original ISS release, and today many scanners support stealth scanning. This is where attackers tread lightly, often using difficult-to-detect, half-open connections. The result is that traditional scan detection tools can miss such attacks.
tcplogd was designed specifically to detect stealth scans common to scanners such as
Note
To learn more about NMAP, QueSo, and Saint, please see Chapter 8, "Scanners."
tcplogd includes logging, the ability to ignore ports/packets, and a function to prevent an attacker from flooding the daemon. With some minor work (shell scripts, perhaps, or something like LogSurfer), you can turn tcplogd into an alert system as well. Get tcplogd at http://www.kalug.lug.net/tcplogd/.
Snort is libpcap-based packet filter, sniffer, and logger that provides baseline network intrusion detection.
Required: libpcap, libc.so.6, Intel Linux, MkLinux, or S/Linux (SPARC)
Config Files: A user-specified rules file (see RULES.SAMPLE) and snort.conf.
Security History: Snort has no significant security history.
Notes: Snort is good for use in heterogeneous networks (it can send alerts to Windows workstations via Samba).
Snort is a rule-based intrusion detection tool that takes both the preemptory and reactionary approach. It listens to network traffic in real-time and matches that traffic against predefined rules. When it finds a match, it performs one of several actions:
Alerts you about the specified traffic
Logs the specified traffic
Ignores (passes) the specified traffic
To compose a rule, you must provide the following:
For example:
alert tcp any any -> 192.168.1.0/24 143 (msg:"IMAP Buffer overflow!"; content:"|90E8 C0FF FFFF|/bin/sh";)
This rule specifies that Snort should generate an alert if it detects an attack on port 143 (IMAP). Note the content specification:
content:"|90E8 C0FF FFFF|/bin/sh";)
This is a preloaded attack signature common to Taeho Oh's September 1998 imapd exploit, available at http://www.linux.opennet.ru/base/exploits/119.html.
Here's another example:
alert tcp any any -> 192.168.1.0/24 80 (msg:"PHF attempt"; content:"/cgi-bin/phf";)
Here, Snort watches for an old /cgi-bin/phf/ exploit. (Snort expects /cgi-bin/phf to appear somewhere in the incoming command line.) To review some typical PHF exploit source, go to http://www.insecure.org/sploits/phf-cgi.html.
Snort is a quick, reliable intrusion detection tool that requires meager system resources. You can add attack signatures by obtaining, compiling, and running exploits against your system while also running a sniffer. The sniffer will capture the characteristic text or binary string passed by the attack tool to your server. Take the last few significant or unique characters in that string and add them as a content descriptor in Snort.
Note
To speed up the attack signature addition process, try using Nessus (see Chapter 8). Nessus is updated often with the latest attacks, and it precompiles these as scan modules. By running a full Nessus scan on your system and simultaneously running a sniffer, you should be able to capture several hundred attack signatures. And if you do, post them to a security list so others can benefit from your research.
Get Snort at http://www.clark.net/~roesch/security.html.
HostSentry, part of the Abacus Project, is an intrusion detection tool that watches login anomalies.
Required: Python (recompiled to support dbm/gdbm and syslog)
Config Files: hostsentry.conf, hostsentry.modules, hostsentry.ignore, hostsentry.action
Security History: HostSentry has no significant security history.
Notes: HostSentry is still in beta, so it only logs anomalies for now. Future features that may be available by the time this book goes to press include account-disabling, automated IP blocking, and dropping the route to the offending host.
HostSentry employs Login Anomaly Detection (LAD). Anomalies include
Bizarre behavior—. In Chapter 19, I described a case where a non-technical user who had a shell account but never used it suddenly began logging into shell, compiling C code, and executing attacks. This was clearly an anomaly.
HostSentrywatches for such irregularities.Time anomalies—. When a user logs in at an uncharacteristic time, this can mean that an attacker has hijacked that user's account.
HostSentrywatches for this as well.Locale anomalies—. When a user logs in from an irregular or uncharacteristic (or even impossible) locale,
HostSentrygenerates an alert.
Also, as I indicated in Chapter 19, you can't always rely on your logs, especially since many crackers have tools that alter utmp, wtmp, and so on. This is why I suggested using some third-party or proprietary logging or intrusion detection tool. HostSentry is one such tool.
HostSentry watches logins (and system logs) and generates its own log information. Hence, if you detect discrepancies between your system logs and HostSentry logs, you know that an intrusion has taken place. The author is also currently adding cryptographic support so that HostSentry logs will remain tamper-proof.
While HostSentry is currently in beta, it looks like the final product will be indispensable. Get HostSentry at http://www.psionic.com/abacus/hostsentry/.
Required: C, Perl, libpcap, tcpdump, tcpslice, Apache, SSH
Config Files: Many. Please see the documentation.
Security History: Shadow has no significant security history.
Notes: None
Shadow is freely available from the Lawrence Berkeley Research Laboratory and the Naval Surface Warfare Center Dahlgren Division. It's a collaborative effort between several well-known security professionals, including Alan Paller from the SANS Institute, Vicki Irwin, Bill Ralph, and Stephen Northcutt.
Note
Northcutt, in particular, has worked on some interesting projects. Stationed at the Naval Surface Warfare Center, he was instrumental in uncovering several emerging stealth techniques in which crackers from disparate locations work in concert to attack a single target. These attacks were incredibly difficult to detect because the attackers would often send one packet every few minutes! Check out Northcutt's corner of the Web for tools he's written, as well as good links and advice on network security: http://www.nswc.navy.mil/ISSEC/index.html.
The Shadow project provides a publicly available, open-source intrusion detection system that allows you to obtain, at any time, a Web-based snapshot of attacks being launched against your site.
Of all the more sophisticated systems listed in this chapter, Shadow is the most easily installed and the one that will give you the most bang for your buck. Basic configuration, as described in the documentation, involves a sensor machine placed outside your firewall and an internal machine that analyzes logged data. Traffic between machines is armored with Secure Shell, and logs are automatically rotated, compressed, and decompressed.
The Shadow project offers complex tools that enable you to distribute security and intrusion detection information between several hosts. It can therefore be used to detect sophisticated attacks in which multiple attackers and targets are mixed and matched. Attackers are now using such sophisticated attacks to obscure their activity, spreading it across several hosts from several source addresses. Because the resulting logs are not unified, such attacks are difficult to pinpoint or identify. Hummer works in cross-host environments and is one potential solution. It can class hosts into hierarchies and groups and can reduce the cloud factor in analyzing results. Hummer is to regular intrusion detection tools as C++ is to C—a step forward.
MOM is a powerful, complex, distributed intrusion detection tool for watching entire networks.
Required: C, Perl 5.003, Perl/Tk (for GUI)
Config Files: Many. See documentation.
Security History: MOM has no significant security history.
Notes: This tool is a whopper. The author describes MOM as "…syslog on steroids…", but this is a gross understatement.
MOM is designed to provide network-wide intrusion detection. If you're looking for a tool to use on a single machine, MOM isn't for you. Briefly, the MOM system works like this:
The main process (the
MOMparent) runs on a central machine. There it gathers, sorts, and reports on data received from children on other hosts.On other hosts, a child client process runs. This process (among other things) reports anomalies to the central
MOMhost.On all hosts,
MOMruns various agents that perform various maintenance, diagnostic, and intrusion detection tasks.
For generalized syslog watching, MOM uses WOTS as an agent. WOTS is a tool for monitoring logging output from multiple sources and then generating actions and reports based on what it finds. (If you find this, do this.) WOTS' chief advantage is that it can watch several log files from a single instance of itself.
Other agents include
scan-detector.pl—This is a generic, Perl-based TCP/UPD scan detector. It should run out-of-the-box without problems, providing you have Perl correctly installed. To learn more aboutscan-detector.pl, check Chapter 8.net.agent—This agent watches your network services (HTTP, FTP, Telnet, etc.).cping.agent—This performs maintenance by checking that all machines listed asMOMhosts have aMOMchild process running.
These tools (and others) independently collect important data on individual hosts and report this data (if significant) to the central MOM unit. At each level of the MOM system, you can specify which action should be taken if a specified pattern is found. For example, you can configure MOM to send email, trigger a pager, or run a script when faced with a particular attack.
Moreover, MOM allows you to query individual children at any time. A special tool takes the query results and formats them into nice, readable logs, either in the GUI or plain text.
Note
The central MOM module has a rugged GUI, primarily for watching log reports in real-time, but you needn't necessarily use it. If you do, you'll need the Perl/Tk extensions.
MOM is primarily of interest to folks with large networks who would like to experiment with intrusion detection. If MOM piques your interest, get it at http://www.biostat.wisc.edu/~annis/mom/.
The HummingBird System is an intrusion detection system for large networks.
Required: g++, Perl 5+, Apache, Kerberos
Config Files: Many. See documentation.
Security History: The HummingBird System has no significant security history.
Notes: None
The HummingBird System (also called Hummer) is a complex toolkit that gives you the power to distribute security and intrusion detection information between several hosts. It can therefore be used to detect sophisticated attacks in which multiple attackers and targets are mixed and matched.
Attackers are now using such attacks to obscure their activity, spreading it across several hosts from several source addresses. (Stephen Northcutt, from the Shadow Project mentioned earlier, offers sample logs from such attacks on his Web site.)
Because logs resulting from such attacks are generally not unified, the attacks are difficult to pinpoint or identify. Hummer works in cross-host environments and is one potential solution. It can class hosts into hierarchies and groups and reduce the cloud factor in analyzing results.
In some respects, Hummer's functionality vaguely resembles MOM's. Hummers on individual machines report data to the Hummer server, which in turn can take action, log the information, or relay it to other Hummers. You can control the behavior of these agents through a centralized, Web-based interface. Moreover, a complex but robust system was included to relay that information between groups of authorized users over the Internet. Hence, you could theoretically have a technical staff remotely monitor network events 24 hours a day on rotation. (A bit extreme, to be sure, but fascinating all the same.)
Finally, the HummingBird System is extremely well documented. It ships with a paper that meticulously documents the system's development, bugs, fixes, and so on.
Check out the HummingBird System at http://www.csds.uidaho.edu/~hummer/.
AAFID is a distributed monitoring and intrusion detection system that employs small standalone programs (agents) to perform monitoring functions in the hosts of a network.
Required: C, Perl 5.004, Data::Dumper, Log::Topics, MD5, Perl/Tk (4.2 or 8.0), Perl IO modules (IO::File, IO::Handle, etc.), and the Perl Socket modules
Config Files: Many. See documentation.
Security History: AAFID has no significant security history.
Notes: AAFID is a new tool (released in September 1998) and is thus far experimental but very interesting. However, before you use it, take time to become familiar with Perl module use. I strongly recommend getting O'Reilly and Associates' Perl Resource Kit for UNIX, a five- volume CD-ROM box set that includes a complete module reference. (In other words, if you want a quick fix that doesn't demand time, energy, a multi-host network, and perhaps a moderate investment, you should probably skip AAFID.)
AAFID is the product of the Autonomous Agents for Intrusion Detection Group from the COAST Laboratory at Purdue University. You may know COAST from their extensive security archive, located at http://www.cs.purdue.edu/coast/archive/index.html.
The AAIDG team created AAFID in an effort to improve on existing intrusion detection models. In particular, they were aiming for something that wasn't entirely reliant on centralization. As they explain in their paper An Architecture for Intrusion Detection using Autonomous Agents:
The central analyzer is a single point of failure. If an intruder can somehow prevent it from working (for example, by crashing or slowing down the host where it runs), the whole network is without protection.
Moreover, the AAGID team saw that current IDS trends were leading to complex systems that relied heavily on interdependent processes. Also, many intrusion detection systems demanded that system configuration also be centralized. These two characteristics made it difficult for system administrators to alter the behavior of separate IDS components without altering the entire system. AAFID was their answer to these problems:
An
AAFIDsystem can be distributed over any number of hosts in a network. Each host can contain any number of agents that monitor for interesting events occurring in the host. All the agents in a host report their findings to a single transceiver. Transceivers are per-host entities that oversee the operation of all the agents running in their host. They exert control over the agents running in that host, and they have the ability to start, to stop and to send configuration commands to agents. They may also perform data reduction on the data received from the agents. Finally, the transceivers report their results to one or more monitors. Each monitor oversees the operation of several transceivers. Monitors have access to network-wide data, therefore they are able to perform higher-level correlation and detect intrusions that involve several hosts.
(From An Architecture for Intrusion Detection using Autonomous Agents, Jai Sundar Balasubramaniyan, Jose Omar Garcia-Fernandez, David Isacof, Eugene Spafford, and Diego Zamboni, COAST Laboratory, Purdue University.)
The AAFID distribution comes with default rules and filters, but it also includes voluminous tutorials about writing your own filters and agents. AAFID is suitable for testing in large network environments. Check it out at http://www.cs.purdue.edu/coast/projects/aafid-announce.html.
Finally, if you'd like to learn more about the technical aspects of intrusion detection, check out the following documents online.
A Framework and Prototype for a Distributed Intrusion Detection System, Diego Zamboni and E. H. Spafford, Department of Computer Sciences, Purdue University, Coast TR 98-06, 1998. Check availability at http://www.cs.purdue.edu/coast/projects/autonomous-agents.html.
A Pattern Matching Model for Misuse Intrusion Detection, Kumar and Spafford http://www.raptor.com/lib/ncsc.pdf.
An Application of Pattern Matching in Intrusion Detection, Kumar and Spafford http://www.raptor.com/lib/ncsc.94.ps.
An Architecture for Intrusion Detection using Autonomous Agents, Jai Balasubramaniyan, Jose Omar Garcia-Fernandez, E. H. Spafford, and Diego Zamboni, Department of Computer Sciences, Purdue University, Coast TR 98-05, 1998 ftp://coast.cs.purdue.edu/pub/COAST/papers/diego-zamboni/zamboni9805.ps.
An Evening with Berferd: In Which a Cracker is Lured, Endured, and Studied, Bill Cheswick http://www.alw.nih.gov/Security/FIRST/papers/general/berferd.ps.
An Introduction to Intrusion Detection, Aurobindo Sundaram http://www.acm.org/crossroads/xrds2-4/intrus.html.
Artificial Intelligence and Intrusion Detection: Current and Future Directions, Proceedings of the National Computer Security Conference, Frank, J., 1994. This document addresses teaching machines to detect intrusion via common patterns. http://phobos.cs.ucdavis.edu:8001/papers/ncsc.94.ps.gz
ASAX: Software Architecture and Rule-base Language for Universal Audit Trail Analysis (An experimental intrusion detection system), Naji Habra, Baudouin Le Charlier , Abdelaziz Mounji, and Isabelle Mathieu. ftp://coast.cs.purdue.edu/pub/doc/intrusion_detection/HabraCharlierEtAl92.ps
Bro: A System for Detecting Network Intruders in Real-Time, proceedings of the 7th USENIX ftp://ftp.ee.lbl.gov/papers/bro-usenix98-revised.ps.Z Security Symposium, San Antonio, TX, January 1998, V. Paxson.
Computer Break-ins: A Case Study, Leendert van Doorn http://www.alw.nih.gov/Security/FIRST/papers/general/holland.ps.
DIDS (Distributed Intrusion Detection System)— Motivation, Architecture, and an Early Prototype, Steven R. Snapp, James Brentano, Gihan V. Dias, Terrance L. Goan, L. Todd Heberlein, Che-Lin Ho, Karl N. Levitt, Biswanath Mukherjee, Stephen E. Smaha, Tim Grance, Daniel M. Teal, and Doug Mansur, Computer Security Laboratory, Division of Computer Science, University of California, Davis. http://olympus.cs.ucdavis.edu/papers/DIDS.ncsc91.pdf
Distributed Audit Trail Analysis, Abdelaziz Mounji, Baudouin Le Charlier, Denis Zampunieris, and Naji Habra. ftp://coast.cs.purdue.edu/pub/doc/intrusion_detection/MounjiCharlierEtAl94.ps.gz
Emerald: Event Monitoring Enabling Response To Anomalous Live Disturbances, SRI International's Computer Science Laboratory (CSL). http://www.sdl.sri.com/emerald/index.html
IDIOT (Intrusion Detection In Our Time), Mark Crosbie, Bryn Dole, Todd Ellis, Ivan Krsul, Eugene Spafford. ftp://coast.cs.purdue.edu/pub/doc/intrusion_detection/IDIOT_Users_Guide.ps
Intrusion Detection In Computers, Victor H. Marshall. ftp://coast.cs.purdue.edu/pub/doc/intrusion_detection/auditool.txt.Z
Intrusion Detection:Challenges and Myths, Marcus J. Ranum, Network Flight Recorder, Inc.http://www.nfr.net/forum/publications/id-myths.html
Michael Sobirey's Intrusion Detection Systems Page. This page currently has 63 intrusion detection systems cataloged. http://www-rnks.informatik.tu-cottbus.de/~sobirey/ids.html
NetSTAT: A Network-Based Intrusion Detection Approach, G. Vigna and R. Kemmerer, Proceedings of the 14th Annual Computer Security Applications Conference, Scottsdale, Arizona, December 1998. http://www.cs.ucsb.edu/~kemm/NetSTAT/docs/vigna_kemmerer_acsac98.ps.gz
Secondary Heuristic Analysis for Defensive Online Warfare, Naval Surface Warfare Center, Dahlgren Division http://www.nswc.navy.mil/ISSEC/CID/.
The Intrusion Detection Archive. This is an archive of the (IDS) mailing list.http://www.geek-girl.com/ids/
There Be Dragons , Steven M. Bellovin. Description of attacks on the AT&T firewall.http://www.alw.nih.gov/Security/FIRST/papers/general/dragons.ps
USTAT: A Real-time Intrusion Detection System for UNIX, Koral Ilgun,Technical Report TRCS93-26, Computer Science Department, University of California, Santa Barbara. http://www.cs.ucsb.edu/TRs/techreports/TRCS93-26.ps
Why Firewalls Are Not Enough, Network ICE Corporation. White paper supporting an argument for the BlackICE IDS.http://www.networkice.com/Library/firewalls.htm