Table of Contents

Configuring Sensors and Signatures

Network sensing can be accomplished using either a sensor or an IDSM (Intrusion Detection System Module). Both of these sensing platforms are components of the Cisco Intrusion Detection System and can be managed by IDS MC. Both sensing platforms monitor and analyze network traffic in real time. They do this by looking for anomalies and misuse on the basis of an extensive embedded signature library. However, the two platforms differ in how they can respond to perceived intrusions.

The sensor is a high-performance plug-and-play appliance. When it detects unauthorized network activity, the sensor can terminate the connection, permanently block the associated host, log the incident, and send an alarm to IDS MC.

The IDSM is a switching module designed for the Catalyst 6000 family of switches. When the Cisco Intrusion Detection System detects unauthorized network activity, the IDSM responds by generating an alarm that can be logged and displayed by IDS MC. The IDSM can terminate network connections when it is running sensor software version 3.0 and later, but not when it is running earlier versions.

Beginning with IDS 4.1 software, a module is available for Cisco 2600/3600 IOS routers.

Network sensing using either the sensor or the IDSM requires configuring a number of sensor (or IDSM) settings and signature settings. After configuring, tuning is required to achieve optimal performance, particularly to minimize false positives and false negatives.

Note   Tuning sensor configurations should not be confused with tuning parameters for individual signatures.

Task List for Configuring Sensors and Signature Settings

To configure sensors, groups of sensors, and signature settings, perform one or more of the following tasks. Some settings can be configured only at the sensor level or only at the group level. For example, signatures can be configured only at the sensor level. As another example, identifying additional ports used by specific signatures can be done only at the group level.

You initiate all these tasks in the Configuration > Settings TOC, which is shown in Figure 5-1 as it first appears when you select Configuration > Settings. Most of these tasks require you to use the Object Selector. The Object Selector handle appears to the left in Figure 5-1.

Tip The Configuration > Settings TOC and the Configuration > History page are the only places where the Object Selector is used in IDS MC.

Identifying Additional Ports Used by Specific Signatures Applied to a Sensor

When using IDSM devices supported by IDS MC, you can specify additional ports that should be considered by signatures that study specific network services (identified by the TCP port used by that network service). These port settings enable you to identify any well-known network service ports that you have reassigned on your internal network. These port settings also enable you to identify any custom TCP-based services, running across your internal networks, that you want the sensor to study for specialized attacks that target these network services.

Port mapping applies only to 3.x IDS modules, 4.x sensor appliances, and IDS MC groups. It does not apply to 3.x sensor appliances.

To identify additional or remapped ports for more extensive evaluation by specific signatures, follow these steps:

Step 2   Click the Object Selector handle.

Step 3   In the Object Selector, select the device or group for which you want to identify additional or remapped ports.

The Object Selector closes.

Step 4   In the TOC, select Port Mapping.

The Port Mapping page appears.

Step 5   To specify additional ports that should be considered by the signature that studies for hijacked ports on a TCP-based service, enter each port number in the TCP HIJACK Ports field, separating entries with a comma.

Step 6   To specify additional ports that should be considered by the signature that studies for TCP-based flood attacks, enter each port number in the TCP SYNFLOOD Ports field, separating entries with a comma.

Step 7   To specify additional ports that should be considered by the attack signature that studies for Telnet-based attacks, enter each port number in the TCP TELNET Ports field, separating entries with a comma.

Step 8   To specify additional ports that should be considered by the attack signature that studies for HTTP-based attacks, enter each port number in the TCP HTTP Ports field, separating entries with a comma.

Step 9   To accept your changes and close the Port Mapping page, click Apply.

Identifying Internal Networks

For each sensor or group of sensors that you manage with IDS MC, you can identify internal networks. These are networks that you consider trusted. Internal networks are handled differently from external networks for the purposes of reports and alarms.

To identify an internal network, follow these steps:

Step 2   In the TOC, click the Object Selector handle.

Step 3   In the Object Selector, select the sensor for which you want to identify an internal network.

The Object Selector closes.

Step 4   Select Internal Networks.

The Internal Networks page appears, and the Object bar displays the sensor you selected in the Object Selector.

Step 5   On the Internal Networks page, you can add an internal network. After you have added an internal network, you can edit its properties or delete it.

Configuring Link Status

For each sensor or group of sensors that you manage with IDS MC, you can configure the way that you want to see your link status reported by the Event Viewer in Security Monitor. Link status refers to the communication between a particular sensor or group of sensors and Security Monitor. You can specify how much time is to elapse before an interruption in your link is reported. You also can specify whether the interruption is to be regarded as an event of high, low, or medium severity.

You can perform this procedure for the sensor appliance but not for the IDSM.

To query for link status, follow these steps:

Step 2   In the TOC, click the Object Selector handle.

Step 3   In the Object Selector, select the sensor for which you want to configure the reporting of link status.

The Object Selector closes.

Step 4   Select Link Status.

The Link Status page appears, and the Object bar displays the sensor you selected in the Object Selector.

Step 5   On the Link Status page, you can specify global settings, or you can choose to override global settings.

Identifying Data Sources

A Cisco IOS router can publish syslog data to a sensor. You must specify the interface that the Cisco IOS router uses.

To identify the interface that a Cisco IOS router uses to publish syslog data to a sensor, follow these steps:

Step 2   In the TOC, click the Object Selector handle.

Step 3   In the Object Selector, select the sensor for which you want to specify a Cisco IOS router interface for the publication of syslog data.

The Object Selector closes.

Step 4   In the TOC, select Data Sources.

The Data Sources page appears, and the Object bar displays the sensor you selected in the Object Selector.

Step 5   On the Data Sources page, you can add an interface for syslog data publication by a Cisco IOS router. After you have added an interface, you can edit it or delete it.

Specifying Blocking Properties

You can configure a sensor to block an attack by generating ACL rules for publication to a Cisco IOS router. You can specify the blocking duration, the maximum number of ACL entries, whether to enable ACL logging, and whether to allow blocking devices to block the sensor's IP address.

To specify blocking properties, follow these steps:

Step 2   In the TOC, click the Object Selector handle.

Step 3   In the Object Selector, select the sensor for which you want to specify blocking properties.

The Object Selector closes.

Step 4   In the TOC, select Blocking Properties.

The Blocking Properties page appears, and the Object bar displays the sensor you selected in the Object Selector.

Step 5   On the Blocking Properties page, you can specify global settings, or you can choose to override global settings.

Specifying Networks and Hosts that Should Never Be Blocked

You can configure a sensor to block an attack by generating ACL rules for publication to an Cisco IOS router. However, it is important to tune your sensor signatures to identify hosts and networks that should never be blocked. For example, you may have a trusted network device whose normal, expected behavior appears to be an attack. But such a device should never be blocked. Also, trusted, internal networks should never be blocked. Proper tuning reduces the number of false positives and helps ensure proper network operation.

To specify the networks or hosts that should never be blocked when an attack is detected, follow these steps:

Step 2   Click the Object Selector handle.

Step 3   In the Object Selector, select the sensor for which you want to identify hosts and networks that should be exempt from blocking.

Step 4   In the TOC, select Blocking > Never Block Addresses.

The IP Addresses page appears. This page shows the list of devices and networks that are capable of being blocked by configuring the sensor that you selected. On this page, you can add, edit, and delete hosts and networks.

Step 5   To add a host or network to the list of those that should never be blocked by the sensor that you selected, click Add.

The Enter Network page appears.

Enter the following information in the Enter Network page:

Step 6   To edit information associated with a host or network on the list of those that should never be blocked by the sensor that you selected, select the check box adjacent to the address of that host or network, and click Edit.

The Enter Network page appears.

Enter the following information on the Enter Network page:

Step 7   To delete a host or network from the list of those that should never be blocked by the sensor that you selected, select the check box corresponding to the address of that host or network, and click Delete.

The host or network that you selected is deleted.

Step 8   To add, edit, or delete additional hosts or networks, repeat Step 2 through Step 7.

Step 9   To continue configuring sensors, select Configuration > Settings.

Using Blocking Devices

You can block an attack on your network by configuring a sensor to request a Cisco IOS router, a Catalyst 6000 VACL, or a PIX Firewall to reject IP traffic that you specify. The Cisco IOS router, Catalyst 6000 VACL, or PIX Firewall in that situation is referred to as a blocking device. Before you can use a Cisco IOS router, a Catalyst 6000 VACL, or a PIX Firewall as a blocking device, you must identify it in IDS MC and specify its properties.

To identify a blocking device and specify its properties, follow these steps:

Step 2   Click the Object Selector handle to open the Object Selector.

Step 3   In the Object Selector, select the sensor for which you want to specify a blocking device and its properties.

The Object Selector closes, and the Object bar displays the sensor you selected in the Object Selector.

Step 4   In the TOC, select Blocking Devices.

The Blocking Devices page appears.

Step 5   On the Blocking Devices page, you can add a Cisco IOS router, a Catalyst 6000 VACL, or a PIX Firewall to be used as a blocking device. After you have added a blocking device, you can edit it or delete it.

Specifying Master Blocking Sensors

A sensor can generate and apply ACL rules to block attacks that it detects. However, you may find that it is more effective in some configurations to have a proxy sensor generate and apply rules for attacks detected by another sensor on your network. These proxy sensors are referred to as master blocking sensors.

To specify master blocking sensors that should be used to block attacks detected by the selected sensor, follow these steps:

Step 2   In the TOC, click the Object Selector handle.

Step 3   In the Object Selector, select the sensor for which you want to specify a master blocking sensor.

The Object Selector closes.

Step 4   In the TOC, select Master Blocking Sensors.

The Master Blocking Sensors page appears, and the Object bar displays the sensor you selected in the Object Selector.

Step 5   To identify a master blocking sensor, click Add.

The sensor that you identify acts as a master blocking sensor.

Configuring Event Logging

A sensor can generate audit event log files based on network data streams, or syslog data streams, or both, that the sensor is configured to study. The resulting log files are stored locally on the sensor.

To generate audit event log files, follow these steps:

Step 2   In the TOC, select Logging > Event Logging.

The Event Logging page appears.

Step 3   On the Event Logging page, you can specify global settings, or you can choose to override global settings, by selecting the Override check box.

Step 4   To enable the generation of audit event log files, select the Generate audit event log files check box.

Step 5   Use the Minimum event level to be logged list box to set the minimum event level that you want to be logged.

Step 6   To specify an FTP server to which you want the sensor to publish a copy of the audit event log files that it archives (stops writing to after a new log file is created), select the Copy archived event log files check box.

Step 7   To specify the target FTP server, enter that server's IP address or DNS name in the Target FTP server field and press Tab.

Step 8   To specify the desired directory path on the target FTP server, enter that path in the Target FTP directory box and press Tab.

Step 9   To specify the user account that the sensor should use to log into the target FTP server, enter that user account in the Username field and press Tab.

Step 10   To specify the password that corresponds to the user account specified in the Username box, enter that password in the Password field.

The username/password pair is used to authenticate the sensor to the FTP server.

Configuring Automatic IP Logging

You can configure a sensor to generate an IP session log when the sensor detects an attack. If you want the sensor to take this action, you must specify it when you configure individual signatures. You must specify how long, in minutes, IP logging is to be done when a sensor detects an attack.

This procedure can be performed for the sensor appliance but not for the IDSM.

To specify the length of IP logging, follow these steps:

Step 2   In the TOC, select Logging > Automatic IP Logging.

The Automatic IP Logging page appears.

Step 3   On the Automatic IP Logging page, you can specify global settings, or you can choose to override global settings, by using the Override check box.

Step 4   For a 3.x sensor, to specify the number of minutes that you want IP logging to be done, enter that value in the Length of Auto Logging box. Integer values from 1 through 60 are valid.

Step 5   For a 4.x sensor, you can specify additional logging parameters.

Step 6   To save your changes, click Apply.

Step 7   To discard your changes, click Reset.

Configuring IP Logging

You can configure a sensor to generate log files for specific IP addresses.

This procedure can be performed for the sensor appliance but not for the IDSM.

To generate log files for specific IP addresses, follow these steps:

Step 2   In the TOC, select Logging > IP Logging.

The IP Logging page appears.

Step 3   On the IP Logging page, you can add an IP address for which you want to generate log files. After you have added an IP address, you can edit it or delete it.

Specifying Postoffice Settings

A sensor can monitor the services that are running on it. The sensor can generate audit events, as warnings, when a service goes down or cannot be restarted. This monitoring function, called Watchdog, helps you track the state and desired operation of your sensors. Watchdog is a feature of the postoffice service.

Watchdog checks the availability of services that are supposed to be running on the sensor and verifies that desired sensor-to-other network object communications (based on postoffice) are available. The Watchdog queries the services to see if they are operational, and if they are not, it issues warnings to the user and attempts to restart the services. You can specify the alarm levels of these warnings.

Additional postoffice settings that you can specify are the postoffice port and the heartbeat interval.

Note   You will rarely need to modify the postoffice settings, and you should attempt to do so only if you are an expert user. Most users should not modify the default values.

To specify postoffice settings, follow these steps:

Step 2   In the TOC, select Communications > Postoffice Settings.

The Postoffice Settings page appears.

Step 3   On the Postoffice Settings page, you can specify default settings, or you can choose to override default settings by using the Override check box.

Step 4   To specify a postoffice port other than the default value, enter the new value in the Postoffice Port field.

Step 5   To modify the interval that IDS MC uses to verify that all other postoffice clients with which it communicates are still accessible and available over the network, enter that value in the Heartbeat field.

To check client availability, IDS MC sends a postoffice packet to each known client and waits for a response packet. If the IDS MC postoffice does not receive a response, it assumes that the route to that client is no longer available, and postoffice issues a route down audit event. The heartbeat value is a whole number that represents how many seconds the postoffice running on IDS MC waits between each check for client availability.

Step 6   To specify how often (in seconds) the Watchdog feature should query the services that are supposed to be running on the sensor, enter that value in the Watchdog Interval field under Watchdog Properties.

Step 7   To specify how long the Watchdog feature should wait for a query response from the services that are supposed to be running on the sensor, enter that value in the Watchdog Timeout field.

Step 8   To specify how many times the Watchdog feature can attempt to restart a service that is determined to be inoperational, enter that value in the Number of Restarts field.

Step 9   To specify the level of the warning that should be issued when a service does not respond to the Watchdog query, select that value in the Daemon Down Alarm Level list box under Daemon Errors.

Step 10   To specify the level of the warning that should be issued when Watchdog cannot restart a service that is down, select that value in the Daemon Unstartable Alarm Level box.

Step 11   To discard your changes and restore the previous settings, click Reset.

Step 12   To save your changes, click Apply.

Specifying RDEP Properties

Version 4.x of IDS sensor software uses Remote Data Exchange Protocol (RDEP) instead of postoffice, which is used by earlier versions. RDEP, a subset of the HTTP/1.1 protocol, uses a client request/server response model. IDS MC does not use RDEP itself to communicate with the sensor. But it does allow the user to configure the RDEP properties on the sensor.

To specify RDEP properties, follow these steps:

Step 2   In the TOC, click the Object Selector handle.

Step 3   In the Object Selector, select the sensor or group for which you want to specify RDEP properties. RDEP is available only with sensors and groups using Version 4.x of IDS sensor software.

The Object Selector closes.

Step 4   In the TOC, select Communications > RDEP Properties.

The RDEP Properties page appears, and the Object bar displays the sensor or group that you selected in the Object Selector.

Step 5   To use the properties of the parent group, deselect the Override check box. To enter properties that are different from those of the parent group, leave the Override check box selected.

Step 6   In the Web Server Port field, enter the port that the sensor uses for RDEP. (The sensor is the RDEP server, and the IDS MC server is the RDEP client.) The default value is 443 and normally does not need to be changed.

Step 7   Enter the Server ID to identify the web server on the sensor. The default value is HTTP/1.1 and normally should not be changed.

Step 8   Select Enable TLS to enable secure exchange between the RDEP server and the RDEP client. TLS (Transaction Layer Security) provides cipher and secret key negotiation, session privacy and integrity, and server authentication. This check box is selected by default.

Step 9   To discard your changes and restore the default values, click Default.

Step 10   To save your changes, click Apply.

Step 11   To discard your changes and restore the previous settings, click Reset.

Step 12   When specifying RDEP properties for a group instead of a sensor, you also have the option of making your settings mandatory. To make your settings mandatory, select the Mandatory check box.

---

Note    By selecting the Mandatory check box, you ensure that your settings cannot be overridden by groups that are lower in the hierarchy of the Object Selector.

---

Adding Remote Hosts

This procedure applies to 3.x sensors. Unless you specify otherwise, the sensor will publish its audit event stream to the host on which you have installed IDS MC. You can identify additional network objects to which the sensor can publish its audit event stream. These additional network objects are referred to as remote hosts in IDS MC. A remote host can be any management client that is capable of processing the sensor's audit event stream, which uses postoffice-based network sessions.

A sensor normally generates a notification and audit event record when it detects an attack. Using this procedure, you can set the minimum level of events to be reported to you. Setting the minimum level of events to be reported to you is one way that you can tune your signatures. Tuning your signatures reduces the number of false positives.

To specify remote hosts for a 3.x sensor, follow these steps:

Step 2   In the TOC, select Communications > Remote Hosts.

The Remote Hosts page appears.

Step 3   To add a remote host, click Add.

The Remote Host page appears.

Step 4   Enter the IP address of the remote host in the IP Address field.

Step 5   To enable the sensor to send its audit event stream to the remote host whose IP address you just entered, select the Send Events check box.

Step 6   Specify the service in the Service list box. Four services, also called daemons, are available:

---

Note    More information on loggerd, eventd, smid, and managed is published in Cisco Secure Intrusion Detection System Internal Architecture, available at http://www.cisco.com/univercd/cc/td/doc/product/iaabu/csids/index.h tm

---

Step 7   Set the minimum event level to be sent to the remote host in the Minimum Event Level list box.

You can select one of the following values:

Step 8   Enter a comment (optional).

Step 9   Enter the host name.

Step 10   Enter the host ID, which typically is the last octet of the IP address of the remote host.

Step 11   Enter the organization name and organization ID.

---

Note    Use only lowercase letters to define organization names. Do not include spaces within the organization name. The host name and organization name are case-sensitive with respect to how postoffice processes audit events on the local host. Host names and organization names are not passed between different postoffice clients; only the Host ID and Org ID values are passed between different postoffice clients.

---

---

Note    Within a postoffice domain, each organization ID/host ID pair must be unique. That is, no sensor, sensor group, or remote host can have the same organization ID/host ID pair as another sensor, sensor group, or remote host.

---

Step 12   To modify the interval that IDS MC uses to verify that all other postoffice clients with which it communicates are still accessible and available over the network, enter that value in the Heartbeat Timeout field.

To check client availability, IDS MC sends a postoffice packet to each known client and waits for a response packet. If the IDS MC postoffice does not receive a response, it assumes that the route to that client is no longer available, and postoffice issues a route down audit event. The heartbeat value is a whole number that represents how many seconds the postoffice running on IDS MC waits between each check for client availability.

Step 13   To specify a postoffice port other than the default value, enter the new value in the Postoffice Port field.

Step 14   To discard your changes and close the Remote Host page, click Cancel.

Step 15   To save your changes and close the Remote Host page, click OK.

The Remote Host page appears, showing the remote host that you just added.

Step 16   After you have added a remote host, you can edit its properties or delete it.

Identifying Allowed Hosts

This procedure applies to 4.x sensors. Unless you specify otherwise, all hosts on your network are allowed to connect to a sensor to configure it and receive alarm data from it. However, you can identify allowed hosts; if you do, no other hosts will be allowed to connect to a sensor.

To identify allowed hosts for a 4.x sensor, follow these steps:

Step 2   In the TOC, select Communications > Allowed Hosts.

The Allowed Hosts page appears.

Step 3   To add a remote host, click Add.

The Enter Allowed Host page appears.

Step 4   Enter the IP address of the allowed host in the IP Address field.

Step 5   Enter the net mask of the allowed host in the Net Mask field.

Step 6   To discard your changes and close the Enter Allowed Host page, click Cancel.

Step 7   To save your changes and close the Enter Allowed Host page, click OK.

Using Additional Settings

This procedure applies to 3.x sensors. Configuration file settings that are not supported by IDS MC can be entered manually, as text input.

To enter additional settings for a 3.x sensor, follow these steps:

Step 2   In the TOC, select Advanced > Additional Settings.

The Additional Settings page appears.

Step 3   Select the sensor configuration file to which you want to add additional text in the File Name list box.

Step 4   In the Contents field, enter the text you want to add to the sensor configuration file that you selected.

Step 5   To discard your changes and restore the previous settings, click Reset.

Step 6   To save your changes, click Apply.

Step 7   To make your settings mandatory, select the Mandatory check box.

---

Note    By selecting the Mandatory check box, you ensure that your settings cannot be overridden by devices that are lower in the hierarchy of the Object Selector.

---

Defining Identification Properties for a Sensor

You can change the properties of a sensor that you have already added to your network. However, some properties cannot be changed.

To define identification properties for a sensor, follow these steps:

The Settings page and TOC appear; 4.x sensors appear as shown here.

Step 2   In the TOC, click the Object Selector handle.

Step 3   In the Object Selector, select the sensor for which you want to define identification properties.

The Object Selector closes.

Step 4   In the TOC, select Identification.

The Identification page appears, and the Object bar displays the sensor you selected in the Object Selector. The properties of the sensor also appear. The Identification page appears as shown here for 3.x sensors; 4.x versions do not have fields for Root Password or Postoffice Settings.

Step 5   To determine which version of sensor software is installed on the sensor, click Query Sensor; this action will update the information displayed by the Identification page if necessary. If you then click Apply, and the queried version is different from the current version, the configuration will be upgraded to the new version. If you click Cancel, no changes will be applied.

Step 6   On the Identification page, make any desired changes to the values in the IP Address, NAT Address, Sensor Name, and Comment fields. You can change the group that the sensor belongs to by using the Group list box. You cannot change the value in the Version field on this page.

Step 7   On the SSH Settings page, you can choose to use a password or to use existing SSH keys for Secure Shell (SSH) communications between your host and the sensor.

Step 8   In the Postoffice Settings content area, enter the postoffice settings of the sensor: Host ID (typically the last octet of the IP address of the sensor), Org Name (all lowercase letters and no spaces), and Org ID (default value 100).

Within a postoffice domain, each Org ID/Host ID pair must be unique. That is, no sensor or sensor group can have the same Org ID/Host ID pair as another sensor or sensor group.

---

Note    You should use only lowercase letters to define organization names. Additionally, do not include spaces within the organization name. The host name and organization name are case sensitive with respect to how postoffice processes audit events on the local host. Host names and organization names are not passed between different postoffice clients, only the Host ID and Org ID values.

---

Step 9   To discard your changes and restore the previous settings, click Reset and skip the rest of this procedure.

Step 10   To save your changes, click Apply.

Caution   Your changes will have no effect on your sensor configuration until you commit them to the database.

Step 11   To see the identification properties you just changed, select Configuration > Pending.

The Pending page appears, showing the device whose identification properties you just changed:

Step 12   To delete a pending configuration without committing it to the database, select the check box for the configuration that you want to delete and click Delete.

Step 13   To commit a pending configuration to the database, select the check box for the configuration that you want to commit to the database and click Save.

Configuring Sensing Interfaces

If you are using IDS 4.1, you can configure more than one sensing interface on a sensor.

To configure sensing interfaces, follow these steps:

Step 2   Click the Object Selector handle to open the Object Selector.

Step 3   In the Object Selector, select the sensor for which you want to configure sensing interfaces. The sensor must be using IDS 4.1.

The Object Selector closes, and the Object bar displays the sensor you selected in the Object Selector.

Step 4   In the TOC, select Sensing Interfaces.

The Sensing Interfaces page appears.

The Sensing Interfaces page displays sensors in two different ways:

Step 5   To detect the sensing interfaces for a sensor whose configuration consists of default settings, click Query Interfaces.

---

Note    You have to click Query Interfaces before you can deploy a sensor whose configuration consists of default settings.

---

Step 6   To change the state of a particular interface, click Enable or Disable.

Learn More About Signatures

Network intrusions can be defined as attacks or other misuses of network resources. Cisco IDS Sensors use a signature-based technology to detect network intrusions. A signature specifies the types of network intrusions that you want the sensor to detect and report. A signature can be thought of as a set of rules that your sensor uses to detect typical intrusive activity, such as denial of service (DoS) attacks. As sensors scan network packets, they use signatures to detect known attacks and respond with actions that you define.

On a basic level, signature-based intrusion detection technology can be compared to virus-checking programs. Cisco Systems produces a list of signatures that the sensor compares with network activity. When a match is found, the sensor takes some action, such as logging the event or sending an alarm to the Event Viewer provided with Monitoring Center for Security (Security Monitor). Sensors allow users to modify existing signatures and define new ones. However, most customers depend on Cisco Systems to provide the latest signatures to keep the sensor up to date and thus able to detect the latest attacks.

Tip To be informed about signature updates by e-mail, you can subscribe to the Cisco IDS Active Update Notification. The subscription form is available at http://www.cisco.com/warp/public/779/largeent/it/ids_news/subscribe.html .

Signature-based intrusion detection can produce false positives, because certain normal network activity can be construed as malicious. For example, some network applications or operating systems may send out numerous ICMP messages, which a signature-based detection system might interpret as an attempt by an attacker to map out a network segment. You can minimize false positives by tuning your sensors.

Sensors can be configured to take one or more of three actions in addition to generating alarms:

Sensors operating with IDS 3.x software can block hosts and networks. Sensors operating with IDS 4.x software can block hosts, networks, and connections.

Signatures can be categorized and grouped in several different ways, some of which are the following:

3.x sensors and 4.x sensors have the same categories: Signature ID, L2/L3/L4 Protocol, Service, Attack, and OS.

Categories for 3.x sensors and 4.x sensors are different. For example, the Signature ID category for 3.x sensors has groupings of General, TCP, UDP, String Match, ACL Violation, and Custom; the same category for 4.x sensors has groupings of General and Custom. (For 3.x sensors, General means embedded; embedded signatures are part of the sensor software. For 4.x sensors, General means all signatures other than those that you create.)

Consider an example that illustrates the categories and groupings of signatures:

1. For a 4.x sensor, select the L2/L3/L4 Protocol category. The resulting page shows the groupings in this category.

2. To continue this example, select the TCP Anomalies grouping. The resulting page shows the signatures in this grouping.

Configuring and Tuning Signatures

You can configure the following properties of signatures:

Some signatures can be tuned. Tuning signature parameters should not be confused with tuning sensor configurations.

Some signatures have special characteristics:

The information for embedded signatures, such as their names and IDs, appears as it does in the Cisco Network Security Database (NSDB). To view the NSDB from the Signatures page, click a signature ID, such as 2000, in the ID column. The entries in the ID column are hyperlinks to the NSDB.

Some signatures have special requirements. For example, to configure a sensor to detect ACL violation signatures, you must first configure one or more Cisco IOS routers to log ACL violations. Then, you must configure those routers to communicate with the sensor. Finally, you must configure the sensor to accept syslog traffic from those routers.

To configure a signature, follow these steps:

The Object Selector closes.

The Signatures page appears, and the Object bar displays the sensor you selected in the Object Selector.

Notice that the Group Signatures list box displays the Signature ID category. You can also use the Group Signatures list box to display the L2/L3/L4 Protocol Signatures, Service Signatures, Attack Signatures, and OS Signatures categories. This is true for both 3.x sensors and 4.x sensors.

For 3.x sensors, the Signature ID category contains the groupings General, TCP Connection, UDP Connection, String Match, ACL Violation, and Custom. For 4.x sensors, the Signature ID category contains the groupings General and Custom.

For 3.x sensors, General means embedded; embedded signatures are part of the sensor software. For 4.x sensors, General means all signatures other than those that you create.

Tip You can filter the display of the signature table. Using the Filter Source list, select any of the displayed columns as the filter source. Next, enter a value in the adjacent field and click Filter. For example, select Severity in the list box and enter the value High in the adjacent field. When you click Filter, the signature table displays all signatures that have a high severity. Clearing the search string or entering the wildcard character ("*") cancels filtering. Note that this filter is not the same as Filters in the Configuration > Settings TOC.

Step 2   Enable or disable all signatures in a particular grouping, if desired:

Step 3   Configure one or more signatures in a particular grouping, if desired:

The Signature(s) in Group page appears, and the Object bar displays the group name and sensor name. Notice that the Signature Group list displays General in this example.

TimeSaver You can select more than one check box, but you cannot configure as many properties if you do.

Tip You can select all signatures by selecting the check box in the heading of the signature table. Also, you can sort a column by clicking the title of the column.

The Edit Signature(s) page appears, showing the name of the signature that you selected. Depending upon the category and grouping of signature that you are configuring, the Edit Signature(s) page will have different fields.

---

Note    Some actions are not available to certain versions of sensor software.

---

Caution   The regular expression you enter here is not compiled by a regular expression compiler. Therefore, you must be careful to enter a valid regular expression; it is not validated here.

The Signature(s) in Group page appears, showing the changes that you just made.

Step 4   Tune a particular signature, if desired:

---

Note    Not all signatures can be tuned. If a particular signature does not have an entry in the Engines column, that signature cannot be tuned. Also, signatures that use the engine named Other cannot be tuned.

---

The Tune Signature page appears, showing the name of the signature that you selected. On this page, for the engine that you selected, you can edit parameters or set them to their default values.

Clicking Default retrieves the built-in micro-engine parameter information for the signature that you are tuning. You can then adjust the default values if needed. Note that only deviations from the built-in micro-engine parameter information are saved by IDS MC, because only such deviations need to be saved.

More information on signature engine parameters is in Cisco Intrusion Detection System Signature Engines Version 3.0: http://www.cisco.com/univercd/cc/td/doc/product/iaabu/csids/csids6/index.h tm.

The Signature(s) in Group page appears.

Step 5   Add a signature, if desired:

---

Note    Not all categories and groupings of signatures can have signatures added to them. As examples, you can add custom signatures, string-matching signatures, UDP connection signatures, and TCP connection signatures.

---

The Signature(s) in Group page appears, and the Object bar displays the group name and sensor name. Notice that the Signature Group list displays Custom in this example.

The Tune Signature page appears.

Defining Filters for a Sensor

Filters can be used to reduce the number of false positives reported by your sensors, so they are considered a method of tuning your sensors.

Filtering an alarm means that the sensor will analyze the data stream but will not generate an alarm. Filtering all alarms from a particular signature is not the same thing as disabling that signature, which results in no analysis of the data stream for that signature.

Note   Filters for a sensor in IDS MC should not be confused with event filters that are part of an event rule in Security Monitor.

A filter is defined by specifying the signature, the source address, and the destination address and whether it is an inclusive or exclusive filter. You cannot define any particular part of the filter (such as the source address) as inclusive or exclusive; you have to define the entire filter as inclusive or exclusive. Also, if you define more than one filter, IDS MC will apply them in the order in which you defined them.

An example of how filters work can be helpful in seeing how to define them. In this example, you want to exclude all alarms that originate from Network 10.10.10.0/24 because that network is using some applications that generate large numbers of false positives. However, there are two signatures that are important to you, so you don't want them to be excluded: They are 994 (Traffic Flow Started) and 995 (Traffic Flow Stopped).

1. Begin by defining an exclusive filter. Specify the source address as 10.10.10.0, which is the network that is generating large numbers of false positives. Specify all signatures so that no alarms are sent to Security Monitor.

2. Next, define an inclusive filter. Specify the same source address, which is Network 10.10.10.0. But specify Signatures 994 and 995, which are the ones that you want to include because they are important to you.

By using these two filters, and in this order, you can filter out a large number of alarms that would be false positives. But you can selectively let some of them (Signatures 994 and 995) pass through. This is possible because you defined the exclusive filter first and the inclusive filter next. Note that if you had defined the inclusive filter first, then the exclusive filter would have filtered out all the alarms from Network 10.10.10.0. This is because filters are evaluated in order.

This procedure defines filters for a sensor as described in this example. The example assumes that you have added Device11 in GroupW to your network. Device11 is a 4.x appliance sensor in this example.

To define a filter for a sensor as described in the example, follow these steps:

Step 2   In the TOC, click the Object Selector handle.

Step 3   In the Object Selector, select Device11, the sensor for which you want to define a filter in this example. Device11 is a 4.x sensor.

The Object Selector closes.

Step 4   In the TOC, select Filters.

The Filters page appears. This page shows that no filters have been defined for Device11, the sensor that you selected.

Step 5   To begin defining the exclusive filter in this example, click Add.

The Enter Filter page appears.

Step 6   Enter a name for the filter: Use "First Filter--Exclusive"

Step 7   Select the action of Exclude.

The Enter Filter page now appears as shown here.

Step 8   Click the Signatures link.

The Enter Signatures page appears.

Step 9   On the Enter Signatures page, add All Signatures from the Available Signatures field to the Selected Signatures field.

The Enter Signatures page now appears as shown here.

Step 10   Click OK.

The Enter Filter page appears again.

Step 11   Click the Source Addresses link.

The Filter Source Addresses page appears.

Step 12   Click Add.

The Enter Filter Address page appears.

Step 13   Select the radio button corresponding to Network and enter 10.10.10.0, the network address being used in this example, along with its network mask of 255.255.255.0. The Enter Filter Address page now appears as shown here.

Step 14   Click OK.

Step 15   The Filter Source Addresses page appears, showing the addition of Network 10.10.10.0 with a subnet mask of 255.25.255.0.

Step 16   Click OK.

The Enter Filter page appears again.

Step 17   Click the Destination Addresses link.

The Filter Destination Addresses page appears.

Step 18   Click Add.

The Enter Filter Address page appears.

Step 19   Select the radio button corresponding to an address of Any and click OK.

The Filter Destination Addresses page appears, showing the addition of Any.

Step 20   Click OK.

The Enter Filter page appears again.

Step 21   Click OK.

The Filters page now appears as shown here. You have just finished defining the first filter in this example.

Step 22   To begin defining the inclusive filter in this example, click Add.

Step 23   Add a filter with the name "Second Filter--Inclusive" with an action of Include.

Step 24   Continue with this example by adding Signature 994 and Signature 995.

Step 25   Add the same source address and destination address that were used for the first filter, and then display the Filters page again. It should now appear as shown here.

The filter named First Filter--Exclusive will be applied first. It will exclude all alarms from Network 10.10.10.0. The filter named Second Filter--Inclusive will be applied next. It will allow alarms from Network 10.10.10.0 if they result from Signatures 994 or 995. Signatures 994 and 995 will not be disabled.

Specifying IP Fragment and TCP Session Reassembly Settings for a Sensor

The goal of defining these reassembly settings is to ensure that the sensor does not allocate all of its resources to datagrams that cannot be completely reconstructed, either because the sensor missed some frame transmissions or because an attack is generating random fragmented datagrams.

These settings ensure that valuable system resources are not reserved for sessions that are no longer active. These settings apply to sensors globally, not to individual settings such as signatures.

To specify IP fragment reassembly options and TCP session reassembly options, follow these steps:

Step 2   In the TOC, click the Object Selector handle.

Step 3   In the Object Selector, select the sensor for which you want to specify reassembly options.

The Object Selector closes.

Step 4   In the TOC, select Reassembly Options.

The Reassembly Options page appears.

When configuring an IDSM or a 4.x sensor appliance, you have the option of TCP strict reassembly. The 3.x sensor appliance does not have that option.

When configuring a sensor appliance (3.x or 4.x), you have the option of specifying Maximum Total Fragments. The IDS module does not have that option.

Step 5   When configuring a 4.x sensor appliance, specify the operating system in the IP Reassemble Mode list box.

Step 6   To specify that you want the sensor to reassemble IP datagrams, select the Reassemble Fragments check box under IP Fragment Reassembly. Reassembling fragments is done by default by all sensors, both appliances and modules.

Step 7   To specify the maximum number of partial datagrams that the sensor can attempt to reconstruct at one time, enter that value in the Maximum Partial Datagrams field. Maximum Partial Datagrams is not available for 4.x sensor appliances.

Step 8   To specify the maximum number of fragments that can be accepted into a single datagram, enter that value in the Maximum Fragments Per Datagram field. Maximum Fragments Per Datagram is not available for 4.x sensors.

Step 9   To specify the maximum total fragments, enter that value in the Maximum Total Fragments field. Maximum Total Fragments is available for sensor appliances but not for IDS modules.

Step 10   To specify the maximum number of seconds that can elapse before the sensor stops keeping track of a particular exchange for which it is trying to reassemble a datagram, enter that value in the Fragmented Datagram Timeout field.

Step 11   To specify that the sensor track only sessions for which the three-way handshake is completed, select the TCP Three Way Handshake check box.

Step 12   To specify how strict the reassembly requirements for this sensor should be when it attempts to reassemble the entire TCP session, select that type from the TCP Strict Reassembly list box. TCP Strict Reassembly is available for IDS modules but not for sensor appliances.

Step 13   To specify the number of seconds that can elapse before the sensor frees the resources allocated to a fully established TCP session, enter that value in the TCP Open Establish Timeout field.

Step 14   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, enter that value in the TCP Embryonic Timeout field.

Step 15   To accept your changes and close the Reassembly Options page, click Apply.

Tuning Your Sensor Configurations

After configuring your sensors, you must tune them to achieve optimal performance on your network, particularly to minimize false positives and false negatives.

Note   Tuning sensor configurations should not be confused with tuning parameters for individual signatures.

To learn more, see Task List for Tuning Sensor Configurations.

Copying Configuration File Settings

You can copy configuration file settings from one sensor or sensor group to another sensor or sensor group.

To copy configuration file settings, follow these steps:

The first page of the Copy Wizard appears.

Step 2   Start the Copy Wizard. The Copy Wizard uses three steps to copy configuration file settings:

Reviewing Pending Configuration File Settings

You can review pending configuration file settings before committing them to the database. You also can delete settings if necessary.

To review pending configuration file settings, follow these steps:

The Pending page appears.

Step 2   Select the check box associated with a sensor.

Step 3   Click Save to save the configuration; click Delete to delete it.

The Pending configuration page appears, no longer showing the pending configuration that you just saved or deleted.

Unlocking Pending Configuration Settings

A user who has pending configuration settings has a lock on those settings. No other users can commit those settings to the database or delete them. If a user has configuration settings that are pending, and the account of that user is deleted, you can use this procedure to take ownership of the pending settings. This procedure is also referred to as a "take lock" procedure because it can be thought of as "taking ownership" of or "unlocking" the settings.

This procedure illustrates the situation in which the account for doc-intern has been deleted, but a configuration is pending for the sensor named doc-intern-sensor.

In this example, you are logged in as "admin" and you will take ownership of the pending configuration so that you can save it or delete it.

To unlock the pending configuration in this example, follow these steps:

Step 2   In the TOC, select View Current Locks.

The View Current Locks page appears. Note that the owner of the pending configuration called doc-intern-sensor is doc-intern.

Step 3   Recall that in this example, you are logged in as "admin". Click Take Lock.

The View Current Locks page appears again. Now, note that you, logged in as admin, are the owner of the pending configuration.

Reviewing Historical Configuration File Settings

You can review historical configuration file settings for a sensor.

To review historical configuration file settings, follow these steps:

Step 2   In the TOC, click the Object Selector handle.

Step 3   In the Object Selector, select the sensor for which you want to review historical configuration file settings.

The Object Selector closes.

Step 4   Select Configuration > History.

The History page appears, and the Object bar displays the sensor you selected in the Object Selector.

Step 5   To view a configuration file, select the corresponding check box and click View.

Step 6   To delete a configuration file, select the corresponding check box and click Delete.

Updating IDS Sensor Software Versions and Signature Release Levels

Cisco Systems periodically releases updates of sensor software versions and signature release levels for its IDS Sensors (both sensor appliances and IDS modules). Two procedures are available:

Updating IDS Sensor Software from 3.x to 4.x

To update a sensor from sensor software 3.x to sensor software 4.x, you must have physical access to that sensor so that you can re-image it.

Note   This procedure applies to Version 1.1 (and later) of the IDS MC.

To update your sensor software from 3.x to 4.x, follow these steps:

---

Note    Some sensors cannot be re-imaged from 3.x to 4.x. Specifically, NRS platforms (the older Netranger sensors) cannot be re-imaged from 3.x to 4.x.

---

Select Configuration > Updates.

Step 2   From the TOC, select Update Sensor Version.

The Update Sensor Version page appears.

Step 3   Select the sensor that you want to update from a 3.x version to a 4.x version.

Step 4   Click Update.

The Update Status page appears.

Updating IDS Sensor Software Other than from 3.x to 4.x

Cisco Systems periodically releases updates of sensor software versions and signature release levels for its IDS Sensors (both sensor appliances and IDS modules). We recommend that you check for and perform regular updates of sensor software versions and signature release levels on sensors that you have deployed. This recommendation also applies to the server(s) where you have installed the IDS MC and Security Monitor.

Note   This procedure applies to Version 1.1 (and later) of the IDS MC and to Version 1.1 (and later) of Security Monitor. When using the IDS MC, you can use this procedure to update the server as well as any sensors that you select. When using Security Monitor, you can use this procedure to update the server but not sensors; sensors are not (and cannot be) updated through Security Monitor.

Note   We strongly recommend that you download and apply all update files, in order and without exception, as they become available. To be informed of the latest update files by e-mail, you can subscribe to the Cisco IDS Active Update Notification. The subscription form is available at http://www.cisco.com/warp/public/779/largeent/it/ids_news/subscribe.html .

Note   We strongly discourage updating sensor software versions and signature release levels in a direct session to an individual sensor if you manage that sensor with the IDS MC. You should instead use this procedure of performing updates through the IDS MC. If you have changed the configuration of a sensor, or updated a sensor, outside of the IDS MC, we recommend that you delete that sensor from your configuration and then add it to your configuration.

Note   Updating sensor software in a direct session to an individual sensor instead of by performing an update through the IDS MC will result in the rejection of the SSH fingerprint for that sensor. This is because the IDS MC is not involved in a session to an individual sensor.

To use this procedure effectively, you must understand the numbering system used for sensor software versions and signature release levels. For example:

You should also understand the update files:

Service pack update files can move major and minor version numbers. For instance, if you apply the first 3.1 service pack update to the last 3.0 version of a sensor, you will move the version number from 3.0 to 3.1.

Signature update files can be applied only to sensors operating with the same version number, or with the same version number plus service pack designation. For example, the signature update file IDSk9-sig-3.1-3-34.zip can be applied to a sensor operating with version 3.1(3)S32 but not to a sensor operating with version 3.1(2)S22 or 3.1(4)S34 or 3.0(3)S22.

Signature update files can be applied only to sensors that are not already operating at that file's signature revision level. For example, the signature update file IDSk9-sig-3.1-3-34.zip cannot be applied to a sensor operating with 3.1(3)S34. The reason is that this sensor is already operating at the same signature version level (S34) that the update file provides.

To use this procedure, you must have access to the server:

To update a sensor from sensor software 3.x to sensor software 4.x, you must have physical access to that sensor so that you can re-image it.

Note   After updating sensor software versions and signature release levels, you cannot revert to the previous version or level using the IDS MC.

To update your sensor software version and signature release level, follow these steps:

The Sensor page appears.

The Select Group page appears.

The Enter Sensor Information page appears.