Chapter 9. Intrusion Detection and Honeypots

The difference between ‘involvement’ and ‘commitment’ is like an eggs-and-ham breakfast: the chicken was ‘involved’—the pig was ‘committed.’

—Author unknown

The machines have taken over the world. Check into it if you want, but the truth is that they have taken over, and we are simply providing the power to run them. We exist as some kind of power cell and nothing more. (Pretty weird so far, huh?)

Does this sound like some kind of nightmare, or perhaps the plot of a high-end science-fiction movie? Take a moment and decide whether the guy in the trench coat and sunglasses is telling you the truth. Are you ready to cross through the looking glass and really see what’s going on? Are you ready to give up 24 hours of cable TV, media propaganda, chocolate milk, and video games? You decide if you want the truth. You can’t handle the truth! Or can you?

You wake up and find yourself surrounded by a glass cocoon filled with sticky fluid and discover that you have probes plugged into your spinal cord. Could this story get any worse?

It can, and it does. You start unplugging the probes one by one. Before you completely realize where you really are, creepy spider machines start hovering around you and checking you out (don’t you hate it when that happens?) and smacking you around.

And then..., and then.... Go ahead and turn the lights back on; yes, you over there by the light switch—flip the switch. We need to stop for a moment and discuss what in the world, if anything, all of this has to do with a chapter on Intrusion Detection Systems and Honeypots.

Although it is partially “borrowed” from a popular movie, this story gives you a sneak peek at the basic premise of how an Intrusion Detection System (IDS) works. IDSs function on three basic premises:

• Where to watch

• What to watch for

• What to do

The first premise, “where to watch,” tells the IDS the logical location it will be monitoring for something to happen. Our little story has you as the “where to watch” portion. The evil machine empire has instructed the creepy spider machines to monitor you and make sure that you do not wake up.

The second premise, “what to watch for,” tells the IDS conditions for which it is supposed to be looking for to raise an alarm or some other kind of action. In this case, the creepy spiders were programmed to look for you to wake up and unplug the probes. Back in the old days, all it took was someone waking up to get the creepy spiders going. Things really have changed, haven’t they?

The third premise, “what to do,” is the action the IDS has been told to take when a situation meets certain parameters. The creepy spiders were programmed to fly up to your pod and smack you around if you happen to wake up and start monkeying around with your sleep chamber.

Let’s put all the spiders and sci-fi stuff aside for a minute and take a look at a real-world example of an IDS in action:

1. You install an IDS to watch the Internet connection and those trying to get into your network through your firewall.
2. You tell the IDS what types of hacks and attacks to look for based on their packet and connection type and what activities these might generate.
3. You tell the IDS to page you and send you an e-mail when one of these attacks occurs.
4. Uber Haxor comes knocking on your door with a port scan (can’t be too uber or too much of a haxor, starting off with something that obvious) that scans the first 1000 TCP ports.
5. The IDS sees the sequential connection attempts to all these ports, checks its database, and sees that this behavior matches the profile you entered that tells it how to recognize a port scan.
6. It attempts to e-mail you and page you at the same time.
7. Suddenly, the port scans increase, and they also come from another source.
8. The IDS also notifies you of this attempt.

Now you have your IDS configured properly; it sits and watches your network 24 hours a day, ready to alert you at the first sign of any funny business.

Sounds pretty cool so far, doesn’t it? Has anyone spotted the flaw in the whole IDS operating principle?

First, the IDS can watch only one interface at a time.

Secondly, the IDS watches only for conditions that you tell it about. If it has not been programmed to watch for the “double-reverse twinkie” attack, it will not let you know if one does occur.

Finally, an IDS can actually become an ally to hackers. Impossible, you say? How many times do you still run right out of the house and check your car when you hear the factory-installed alarm go off in the middle of the night? The same “crying wolf” situation can occur with an IDS. If your pager starts filling up with messages sent by the IDS, you start filtering out what you believe to be “false positives;” this could lead to you missing the pages that could really mean something.

The secret to configuring and deploying an IDS is “tweaking.” You must deploy the IDS in a lab first, see what normal traffic causes the IDS to alert, and then start “turning down the squelch”—that is, decreasing the IDS’s sensitivity to these conditions. You can also resist the urge to alert on everything that occurs. Most people want to be notified of every little “burp” that takes place, but this is not realistic. IDSs are not perfect, and they generate false positives from time to time. Let’s take a real-world look at the essentials behind Intrusion Detection.

Essentials First: Intrusion Detection

Networks of all sizes are designed to enable the sharing of information, and only rarely is security a part of that design. Many businesses are leveraging IP-based networks, such as the Internet, to bring remote offices, mobile workers, and business partners into their trusted internal network environments. The Internet is continuously growing and connecting more and more places; as it becomes increasingly reliable, companies can redefine how corporate applications function. The clearest example is how almost everything is becoming based on HTML. Although this enables businesses to have broader interaction with customers, streamline operations, reduce costs, and increase revenues, it also comes at a price and with risks.

The very reach and openness that makes the Internet such a powerful business tool also makes it a tremendous liability. Simply put, the Internet was designed to connect and share, not to secure and protect. The websites and portals that welcome remote sites, mobile users, customers, and business partners into the trusted internal network might also be welcoming attackers who would misappropriate network resources for personal gain. As discussed in Chapter 8, “Wireless Security,” the growth of wireless networks is compounding this problem.

The question becomes this: How are these mission-critical communications protected from an inherently insecure medium such as the Internet? This book has covered various means of increasing the security of these resources by adding layers of protection. The most common layers of security in a network are an Internet router prescreening packet and a stateful firewall. However, your organization has both a web and e-mail server that must be accessible from the Internet to function. You cannot block this traffic because your business depends on it. We also know that, as the Internet has grown, so have the sophistication of the attacks; however, the knowledge level required to conduct these attacks has decreased, as shown in Figure 9-1.

Figure 9-1. Attack Sophistication and Attacks

Neither the router nor the firewall can tell you if that WWW packet actually contains an attack or a customer; unfortunately, many people have placed their trust in these devices, which can fall short in the detection arena. Perhaps your organization has a talented system administrator who is trusted to “secure and lock down” business-critical servers or implement thorough security policies and procedures. None of the security solutions discussed so far address the need to detect attacks or intrusion attempts!

In Internet terms, Intrusion Detection is rather young; research began in the 1980s with the efforts and writing of Anderson and Denning. In the 1980s, the government first began using basic IDS functionality on what was then still the ARPANET. Late in the 1980s, members of the Haystack Project formed Haystack Labs as a commercial venture into developing host-based intrusion detection. Network-Based Intrusion Detection followed in the 1990s with Todd Heberlein leading the charge. By then, several organizations were developing IDS tools, Haystack Labs, SAIC; the United States Air Force developed ASIM (automated security measurement system), and the team that developed this solution formed the Wheel Group in 1994, as shown in Figure 9-2.

Figure 9-2. IDS Development Timeline

This is relevant to the discussion because, in 1994, Cisco purchased the Wheel Group; this acquisition formed the core of the IDS and security services.

Whether an attacker’s motive is intellectual challenge, espionage, political, financial, or even just to make trouble, your network will face an attack. Not only is it common sense to monitor these attacks, but in many cases, it is also a business imperative. Starting in the early 1990s, new products began to appear to deal with this aspect of network security: Intrusion Detection Systems (IDS). An IDS is like an alarm system for your network. The network is protected, but without the IDS (alarm), you would never know whether an attacker was trying to gain entry. The goal of Intrusion Detection is to monitor network assets to detect unusual behavior, inappropriate activity, and attacks, or stop the attack (intrusion) and even provide information to prosecute the attacker.

IDS can be deployed in a variety of locations within a network to further increase an organization’s security and protection. In general, two basic forms of IDS are used today: network-based and host-based IDS. Both types of sensors offer different techniques for detecting and deferring malicious activity, and both should be deployed to provide the most effective enhancement to a layered defense strategy:

• Network-Based Intrusion Detection System (NIDS) reside directly on the network and watch all the traffic that traverses the network. NIDS are effective at both watching for inbound/outbound traffic flows and traffic between hosts on or between local network segments. NIDS are typically deployed in front of and behind firewalls and VPN gateways to measure the effectiveness of those security devices and interact with them to add more depth to the network’s security.

• Host-Based Intrusion Detection System (HIDS) are specialized software applications that are installed on a computer (typically a server) to watch all inbound and outbound communication traffic to and from that server and to monitor the file system for changes. HIDS are extremely effective on mission-critical, Internet-accessible application servers, such as web or e-mail servers, because they can watch the applications at its source to protect them.

NIDS and HIDS should be deployed together to provide a truly effective layered defense with visibility into and control of an organization’s communications. IDSs also provide organizations a check-and-balance on the effectiveness of their security systems and the overall effectiveness of their security dollars. The next section discusses the overall capabilities of an IDS.

IDS Functional Overview

IDS systems that are available on the market today promise a plethora of feature sets and capabilities. In evaluating an IDS for your organization, the following capabilities should generally be the focus, beyond traditional event logging:

• Event correlation—When an IDS is deployed in a busy network with multiple IDS, the ability to correlate events (attacks) is crucial to ensuring that your network is secure. Consider that an attack could span multiple segments as one host is compromised and then used to attack another, and so on. Without proper event correlation, this attack could cause great confusion and lead to many hours of wasted resources attempting to isolate the cause of the outage. Event correlation allows the IDS administrator to quickly track down and relate events that occur across multiple sensors that are deployed in different subnets, or perhaps in different geographical locations and over extended periods of time.

• Centralized sensor management—Having an IDS be able to correlate events is important, and having all the IDS managed via centralized management is just as critical. In the real world, every device (server, router, firewall) creates logs; however, they are rarely checked, let alone reviewed. Therefore, having a centralized management platform that allows for event correlation and response control over multiple sensors and the ability to run detailed reports on your network’s security is crucial for success.

• Customizable signatures and thresholds—Company or business-specific applications, software upgrades, new operating systems, viruses, and intelligent hackers are always looking for and discovering new vulnerabilities. There is always a delay from when a new vulnerability is discovered and IDS developers release a new signature that detects the attack that is used to exploit the vulnerability. Therefore, an IDS must allow administrators the ability to create attack signatures to deal with any eventuality.

• Elimination of false positives—Just like every operating system (such as Windows) that comes with all the features enabled, so do IDS devices. In other words, they are overly sensitive out of the box and provide a lot of false positives, thereby resulting in FUD (fear, uncertainty, and doubt) about your network security. You can understand, then, that every good IDS must have the capability to eliminate false positives. Caution, however—only eliminate if you are sure and, if you are sure, wait 24 hours.

• Standards-based implementation—An important aspect of deploying any technology is choosing an implementation that is standards-based. Many vendors create products that perform wonderful security services, but few are interoperable or provide the framework for future implementations. IDS is no exception to this rule, and few standards currently exist. Because the most important aspect of integrating IDS and managing it are its reporting capabilities, a standard has emerged based on the Common Vulnerabilities and Exposures (CVE) database. The CVE database both classifies and groups vulnerabilities into an easily referenced system. CVE compatibility is important for IDS because it provides reporting capabilities that far surpass the typical cryptic reporting historically found in IDS. By integrating CVE-compatible IDSs, organizations can use other CVE-compatible tools, such as Vulnerability Assessment (VA) tools, to further enhance the accuracy and criticality of event reporting. CVE has become widely adopted and will continue to be a standard method of reporting and classifying network security events (http://cve.mitre.org/cve/).

• Intrusion Prevention functionality—Intrusion Prevention is essentially the ability to actively respond to and prevent intrusions and unwanted traffic. The term “Intrusion Prevention” has recently been the subject of much confusion and is often marketed as a competing technology to Intrusion Detection. However, the reverse is true: In today’s market, an IDS must support the capability to actively respond to suspected threats.

• Signature matching—Monitors all traffic traversing a network and then matches each packet or series of packets with known attack patterns (signatures). The IDS then responds either passively or actively to that event. The response can vary from generating an SNMP alarm, crafting an e-mail alert, or actively stopping the attacker from being able to complete the attack (also referred to as Intrusion Prevention).

• Anomaly detection—Allows an IDS to establish a baseline of normal traffic patterns and information flows, and then respond whenever the normal thresholds are exceeded (for example, if a new protocol is detected on a network). Anomaly Detection becomes most effective when it’s coupled with Protocol Decoding, whereby the IDS knows what normal behavior is expected within certain protocols and responds if abnormal commands or requests are detected.

There is a common misconception about IDSs and the fact that they can monitor everything; this is just not true. Having an IDS as a layer in your overall security plan is a good idea. However, depending on it as a one-stop solution is a bad idea.

Network Intrusion Detection System (NIDS)

Network Intrusion Detection System (NIDs) sit and “capture” all the packets on the network segment to which they are connected. This reading is similar to a packet sniffer; however, the differences appear after the packets are captured or sniffed. NIDSs are built on the wiretap concept and can be implemented in a couple of different ways. These methods have been developed to deal with the prevalence of LAN switches and how they operate to isolate traffic. An IDS must see as much of the network traffic as possible to be effective. The different NIDS implementation methods are as follows:

• Inline wiretap—This method of capturing packets places a physical tap in between (that is, inline between) two network devices. The NIDS would be plugged into this tap.

• Port mirroring—Depending on the switch you are using, port mirroring, also known as port spanning, is perhaps a more flexible solution. This technique tells the switch to send copies of every packet that, for example, is to be sent to the port your firewall is plugged into to another port. The NIDS is connected to this mirrored port.

After the NIDS reads the packets, the packets are analyzed in a variety of ways, depending on the NIDS you are using. Some NIDSs look for a fingerprint match by comparing the packet to the attack signatures it has in its database, while others look for unusual packet activity that could indicate that an attack is in progress. One of the benefits of a NIDS is that, once installed, they are unobtrusive and stealthy.

There are some issues relating to scalability and timeliness that the IDS industry is still trying to overcome. NIDSs have had some trouble scaling as network speeds have increased, and with Gigabit Ethernet making inroads to networks of all sizes, it will not be long before 10 Gigabit speeds will be used. Of course, NIDSs want to capture every single packet and analyze its contents; this makes these new speeds a bottleneck that has not yet been completely solved. In addition, the updating of attack signatures is not yet close to being where it should be to detect the latest attacks. It is clear that IDS vendors and how they update signatures are still a far cry from the timeliness the anti-virus community has achieved.

NIDS deployment is entirely based on the existing network design and architecture that is in place at each location. The more network segments a network has usually determines the number and placement of NIDSs.

Traditional NIDS placement allows them to be the most effective on the network perimeter, such as on both sides of the firewall (internal and external), near the dialup server, and on links to business partner networks. This placement allows an organization to measure the real effectiveness of its pre-screening routers and firewalls. These links tend to be low bandwidth (T1 speeds) such that an IDS can keep up with the traffic. This provides a good measure of checks and balances and is ideal for the security-aware organization, where application servers behind the firewall are accessible to the public Internet. Another high-value point is the corporate WAN backbone. A frequent problem is hacking from “remote” areas of the network into the main corporate network. Because WAN links tend to be low bandwidth, NIDS can be extremely beneficial.

Security best practice says that, when considering an IDS solution, both internal and external NIDSs should be used. This allows the NIDSs to monitor attacks from the Internet and internal threats. It might seem a bit odd to have two NIDSs; however, remember that statistically, the majority of attacks come from internal sources. Neglecting either location reduces the effectiveness of the IDS solution and greatly decreases your network’s security.

Host Intrusion Detection System (HIDS)

Host Intrusion Detection Systems (HIDS) monitor, detect, and respond to user and system activity and attacks on a given host. In contrast to NIDSs, HIDSs are installed on the host (for example, the web or e-mail server) to be monitored. HIDS monitors the host’s audit and event logs, whereas a NIDS monitors packets. Rather than trying to identify packets contents versus attack signatures, the HIDS approach attempts to identify known patterns of local or remote users doing things they should not be doing.

HIDS acts much like anti-virus software (however, they are not a replacement for it) with extended capabilities that greatly increase the level of security that can be provided. HIDS is best suited to combat security threats against hosts because of their capability to monitor and respond to specific user actions and file accesses on the server. The majority of computer threats come from within organizations, from many different sources such as disgruntled employees or corporate spies. HIDSs monitor servers by providing information regarding the following:

• Intrusion attempts or successes and suspicious behavior by authorized users.

• Scans of the host to ensure that they conform to accepted security practices such as having all the latest patches and not having unnecessary services running.

• Audit policy management and centralization, supply of data forensics, statistical analysis and evidentiary support, and, in certain instances, some measure of access control. More robust tools typically provide these functions.

The deployment of HIDS is fairly straightforward; it is an application that resides on a server that watches for file system changes, registry changes, open ports, running applications, and all traffic originating to and from the host on which it resides. Server farms are often placed on their own network and application servers are strong candidates for HIDS.

Where multiple hosts are concerned, HIDS should be configured to report to a centralized management console to provide event correlation and enterprise-wide reporting. Typical candidates for HIDS deployments are web servers, file servers, or any application server that provides network communication resources to the public Internet.

How Are Intrusions Detected?

Every IDS vendor (of which there are several) has buzzwords of every type to inflict FUD on the explanation of how an IDS performs its job. This seems counter productive because each vendor wants to sell, but alas, the world is a fickle place and security is full of snake oil! This section takes a high-level look at the methods any good IDS should use.

An IDS has a special implementation of TCP/IP that allows it to gather the packets and then reassemble them for analysis. It is not enough to simply sniff the packets; an IDS must examine them. They do this in several ways, as discussed in the following sections.

Communication Stream Reassembly

An IDS has the capability to reconstruct a stream of packets into the communication session and thus analyze what is actually happening. This process is crucial because it allows the IDS to piece together events and provide proper event correlation back to the management station. This becomes even more critical since studies have found that a core cause of network worms are when field employees take laptops to client networks, get them infected, and then bring them back to the corporate network. Even worse is when employees establish a VPN tunnel into the company and, at times, bypass the security checks for worms. The main reason is that the employee “carries” his PC past the firewall into his office, plugs it in, and logs into the corporate network with an infected PC. Ouch! It is a good idea to have HIDS on laptops to prevent this from happening.

Protocol Analysis

Attacks use methods of altering the underlying protocol information to be successful. For example, the Ping of Death is successful because it alters the packet size and, through protocol verification, this would be detected. An IDS has a verification system that can flag invalid packets; this can include valid packets that are severely fragment, which again proves that communication stream reassembly is important.

An important aspect of protocol verification is that of application verification, where the IDS detects inappropriate application, protocol behavior. For example, the WinNuke attack uses NetBIOS (a valid protocol) but adds out-of-band information, which is valid but is only used to attack a host.

Anomaly Detection

Anomaly detection is similar to the training of SPAM filters because a period of learning by an IDS allows it to determine normal baseline levels of activity. Of course, normal is different for every network. The thought behind this approach is to measure a baseline of statistics such as file activity, user logins, CPU utilization, disk activity, and so on. After the baseline is established, IDS is used to detect statistical anomalies.

For example, assume that you are monitoring activity and your IDS begins to note that, early every morning, many of the hosts on your network become very active. You might not immediately know what is going on, but you are alerted that you should investigate.

Signature/Pattern Matching

Signature/pattern matching is the most common method of detecting attacks, and it means that the IDS must be able to recognize every attack technique to be effective. An IDS has large databases with thousands of signatures that allow for the IDS to match attack signatures or patterns.

For example, many IDSs are used to monitor abuse, such as a user visiting pornography or gambling websites while at work. Detecting that kind of misuse is based on keyword; however, consider a different scenario in which someone is using ICMP to scan and map out your network. Packets contain certain signatures that can be matched, as demonstrated in Figure 9-3.

Figure 9-3. Enterasys IDS Detection Screen

This type of attack detection takes place at a more granular level than protocol analysis or anomaly detection. As a result, specific events are identified that, for example, indicate that a compromise has occurred. One of the most frequently matched patterns is when an attacker ensures that he has achieved root permissions on a host. The host replies that root access was achieved in a packet that will be sent to the attacker and that can be analyzed for the word root. This is a greatly simplified example, but it demonstrates what an IDS looks for (that is, matches).

Log Analysis

IDSs have the capability to receive log messages from multiple devices and audit these logs for related security events. For example, an NIDS can simply log all the application layer protocols that are used on a machine. Downstream event log systems (WinNT Event, UNIX Syslog, SNMP TRAPS, and so on) can then correlate these extended events with other events on the network. Log analysis not only means having the capability to correlate Syslogs and other events, but also to have a mechanism in place to record packets that have triggered the IDS to raise the alarm. Some of these additional useful mechanism functions are as follows:

• Capture offending packets—The IDS sensor captures the packet that caused the event/alarm to be triggered. This provides the contents of the packet for analysis. An IDS can be configured to collect additional packets and even the entire session. This is critical in understanding why a signature tripped and identified the true from the false positive.

• Session reconstruction—Often, an IDS alarms on a packet, perhaps a single packet, but that packet is only the event that triggered the alarm. The capability of reconstructing the entire communication session is critical in detecting the entire attack and helps eliminate false positives because you have a better picture of what has occurred.

Logs are important because they provide the means to which the alarm is raised when an event happens. The next step is to combine these methods to increase your network’s security.

Combining Methods

Attackers continually modify and improve their abilities, thereby making them increasingly difficult to detect. To combat this, IDS continues to evolve, becoming smarter and better at detection by combining the methods they use to detect intrusions.

For example, an IDS might have the capability to combine the methods of signature-based pattern matching, protocol analysis, and anomaly detection. This ability to use multi-method attack detection is another example of the ever-evolving way in which IDSs continue to grow.

Intrusion Prevention

Intrusion Prevention Systems (IPSs) prevent an attack from being successful at the earliest possible moment. IPS works with an IDS, and vendors have combined the two technologies to make an IPS-capable IDS. Two techniques are used to prevent an attack:

• Sniping—Allows the IDS to terminate a suspected attack through the use of a TCP Reset packet or ICMP unreachable message.

• Shunning—Allows the IDS to automatically configure your pre-screening router or firewall to deny traffic based on what it has detected and therefore shunning the connection. As IDS becomes more advanced, this shunning is evolving into a new term, blocking, where an IDS contacts a router or firewall and creates an access control list (ACL) to block the attacking IP address.

IPS Responses and Actions

As discussed so far, an IDS can take several actions to prevent detected intrusions. The most proactive ways include sniping and shunning. The IDS can handle sniping; however, shunning requires the assistance of other devices. However, IDS sensors should report back to a central console that, in turn, also generates some responses if so configured. Following are some actions that an IDS can generate in response to an attack:

• Reconfigure firewall/router—An IDS with a shun enabled can configure the firewall to filter out the intruder’s IP address. However, the intruder can still attack from other addresses. Checkpoint firewalls support a Suspicious Activity Monitoring Protocol (SAMP) for configuring firewalls. Checkpoint has its OPSEC standard for reconfiguring firewalls to block the offending IP address.

• Send an SNMP trap—Configure the IDS to send an SNMP trap datagram to a management console like HP OpenView, Tivoli, Cabletron Spectrum, and so on.

• Generate log—An IDS can log to Windows event log, Syslog server, pager, or even send an e-mail.

Remember my caution, however; only allow the IDS to proactively change your other network devices after an extended period of manual monitoring and extensive tuning. IDS is a developing field, and IPS is even younger (only a couple of years).

IDS Products

Many IDS systems exist, and a lot of confusion surrounds them because there is little in the way of standards with regards to how they operate. It is difficult to provide a direct comparison between products because terminology, meanings, features, and functionality have not matured to a level at which an effective comparison can occur. However, many products are based on the work done by the open source community efforts in the IDS arena. The foremost of these products is Snort.

Snort!

Snort! Snort! Snort!

Don’t worry—the snorting that you are hearing is not coming from some sort of weird beast; it is coming from an open source IDS developed by the folks over at http://www.Snort.Org. Here is a description of “Snort,” quoted on the website:

Snort is an open source network Intrusion Detection System, capable of performing real-time traffic analysis and packet logging on IP networks. It can perform protocol analysis, content searching/matching, and can be used to detect a variety of attacks and probes, such as buffer overflows, stealth port scans, CGI attacks, SMB probes, OS fingerprinting attempts, and much more.

Snort uses a flexible rules language to describe traffic that it should collect or pass, as well as a detection engine that utilizes a modular plugin architecture. Snort has a real-time alerting capability as well, incorporating alerting mechanisms for syslog, a user specified file, a UNIX socket, or WinPopup messages to Windows clients using Samba’s smbclient.

Snort has three primary uses. It can be used as a straight packet sniffer like tcpdump(1), a packet logger (useful for network traffic debugging, etc.), or as a full blown network Intrusion Detection System.

Before you get too excited by the graphical interface you see in Figure 9-4, that is not part of the Snort IDS software package; it is a GUI interface developed by a group of people at Engage Security (http://www.engagesecurity.com).

Figure 9-4. IDS Center Main Snort Configuration Screen

The Snort application itself is a command-line application that is extremely well written, albeit sometimes difficult to configure and monitor. As shown in Figure 9-4, the IDScenter GUI front-end allows users to have a graphical configuration and monitoring interface.

Figure 9-5 gives you an idea of the basic configuration options that can be set for Snort operation. This screen in IDS Center is crucial for beginning the inevitable tweaking that must occur.

Figure 9-5. IDS Center Snort Rule Configuration Page

Figure 9-6 shows the method users have for selecting the intrusion or attack profiles that Snort will be required to look for and how to notify customers. In addition, Figure 9-6 shows the alerting options that can be set when situations that require administrative attention occur.

Figure 9-6. IDS Center Notification

You might already know about Snort if you are familiar with Linux or other *nix operating systems, but what you might not know is that the IDS Center software is Win32-based, as is the version of Snort that it manages.

Created by people who really want Snort to work under Windows, a handful of Win32 Snort installation packages are available on the Internet. The majority of these packages work well, but a few of them need additional development cycles. Also keep in mind that, after you configure and deploy a Snort machine, you will not be able to use it for anything else after you engage the monitoring functions.

Limitations of IDS

Still an evolving technology, IDS has some manageable limitations given its overriding benefits. An IDS should always be deployed in addition to pre-screening routers and firewalls. Primary systems such as firewalls, encryption, and authentication are rock solid. Bugs or misconfiguration often lead to problems in these devices, but the underlying concepts are proven and accurate. Regardless, some of the limitations are as follows:

• HIDS versus NIDS debate—This should never be a debate; both are needed and should work together in a unified approach to increase your network’s security as they play different roles.

• Attack patterns—IDS products are not always updated with the latest attack signatures.

• False positives—Normal traffic can cause false positives.

• Resource limitations—NIDSs sit at centralized locations on the network. They must be able to keep up with, analyze, and store information generated by potentially thousands of machines. NIDS must emulate the combined entity of all the machines sending traffic through its segment. Obviously, it cannot do this thoroughly, and it must take short cuts.

• Long term state—A classic problem is “slow scans,” in which the attacker scans the system very slowly. The IDS cannot store that much information over that long of a time period, so is cannot match the data together.

• Sensor blindness—IDSs are built on regular computers that do not have any special capabilities; thus, it is possible to saturate the link to which they are connected and blind them, thereby causing them to drop packets they should have been recording. For example, the open source port-scanning tool nmap includes a feature known as decoy scans, which causes nmap to send hundreds of scans using spoofed IP addresses. It therefore becomes an improbable task for the administrator to discover which of the IP addresses was real and which was one of the decoy addresses. These two scenarios retain forensics data, however. If the attacker is suspected, the data is still there to find. Another attack is to fill up event storage.

• Storage limitations—When an attacker is trying to blind the IDS sensor, she might have the dual purpose of filling up the sensor database or hard drive. This causes the sensor to delete events or stop recording events.

• Denial of service—An IDS is extremely complicated because it has an entire TCP/IP implementation running. As a result, IDS can be susceptible to attacks. Attackers can often download the same IDS their targets use free of charge, and then experiment to find packets that will disable the IDS. During the attack, the intruder then disables the IDS and continues the attack undetected.

• Fragmentation—The act of breaking up large packets into multiple smaller packets. The receiving TCP/IP stack then reassembles the packets and their data. Most IDSs do not have the ability to reassemble IP packets. Simple tools exist that can automatically fragment attacks to evade IDS.

• Pattern evasion/change—Many simple NIDSs rely on “pattern matching.” Attack scripts have well-known patterns, so simply compiling a database of the known attack scripts provides pretty good detection; however, it can easily be evaded by simply changing the attack script and thus rendering the IDS pattern match useless.

• IDS “evaluation” tools—A variety of tools are freely available to test the accuracy and usefulness of an IDS. The two most commonly used are “snot” and “Stick.” These tools create thousands of attacks to see whether the IDS will sense them. An attacker can use these tools to hide their attacks or to potentially blind the IDS.

These limitations do not mean that the uses of IDS are invalid or somehow lessened. Hacking is so pervasive and attack tools so readily available that it is astounding what an IDS will detect. Properly maintained and managed, IDS dramatically improves the security of any network. However, one of the key fundamental points of properly using an IDS has been saved for the end of this section.

A security policy is crucial to the successful use of an IDS. You might ask, “But why do I need another policy and process to follow? They are such a burden!” It cannot be emphasized enough that the assets your security measures are designed to protect have value, and not ensuring that everyone involved in protecting them follows the same standards would be a grave mistake. One cowboy can ruin it for everyone.

Essentials First: Honeypots

You are probably wondering what is Winnie the Pooh and his predilection with honey doing in a book about network security.

Until this point, this book has not discussed taking the fight to the attackers, and that is what this section does by covering Honeypots. A Honeypot is a highly flexible computer system on the Internet that is customized to be a security tool and is expressly set up to attract and “trap” people who attempt to penetrate other people’s computer systems through probes, scans, and intrusions. This target audience includes the hacker, cracker, and script kiddie, regardless of their location in the world.

Honeypots do not fix a single security problem—how bizarre is that? Instead, they are used for misdirection, prevention, detection, and information gathering by being closely monitored and designed to look like something they are not for the attackers to hack into. Conceptually, this means that a Honeypot should not be used for production because its value lies in being probed, attacked, or compromised. When I first heard of a Honeypot, I was confused as to why in the world would you want such a device on your network? It seems to me that having a computer designed to let attackers hack into would not serve much of a purpose. Honeypots, in fact, serve several crucial purposes:

• Honeypots distract attackers from more valuable resources on your network, thus allowing the protection of your resources by distracting attackers to devices that they presume are real.

• Honeypots provide early warning about new attacks and intrusion attempts. IDS can generate false positives, whereas those who are likely to intend harm access only a Honeypot because it is nonproduction.

• Honeypots allow for in-depth examination of an attacker’s activities during and after the exploitation of a Honeypot. This might seem like something only someone involved in research might do, but think about what you can learn. You can use this education to ensure that the real security resources on your network are configured/patched correctly.

• Perhaps the most interesting benefit of Honeypots is CYA, or cover your assets. Honeypots have the unique ability to show that your network security design is effective.

• To know your enemy is another reason why Honeypots exist. It is not enough to know that attackers are out there; everyone knows this—just turn on the evening news. What is important, however, is determining their techniques and methods. After you have an attacker profile, you can defend against further exploits.

Clearly the problem of false positives discussed in the IDS section is not a real issue with Honeypots. Specifically, if an attack happens to a Honeypot that is just a passive device, you will know it. This really means that detection of attacks is really no longer much of an issue, is it? In the real world, you often see Honeypots deployed on a Demilitarized Zone (DMZ); however, the Honeypot is not listed in DNS, WINS, or registered, nor is it linked to a production machine in any way. If the Honeypot begins to get scanned from hosts within the DMZ, that tells you something. What if the Honeypot is inside the network and it gets attacked? These placements of Honeypots are passive in that they are waiting for someone to attack them.

This chapter covers Honeypots to demonstrate that, just as an active device such as IDS has a role in securing your network, so does a passive device such as Honeypot, which does not have the same limitations as an IDS.

The design and intent of Honeypots fall into two categories:

• Research Honeypots—Complex to deploy and maintain and primarily used by research, military, or government organizations.

• Production Honeypots—Used by organizations that are concerned with the security of their networks; we focus on these. A production Honeypot is typically deployed with a certain goal or intent in mind.

In addition to these two broad categories of Honeypots, Honeypots can also be classified by their function, as follows:

• Port monitors—A rather straightforward type of device, these Honeypots listen on ports that are targeted by attackers. By design, they respond to port scans, thus letting the attacker attempt to connect. These types of Honeypots log on connection attempts on a port.

• Deception systems—Take the next step from just monitoring a port and deceive attackers by interacting with them as a real system would. This means that, instead of just replying on TCP port 110 like an e-mail server configured for POP3, a deceptive Honeypot responds as if it were a real mail server. Deception systems do not implement every aspect of a mail server; rather, they implement just enough to make it sweet as honey to an attacker.

• Multi-deception systems—Increasing yet another level are the more advanced Honeypots that not only allow for multiple services that can be emulated, but can also simulate different operating systems. One of the most commonly used tools for this purpose is Specter, which can be found at http://www.specter.com/.

Honeypot Design Strategies

Perhaps the clearest and most present danger is that when your Honeypot is working correctly, it detects attackers coming after your network and its resources. In practice, this means that you already have a criminal in some part of your network. As a result, a few items must be taken to ensure the security of the network.

Use a firewall! Yes, a firewall—even though the Honeypot is designed to let attackers in, still use a firewall to ensure that they do not get too suspicious. Create a rule set that allows basic Internet functionality out from the Honeypot back to the Internet. Experts recommend that you should allow all inbound traffic to reach the Honeypot, but only allow FTP, ICMP, and DNS outbound.

The way you are going to see an attacker’s activities is through various logs and through the actual Honeypot logs. Failure to ensure that these are working will make your life = difficult and basically nullify your entire motivation for setting up a Honeypot.

Honeypot Limitations

Although a Honeypot has many benefits, it also has the following limitations:

• If the system does indeed get hacked, it can be used as a stepping-stone to further compromise the network.

• Honeypots add complexity. In security, complexity is bad because it leads to increased exposure to exploits.

• Honeypots must be maintained, just like any other networking equipment/ services.

Chapter Summary

This chapter introduces two of the newest available security-related technologies—Intrusion Detection and Intrusion Prevention. This chapter began by exploring the two fundamental types of IDS: host-based that run on servers, and network-based IDS that run on a network. This chapter also covered the basic operation of an IDS and concluded by covering Honeypots.

Chapter Review Questions

1. When and who were the first to develop a commercial IDS?

2. What are the two types of IDS, and should they be deployed together or separately?

3. Define and discuss NIDSs. How and where are they effective in a network?

4. Define and discuss HIDSs. How and where are they effective in a network?

5. When is anomaly detection the most effective and why?

6. Which Intrusion Detection methodology also verifies application behavior?

7. List and define each of the two techniques an IDS can employ to prevent an attack.

8. List the three most important IDS limitations, in your opinion, and explain why you choose them.

9. Honeypots distract attackers from more valuable resources. True or false?