Intrusion Detection Systems Secure your network. 4389KB Mar 29 2010 05:04:06 AM
.
One thing is for certain: intrusion detection systems are extreme resource hogs. Vendors typically recommend that you run the engine on a dedicated system with 128MB of RAM and an Intel
300MHz Pentium II or Pro processor or RISC equivalent if the engine is running on UNIX. Since an IDS logs all traffic, copious amounts of disk space are required for its databases. While about
100MB of disk space is usually recommended, plan on using a whole lot more unless you will frequently purge the database or your network sees very little traffic. The requirements for the
dedicated system running the console are about the same, except you must reserve enough disk space to store a copy of each engine’s database.
IDS Limitations
So far, an IDS sounds like a wonderful security device—but these systems are not perfect and do have their limitations. While you are monitoring network activity in “real time,” remember that any
countermeasures the system will take may end up being too late to do any good. Let’s look at a common denial of service DoS attack to see how this can occur.
Teardrop Attacks
In order to understand how a teardrop attack is used against a system, you must first understand the purpose of the fragmentation offset field and the length field within the IP header. A decode of an IP
header is shown in Figure 8.1. The fragmentation offset field is typically used by routers. If a router receives a packet that is too large for the next segment, the router will need to fragment the data
before passing it along. The fragmentation offset field is used along with the length field so that the receiving system can reassemble the datagram in the correct order. When a fragmentation offset value
of 0 is received, the receiving system assumes either that this is the first packet of fragmented information or that fragmentation has not been used.
FIGURE 8.1 A decode of an IP header
If fragmentation has occurred, the receiving system will use the offset to determine where the data within each packet should be placed when rebuilding the datagram. For an analogy, think of a child’s
set of numbered building blocks. As long as the child follows the numbering plan and puts the blocks together in the right order, he can build a house, a car, or even a plane. In fact, he does not even need
to know what he is trying to build. He simply has to assemble the blocks in the specified order.
The IP fragmentation offset works in much the same manner. The offset tells the receiving system how far away from the front of the datagram the included payload should be placed. If all goes well,
At this point, the system will try to realign the datagrams to see if it can make them fit. If it cannot, the receiving system will send out a request that the data be resent. Most IP stacks are capable of
dealing with overlaps or payloads that are too large for their segment.
Launching a Teardrop Attack
A teardrop attack starts by sending a normal packet of data with a normal-size payload and a fragmentation offset of 0. From the initial packet of data, a teardrop attack is indistinguishable from a
normal data transfer. Subsequent packets, however, have modified fragmentation offset and length fields. This ensuing traffic is responsible for crashing the target system.
When the second packet of data is received, the fragmentation offset is consulted to see where within the datagram this information should be placed. In a teardrop attack, the offset on the second packet
claims that this information should be placed somewhere within the first fragment. When the payload field is checked, the receiving system finds that this data is not even large enough to extend past the
end of the first fragment. In other words, this second fragment does not overlap the first fragment; it is actually fully contained inside of it. Since this was not an error condition that anyone expected,
there is no routine to handle it and this information causes a buffer overflow—crashing the receiving system. For some operating systems, only one malformed packet is required. Others will not crash
unless multiple malformed packets are received.
Previous Table of Contents Next
Copyr ight © Sybex, I nc.
IDS versus Teardrop
How would a typical IDS deal with this attack? When the teardrop attack is launched, the initial packet resembles a normal data transfer. From just looking at this first packet of information, an IDS
has no way of knowing that an attack is about to occur.
When the second packet is transmitted, the IDS would be able to put together the datagram fragments and identify that this is a classic example of a teardrop attack. Your IDS could then alert the
networking staff and take preventive measures to stop the attack.
You only have one tiny little problem: if your attacker was lucky enough to identify an operating system that will crash with only one malformed packet, it is too late to prevent the attack from
occurring. While it is true that your networking staff will have the benefit of knowing that their server has just crashed, they have probably already figured that out from the number of calls from irate users.
So while your intrusion detection system was able to tell you why the server crashed, it was unable to prevent the attack from occurring in the first place. In order to prevent future occurrences, you would
need to patch the system before an attacker strikes again.
Why not simply block the attacking IP address? Your attacker is probably savvy enough to use IP spoofing, making it look like the attack came from somewhere other than his or her real IP address.
Unless your IDS is on the same collision domain as the attacking system, it will be unable to detect that a spoofed address is being used. This means that your attacker could continue to randomly
change the source IP address and launch successful attacks.
Other Known IDS Limitations
In February 1998, Secure Networks, Inc. released a white paper about testing it had performed on a number of intrusion detection systems. This testing discovered a number of vulnerabilities in IDS that
would allow an attacker to launch an attack and go completely undetected. A complete copy of this study can be obtained from
http:www.securenetworks.com While some of the conclusions of the study are a bit melodramatic, the actual testing raises some
valid points. In short, the study focused on two problem areas: IDS detection of manipulated data and direct attacks on the IDS itself. The conclusion of the study was that sniffer-based intrusion detection
would never be capable of reliably detecting attacks.
Data Manipulation
One of the problems was that some of the intrusion detection systems did not verify the checksum field with the IP header refer to Figure 8.1. This would most certainly be done by the receiving
system, and manipulating this field would cause the IDS to record a different payload than the receiving system would process.
The example cited in the study was the PHF CGI attack. An IDS would attempt to detect this attack by looking for the character string phf within the payload portion of all HTTP requests. If this pattern
is detected, the IDS would assume that this attack was taking place. A savvy attacker could attempt to send a series of packets, each with one character that produced the string
phoof
. The attacker could then manipulate the checksum field so that each packet which contained the letter o had an invalid
checksum. The result would be that while the receiving system which would verify the checksum would only process the character string
phf
, the IDS which does not verify the checksum would read this transmission as
phoof
. While this inconsistency in how traffic is processed is certainly a valid concern, it is not
insurmountable. For example ISS RealSecure, one of the packages that exhibited this problem, was fixed by the next product release. Such problems are typical in an infant technology. Firewall vendors
have gone through a similar learning process and continue to make improvements even today. There is no reason to assume that network security will ever become a stagnant field.
Attacks against the IDS
Another issue raised by the Secure Networks study was the vulnerability of the IDS to direct attacks. This is a valid concern, because a direct attack against the IDS may inhibit its ability to detect
intrusions. By shutting down the IDS, an attacker could launch an attack against the network without fear of detection.
IDS versus Firewall
This highlights a major difference between a firewall and an IDS. A firewall acts as a perimeter guard. This means that all traffic must pass through it in order to move from one section of a
network to another. If the firewall is attacked and services are disrupted, it will typically fail open, meaning that it will be unable to pass traffic. While this disrupts all transmissions, it prevents an
attacker from disabling the firewall and using this opportunity to launch an attack on an internal host.
An IDS, on the other hand, does not sit between network segments. It is designed to run unobtrusively within a single collision domain. If the IDS is disabled, it technically fails closed
because traffic flow is not disrupted. An attacker may be able to disable the IDS while still gaining
Again, this problem is not as insurmountable as the Secure Network study would make it seem. There is no legitimate reason to have the intrusion detection system directly addressable by every network
host. The act of sniffing network traffic does not require a valid IP address. The only systems requiring connectivity are
• The engine • The console
• A DNS system if you wish to resolve IP addresses to host names • The firewall or router if you wish to let the IDS modify filtering rules
Segregating IDS communications from the public network can easily be accomplished using a separate private network along with private IP address space. In fact, it can even be done in-band, as
long as routing to this subnet is disabled. While the engine requires an IP protocol stack and thus an IP address on the main network, there is no reason why this address has to be valid. An example of
this configuration is shown in Figure 8.2.
In Figure 8.2, your regular network systems have been assigned address space from the
10.1.1.0
subnet. All systems within this subnet are allowed some level of Internet access, and your firewall has been configured to use
FIGURE 8.2 Managing IDS through a separate subnet
NAT with these addresses. As far as the firewall is concerned, only the
10.1.1.0
network exists internally.
If you look closely at the figure, you will notice that the DNS system has two IP addresses: one for the
10.1.1.0
network and one for the
192.168.1.0
network. This device has been specifically configured not to route any traffic between these two subnets. IP forwarding has been disabled: while it is able to
communicate with systems on both subnets, it is unable to act as a router and forward traffic between them.
Previous Table of Contents Next
Your IDS engine and monitor are using address space from the
192.168.1.0
subnet. While they will be able to communicate with each other and the DNS system, they will not be able to communicate with
any system using a
10.1.1.0
address. This is because there are no devices routing between the two network segments. Your IDS is also unable to send to or receive any data from systems outside the
firewall.
What happens when your IDS engine tries to monitor traffic? As mentioned, the IDS engine will capture all traffic on the network, not just traffic on its own subnet. This means that it is perfectly
capable of recording all traffic on the local network, including communications between systems on the
10.1.1.0
subnet and the Internet. It can then report these findings to the console via the
192.168.1.0
subnet. What happens when either system needs to resolve an IP address to a host name? We did, after all,
mention that the DNS system was incapable of routing information. While this is a true statement, it does not prohibit you from using the DNS system as a proxy in order to resolve address queries.
In Chapter 3, you saw that DNS is simply an application layer service that is responsible for translating host names to IP addresses and vice versa. When your engine sends a DNS query to the
DNS server, it will attempt to respond to the request with information stored locally either through local domain files or via cached entries. If this is not possible, the DNS server will attempt to contact
one of the root name servers.
If the best route to the root name server has been configured to be through the
10.1.1.15
IP address, such as by creating a default route which points to
10.1.1.1
on the firewall, the DNS server will transmit the request using the source IP address
10.1.1.15
. The DNS server is not routing your query; it is acting as a proxy in order to resolve the query for you.
When it receives a reply to the query, the DNS server will then forward the response back to the engine using the best route it knows. This would require the system to transmit using the
192.168.1.1
address. Again, the information is not being routed; it is being proxied by the DNS service. This means that your IDS is fully capable of resolving DNS queries without using the same subnet address
as the rest of the network.
The result is a hidden subnet which is not directly addressable from the Internet. An attacker would need to penetrate the firewall and compromise the DNS server in order to gain connectivity to either
the IDS engine or console. If the IDS cannot be directly addressed, it obviously cannot be attacked.
.
Internal Attacks against the IDS
The IDS engine and console are vulnerable to internal attack, however. If someone on the
10.1.1.0
network discovers the IP address of the IDS, it would be a simple matter of changing or spoofing the local address in order to address these systems directly on the
192.168.1.0
subnet. This is referred to as “security through obscurity”: the systems will only remain secure as long as no one knows
where they are hidden. Still, by making these systems completely inaccessible from the Internet, you have dramatically limited the scope of potential attack origination points and simplified the
process of discovering the attacker.
When internal attacks are a concern, you can go with an IDS that does not require an IP stack. For example, RealSecure supports network monitoring from a system that does not have IP bound to
the monitored network. With no IP address, the system is invulnerable to any form of IP-based attack. Of course, this also means that you will have to make special considerations for the
monitoring console. You will either need to run the IDS console on the same system as the engine or install a second network card in the engine so that it can communicate with the console through
a private subnet.
IDS Countermeasures
Along with logging and alerting, an intrusion detection system has two other active countermeasures at its disposal:
• Session disruption • Filter rule manipulation
These vary with each specific product, but let’s look at the general strengths and weaknesses of each method.
Session Disruption
Session disruption is the easiest kind of countermeasure to implement. While there are some variations on its implementation, in its most basic form session disruption is produced by having the
IDS reset or close each end of an attack session. This may not prevent the attacker from launching further attacks, but it does prevent the attacker from causing any further damage during the current
session.
For example, let’s say that your IDS engine detects a would-be attacker attempting to send the character string
CWD ~root
during an FTP session. If formulated correctly, this exploit would provide
If session disruption is enabled, your IDS engine would first identify and log this potential attack, then spoof ACK-FIN packets to both ends of the session in order to tear down the connection. The
IDS engine would do this, pretending to be the system on the other end of the connection. For example, it would transmit an ACK-FIN to the attacker using the source IP address, port numbers,
and sequence numbers of the FTP server. This would effectively close the communication session, preventing the attacker from accessing the file system. Depending on the IDS engine in use, it may
then attempt to block all communications from the attacking host indefinitely or for a user- configurable period of time.
While session disruption is a powerful feature, it is not without its limitations. For example, the teardrop example given earlier in this chapter showed that the intrusion detection system would be
unable to block the attack. While the IDS has enough time to react to the FTP exploit, it could never react quickly enough to save a system from teardrop if only one malformed IP header will crash the
system.
Previous Table of Contents Next
Copyr ight © Sybex, I nc.
Filter Rule Manipulation
Some IDS engines have the ability to modify the filter rules of a router or firewall in order to prevent continued attacks. This stops the attacking system from transmitting additional traffic to the target
host; the IDS adds a new filter rule to the firewall that blocks all inbound traffic from the suspect IP address. While filter rule manipulation is a powerful novelty, it is not without its limitations. You
should fully understand the implications of this feature before you enable it.
On the positive side, filter rule manipulation can prevent an attack with far less network traffic than session disruption. Once the IDS modifies the filter rules, attack traffic ceases. With session
disruption, the IDS must continually attempt to close every attack session. If you have a persistent attacker, this could add quite a bit of extra traffic to the wire.
On the negative side, filter rule manipulation is not always 100 percent effective. For example, what if the source IP address of the attack is inside the firewall? In this case, modifying the filter rules will
have no effect. Since the attacking traffic never actually passes through the firewall, it is not subject to the filter rules. This means that a filter change will have no effect on the attack.
Also, a savvy attacker may use a spoofed IP address rather than a real one. While the firewall may begin blocking the initial attack, all the attacker has to do is select another spoofed address in order to
circumvent this new rule change. With session disruption, the IDS reacts based on attack signature, not source IP address. This means that session disruption would be able to continually fend off the
attack, while filter rule manipulation would not. The IDS could make successive rule changes, thus attempting to block all spoofed addresses as they are detected. If the attacker quickly varies the
source IP address, however, the IDS would never be able to keep up. Remember that it takes a certain amount of time typically 10–30 seconds for the IDS and the firewall to complete the filter change.
The ability to perform live filter rule changes could be exploited for a DoS attack. If the attacker purposely varies the source IP address in order to trigger multiple filter rule changes, the firewall
may become so busy that it stops passing traffic. Any active sessions during the filter rule change may be terminated, as well
. Clearly, the ability to modify filter rules should be used sparingly and only for attacks that would be
considered extremely detrimental. For example, just about every unpatched IP device or system produced before 1996 is vulnerable to the Ping of death, an exploit that breaks the IP protocol stack
on a target system by sending it an oversized ICMP datagram. If you are running an environment with many older systems that have not been patched, modifying the filter rules to block these attacks
makes a lot of sense. While frequent rule changes could potentially cause a Denial of Service, letting this traffic onto your network most certainly would interrupt all IP communications.
The Ping of death affected networking hardware as well as computer systems. Make sure that all of your IP devices are patched against this form of attack
.
Not all intrusion detection systems are compatible with all firewalls and routers. For example, ISS RealSecure can only modify Check Point Fire-Wall-1. At the time of this writing, it is not compatible
with any other firewall product, although there are plans to add Cisco routers to a future release. So, while session disruption can be used by any IDS which supports this feature, you can only use filter
manipulation if you are using a compatible firewalling system
.
Host-Based IDS
Until now we have focused on intrusion detection systems which run on a dedicated server and monitor all passing network traffic. These devices are used to control traffic within an entire collision
domain. There are, however, host-based IDS products which are designed to protect only a single system.
Host-based IDS functions similarly to a virus scanner. The software runs as a background process on the system you wish to protect as it attempts to detect suspicious activity. Suspicious activity can
include an attempt to pass unknown commands though an HTTP request or even modification to the file system. When suspicious activity is detected, the IDS can then attempt to terminate the attacking
session and send an alert to the system administrator.
Some Drawbacks
Host-based intrusion detection systems have quite a few drawbacks, which make them impractical for many environments. For starters, most can monitor only specific types of systems. For example,
CyberCop Server by Network Associates is only capable of protecting Web servers. If the server is running multiple services such as DNS, file sharing, POP3, and so on, the host-based IDS system
may not be able to detect an intrusion. While most do watch core server functions, such as modifications to a user’s access rights, an attacker may find a way to disable the IDS before
attempting any changes to the system. If the IDS becomes disabled, the attacker is free to wreak havoc on the system.
Another problem is that host-based intrusion detection systems simply run as a background process and do not have access to the core communication functionality of the system. This means that the
IDS is incapable of fending off attacks against the protocol stack itself. For example, it takes 10 or more teardrop packets to crash an unpatched NT server. While this is more than ample time for a
network-based IDS to react and take countermeasures, a host-based IDS would be left helpless because it would never even see this traffic.
Previous Table of Contents Next
Copyr ight © Sybex, I nc.
It can also be argued that there is a logistical flaw in running your intrusion detection software on the system you wish to protect. If an attacker can infiltrate the system, the attacker may compromise the
IDS, as well. This is an extremely bad thing: the attacker has just punched through your last line of security defense.
Only sloppy attackers fail to clean up after themselves by purging logs and suspected processes. This is why many security experts suggest that system administrators forward all log entries to a remote
system. If the system is compromised by an attacker, the logs cannot be altered. This same principle should be extended to your intrusion detection systems, as well
.
When Is Host-Based IDS Effective?
Despite all these drawbacks, host-based intrusion detection systems do have their place. For example, let’s assume you have a Web server you wish to protect which is located on a DMZ network segment.
This DMZ is behind your firewall but in an isolated segment that only contains the Web server. The firewall is configured to only allow in HTTP traffic to the Web server.
In this situation, a host-based IDS product may be sufficient to protect the Web server, because the firewall is providing most of your protection. The firewall should insure that the only traffic allowed
to reach the Web server is HTTP requests. This means that you should not have to worry about any other services being compromised on the Web server.
Your host-based intrusion detection system only has to insure that no suspect file access requests or CGI and Java exploits are included in these HTTP requests and passed along to the Web server
process running on the system. While this is still no small feat, it does limit the scope of the kinds of exploits the IDS will be expected to handle.
Host-based IDS can also be extremely useful in a fully switched environment. The reasoning behind this is shown in Figure 8.3. In this figure, all systems are directly connected to a backbone switch.
This, in effect, gives every system its own collision domain: the switch will isolate all unicast traffic so that only the two systems involved in the communication will see the traffic.
FIGURE 8.3 A network-based IDS is incapable of seeing all traffic in a fully switched environment.
A host-based IDS would be in a much better position to protect the intranet Web server. Since it runs on the system you wish to protect, it is unaffected by the traffic isolation properties of the switch. It
will see all the traffic that the Web server sees, so it can protect the system from HTTP-based attacks.
Most switch vendors allow you to configure one of the switch’s ports as a monitoring port. This allows the switch to send a copy of all passing traffic to any system connected to this port. If you will be using
a network-based IDS in a switched environment, connect it to this monitoring port in order to insure that the IDS can verify all passing traffic
.
IDS Setup
Product selection in the IDS market is not quite as diverse as it is in the firewall market. This is because IDS is still a fairly new technology which is just starting to claim its market share. For the
purpose of discussing how you would set up an IDS, we will look at Internet Security Systems ISS RealSe-cure. RealSecure version 2.x is an excellent IDS which supports Windows NT, Solaris, and
even Linux as IDS engine platforms. The console, however, only runs on Windows NT.
Before You Begin
For this walk-through, we will focus on the Windows NT version of Real-Secure. As mentioned, you can choose to run the monitor and the console on the same system or on separate platforms. The two
factors governing this decision are cost and performance. The RealSecure software costs the same whether you want to use one platform or two. For two platforms, however, you will obviously need
to purchase two-server class systems, as well as two Windows NT server licenses.
If the system will be monitoring a low-bandwidth connection T1 speeds or less, you will probably be better off running a single “killer” machine rather than two lower-quality computers. If you plan to
monitor a network backbone or other high-traffic areas, you may wish to consider purchasing two appropriately outfitted systems. Receiving and processing every packet on the wire takes a lot of
CPU horsepower. RealSecure checks each packet for more than 130 different suspect conditions. Combine this with making log entries and launching countermeasures when required, and you have a
very busy system.
Where to Place Your IDS
In order to decide where to best place your IDS, you must ask yourself, “Which systems do I wish to protect and from which sources?” It’s good to clarify this point up front—you may find you actually
One potential deployment is shown in Figure 8.4. In this configuration, both the DMZ and the internal connection of the firewall are being monitored. This allows you to verify all inbound traffic
from the Internet. It also allows you to reinforce the existing firewall. Both IDS engines are running without IP being bound to the public network segment. IP is only running on a network card which
connects the engines back to the console. This allows your IDS engines to be completely invisible to all systems on the public network segment.
FIGURE 8.4 A potential deployment of two IDS engines
There are a few limitations to this configuration, however. First, you will be unable to monitor attack traffic from the Internet which is targeted at the firewall. While your firewall should be capable of
logging such activity, you may not have the benefits of raw packet captures, dynamic filter rule manipulation, or any of the other features that an IDS can offer. If your link to the Internet is a T1 or
less, and you want to monitor Internet traffic only, you may be better off buying one really good server and running all IDS functions outside the firewall. Since IP will not be needed on this system,
it should be safe from attack.
Another limitation of the design in Figure 8.4 is that it does not allow you to monitor any of the unicast traffic generated between internal systems. If your goal is to monitor all network traffic, you
may wish to move your internal IDS engine to its own port on the switch and configure this switch port for monitoring. This would allow you to see all traffic activity inside the firewall.
Previous Table of Contents Next
Copyr ight © Sybex, I nc.
If your goal is to lock down the network as much as possible, you may wish to combine these solutions: placing one IDS engine outside the firewall and another IDS engine off a monitoring
switch port, and having both engines communicate with the console through a private subnet. This would allow you to monitor all passing traffic within your network while still maintaining control
from a central console.
Once you have selected the areas you wish to monitor, you can select the number of IDS engines required, as well as the appropriate hardware.
Hardware Requirements
ISS suggests the following minimum hardware requirements for the Real-Secure engine:
• Pentium II 300MHz processor • 128MB of RAM
• 110MB of disk storage • At least one PCI network card
The disk storage requirements are probably a bit light. If you will be monitoring a high-traffic area or if you think that you may wish to capture a lot of raw data, plan to expand the amount of disk space
accordingly.
ISS suggests the following minimum hardware requirements for the RealSecure console:
• Pentium II 200MHz processor • 128MB of RAM
• 100MB of disk storage per engine • One PCI network card
Again, be generous with disk space. It is better to have too much than not enough. The more disk space available, the longer you will be able to retain your logs. This is important if you want to look at any
long-term trends. If you will be running the engine and the console on the same system, consider increasing the processor requirements to a 400MHz Pentium II and the memory requirements to
192MB
.
Installing NT
RealSecure should be run on a Windows NT server which has been dedicated to IDS functions. When installing NT server, observe the following guidelines:
• Install all required network cards before loading NT. • Create an NTFS
C
partition of 800MB which will hold the NT operating system and swap file.
• Create an NTFS
D
partition of the remaining drive space 200MB minimum to hold the IDS program files and logs.
• Remove all protocols except TCPIP. • In the Control Panel, open the Services dialog box and disable all services except the Event
Log service and the Net Logon service. • Install the 128-bit version of Service Pack 3. The 128-bit version is required if you wish to
use strong encryption between the IDS console and engines. • At a minimum, install the hotfixes
getadmin-fix, ndis-fix, pent-fix, srvr-fix
, and
teardrop2-fix
. Other hotfixes, such as
scsi-fix
, can be installed as you require.
• Under the Performance tab in System Properties, change the Boost to the foreground application to None.
• If you are running the server service, go to the Server Properties dialog box and change Optimization to Maximize throughput for network applications.
Once you have followed these guidelines, you are ready to make an emergency recovery disk and install RealSecure.
RealSecure Installation
Installing RealSecure is straightforward. The program files are a 12MB self-extracting executable. You can download a demo if you contact ISS via e-mail. The demo is simply a copy of the full
product that will expire in 30 days. For more information, visit the ISS Web site at
http:www.iss.net The self-extracting executable will start by copying some files to a temporary directory and launching
the Setup program. If you do not have Service Pack 3 installed, the Setup program will warn you that it is required and terminate execution.
As shown in Figure 8.5, you are first asked to select which portions of the program you wish to install. You can choose to install just the engine, just the console, or both portions on the same
system. The final two options, load or export a public key, are useful after the IDS software has been installed. These options are provided so that you can manage the encryption keys used by the console
and the engine when they are located on different systems. RealSecure uses a publicprivate key pair for all communications between the console and the engine. Once you have made your selection,
click Next.
If you have chosen to install both the engine and the console on the same machine, the information box in Figure 8.6 will appear. This is simply a warning that the system may experience performance
problems if it is used in a high-traffic area. We have discussed these concerns at length earlier in this chapter. Simply click OK to go on to the next screen.
FIGURE 8.5 The Select Components screen of the RealSecure installation
FIGURE 8.6 An information box warning that you may experience performance problems with your
configuration
If you find that a single machine is not up to the task of providing all IDS functionality, you can always split the functions across two machines later
.
You will then be prompted to choose the destination for the RealSecure files. The default is to place them under the Program Files directory on the
C
drive. It is strongly recommended that you change this path to
D
so that all RealSecure files are stored on their own partition. This will help to insure that system functionality is not affected if the log files grow large enough to fill the entire drive. Once
you have specified a new path, click Next to continue.
Once you have selected a location for your files, you will be presented with a dialog box which asks you to specify whether to use a weak or strong encryption channel between the IDS engine and the
console. If you will be installing both pieces on the same machine, this prompt is a moot issue.
Strong versus Weak Authentication
With weak authentication, an engine accepts a connection from a console if the console presents the right public key during connection setup. This is a sufficient level of authentication if the
system will be communicating over a private subnet, such as the one shown in Figure 8.4. If, however, the console and engine will be communicating over a public subnet, especially through a
firewall, then strong authentication should be used.
With strong authentication, an engine challenges the identity of a console during connection setup. The console is forced to exchange handshake information with an engine based on the console’s
public key, its private key, and a shared secret. While this causes a larger degradation in performance than weak authentication does, it helps to insure that an attacker does not impersonate
the console in an effort to shut down the IDS engine.
Previous Table of Contents Next
Copyr ight © Sybex, I nc.
FIGURE 8.7 The Cryptographic Provider screen
You should use the 128-bit version of Service Pack 3 if you wish to use strong encryption. If you have installed the 40-bit version of Service Pack 3 the version on Microsoft’s FTP site, you will
only be able to use weak encryption. If you select strong encryption with only the 40-bit version of Service Pack 3 installed, the installation utility will warn you that only weak encryption can be used.
Weak encryption is usually sufficient for use behind a firewall. If you will be communicating on a public network, however, you should seriously consider using strong encryption. As with strong
authentication, there is a slight performance degradation when you use strong instead of weak encryption. It is far more secure, however.
At this point, the installation utility will prompt you to name the program group and begin installing files to the system. Once this process is complete, you will be presented with the dialog box in Figure
8.8. This prompt asks if you wish to check the permission levels set on the Registry keys and directories used by RealSecure in order to insure that they can only be accessed by the system
administrator or an equivalent account.
FIGURE 8.8 RealSecure can set appropriate permission in order to prop-erly restrict access.
You can only set directory permissions on an NT server if you have partitioned your drives to use NTFS
.
Now the installation is complete. You will be prompted to reboot the server so that Registry changes can take effect and the IDS engine service can start. The engine starts automatically during system
initialization, but the console must be launched from the RealSecure program group. Once the system restarts, copy your
ISS.KEY
file to the RealSecure program directory.
Configuring RealSecure
To launch the RealSecure console, select the RealSecure icon from within the RealSecure program group. This will produce the screen shown in Figure 8.9. The top of your screen is the RealSecure
FIGURE 8.9 The RealSecure Console screen
In order to see all the information screens, you should use a screen resolution of 800 × 600 or higher
.
Selecting Monitor Engine will produce the Add Engine dialog box. Use this box to select all the engines you wish to monitor. If you have installed the console and the engine on the same computer,
you should see an entry for the localhost engine. If the engine is on a remote computer, you will need to click Add and fill in the IP address of the IDS engine. Do this for each engine on your network.
Then highlight each engine you want and click OK to begin monitoring them.
When the engine appears on the Engine View, you can right-click a particular engine entry to produce a Maintenance menu. From this menu, select the Properties option in order to configure the
specific characteristics of this engine. This will produce the Engine Properties screen shown in Figure 8.10.
FIGURE 8.10 The Policies tab of the Engine Properties screen
The Policies tab of the Engine Properties screen allows you to customize the type of security policy your IDS will use. You can select the For Windows Networks policy in order to look for
vulnerabilities that are specific to a Windows environment, or you can select Maximum Coverage in order to check for everything.
Remember—the more verification the IDS engine must perform, the more horsepower it is going to require. The different policies are designed to help you check for only the specific vulnerabilities you
need to worry about
.
FIGURE 8.11 The Security Events tab of the Edit Policy screen allows you to customize your IDS
policy settings. The Security Events tab allows you to configure which attacks your IDS should look for and what
type of action should be taken if a particular exploit is detected. The IDS engine will look for every item that is checked off in the Enable column. If you know for sure that you are immune to a
particular type of exploit, you can conserve resources by not inspecting for it. For example, if none of your hosts is running Finger as a service, there should be no need to check for any of the Finger
exploits.
If you are ever unsure whether you need to worry about a particular exploit, online Help has an excellent description of each exploit listed. If you are still unsure whether you need to worry about a
particular exploit, it is better to err on the side of caution and let the IDS check for the vulnerability
.
The Priority column allows you to select the level of urgency you wish to associate with each event. If you refer back to Figure 8.9, you will see that each of these priority levels is displayed in its own
window. This allows you to quickly distinguish between traffic you wish to investigate later and traffic that requires your immediate attention. It also helps to sort these items for later reports.
Regardless of the priority you set for an item, the Notify Console box must be checked in order to have detected events reported in one of the three console windows.
Previous Table of Contents Next
Copyr ight © Sybex, I nc.
If you click within the Actions column, the Action dialog box shown in Figure 8.12 appears. From here you can select how you want the IDS engine to react when a specific event is detected. This can
be as benign as simply logging the event or as reactive as killing the connection, modifying the firewall rules, and sending notification of the event via e-mail or an SNMP trap message. You can
even record the raw data of the packets in order to completely document the attack.
FIGURE 8.12 The Action dialog box
If you click the Connection Events tab of the Edit Policy menu, you will be presented with a screen similar to the one shown in Figure 8.13. Use the Connection Events screen when you require a bit
more granularity. For example, let’s assume you have a Web server sitting on a DMZ network. While you expect the Web server to receive connections from the outside world, this system should never
try to establish any kind of connection with any other system. If this occurs, it is possible that the Web server has been compromised by an attacker who is now trying to probe or attack other systems.
FIGURE 8.13 The Connection Events tab of the Edit Policy menu
Using the Connection Events settings, you can easily set up three policy rules to monitor all source traffic that originates from your Web server. Three are required because you need to set up one rule
for TCP, one rule for UDP, and another for ICMP. For the source address, use the IP address of the Web server. Set Destination Address, Source Port, and Destination Port to Any, because you want to
be informed of all traffic originating from this system.
This is a powerful tool which allows you to monitor more than just events that seem suspicious. The Connection Events settings can also be used to monitor specific services, even if no exploits are
detected
.
The User-Specified Filters tab of the Edit Policy menu allows you to configure specific services or systems that the IDS should not monitor. This is useful if you wish to insure that specific types of
Finally, the User-Specified Actions tab lets you add items to the Action dialog box. Do this by creating a new action item and associating it with an executable file located on the IDS engine. For
example, if the engine is outfitted with a modem and paging software, you could configure an action item that pages you when a critical event is recorded. Command-line arguments can even be passed
along to the executable in order to customize the action for each specific event.
When you have finished editing your engine policy, click OK to return to the Edit Policies tab of the Engine Properties screen. You will be informed that you have made policy changes and that they
need to be applied using the Apply to Engine button. You can do this now or go on to the General tab to customize the engine even further.
The General tab oddly enough displays general information about the engine configuration. From here you can see what software version the engine is running and the system’s IP address. You can
also view or change the port numbers used to communicate with the console, the NIC which the engine is monitoring, and even the directory where the RealSecure software is located. Typically, you
will not need to change any of these settings.
If you click the Actions tab, you will be presented with the screen shown in Figure 8.14. There are some important configuration options on this screen that you may wish to modify. The most
important is the Tag Real-Secure Kills check box. When this box is checked, RealSecure adds information to all packets used for session disruption, which helps the person on the other end detect
the reason for the dropped connection. While the traffic would have to be inspected with either an analyzer or a tool specifically designed to look for this type of traffic, broadcasting that RealSecure
disrupted the connection may be more information than you wish to hand out. If you want your IDS engine to be truly invisible, you should deselect this option.
Also on this tab are text boxes where you can enter the information required to use the associated action item. For example, you must supply a mail gateway and a destination e-mail address if you
wish to receive e-mail notification of certain events. If you double-click the FireWall-1 icon within the Action Add-ins box, the Configure FireWall-1 Actions screen appears, as shown in Figure 8.15.
From this screen you can specify which firewall should
FIGURE 8.14 The Actions tab of the Engine Properties screen
be modified during certain events and what the properties of those modifications should be. For
FIGURE 8.15
The Configure FireWall-1 Actions screen Once you have finished making configuration changes to the engine, you should apply your changes
to the engine from the Edit Policies tab. Click Apply to Engine, and your changes are applied to the engine and all further traffic inspection is performed using these new policies.
If you have multiple engines, you should repeat these configuration steps for each one
.
When you have finished configuring your engines, there is one last configuration option you may wish to change. Return to the top menu of the Real-Secure console and select View Options. This
will produce the RealSecure Console configuration box. Select the Priority Views tab. Your screen should appear similar to Figure 8.16.
FIGURE 8.16 The Priority Views tab of the RealSecure Console Configuration box
The three settings on the Priority Views tab allow you to customize how long an entry will remain in the Priority windows on the RealSecure console screen. Once this time limit is reached, the entry is
purged from the screen. While it is still recorded in the log, it will not be visible in any of the priority windows.
Previous Table of Contents Next
Copyr ight © Sybex, I nc.
The default value for each is 300 seconds or five minutes. This is fine if you plan to stare at the console screen 24 hours a day. In the event that you do have a life, however, you may wish to bump
these values up a bit, provided that you have enough disk space to accommodate the additional information. The maximum value that can be set for each of these three windows is 32,000 seconds
or just under nine hours. While a short retention value for the medium and low priorities may be sufficient, you may wish to bump up the retention for the high priority window to the maximum
value. If you have not enabled some form of alerting, such as e-mail or SNMP trap messages, this may be your best way to insure that you catch critical events.
Alerting should be considered a critical function of IDS maintenance. Make sure you have some way to stay informed of critical events
.
Monitoring Events
You can now monitor events from the RealSecure console. The Priority windows on the right-hand side of the screen should begin to display selected events once they are detected. You can even try to
trigger one of the events by launching an attack against one of your protected systems. You do not have to try anything destructive; a simple port scan should suffice to insure that the IDS engine is
doing its job.
On the left-hand side of the screen is the RealSecure console is the Activity Tree. This window is shown in Figure 8.17 with the Events tab selected. The Activity Tree allows you to quickly sort
through all recent activity by source IP address, destination IP address, or even specific event. This can be an extremely power tool for determining what traffic is traversing your network. For example,
a quick review of Figure 8.17 tells you that someone was attempting to communicate with one of your systems via SNMP. By opening up further branches of the tree, you can see which system was
the target and how many requests were sent.
You can access an exploit description of each detected vulnerability by right-clicking it
.
FIGURE 8.17 The Events tab of the Activity Tree window
The amount of detailed information that you can collect with a good IDS is downright scary. For example, let’s say you want to further investigate all the HTTP requests you noticed in Figure 8.17.
You could click the Source Tab, as shown in Figure 8.18, in order to get a better look at what these users are doing. By expanding the tree you can continue down one of the branches until you can see
exactly where each host was going. In fact, you could even detect that one of your users has performed a search on Excite’s Web site in order to look for HP Openview Certified Consultants.
Perhaps the user was trying to be helpful by investigating the SNMP traffic you noted on the Events tab if you believe that, I have a wonderful bridge I would like to sell you....
The Destination tab yields much of the same detail. The difference is that the tree is sorted by destination IP address or host name. By navigating down the branches, you can see who has accessed
each address and what type of traffic was generated.
FIGURE 8.18 The Source tab of the Activity Tree window
Reporting
An intrusion detection system would not be complete without the ability to run detailed, as well as summary, management reports. Before you can run reports from the RealSecure console, you must
upload the data stored in each engine’s database. Do this by selecting File Synchronize All Logs from the RealSecure console menu. This will produce the screen shown in Figure 8.19, which tells
you that log information is now being transferred from the engine to the console. Once this transfer is complete, you can close this information box.
.
FIGURE 8.19 The synchronizing database information screen
After all the data has been transferred to the console, you can begin to run reports. Select View Reports from the RealSecure console menu. The system includes a dozen canned reports. The Top 20
Events report is shown in Figure 8.20.
FIGURE 8.20 A report on the top 20 events
The Top 20 Events report is designed to give you a 20,000-foot view of what has transpired on your network. If you require further detail, you can select one of the events listed in the left-hand column.
This will produce an additional text report that identifies every recorded instance of the event. Of course, all reports can be printed if the RealSecure console has access to a local or network printer.
If none of the reports is to your liking, you can customize new reports to fit your requirements. The console database is even ODBC-compliant, so you can read the data file with ODBC-compliant
database programs such as Microsoft Access. This provides even more flexibility in analyzing and reporting the information collected by the RealSecure system.
Summary
In this chapter you have learned about the basics of intrusion detection systems and how they can aid in securing a network environment. You have seen some of the strengths and weaknesses of IDS
products in general. We even walked through the installation and configuration of RealSecure, one of the top-selling IDS products.
The next chapter looks at authentication and encryption technology. These have become extremely popular subjects as organizations race to provide connectivity over less-than-secure network channels.
Previous Table of Contents Next