Note Remember—the more verification the IDS sensor 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.
Of course, no policy is ever going to be an exact fit. For this reason, you should consider using one of the policies as a template and customizing it to fit your needs. Instead of editing any of the default policies directly, you should highlight the closest fit and click the Derive New Policy button. This will clone the policy you have highlighted and allow you to give it a name. Once you have completed this task, you can click Customize in order to critique the settings. This will produce the Policy Editor window for your new custom policy. The Policy Editor allows you to alter security and connection events, create user-defined events, and establish filters. As seen in Figure 8.10, on the left side of the window is the tree view of a particular tab, on the upper right-hand side is a detailed list, while the bottom right-hand section displays an explanation of whatever is selected on the left pane of the window.
Figure 8.10: The Security Events tab of the Policy Editor 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 sensor will look for every item that is checked off in the Enabled 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.
Tip 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.8, 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 Display box (under the Response column) must be checked in order to have detected events reported in one of the
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.11: The Response dialog box
If you click the Connection Events tab of the Policy Editor menu, you will be presented with a screen similar to the one shown in Figure 8.12. 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.12: The Connection Events tab of the Policy Editor 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.
Note 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 traffic are not recorded in the IDS logs. For example, you could filter out all HTTP traffic from your desktop system’s IP address so that your pointy-haired boss does not find out just how much time you spend surfing the Dilbert Zone. (There may even be a few useful security-related reasons for this feature.)
Finally, the Filters tab lets you ignore any protocol, connection type, or traffic on your network. This is can be beneficial, especially if you suspect a hacker is exploiting services beyond the common ones (DNS, FTP, HTTP, etc.) By defining a comprehensive policy, and then ignoring the common protocols, unusual traffic patterns can stand out.
When you have finished editing your sensor policy, click OK to return to the Policies tab of the Sensor Properties screen. You will be informed that you have made policy changes and that they need to be applied using the Apply to Sensor button. You can do this now or go on to the General tab to customize the sensor even further.
The General tab (oddly enough) displays general information about the sensor configuration. From here you can see what software version the sensor is running and the system’s IP address. You can also view or change the port numbers used to communicate with the console, which NIC the sensor is monitoring, and even the directory where the RealSecure software is located. Typically, you will not need to change any of these settings.
The Alerts tab defines three levels of alerts that the sensor can write to the NT Event Log: Error, Warning, and Informative. Each level can be enabled or disabled, and if enabled, can be configured to notify the console and/or send an SNMP trap to a third-party management system. The Encryption tab shows the current cryptographic provider (the system used to encrypt communication between the sensor and the console) along with all available providers. If you are configuring an OS sensor, the next tab is used to define connection and audit policy settings for the sensor. And finally, the Event Log tab pulls all sensor entries from the NT Event log and displays them in the window, allowing an administrator to quickly see how the sensor is interacting with the operating system, or if the sensor itself is having a problem.
While responses can be configured for each individual sensor policy, global responses can be used to simplify administration. By selecting the Global Responses option under the View menu, you will be presented with the screen shown in Figure 8.13. There are some important configuration options on this screen that you may wish to modify. The most important is the RSKILL item, which displays the Tag RealSecure 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 sensor to be truly invisible, you should deselect this option.
Figure 8.13: The Responses tab of the Sensor Properties screen
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. Other examples include the Lucent and Check Point firewalls. If you click on the LMF icon on the left pane of the window, the Lucent Firewall options are presented in the right pane, as shown in Figure 8.14. From this screen you can specify the IP address of the firewall that should be notified during certain events and which key should be used to contact it.
Figure 8.14: The Lucent Firewall screen of the Global Responses window
The option below LMF is OPSEC, which refers to FireWall-1 from Check Point. Options on this tab include Notify, which specifies how FireWall-1 should log the recorded event. The Action item specifies how the firewall responds to an event, whether to simply notify, to inhibit the event, or to inhibit and close the connection. The FireWall Host specifies which firewall routers are affected—all of them, just the gateway devices, or others as specified by the administrator. The Inhibit Expiration option allows you to specify whether the rule change should be permanent or removed after a specific period of time. And finally, the Initialization Settings and Event Port options specify the IP address and port number of the FireWall-1 Management Server.
Once you have finished making configuration changes to the sensor, you should apply your changes to the system (if the changes were made to the Global Responses page), or to the sensor from its own Responses window. Click OK, and your changes are applied to the system or sensor, and all further traffic inspection is performed using these new policies.
Note If you have multiple sensors, you should consider using the Global Responses instead of configuring steps for each one.
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 sensor 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.15 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 powerful tool for determining what traffic is traversing your network. For example, a quick review of Figure 8.15 shows you that someone from an IP address of 24.6.91.205 has attempted gain access to this NT system (IP address
24.92.184.100) through a NetBIOS session.
Figure 8.15: 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 the attempt at system access as illustrated in Figure 8.16.You could click the Source Tab 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.
Figure 8.16: The Event Inspector window
By right-clicking the individual event at the lowest level of detail in the tree, you can choose the Inspect Event option. This creates the Event Inspector window, which provides a high level of detail—the source and destination IP addresses, the protocols, the source and destination ports, (including the information type and value), along with the actions taken. In fact, you can resolve the IP address of the system that sent the request into a domain name (see Figure 8.16). This can be useful; by knowing the domain name you can contact the owner of the domain name, and eventually trace the activity to a particular system.
While this does not guarantee you’ll find the hacker, you can at least eliminate one avenue used to attempt system penetration. In Figure 8.16, you can see that the source of the connection request to the server comes from a computer on the home.com domain, (which just happens to be the name reserved for @Home, AT&T’s cable modem ISP. You could now do a WHOIS query to find out the contact information for the owners of the domain name, and contact them with the details of the attempted access. @Home keeps track of which users are assigned particular host names, and they have a strict usage policy prohibiting unauthorized probing of systems by their clients.
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.
Reporting
An intrusion detection system would not be complete without the ability to run detailed, summary management reports. Before you can run reports from the RealSecure console, you must upload the data stored in each sensor’s database. Do this by selecting File ¾ Synchronize All Logs from the RealSecure console menu.
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.17.
Figure 8.17: 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.
Chapter 9: Authentication and Encryption
Authentication and encryption are two intertwined technologies that help to insure that your data remains secure. Authentication is the process of insuring that both ends of the connection are in fact who they say they are. This applies not only to the entity trying to access a service (such as an end user) but to the entity providing the service, as well (such as a file server or Web site). Encryption helps to insure that the information within a session is not compromised. “Compromising” could include not only reading the information within a data stream, but altering it, as well.
While authentication and encryption each has its own responsibilities in securing a communication session, maximum protection can only be achieved when the two are combined. For this reason, many security protocols contain both authentication and encryption specifications.