The IDS Device Manager is a web application that comes preinstalled on all sensors version 3.1 or higher. This application can be used to configure and manage your CIDS sensors. You can access the IDS Device Manager using Netscape or Internet Explorer. Unlike CSPM, this application can’t be used to create multiple configurations for multiple sensors.
The IDS Device Manager provides a GUI interface that’s used to configure each sensor individually. Figure 25-4 illustrates the IDS Device Manager view displayed during the initial connection using Netscape or Internet Explorer.
Before the IDS Device Manager can be used to configure CIDS sensors, the sensors must first be bootstrapped, as previously discussed. Once the sensors are bootstrapped, you can connect to the sensor using Netscape or Internet Explorer. To connect, simply type https://<sensor_ip_address> in the address bar and press ENTER. Notice you must use HTTPS, and not just http.
The sensors contain a web server that’s running the Device Manager application. For security reasons, the web server uses an encryption protocol known as Transaction Layer Security (TLS), which is closely related to Secure Socket Layer protocol (SSL). When you enter the URL to the sensor in the address bar, the web browser attempts to connect to the sensor using TLS or SSL. You can disable the security feature by selecting Device | Sensor Setup | Network, where Device is the Area, Sensor Setup is the Sub-Area, and Network is the TOC item.
When you connect to the Device Manager application, you’re presented with a security alert dialog box warning that the certificate being used by the sensor has been issued by an unknown Certificate Authority (CA), as shown in Figure 25-5. The sensor generates its own certificate, so it isn’t a trusted CA. To connect to the sensor, you must choose to ignore this warning. To prevent this security alert dialog box from being presented each time you connect to the sensor, you must configure your web browser to trust the sensors as a CA.
If you change the organization or host name of the sensor, a new certificate is generated. You’ll then be required to perform the fingerprint validation again.
When you connect to the Device Manager, you’re prompted for a user name and a password. The default user name is netrangr and the password is attack. The user name and the password can be changed once access to the Device Manager is accomplished.
The Device Manager GUI interface consists of the following:
The Area Bar contains the four major configuration headings that can be selected to configure specific settings for the IDS sensor. Once an area is selected, a list of corresponding Sub-Areas is listed in the Sub-Area Bar.
The areas include the following:
The content of the Sub-Area Bar changes depending on the Area that’s selected. The configuration objects that make up the Sub-Area menu are subcategories under the major area. For example, when the Device Area is chosen, the only Sub-Area that can be selected is Sensor Setup, but when the Monitoring area is selected, you can choose from the three Sub-Area categories: Log, Sensing Interfaces Statistics, or IDS Event Viewer. Once a Sub-Area is selected, the Table of Contents (TOC) for that Sub-Area is displayed.
Each Sub-Area selected contains a different Table of Contents (TOC). When an item in the TOC is selected, the content area will display the configuration parameters for the item selected.
The Content Area is where the configuration parameters for each configurable setting are displayed. From this area, you can add, change, or delete the existing sensor configuration settings from within the Content Area panel. The Content Area is where the configuration parameters are set.
The Path Bar displays the current path, including the Area, Sub-Area, and the TOC item currently selected. This path shows the menus that were selected to reach the current destination.
The tool bar has important tools that assist with the configuration and management of the network sensor. The tool bar contains the following tools and links:
The Logout link can be selected to log out of the current sensor. Only one connection to the sensor is allowed at a time, so logging out of the sensor once you complete the configuration is important.
The Apply Changes link must be used to save any configuration changes that were made. The changes made to the sensor aren’t applied until the Apply Changes link is selected. If you don’t want to apply or save the changes made, you can click reset to remove all the changes made and return the settings to their previous state. As you can see in Figure 25-6, once the changes have been applied, you might be required to reset the sensor.
The Help link can be selected to provide additional help with the use of Device Manager and the configuration of the CIDS sensor.
The Network Security Database (NSDB) can be displayed by selecting NSDB from the Tool menu, as seen in Figure 25-7. The NSDB contains specific information regarding the signatures and the types of attacks each signature is used to detect. The NSDB is explained in more detail in the next chapter.
The about link can be selected to view the current IDS version the sensor is running.
Once the sensor is bootstrapped with the correct configuration, the IDS Device Manager application can be used to configure and manage the CIDS sensor. To configure the sensor, you must use a web browser, such as Netscape or Internet Explorer, to connect to the sensor, and then select the configuration panel containing the configuration data you want to configure.
The Network panel can be selected by navigating to Device | Sensor Setup | Network, where Device is the Area, Sensor Setup is the Sub-Area, and Network is the TOC item. Once the Network TOC item is selected, the network panel is displayed in the content area, as seen in Figure 25-8.
The Network panel lists the configuration parameters that were configured during the sensor bootstrap process. From this panel, the common network and PostOffice setting can be modified. Additional settings that can be configured include the following:
Heartbeat Interval This setting is used to calculate how many attempts the sensor should make to wait for a heartbeat acknowledgement from a remote host before considering the host is down and generating a route-down alarm.
Route-Up Alarm Level This setting configures the level of alarm to be generated when a route-up event is detected. The default setting is Informational. Possible settings include the following:
Informational—Categorizes the event as informational in nature and not a risk to security. These events are shown with a blue icon in the IDS Event Viewer.
Low—Categorizes the event as mildly severe. These events are displayed with a yellow icon in the IDS Event Viewer.
Medium—Categorizes the event as a moderate risk. These events are displayed with an orange icon in the IDS Event Viewer.
Categorizes the event as a high risk. These events are displayed with a red icon in the IDS Event Viewer.
The values (1 to 5) are mapped to these logical names, based on the configuration settings in the severity mapping panel. The names previously used are the default severity mappings configured on each sensor.
Route-Down Alarm Level This setting configures the level of alarm to be generated when a route-down event is detected. The settings for route-down alarms are the same as previously mentioned for the route-up alarm level. The default setting for this parameter is high.
Enable TLS/SSL This setting configures the web server to use TLS and SSL.
Web Server Port This setting configures the port number on which the sensor’s web server will listen for HTTP or HTTPS requests. By default, this parameter is set to 443 for HTTPS communications.
You can configure the allowed hosts during the bootstrapping or from the IDS Device Manager. By default, the sensor only allows access from IP addresses to which the sensor has been configured to allow access. By default, the sensor allows access from any host with an IP address belonging to the 10.0.0.0 /8 network. Before you can connect to the sensor, you must configure the sensor—during bootstrap—to allow the IP address of the host which you’ll use to connect to the sensor. Figure 25-9 illustrates the Allowed Hosts panel.
To allow hosts, you can enter the specific host address or the network address. When adding a network address, you only have to enter the octets that make up the network address. For example, if you want to allow all hosts in the 172.30.0.0 /16 network, you could add the first two octets, such as 172.16. In addition, you can allow all hosts to connect to and manage the sensor by clicking Allow All Hosts.
You can allow unsecured access to the sensor via Telnet or FTP. The protocols are considered insecure because they send data in clear text. To enable Telnet or FTP, select the Remote Access item in the TOC and select either protocol by placing a check mark in the corresponding checkbox, as Figure 25-10 shows.
From the SSH TOC panel, you can generate a new or delete an existing host key. Host keys are used by the sensor to connect to PIX firewalls and other hosts. Once the SSH session is open, the sensor can use the connection to perform blocking.
You can configure the sensor to create a new host key by selecting the Generate Host Key link on the Host Key panel. Once the host key is created, apply your configuration settings. With the new key created, you must then update the known host tables on the remote systems with the new key fingerprint. You can delete exiting keys by selecting the Known Hosts TOC item.
If you’re using the sensor to configure blocking on a PIX firewall, you must manually connect to the firewall using SSH, and then accept the SSH key of the PIX firewall.
You can configure the time, date, and time zone information from the Time panel.
The password for the netrangr account can be changed from the Password panel. You needn’t click Apply Changes on the toolbar for this change to take effect.
By default, the CIDS sensors publish alarm and event data to the host on the host in which you installed IDS Device Manager. You can change or add additional hosts, allowing the sensor to send the event stream to multiple hosts. You must add the IDS Event Viewer as a remote host if alarms are to be sent to the Event Viewer. When adding a remote host, you can specify the level of alarm that should be sent to the remote host. The Remote Hosts panel is illustrated in Figure 25-11.
Event Destinations enables you to configure the level of alarms to be sent to previously configured remote hosts. You can specify the level of alarm to be sent, the service to which the alarm should be sent, and the type of message to be sent.
As discussed in Chapter 23, the sensor uses signatures to detect network intrusions. A signature specifies the types of network attacks for which you want the sensor to detect and generate alarms. Signatures are arranged in two different ways. Signatures are arranged in six categories based on the type of traffic that’s analyzed. And signatures are also organized into signature groups, based on the signature engine type, as seen in Figure 25-12. Each signature group contains a configuration pane that can be used to configure each specific signature contained in that signature group. From the configuration pane, the signatures can be enable or disabled, the severity can be assigned, and the responsive action can be specified.
The six categories of signatures are as follows:
Built-in signatures are known attack signatures included in the sensor software. The signatures that make up the built-in group can’t be added to, removed, or renamed. You can adjust the built-in signatures by adjusting a number of group signature parameters. Figure 25-13 illustrates the configuration pane for built-in and custom signatures.
Custom signatures are user defined. These signatures can be fine-tuned through signature engine parameters.
TCP connection signatures are user-defined signatures based on the TCP port number of the traffic being monitored. As seen in Figure 25-14, you can use the TCP connection signatures configuration pane to enable or disable a TCP connection signature. You can also configure the severity of the signature, as well as the actions to take when the signature is matched.
UDP connection signatures are user-defined signatures based on the UDP port number of the traffic being monitored. As seen in Figure 25-15, the UDP connection configuration pane can be used to configure the UDP connection signatures.
String matching signatures are user-defined signatures that detect malicious activity by analyzing network traffic looking for a specific string match. String-matching signatures can be configured to analyze incoming, outgoing, or bidirectional traffic. Figure 25-16 illustrates the String matching signature configuration pane.
ACL signatures are user-defined signatures that generate alerts based on policy violations recorded by access devices. To allow a sensor to send alarms based on ACL violations, you must first configure one or more routers to log ACL violations. The routers must then be configured to send syslog messages to the sensor. When the sensor receives a syslog message from the router, the sensor generates an alarm.
By default, the most critical signatures are enabled. Other signatures must be enabled to allow the sensor to monitor network traffic for that specific signature. Enabling and configuring the parameters for each signature is accomplished from the Configuration Area and the Sensing Engine Sub-Area. Signatures are discussed in more detail in the next chapter.
From the Configuration Area, you can configure the level of logging the sensor should perform. As seen in Figure 25-17, you can configure the sensor to log the following:
TCP connection requests and UDP traffic
TCP connection requests, SYN-ACK, FIN, RST, and UDP traffic
TCP SYN-ACK packets from the specified port and UDP traffic
You can configure filters to control the behavior of the sensing engine filters. You can configure the sensor to exclude or include signature matches based on the source or destination IP address. Signature filtering is only effective on enabled signatures. You can configure filters based on the IP address or IP address range. Figure 25-18 illustrates the filtering configuration pane.
You can use your network sensors to monitor the amount of spam entering your network. This feature examines the number of recipients contained in a mail message crossing the network. Figure 25-19 illustrates the spam control configuration pane.
The reassembly options TOC item contained in the Configuration Area can be used to configure IP fragment reassembly parameters. By configuring this configuration pane, you configure the sensor to reassemble all the fragmented packets before they’re compared to the signature database. Figure 25-20 displays the IP fragment reassembly options configuration pane.
Reassembling IP fragments into the complete datagram consumes sensor resources, such as memory and CPU cycles. Without some additional parameters in place, it would be possible for the sensor to run out of resources by attempting to track and reassemble too many datagram fragments. To prevent this from happening you must configure the following parameters:
Maximum Partial Datagrams
Maximum Fragments per Datagram
Fragmented Datagram Timeout
Cisco recommends you don’t modify these settings unless you thoroughly understand your traffic patterns and the likelihood of receiving fragmented packets over a specified amount.
The Maximum Partial Datagrams parameter is used to specify the maximum number of partial datagrams that can be tracked by the sensor. When the sensor receives a fragmented datagram, it must then collect all the associated fragments that make up the entire datagram and reassemble them. This parameter sets the maximum amount of partial datagrams the sensor will attempt to reassemble. The sensor has a limited amount of resources and could be swamped if this limit is set too high.
The Maximum Fragments per Datagram parameter is used to limit the amount of fragments the sensor will track to reassemble a single datagram. This parameter is used to limit the amount of fragments that must be tracked by the sensor.
The Fragmented Datagram Timeout parameter represents the maximum amount of time that can elapse between fragments. The sensor can’t wait forever to receive all the fragments that make up a datagram. In addition, hackers could swamp the network with partial datagram fragments in an attempt to overwhelm the sensor’s resources. If the sensor doesn’t receive any additional fragments for a specific datagram within the timeout period, the existing fragments for that datagram are discarded and the datagram fragments are no longer tracked.
You can specify which TCP data streams should be analyzed based on the capability of the sensor to rebuild the entire session. Like IP fragment reassembly settings, these settings ensure that system resources, such as memory and CPU cycles, aren’t reserved for sessions that are no longer active. The TCP reassembly configuration pane is illustrated in Figure 25-21.
To specify that the sensor track only sessions for which the three-way handshake is completed, select Enabled in the TCP Three Way Handshake list box.
In the TCP Embryonic Timeout field, enter a numerical value between 1 and 180 to specify the number of seconds that can elapse before the sensor frees the resources allocated for an initiated, but not fully established, TCP session. The default number of seconds is five.
In the TCP Open Establish Timeout field, enter a numerical value between 1 and 3,600 to specify the number of seconds before the sensor frees the resources allocated to a fully established TCP connection when no more packets are being seen for that connection. The default number of seconds is 90.
You can specify that specific network IP addresses are internal networks for the purpose of logging and reporting. IP addresses that don’t match a configured IP internal network are considered external addresses. When the sensor generates an alarm, the IP address of both the source and destination are logged as internal (IN) or external (OUT) to help security administrators to identify the origin and destination of suspected attacks.
You must configure data sources when using ACL policy violation signatures. Cisco routers publish syslog messages to the sensors, including attempted ACL policy violations. The Cisco routers represent the data sources for ACL policy violation signatures. In the IP Address field, enter the IP address of the interface of the router that will publish syslog data to the sensor or the IP address of a network, if multiple routers from the same network will be sending syslog data to the sensor.
As shown in Figure 25-22, the Sensing properties configuration panel can be used to configure the following:
Alarm level for traffic flow
Alarm level for link status
The amount of time the sensor should store information once a host stops communication
Figure 25-22: Sensing properties configuration panel
You can select automatic to allow the sensor to choose the interface to be used for IDS or you can manually specify the interface to be used as the sensing interface. If you choose to configure the sensing interface manually, you need to know the specific device name for your sensor. Table 25-4 lists the sensor interfaces and their names.
Packet Capturing Device
All Ethernet sensors except the 4210
4200 Series Token ring Sensors where NICs aren't labeled 100/16/4
4200 Series Token ring Sensors where NICs are labeled 100/16/4
Used with SFDDI and DFDDI interfaces
Monitoring interface on the 4210 series sensor
You can configure the sensor to generate an alert when no traffic is seen for a specified amount of time, possibly indicating the sensor is no longer receiving traffic on the network. You can configure the timeout period, the amount of time the sensor will wait to see traffic before generating an alert, and the level of alert that will be generated if the timeout is reached.
You can configure the sensor to generate an alert if the link fails between the sensing interface and the local access device. If the sensor detects the physical link is non-operational, it generates an alert. You can configure the level of alert to be generated when the link fails.
The Storage Timeout Seconds field enables you to configure the amount of time the sensor will store data from a host once that host gone silent.
The logging Sub-Area can be used to configure specific logging settings on the sensor. The logging Sub-Tab includes four TOC items. TOC items are as follows:
Exporting event logs
Automatic IP logging
The event logging configuration panel can be used to enable logging, as well as to specify the level and type of events that should be logged. As Figure 25-23 shows, you can log the following:
Figure 25-23: Event logging configuration panel
The exporting event logs configuration panel can be used to configure the automatic exporting of event logs to an FTP server. These logs can be stored for future examination, if needed. Figure 25-24 illustrates the exporting event logs configuration panel. You must specify the FTP server, directory, user name, and password to allow the sensor to upload event logs.
Automatic IP logging is a responsive action that can be initiated when a signature is matched. When a properly configured signature is matched, the sensor responds by sending an alarm, and then recording all IP packets transmitted by the offending IP address. The automatic IP logging configuration panel enables you to configure the number of minutes the sensor should continue logging once the signature has been matched.
Sensors can be configured to log all packets from a specified host or host range. On the IP logging configuration panel, you must specify the host or range of IP addresses that should be logged by the sensor.
The 4200 series network appliances are the only sensors that support blocking. The IDSM can’t be configured to block IP addresses through device management. The blocking properties configuration panel is illustrated in Figure 25-25.
The 4200 series network appliances can be configured to block specific host addresses once a signature is matched. The blocking response is configured within the signature file itself. If a signature is matched and that signature is configured for blocking, the network appliance can configure a perimeter router or firewall to block all packets from that host for a specific number of minutes. To use this feature, you must specify the number of minutes the offending host should be blocked, as well as the Cisco ACL number used on the perimeter device.
Additional parameters used when blocking is enabled are located in the Blocking area Sub-Areas. The following Sub-Areas are used to configure blocking:
Never Block Addresses
Master Blocking Sensors
Blocking an IP address is also called shunning a host or IP address.
When you enable address blocking, you must specify which addresses should never be blocked. Without this feature, hackers could spoof the address of your event viewer host (for example) and use this address to launch an attack. The sensors, detecting this attack, would then update the ACL on a managed device to block the IP address of your event viewer. If the Event Viewer address is blocked, you could potentially lose communication between your sensors and your Event Viewer host. If communication between the sensors and the Event Viewer host is lost, you won’t receive alarm notifications. Figure 25-26 shows the never block addresses configuration panel.
The Blocking Devices area lists the devices managed by the sensor. The router must be configured to allow telnet access from the sensor. Figure 25-27 illustrates the Blocking Device Properties window. You can use a single sensor to manage more than one perimeter device, but a perimeter device can’t be managed by more than one sensor. The information that must be configured on this panel to enable the sensors to block IP addresses includes the following:
The IP address used for telnet access to the router
The telnet user name and password
The enable password
The perimeter device interface address (configured in the Blocking Device interface TOC)
You should understand how to configure a sensor to manage a perimeter device.
If the router to be managed doesn’t have user names configured, leave the Telnet User field blank.
Depending on the size and complexity of your network, you could have multiple entry points into your network. Some perimeter routers might be controlled by one sensor, while other perimeter routers are controlled by others. To configure your CIDS environment to allow any managing sensor to block IP addresses on routers controlled by a different sensor, you must enable a master blocking sensor. The master blocking sensor sends messages to the managing sensors to update the ACL on the routers that they manage. This master blocking arrangements prevents multiple sensors from attempting to update routers ACLs simultaneously.
You can restore the factory defaults of the sensor by clicking Reset Configuration on the restore defaults configuration panel. All configuration settings are restored to factory defaults except
IP address, subnet mask, default gateway
The Monitoring Area contains logs and statistics generated by the sensor. The monitoring area contains the Sub-Areas, Logs, Statistics, and Event Viewer. This Area and the Sub-Area contain information and reports about both the sensor and its operating environment.
The Logs Sub-Area contains links to the logs generated by the sensor. These log files provide a record of all events the sensor has detected and can be used by security administrators while investigating an intrusion. The Logs Sub-Area, as seen in Figure 25-28, includes the following TOC items:
Figure 25-28: The Logs Sub-Area
The sensing interface statistics panel reports the characteristics of the traffic captured by the sensor’s sensing interface, as seen in Figure 25-29.
The event viewer Sub-Area contains links to Cisco’s web site detailing technical information and access to the event viewer installation files.
The Administration Area is where the administrative functions can be configured and performed. The Administration Area contains the following Sub-Areas:
The system information panel lists configuration and system information for the local sensor. As you can see in Figure 25-30, the system information report includes the following information:
Web Server Port
CIDS Daemon Status
CIDS Connection Status
CIDS Logging Disk Usage
The update configuration panel can be used to update the software installed on the sensor. Updates can be initiated manually or they can be scheduled, as shown in Figure 25-31. When performing an update or configuring an automatic update, you must specify the FTP server address, directory, user name, and password.
Manual blocking can be initiated from the Administration Area. You can specify the IP address or the network address you want to block and the amount of time the address(s) should remain blocked, as shown in Figure 25-32.
The diagnostics Sub-Area can be used to run a new diagnostics test or to view the report generated when the last diagnostics report was generated.
The system control panel enables you to perform basic administration of the sensor. This panel allows the administrator to
Stop and restart IDS processes
Reboot the sensor
Power down the sensor
The IDM properties allow the administrator to customize some configuration settings within the sensor itself. Using the configuration panel in the Sub-Area Severity mapping, you can customize the mapping of severity number (1–5) to the severity names. By default, the mappings are as follows:
Informational Categorizes the event as informational in nature and not a risk to security. These events are shown with a blue icon in the IDS Event Viewer.
Low Categorized the event as mildly severe. These events are displayed with a yellow icon in the IDS Event Viewer.
Medium Categorizes the event as a moderate risk. These events are displayed with an orange icon in the IDS Event Viewer.
High risk. High-risk events are displayed with a red icon in the IDS Event Viewer.
The second IDM properties TOC item is signature pagination. This configures the number of signatures listed on a single display page when viewing signature groups.