In this chapter, we discussed the basics behind how VPNs work and the process of tunneling. We discussed the advantages of VPNs, including security, deployment, and cost benefits. We also
We also covered the popular VPN protocols IPSec, L2TP, and PPTP. IPSec is a suite of security protocols that includes IKE, AH, and ESP. IKE is used in two phases to negotiate and authenticate VPN
Finally, we covered L2TP and PPTP and saw the advantages of a Layer 2based tunneling protocol, including the transmission of non-IP protocols, and its ability to pass NAT without issue. The downside is that because both protocols were built on PPP, they have communication session vulnerabilities that aren't found with IPSec.
Regardless of your choice of VPN hardware or tunneling protocol, the concepts of VPNs are universal. Correctly identifying and weighing the disadvantages and advantages for your particular environment is a necessary part of designing remote communications. After a VPN is decided upon as the choice communication for your situation, a full understanding of the principles of cryptography and their incorporation into the VPN will help facilitate a smooth implementation.
Understanding VPNs, IPSec, cryptography, and other tunneling protocols will be advantageous to
1 Microsoft, Inc. "How to Configure an L2TP/IPSec Connection Using Pre-shared Key Authentication (Q240262)." http://support.microsoft.com/default.aspx?scid=kb;EN-US;q240262. September 2004.
2 Microsoft, Inc. "Mutual Authentication Methods Supported for L2TP/IPSec (Q248711)." http://support.microsoft.com/default.aspx?scid=kb;EN-US;q248711. September 2004.
3 Bruce Schneier and Mudge .
"Cryptanalysis of Microsoft's PPTP Authentication Extensions (MS-CHAPv2)."
August 1999. http://www.
4 Kory Hamzeh, Gurdeep Singh Pall , et al. "RFC 2637 Point-to-Point Tunneling Protocol." July 1999. http://www.ietf.org/rfc/rfc2637.txt. September 2004.
5 W. Townsley, A. Valencia , et al. "RFC 2661Layer Two Tunneling Protocol 'L2TP'." August 1999. http://www.ietf.org/rfc/rfc2661.txt. September 2004.
Chapter 8. Network Intrusion Detection
A good network intrusion detection system (IDS) can have an
Network Intrusion Detection Basics
Network intrusion detection systems are designed to sniff network traffic and analyze it to identify threats in the forms of reconnaissance activities and attacks. By detecting malicious activity, network intrusion detection enables you to identify and
Although the focus of this chapter is network IDS, there is also a
The Need for Intrusion Detection
Many people have
Many attacks involve multiple steps or phases. For example, an attacker might start by launching a scan that sends a DNS query containing a version.bind request to each IP address in a range. Some DNS servers respond to such a query with their BIND version number. The goal of this scan is to identify which hosts are DNS servers and what versions of BIND they are using. Based on the results of the first scan, the attacker then sends a specially crafted DNS query to some of the DNS servers to exploit a buffer overflow vulnerability in a particular version of BIND. This second set of queries could occur hours or days after the first setor it could occur within seconds. It depends on the tools being used and the attacker's methodology.
If any of the buffer overflow exploits are successful, the attacker might be able to perform unauthorized actions on one or more of the servers,
If you are not using intrusion detection, how will you know when a successful attack has occurred? Some attacks are immediately visible, such as a website defacement; others are not. Perhaps you will look through a directory and see some
A properly configured, robust IDS can play more than one role in identifying typical attacks. An IDS can detect reconnaissance activity that may indicate future targets of particular interest. It also generates alerts for the
Although there are various ways to detect anomalies in network traffic, many IDS products based on anomaly detection methodologies work by establishing baselines of normal network activity over a period of time, then detecting significant deviations from the baseline. For example, a product could monitor a network for two weeks to identify which network services are provided by each host, which hosts use each service, and what volume of activity occurs during different times of the day and days of the week. A month later, if the IDS sensor sees a high volume of traffic involving a previously unused service on a host, this could indicate a distributed denial of service (DDoS) attack against the host or a compromised host providing a new service. This class of product is sometimes known as a DDoS attack mitigation system , because it not only detects the DDoS attacks, but also acts to stop them through intrusion prevention techniques (as described in Chapter 11). Examples of DDoS attack mitigation systems include Captus IPS, Mazu Enforcer, and Top Layer Attack Mitigator.
One obvious drawback of this type of anomaly detection is that the baseline needs to be updated constantly to reflect authorized changes to the environment, such as the deployment of a new server or the addition of another service to an existing server. Some products permit the baseline to be updated manually, at least in terms of identifying which hosts are authorized to provide and use certain services. If the baseline can be kept current, or if the environment is quite static and the baseline changes rarely, anomaly detection can be extremely effective at identifying certain types of attacks and reconnaissance activities, such as port and host
Many signature-based IDS products perform some type of protocol anomaly detection. This means that the IDS
One significant limitation of anomaly-based IDS is that
A network IDS signature is a pattern you are looking for in traffic. When a signature for an attack matches observed traffic, an alert is generated, or the event is
Although some network traffic signatures, such as ones for the Land attack, are quite simple, others are considerably more complicated. Many signatures are protocol or application specific; for example, many signatures pertain only to DNS traffic. Because DNS zone transfers traditionally use TCP port 53, a signature pertaining to a zone transfer vulnerability includes the TCP protocol and also needs to look for destination port 53. Each signature specifies other characteristics that help to identify the vulnerability that the attacker is trying to exploit. Some IDSs focus on long sequences of code from published exploits, whereas other IDSs actually perform full protocol analysis, examining and validating the header and payload values of each packet. Although full analysis is more resource
Most intrusion detection vendors release new sets of signatures regularly. If a major new vulnerability is discovered or an exploit is widely seen, intrusion detection vendors quickly research the exploit or vulnerability, create new signatures for it (or determine that existing signatures already match it), and release the signatures to their users as soon as possible. This process is similar to the process that antivirus software vendors follow when addressing threats from new viruses, worms, Trojans, and other types of malicious code. When a major new threat emerges suddenly, such as the Slammer and Netsky worm, IDS
How Signatures Work
Let's look at an example of a signature for the Nimda worm. Because the worm uses a common text-based protocol (HTTP) and uses a relatively simple exploitation technique, it's an ideal subject for understanding the basics of signatures. When the Nimda worm
The purpose of this particular request is to exploit a Unicode-related vulnerability in certain unpatched Microsoft IIS servers to gain unauthorized privileges.
is the Unicode equivalent of a slash, so this command is actually trying to traverse the root directory to exploit the vulnerability. Although no damage is done to the server, success at this point
You want your network intrusion detection sensors to notify you when they see this traffic. Many different possible signatures exist. A simple text-matching signature would look for /scripts/..%c0%af../ in a URL (more precisely, in the payload of a TCP packet that a client sends to a server's port 80). Because the Nimda worm issues several GET requests with slightly different values, you would need a separate signature for each one of them if you wanted to identify each attack attempt.
Some IDS sensors have a much more robust way of identifying these types of requests as attacks. Rather than doing simple text matching, they actually decode the request, substituting a slash for the %c0%af sequence, and then analyze the validity of the decoded URL. As a result of the analysis, the IDS sensor determines that the attacker is trying to go past the root directory, and it generates an alert. Although this method is more resource intensive, it provides a much better detection capability than the simple text-matching method because it actually examines traffic for the attack technique, not for specific known instances of that technique being used.
False Positives and False
The Intrusion Detection System Is Possessed!
I will never forget the first time I had to review and analyze intrusion detection alerts. I opened the IDS console to review the data, and my mouth dropped as I saw hundreds of alerts that all said "Devil." I scrolled through screen after screen of Devil alerts, and I started to
A false negative occurs when a signature fails to generate an alert when its associated attack occurs. People tend to focus on false positives much more than false negatives, but each false negative is a legitimate attack or incident that IDS failed to notice. False negatives get less attention because you usually have no way of knowing that they have occurred. Sadly, you're most likely to identify a false negative when an attack is successful and wasn't noticed by the IDS, or when a different type of network IDS sensor or host-based IDS product notices it. In addition, if a signature generates many false positives, the analyst usually shuts off the signature altogether or ignores all the corresponding alerts. This means that the analyst doesn't review
To better understand false positives and negatives, let's look at a simple example. Suppose that in your intrusion detection system, you write a signature that looks for
Because of the false positives, you decide to rewrite your signature to use some contextual information as well. Now your signature is a URL that contains /winnt/system32/cmd.exe . Because this is a more specific signature, it triggers fewer false positives than the more general signature.
Unfortunately, reducing false positives often comes at the expense of increasing false negatives. If an attacker uses a URL that includes
, the more specific signature misses it,
As if developing an IDS signature that minimizes false positives and false negatives isn't difficult enough, you must also consider the effects of IDS evasion techniques on signature development. Attackers have many methods of altering their code to avoid IDS detection. Many are simple, such as the example discussed previously that
Some evasion techniques actually relate to the IDS sensor's
Besides false positives, you might also have alerts that address legitimate problems that you simply don't care about. Unwanted alerts seem to occur in just about every environment. For example, if your environment is an ISP or a wireless company, you are providing network services to customers. You probably have a lot of traffic passing on your networks between your customers and other outside hosts. If you are monitoring these networks with IDS sensors and you tune them to identify all possible scans and attacks, you are likely to be overwhelmed with a huge number of alerts that you honestly don't care about. Do you really want to know if one
Tuning your sensors to produce only the information relevant in your environment is critical if you're going to get the best results from your IDS solution.
When an intrusion detection system sees traffic that matches one of its signatures, it logs the pertinent aspects of the traffic or generates an alert, depending on the severity of the activity and the configuration of the IDS sensor. Alerts can be delivered to intrusion analysts in a variety of ways, including messages on the analyst console, emails, and SNMP traps, depending on the product being used.
Reporting is another key element of intrusion detection. If you have only one sensor, reporting should be simple. If you have dozens of sensors, you probably don't want separate
Review IDS Sensor Status Regularly
I was helping an intrusion analyst tune the dozens of network IDS sensors deployed in his environment. He told me he had noticed recently that the number of alerts he was seeing on his analyst console had dropped significantly. After a few days of this, he noticed that several sensors weren't generating alerts. Puzzled, he finally checked the sensor status reports and discovered that none of them were seeing packets. An investigation revealed that a co-worker had reconfigured the switches to which the sensors were connected.
Check the status of your sensors regularly. Most IDS sensors provide some
Many different network IDSs are available, each with its own distinct features. Some of the best-known and most popular products include Cisco Secure IDS, Enterasys Dragon Network Sensor, ISS RealSecure Network Sensor, NFR Sentivist IDS, Snort, and Sourcefire Intrusion Management System. They all provide alerting, logging, and reporting capabilities. Signature sets are available through a variety of means, depending on the product. Users of some products have written their own signatures and made them
Network IDS sensors have other helpful features. For example, some systems can perform network monitoring and traffic analysis, collecting statistics on connections, protocols in use, and the like. This capability can be invaluable in identifying policy violations, such as unauthorized services in use, and traffic
Some IDS products provide tiered solutions, which typically involve deploying multiple IDS sensors on various network segments. Each sensor transmits its IDS data to a centralized server that stores all the data. The individual sensors or the centralized box, which is able to correlate events from all the sensors' data, can make alert decisions. Many IDS solutions also have separate analyst consoles that connect to the centralized system or the individual sensors; these enable analysts to view recorded data and alerts, as well as reconfigure the sensors and update signatures. Some software vendors, such as ArcSight, e-Security, GuardedNet, Intellitactics, and netForensics, offer console products that can process and correlate data from various brands of IDS sensors, firewalls, and other hosts; Chapter 20, "Network Log Analysis," discusses such products.
Besides intrusion detection products, some intrusion detectionrelated services might be able to assist you with the analysis of your intrusion detection data. Some organizations choose to outsource the analysis of their IDS sensor data to specialized commercial monitoring services. Other organizations elect to do their own analysis, but also submit their data to free distributed IDS services for additional help.
As IDS products have become more popular, the use of free distributed IDS services has also grown significantly. The basic concept is that administrators from organizations all over the world submit logs to a distributed IDS service from their own IDS sensors, firewalls, and other devices. These services analyze the data from all the sites and perform
Using a distributed IDS service has a few benefits. Because the service receives logs from many environments, it has a wealth of data to use for its intrusion analysis. A distributed IDS service finds patterns among all the attacks that individual sites cannot see. Another great feature of some distributed IDS services is that if they conclude that a host at a particular IP address
Many companies, such as Counterpane, ISS, and Symantec, offer managed security services that include IDS monitoring capabilities. This generally entails 24-
At best, outsourced IDS monitoring can identify serious attacks and help your organization respond to them quickly and appropriately. If your organization doesn't have the time or expertise to analyze its own IDS sensor data properly and promptly, outsourcing that work is important for maintaining a strong perimeter defense. At worst, such services add little or nothing to the existing IDS solution, while requiring substantial financial commitments. Because outsourced IDS monitoring is very resource-intensive, it can easily cost millions of dollars a year for larger organizations.