9.2. IDS Architectures

 < Day Day Up > 

Just as there are many types of networks and environments, there are many types of IDS. Understanding your IDS options is key to ensuring that your IDS infrastructure is a valuable addition to your security architecture and not simply wasted processing power.

9.2.1. Host-Based IDS

Host-based IDS (HIDS) monitors activities on a single host looking for signs of attack. HIDS may look for changes in important files such as password files and network configuration. Some HIDS actively monitor syscall activity to determine when a process is attempting to access a resource to which it normally would not have access. Further, some HIDS are geared towards protecting databases by observing queries and other transactions. Figure 9-2 shows HIDS processes running on multiple hosts. Notice that each host needs to have its own HIDS capability.

Figure 9-2. HIDS processes monitoring attacks on multiple hosts


HIDS have the advantage of being able to detect a wide variety of attacks across diverse interfaces. HIDS can watch activity not only from the network, but also from the console or other interfaces. HIDS can also be highly customized to a particular host. For instance, syscall auditing can be highly accurate on hosts like mail and DNS servers that do the same thing day in and day out.

Unfortunately, HIDS can have a large management overhead. The HIDS software must be installed on every host that is to be monitored. For free software, this is merely administrative overhead. However, when HIDS software is licensed per installation, costs can skyrocket. This, of course, needs to be balanced with the potential Total Cost of Ownership (TCO) of a HIDS. While the open source solution may be license free, it may be ultimately more difficult to administer and use, costing you more money in the long run. Commonly HIDS are installed on servers that are higher value targets and may be worth the administrative and cost overhead.

Further, the audit logs from each HIDS installation have to be aggregated and examined. For networks with thousands of hosts, this can be quite difficult and may outweigh the advantages HIDS offer.

9.2.2. Network-Based IDS

Network-based IDS (NIDS) are intrusion detection systems that monitor network traffic for many hosts at a time. NIDS promiscuously sniff network traffic and look for signs of attack. Figure 9-3 shows a NIDS on the same LAN seeing an attack launched against the web server.

Figure 9-3. NIDS detecting an attack


NIDS tend to be made up of sensors located throughout a network and a centralized management server. The sensors are responsible for actively sniffing traffic and detecting attacks. Once an attack is sensed, these sensors send their data to the central management server. The central management host is also usually responsible for configuring and updating attack signatures on the sensors. This server may have a database to store the sensor events for rapid correlation and analysis by a security administrator.

NIDS excel at finding attacks across a wide collection of hosts. There is an economy of scale with NIDS that allow many hosts to be monitored by one special purpose sensor. However, there is also a sacrifice. NIDS don't have the view into each host that a HIDS does. NIDS alerts are a bit more of a "guessing game" in the sense that a NIDS will likely not be able to tell if an attack was successful. For some, this is an important distinction as they only want to be notified when a compromise or service disruption has actually occurred. For others, the knowledge of attacks, even if compromise was not achieved, is critically important. This is a debate that you will have to weigh in your own enterprise.

False Positives and False Negatives

There are many metrics that people try to use to quantify NIDS. Packets per second, total number of signatures, and number of concurrent sessions are all tangible quantities that NIDS vendors can measure in a lab. However, the rate of false positives and false negatives is not so measurable. Basically, false positives are events that a NIDS will identify as an intrusion but are actually not successful compromises of a system. This gets to a core issue with modern-day NIDS systems. Many of them are signature based, and when they alarm, they are really providing you notification that some traffic matched a known malicious signature. They do not actually detect intrusions, rather they detect signs of intrusions. Unfortunately that fine point is often lost on security administrators, making false positives a real problem.

False positives cause security administrators to waste their time tracking down intrusions that never actually happened. Or worse, false positives can desensitize administrators to alerts generated by a NIDS and cause them to ignore future alerts.

False negatives are successful intrusions that were not caught by the NIDS. False negatives are what people typically think of as an "IDS failure" because an administrator viewing IDS alerts thinks everything is fine, when in reality an attacker is inside the system.

Reducing the numbers of false positives and false negatives is an ongoing activity of not just the IDS vendor but also by the organizations running the NIDS. NIDS need to be tuned to their environment to minimize both values. Tuning is performed by manipulating settings for when a NIDS issues alerts and changing the traffic that can generate an alert. Tuning a NIDS can be a laborious process, but it's critical if you want to have a realistic view of ongoing attacks on your network.


One of the challenges of NIDS is placement of sensors. Sensors must be able to sniff traffic destined to hosts you want to monitor. In theory, you could place a sensor in front of each host. Figure 9-4 shows this extreme NIDS implementation. However, this would likely be prohibitively expensive to deploy and maintain. This architecture has all the management problems of HIDS architectures with none of the advantages of HIDS.

Figure 9-4. A NIDS sensor per host


So, sensor placement can be pushed farther away from the host in a network to be able to intercept traffic at subnet boundaries. However, this may still be expensive to deploy and difficult to implement on complex network infrastructures. Ultimately, sensors may be pushed to the core of a network. However, at the core, target traffic may bypass the sensor completely. Figure 9-5 shows attacks at the edge of a network being missed by a central core sensor.

Further, the amount of data being passed through the core of a network may exceed the capacity of the sensor. Ultimately, sensor placement in your network must be a balance between the economy of running fewer sensors and the advantages of having deeper sensor penetration.

Figure 9-5. A NIDS sensor at a network core


There are a variety of ways to get traffic to a sensor. One option is a tap. A tap is a specialized device that splits traffic off of a physical wire into two streams. Think of it in the same way a phone line is tapped. One stream goes to the endpoint just as it was original destined. The other stream of exactly the same data goes to the IDS sensor. Figure 9-6 shows a network tap in front of a server. All traffic going to the web server is duplicated by the tap and sent to the NIDS sensor.

Figure 9-6. Network tap


However, a tap may be infeasible due to network architecture. There may not be a single wire that can be tapped that provides the proper view of your network. Another option is to utilize the potential capability that your Ethernet switches may have. Some switches can flood traffic from multiple ports or VLANs to a single port. For instance, on a Cisco switch, this is called a span port. On other devices, it may be called a mirror port. Span ports serve as virtual network taps and may be more flexible than a network tap. In Figure 9-7, traffic from all ports on the switch is forwarded to the span port connected to the NIDS sensor. Typically, a span port is a transmit-only port on the switch. That means any data sent from the NIDS sensor will be dropped by the switch, effectively making a one-way cable attached to the sensor.

Figure 9-7. Span port on a switch


Another issue with respect to placement is whether your IDS sensor should be in front of or behind your firewall. Firewalls should be stopping the majority of random scans and attacks that target your network. If an attack doesn't make it past the firewall, then there is no chance of it successfully compromising a host. By placing your IDS sensors behind the firewall, you only watch traffic destined for internal hosts.

Internal placement can be good or bad, depending on how you look at it. Since many attacks are blocked by the firewall, you should receive fewer alerts from the IDS. However, the firewall may block precursor events, such as port scans, that may signal a broader attack at a later date. To overcome this, you can always put a sensor on the inside and a sensor on the outside of your firewall. Conversely, you can rely on your firewall logs to provide the detailed information about dropped packets. Again, the placement will be based on your particular environment.

9.2.3. Log Analysis Versus IDS

The term Intrusion Detection System tends to imply a specialized piece of software or hardware designed to detect attacks against a system. Some IDS products are highly sophisticated, enterprise-level systems. Other intrusion detection techniques may have security value, but ultimately may not be considered mainstream intrusion detection. Analysis of logfiles is such a technique.

By analyzing logfiles, an administrator may be able to find traces of an attack. However, logfiles are used for many other purposes besides intrusion detection. Although as it may not be necessary to draw a dark line around what is and what is not IDS, the term "IDS" tends to be associated with a specialized security product. Log analysis, while potentially part of determining if an intrusion has occurred, is more of a general purpose system administration technique. Some tools, like swatch, can be configured to monitor logfiles for security specific events such as password failures. These tools, however, are best incorporated into a holistic monitoring view rather than pigeonholed as an IDS solution.

9.2.4. Honeypots Versus IDS

As the old saying goes, "you attract more bees with honey than with vinegar." Similarly, you attract more hackers with an extremely vulnerable system than you do with a well secured system. That's the basic idea behind a honeypot. A honeypot is a host that entices an attacker. It may have active services with perceived vulnerabilities within these services (e.g., a version of OpenSSH that looks vulnerable).

However, the trick with a honeypot is that this "exploitable" host is not what it seems. A honeypot is really a collection of tools designed to fool an attacker into believing he has compromised a live host. However, no compromise has really occurred. Rather, the honeypot is logging the activities of the attacker, attempting to gain insight into his tools, methods, and potentially uncovering his motives for exploiting a host. For instance, a honeypot that is compromised by an automated script may indicate that an attacker was simply looking for a target of opportunity. However, a honeypot where an attacker interactively works with the host and attempts to learn about the services and how to exploit trust relationships may indicate a targeted attack upon your organization.

Honeypots are not IDS hosts. Their purpose in life is to be intruded upon, not detect intrusions. While you can infer activities on the rest of your network from the activities on a honeypot, it is not really a tool that gets integrated into your operations. Honeypots require a great deal of care to ensure they are not used in a manner you do not intend. Further, decomposing what has happened on a honeypot after an intrusion can be very time consuming. Honeypots make great research tools, however for an active enterprise with limited resources, they can be a tremendous waste of time.

More information on honeypots and lessons learned from them can be found at the Honeynet Project's homepage, http://www.honeynet.org/. The Honeynet Project is an organization dedicated to the study of how hackers operate and to assisting the community in understanding the ever-changing blackhat landscape.

9.2.5. Intrusion Prevention Systems

An IDS is a passive system. While the information an IDS generates may be useful for detection and responding to intrusions, responses are usually out of band and often involve a human. A recent trend has been for IDS vendors to create Intrusion Prevention Systems (IPS) that place IDS technology in the critical path to an application.

An IPS is an active version of an IDS. Rather than simply reporting an attack, an IPS will actively block the malicious traffic. The core logic is the same as an IDS, however the IPS sits in the network like a firewall and can control access to internal hosts. Figure 9-8 shows an IPS blocking an attack. Compare this to Figure 9-6 where the NIDS sensor is just a leg on the network and cannot do anything to prevent the attack from occurring.

Figure 9-8. Intrusion Prevention System


The danger of an IPS is that legitimate traffic may be blocked by the device. IDSes have a history of excessive false positives. In the case of an IDS, a false positive only results in an alert being generated.

Although we're passing off false positive alerts from an IDS as innocuous, this is done purely for illustrative purposes. Remember the boy who cried "Wolf!" Never underestimate the desensitization that comes with gratuitous alerting.


In an IPS, the false positive can result in valid traffic being denied. In fact, an attacker may exploit this capability by spoofing traffic from a victim host to deny service through the IPS. For some networks, this is completely unacceptable. In the case of an e-commerce web site, denied traffic may be directly tied to loss of revenue. The risk of blocking valid traffic may outweigh the need to protect the network.

     < Day Day Up > 


    Mastering FreeBSD and OpenBSD Security
    Practical Guide to Software Quality Management (Artech House Computing Library)
    ISBN: 596006268
    EAN: 2147483647
    Year: 2003
    Pages: 142
    Authors: John W. Horch

    flylib.com © 2008-2017.
    If you may any questions please contact us: flylib@qtcs.net