Release Notes for Management Center for IPS Sensors 2.1 and Monitoring Center for Security 2.1 on Windows and Solaris

These release notes are for use with Management Center for IPS Sensors 2.1 (IPS MC) and Monitoring Center for Security 2.1 (Security Monitor) on Windows 2000 or Solaris. The supported Windows version is Windows 2000, Service Pack 4; the supported Solaris version is 2.8.

Important Notes

The following information is important to you as a user of IPS MC 2.1 or Security Monitor 2.1:

•

Risk Rating is not supported by 4.x sensors: (1) If you select a Risk Rating (any value), you will not receive any 4.x alarms in the IDS Alarms reports in Security Monitor. (2) If you use a Risk Rating (any value) in a 4.x event rule in Security Monitor, the rule will not be triggered.

•

If you are using CSA 4.5 VMS with IPS MC 2.1 or Security Monitor 2.1, you need to set your CSA security level to "Off." Advanced users can suspend Rule 179, "CiscoWorks interpreters and command shells, write CiscoWorks script and batch files."

•

Cisco Host Intrusion Detection System is no longer supported. This functionality is replaced by Cisco Security Agent.

•

Use static IP addresses for the host or hosts where IPS MC and Security Monitor are installed, because DHCP is not supported for IPS MC or Security Monitor.

•

Do not use download accelerator programs such as DAP, because they are not supported.

•

You cannot use SSH keys in IPS MC if you want to use a sensor as a master blocking sensor.

•

If the idsmdc.log file is growing too large with unwanted data, you can reset its size to 0 (zero) by backing up the database. Then, you can delete the backup file. (The idsmdc.log file is in the same directory as idsmdc.db, the directory that was specified for the database at installation.) Also, you can use IdsDbCompact to reduce the size of the database.

•

We strongly recommend that you avoid connecting to the database directly, because doing so can cause performance reductions and unexpected system behavior.

•

Event Viewer in Security Monitor 2.0 and later supports blocking when you are using sensors that are operating with IPS 4.x software.

•

If you do not specify the -f"filename" option when using the IdsImportIdiom command line utility, the program reads "standard input" for data. As a result, the program waits forever for input; it will not time out or return, and you must abort it. Although this is not a defect, you need to be aware of this behavior to avoid misunderstanding when you use this command line utility.

•

You can forward syslog messages on the basis of IP address/hostname and port. The IP address/hostname is a required field whose default value is localhost. If a DNS name is entered, it must resolve to an IP address at data entry time. If at any time during syslog forwarding, a DNS name cannot be resolved to an IP address, an appropriate error message is logged to the Audit Log.

•

When firewall reports are generated, performance may be degraded as a result of configuring both WINS and DNS on Windows 2000 servers, because it may take a long time to resolve IP addresses to a hostname when the IP address does not exist in DNS or WINS. Security Monitor automatically disables any further DNS lookup activity for that particular report instance if the cumulative time for doing lookup in a particular report exceeds 10 minutes. Another way to improve performance is to reconfigure your report generation filters to select a smaller subset of syslog messages to be included in the report.

•

When firewall reports are generated, no correlation is done for sessions that involve more than one connection (such as FTP and RTSP). Each connection in a session appears independently in the report. If the port numbers used by connections do not map to standard port numbers, they are categorized as Unknown TCP or UDP service.

•

If an online help page displays blank in your browser view, refresh the browser.

•

Certain details are important when backing up the database and then restoring it in IPS MC or Security Monitor:

–

Also on Windows, do not use a path that is longer than 67 characters, including the drive letter and backslash characters.

–

On Windows and Solaris, the available partition space to backup must be no less than the size of the existing database. For a restore, it is suggested that the partition space be no less than double the size of the database being restored.

–

On Solaris, the file/directory owner, group, and/or permissions must be the same as the default values. If you back up or restore from a directory other than the default, you must make sure that the file owner, group, and permissions match the defaults.

•

Any scheduled report in IPS MC and Security Monitor existing at the time of a backup is rerun immediately following the restore of that backup because the job scheduler considers them overdue. As an example, consider the following actions by a user: The user had four reports. He did a backup, scheduled a daily report, waited two days, and did a restore. He then had a total of five reports--the four originals and one that ran immediately following the restore. This is expected behavior, not a defect, but you should be aware of it to avoid confusion.

•

The initial configuration of IOS IPS signatures is different in IDS MC 2.0.2 and later than it was in earlier versions. In IDS MC 2.0.2 and later, all IOS IPS signatures are unselected by default. As a result, if you upgrade from IDS MC 2.0 or IDS MC 2.0.1 to IDS MC 2.0.2 or later, any IOS IPS signatures that you left at their default values will be unselected in your new IDS MC or IPS MC installation. However, your configuration and tuning information will be preserved when upgrading if you changed any of the default settings.

New and Changed Features

New Features in IPS MC 2.1

•

IPS 5.0 support. The major changes of Cisco IPS (Cisco Intrusion Prevention System) version 5.0 from the previous versions are:

–

Event action configuration (action types include Deny Packet, Deny Flow, Deny Attacker).

•

Allowed host configuration. IPS MC 2.1 enables you to configure which hosts on your network are allowed to connect to a sensor to configure it and to receive alarms from it.

•

SNMP Traps Destination. IPS MC 2.1 enables you to specify or edit the list of interested parties to whom the traps should be sent.

•

Reassembly. IPS MC 2.1 enables you to specify the IP and TCP reassembly parameters for 5.x sensors.

•

IP Log. IPS MC 2.1 enables you to specify IP log parameters that include time, number of packets, and maximum size.

•

Sensing interface and inline interface configuration and a choice to enable and disable interface/interfaces. General interface properties include:

•

A new Interface Pairs screen that displays the existing logical interface pairs in the sensor and enables you to create logical inline pair(s) and to edit or delete, as allowed, the existing pair(s).

•

Traffic flow notification configuration. This is provision of configuration to the sensor to monitor the flow of packets across an interface and to send notification if that flow changes during a specified interval. The configurable parameters are:

•

Under interface configuration. IPS MC 2.1 provides configuration of bypass setting that enables you to set the bypass mode. The bypass feature can be used both as a diagnostic tool and as failover protection mechanism. There are three modes you can choose from:

•

Provision to assign physical interfaces and logical interfaces to an analysis engine. The analysis engine monitors traffic that flows through the specified interfaces or interface pairs.

•

Provision to edit (or tune) existing signatures (alarm firing conditions) and to add new custom signatures.

•

Provision to define signature variables that can be used within multiple signatures.

–

One for most frequently configurable parameters, such as, severity, actions, and enable/disable.

•

An expanded signature license management capability and automated IPS device signature subscription license key updating.

•

Dynamic IOS IPS project phase II provided support on the following three engines:

•

Provision to override sensor's configuration by providing a configurable force deployment flag at the global level.

New and Changed Features in Security Monitor 2.1

•

Sensor support. Security Monitor 2.1 supports both IPS 4.x and IPS 5.0(1) software.

•

New database schema. Database tables employ a new schema. All configuration and event data will be retained with the exception of data from monitored IPS sensors (pre-version 4) that communicate using the PostOffice protocol. These devices will be deleted during upgrade; however, the events will remain in the database. (A new utility, IDS Convert Archive 2.0 to 2.1, enables you to convert the archive log files saved in 2.0 to 2.1.)

•

NSDB support. Security Monitor 2.1 provides access to the NSDB for IPS alerts. You must be able to specify the location of the server that is providing the NSDB.

•

E-mail. You can configure username and password for Security Monitor 2.1 to send e-mail notifications.

•

Protocol enhancement. Security Monitor 2.1 provides support for accepting events from:

–

5.0 IPS devices and Remote Security Monitor Server devices via the SDEE protocol

•

Active source denies. Security Monitor 2.1 provides a new active source denies feature for reporting the current status of the new source (attacker) deny actions from IPS 5.0

•

Active host/connection block actions reporting. Security Monitor 2.1 provides a new feature for reporting host/connection block actions from IPS 5.0. This displays the current active host and connection blocks for the selected sensor.

•

Network Block Status and Removal. This enables you to individually select and remove a network block from the sensor. The network blocks in the Network Blocks report are now displayed in a multiple selection table.

•

New action type support. Security Monitor 2.1 supports the new action types that are supported in IPS 5. These include:

•

Risk Rating. Security Monitor 2.1 displays the Risk Rating for each IPS 5.0 event as an additional column in Event Viewer. The system can filter events based on the Risk Rating value and provide a Risk Rating filter for IPS-related report templates. Also, Security Monitor 2.1 enhances the event rule functionality to enable the use of the event Risk Rating in the rule definition.

Security Monitor 2.1 contains the following changed feature, which was introduced in version 2.0.1: automatic archive of historical audit events. On upgrade from any release before 2.0, the audit events are automatically archived rather than upgraded to the new data format. You can upgrade your data at any time; however, to ensure upgrade integrity, you cannot upgrade the data while the system is being upgraded. All configuration data is upgraded.

Product Documentation

Note We sometimes update the printed and electronic documentation after original publication. Therefore, you should also review the documentation on Cisco.com for any updates.

Related Documentation

Table 1 Product Documentation
Document Title	Available Formats
Release Notes for Management Center for IPS Sensors 2.1 and Monitoring Center for Security 2.1 on Windows and Solaris	•On Cisco.com at this URL: http://www.cisco.com/univercd/cc/td/doc/product/rtrmgmt/cw2000/mgt_ids/idsmc21/index.htm
Using Management Center for IPS Sensors 2.1	•On Cisco.com at this URL: http://www.cisco.com/univercd/cc/td/doc/product/rtrmgmt/cw2000/mgt_ids/idsmc21/index.htm
Using Monitoring Center for Security 2.1	•On Cisco.com at this URL: http://www.cisco.com/univercd/cc/td/doc/product/rtrmgmt/cw2000/mon_sec/secmon21/index.htm
Supported Devices and Software Versions for Management Center for IPS Sensors 2.1	•On Cisco.com at this URL: http://www.cisco.com/univercd/cc/td/doc/product/rtrmgmt/cw2000/mgt_ids/idsmc21/index.htm
Supported Devices and Software Versions for Monitoring Center for Security 2.1	•On Cisco.com at this URL: http://www.cisco.com/univercd/cc/td/doc/product/rtrmgmt/cw2000/mon_sec/secmon21/index.htm
Context-sensitive online help	•Select an option from the navigation tree, then click Help. •Click the Help button in the dialog box.

Note We sometimes update the printed and electronic documentation after original publication. Therefore, you should also review the documentation on Cisco.com for any updates.

Additional Information Online

Installation Notes

System Requirements

IPS MC and Security Monitor are components of the VPN/Security Management Solution (VMS). CiscoWorks Common Services 2.3 is required for IPS MC and Security Monitor to work. CiscoWorks Common Services 2.3 provides the CiscoWorks Server base components and software developed to support IPS MC and Security Monitor, including the necessary software libraries and packages.

Table 2 Related Documentation
Document Title	Available Formats
Documentation Guide for the VPN/Security Management Solution 2.3	This document describes the basic tasks involved in preparing and configuring network devices using management centers. •On Cisco.com at this URL: http://www.cisco.com/univercd/cc/td/doc/product/rtrmgmt/cw2000/cw2000_b/vpnman/vms_2_3/
Installing the VPN/Security Management Solution (VMS) 2.3 on Windows	This document describes installing and setting up VMS 2.3 on Windows. •On Cisco.com at this URL: http://www.cisco.com/univercd/cc/td/doc/product/rtrmgmt/cw2000/cw2000_b/vpnman/vms_2_3/
Installing the VPN/Security Management Solution (VMS) 2.3 on Solaris	This document describes installing and setting up VMS 2.3 on Solaris. •On Cisco.com at this URL: http://www.cisco.com/univercd/cc/td/doc/product/rtrmgmt/cw2000/cw2000_b/vpnman/vms_2_3/

You can install IPS MC and Security Monitor on Windows 2000 and Solaris. Table 3 shows VMS bundle server requirements for Windows 2000 systems.

Note IPS MC and Security Monitor have been tested with the listed platforms, browsers, and service packs. If you install IPS MC and Security Monitor concurrently with software other than what is listed, IPS MC and Security Monitor might not function properly.

Additionally, you should not install any VMS products on a Windows server that is running any of the following services:

Downloading the Applications and Installing VMS

Table 3 Server Requirements for Windows
System Component	Requirement
Hardware	•IBM PC-compatible with a 1 GHz or faster Pentium processor. •Color monitor with at least 800 x 600 resolution and a video card capable of 16-bit colors. •CD-ROM drive. •100BaseT or faster (100 Mbps or faster) network connection. •Single and multiple CPU computers.
Operating System	Windows 2000 Professional, Server, or Advanced Server with Service Pack 4 and Terminal Services turned off. Note IDS MC and Security Monitor support only the U.S. English versions of these operating systems. In addition, only the U.S. English Regional Options setting is supported.
File System	NTFS
Memory	1 GB, minimum
Virtual Memory	2 GB, minimum
Hard Drive Space	9 GB of free hard drive space, minimum Note The actual amount of hard drive space required depends upon the number of CiscoWorks Common Services client applications you are installing and the number of devices you are managing with the client applications.

It is not possible to directly download IPS MC 2.1 and Security Monitor 2.1 application files for Windows or Solaris from Cisco.com. Obtaining the application files has been made part of installing VMS 2.3. The four basic steps you must perform are as follows:

Step 1

Proceed to the VMS update page (http://www.cisco.com/cgi-bin/tablebuild.pl/vms) and download the appropriate VMS 2.3 bundle installer (Windows or Solaris).

Step 2

Install VMS 2.3 as described in Installing the VPN/Security Management Solution (VMS) 2.3 on Windows or Installing the VPN/Security Management Solution (VMS) 2.3 on Solaris.

Installing the Applications

You can install IPS MC 2.1 and Security Monitor 2.1 for Windows or Solaris on a new system (a "clean installation"), or you can upgrade from 2.0 or later using one of the following upgrade and restore scenarios:

Note Upgrading from a version earlier than 2.0 (such as 1.2.3) requires two steps, because you must first upgrade to 2.0.1 or 2.0.2 (upgrading to 2.0 is no longer available).

To upgrade to 2.0.2, see "Installing the Application" in Readme Document for Management Center for IDS Sensors 2.0.2 and Monitoring Center for Security 2.0.2 for Windows and Solaris," which is available at http://www.cisco.com/cgi-bin/tablebuild.pl/mgmt-ctr-ids-app.

If you are upgrading from 2.0 or later or if you are performing a clean installation on Windows, run setup.exe, following the screen prompts as you are asked for directory path information and passwords.

If you are upgrading from 2.0 or later or if you are performing a clean installation on Solaris, run setup.sh, following the screen prompts as you are asked for directory path information and passwords.

Note This post-upgrade installation note applies when you are upgrading IDS MC 2.0 to IPS MC 2.1 and when you are upgrading Security Monitor 2.0 to Security Monitor 2.1. This note does not apply if you are performing a new installation rather than an upgrade installation. During upgrade, your sensors may continue to detect events, but they cannot send them to your server. Because the upgrade can take up to two hours, your sensors may detect many events during that time, and subsequently flood your server after startup. In turn, your system may throttle and possibly even pause the receiver on startup following the upgrade, while all unretrieved events are forwarded from the sensors. You can be assured that events will not be lost during upgrade, except possibly under extreme circumstances.

Note If you upgrade from IPS MC 2.0.1 or Security Monitor 2.0.1 to IPS MC 2.1 or Security Monitor 2.1, a dialog box tells you that the database is being upgraded from 2.0 to 2.1. This is a known defect (CSCsa85335); the dialog box should tell you that the database is being upgraded from 2.0.1 to 2.1. This defect also applies to an upgrade from 2.0.2 to 2.1.

Note If you have questions about which major or minor updates you are eligible to download and you have a service contract, check the Cisco Product Upgrade tool at www.cisco.com/upgrade for help.

Known and Resolved Problems

Table 4 describes problems known to exist in this release of IPS MC; Table 5 describes problems resolved since the previous release of IPS MC.

Table 6 describes problems known to exist in this release of Security Monitor; Table 7 describes problems resolved since the previous release of Security Monitor.

Table 4 Known Problems in Management Center for IPS Sensors, Release 2.1
Bug ID	Summary	Explanation
CSCeg45961	IDSM-2 recognized as appliances under Devices tab	Symptom: IDSM2 blade is recognized as an appliance as opposed to a blade under "Devices" tab. Conditions: Import an IDSM2 configuration into the PDS MC. Workaround: None. Further Problem Description: None.
CSCin32177	Import fails to bring filter if it contains SystemVariables on it	Symptom: Import fails to bring filter if it contains system variables. Conditions: Filter contains system variables during import. Workaround: None. Further Problem Description: None.
CSCsa45571	MC2.0:Able to run any commands using the RegisteredCronJobs.xml	Symptom: IPS MC 2.1 uses NMSROOT\MDC\etc\ids\xml\RegisteredCronJobs.xml for its operation. This file could be accessed by anyone who gains access to the IPS MC 2.1 server. Any change made to this file may affect the IPS MC normal operation and may be viewed as a security risk. Conditions: Gaining illegal access to the IPS MC 2.1 server and modifying the file NMSROOT\MDC\etc\ids\xml\RegisteredCronJobs.xml may affect the IPS MC normal operation and should be viewed as a security risk. Workaround: The IPS MC server should be secured and protected in general. Further Problem Description: None.
CSCsa55627	No way to change TLS setting in MC	Symptom: IPS MC 2.1 does not allow the user to either view or modify the TLS settings after the device is imported into IPS MC. Conditions: TLS setting cannot be viewed or modified after device is imported into IPS MC 2.1 Workaround: Reimport the device. Further Problem Description: None.
CSCsa57690	Integration issue : event listening needs to work with IPS 5.0	Symptom: For IPS 5.x devices, MC 2.1 will not listen to sensor events after deploy to know the post deploy device status. Conditions: During deploy, MC 2.1 will not gather/listen to sensor events to know the post deploy device status for IPS 5.x devices. Workaround: None. Further Problem Description: None.
CSCsa60182	Regular expressions with . , characters cause errors	Symptom: Deploying a configuration to a 5.x IPS device from IPS MC has an error upon completion and viewing the status messages from the realtime Progress Viewer reveals a message that contains the following text: Starting to Deploy... An EditConfigDelta request sent for all the changed components. ECD result for signatureDefinition: Error unspecifiedError: <engine name> <sig id>:<subsig id> : Regex error: unbalanced brace. Sensor has excepted all/some current config. Conditions: Creating a custom signature for a 5.x IPS device where that signature's engine allows the user to specify a regex expression can cause errors during deployment of the configuration to the device if the user specifies either a '.' (i.e., period character) or a ',' (i.e., comma character) in the regex expression. Workaround: None. Further Problem Description:** None.
CSCsa60656	MC2.1:alt-tcp-reset interfaces are not allowed for interface pair	Symptom: Alternate tcp reset interfaces are not allowed for interface pairing. Conditions: MC does not allow users to add/edit interfaces which are assigned as alt-tcp-reset interfaces. Workaround: None. Further Problem Description: For IPS 5.x sensor: 1) There were four ethernet interfaces (fastethernet2/0-2/4) and two gig interfaces of which gig0/1 was a command and control interface. 2) Configure Fastethernet2/3 and Gigabitethernet0/0 as alt-tcp-reset interfaces for Fastethernet2/1 and Fastethernet2/2 respectively. 3) Now configure an inline pair with interfaces Fastethernet2/1 and Fastethernet2/2 and imported the device into MC. 4) From MC, try to add another interface pair, MC displayed the "Fastethernet0/0" interface only. MC will not allow the user to add/edit interfaces which are assigned as alt-tcp-reset interfaces.
CSCsa63096	Updated Signature Version not in Select Group When Grouping by Releases	Symptom: After updating IDS MC 2.0 with the new signature update, the MC does not display the signature version in the Signatures by release under Configuration/Settings/Signatures/IDS4.x Conditions: After updating the signature level to S127 of sensor via IDS MC, go to Configuration/Settings/Signatures/IDS 4.x and group the signatures by release and MC does not display the version S127. Workaround: In order to see the new signatures added during a signature update users might have to use the "Compare Signature Version" under Configuration->Updates->Compare Signature Version. Further Problem Description: None.
CSCsa65766	Processes Not Stopping on Upgrade	Symptom: 'Stop All Programs' window shown during MC upgrade from 1.2.3 to 2.0.2. Conditions: The Cisco Work upgrade program will show 'Stop All Programs' window during MC upgrade from 1.2.3 to 2.0.2. This happens when some of the files required by the upgrade program is used by some other running process. This is harmless. Workaround: Click on the Next button in 'Stop All Programs' window to continue the MC ugprade. Further Problem Description: None.
CSCsa65979	Auto signature download does not work	Symptom: In IDSMC 2.0 (Build 2075) when one tries and connect to the Automatic Signature update he gets the following error message "Could not connect to CCO: 1) Unable to connect to any signature update server". Mgt Center> Data Mgt>System Configuration>Automatic Signature Download This can be reproduced in the lab using a customers or an employees CCO credentials. The Audit Log shows the following: RDEP/SDEE Collector (sensor14) parsed an evError: errSystemError MainApplication::findAutoUpdateCandidate Error attempting to retrieve directory listing from remote auto update server: ssh: connect to host x.x.x.x port 22: Connection refused No proxies are configured on IE and you can connect to CCO and download files from the VMS machine using the same credentials. Conditions: None. Workaround: None. Further Problem Description: None.
CSCsa70100	MC2.1:MC does not handle the scheduling threshold configuration correctl	Symptom: MC does not handle the Health status scheduling threshold properly. Conditions: 1) Add two IPS devices to MC say sensorA and sensorB. 2) Configure the value of Runfrequency as 5, Runwait time as 10 and scheduling threshold as 30 mins respectively. 3) Generate configuration for both the devices. 4) Schedule the deploy for sensorA within the threshold time. 5) Schedule the deploy for sensorB much after the threshold period. 6) Enable the health status tool. MC notifies the user with the following message. The query of status for sensor sensorA was postponed; there is a configuration deployment in progress for the sensor at this time The query of status for sensor sensorB was postponed; there is a configuration deployment in progress for the sensor at this time Actually only sensorA must be excluded since its deploy time falls within the threshold time.SensorB should be queried for the status and reported to the user. Workaround: None. Further Problem Description: None.
CSCsa70617	MC2.1:Sensor Health tool does not report the mainApp failure correctly.	Symptom: Sensor Health tool does not report the mainApp failure correctly. Conditions: When the mainApp process is not running the following can occur: The expected behavior is that once MC contacts the sensor for executing the getVersion and the getAnalysisEngineStatistics commands, MC should detect the mainApp failure on executing getVersion command itself. But MC reports differently as follows. "The sensor sensor1 reports that it is running low on resources. You may need to close any open CLI sessions to the sensor and disable non-essential signatures to alleviate this problem" Workaround: None. Further Problem Description: None.
CSCsa74236	Inconsistency in 4.x and 5.x sensor Statistics information	Symptom: Under Devices->Statistics page, the MC does not list the component "Interface" for a 4.x sensor though it is available for a 5.x device. Conditions: None. Workaround: This is by design as 4.x sensors do not have a control transaction to retrieve interface statistcs. Further Problem Description: None.
CSCsa76625	Signature wizard with engine parameters not working	Symptom: In MC 2.1, Custom Signature Wizard (CSW) for IPS 5.x does not allow the user to configure the engine parameters (tune parameters) instead it ask the user to go to Signature Summary page to tune the newly created custom signature. Conditions: In MC 2.1, creating custom signature creation is a two step process. This means configuring the edit parameters and tuning the engine parameters are now done in two steps. First you need use Custom Signature Wizard (CSW) to create custom signature with edit parameters and then you need to go to Signature Summary Screen to tune the newly created custom signature. Please see 'CSCsa86856: Adding Custom Signature in Signature Page loads CSW' Workaround: None. Further Problem Description: In MC 2.1 custom signature can be created only with using the Custom Signature Wizard (CSW). This is true even from the Signature Summary page.
CSCsa80232	MC allows email address to be configured with no Email Server	Symptom: MC allows email address to be configured with no Email Server. Conditions: User can configure email address in Deployment settings (at both Group and Device levels), though there is no email server configured in the Admin->System Configuration page. Workaround: None. Further Problem Description: None.
CSCsa82957	MC2.1: Audit log contains error message after sigupdate	Symptom: Under certain conditions, the following error message is seen in the Audit Log report after a signature update (the error message shown is an example): "The signature update encountered an error while parsing the version(5.0(1)S149 .0). Some sensors may not show up as potential update candidates as a result of this problem." In this example it was a 5.0 (1) S149 sensor that was imported, and then a S155 signature update was applied. Signature update to the sensor proceeds without any errors, and the IPS MC server is correctly updated as well. Users are not expected to encounter this defect because they will not be using signature update files in unexpected formats. Conditions: This error occurs when a version number is in an unexpected format. IPS MC supports only major, minor, service pack, and signature level updates without virus numbers, for example, 5.0(2) S100.0. This error will occur when your version number is, for example, 5.0(0.2) S10. Note the "0.2" that causes the error. Workaround: None. Further Problem Description: When ISP MC encounters a version number in an unexpected format, it ignores the sensor's having it.
CSCsa83811	Cannot Undo Sensor Move	Symptom: Cannot Undo Sensor Moved to a group. Conditions: Move a Sensor to a different group using the identification page. Now delete the pending configuration. The sensor will not revert back to its original location or group. Workaround: Move the sensor back to the group from where it came. Further Problem Description: None.
CSCsa84230	Completed Device Inventory report page Go to check box is not working	Symptom: Completed Device Inventory report page Go to check box is not working Conditions: In Completed Device Inventory report page "Go to" check box at the top will not be selecting any of the options. Workaround: None. Further Problem Description: None.
CSCsa84272	MC2.1:Sigupdate fails for IPS5x when pending changes are present at grou	Symptom: Under certain conditions, signature updates fail for IPS 5.x devices. Conditions: This defect occurs when changes are pending at the parent level. Workaround: Use the MC's GUI page at menu location: configuration->pending to see the list of sensors and/or groups that has pending configurations. If a group is listed (since this defect occurs when a sensor is part of a group that has pending changes), then check the MC's object selector to identify all sensors of that group. These are the sensors that will be rejected during the update because they have pending configurations. Avoid selecting them. Or you can save or delete group pending configuration changes if you finished configure them through configuration>pending page. Further Problem Description: When this problem occurs, only the IPS MC server is updated with the signature updates. The Progress Viewer shows the following messages: "Local MC: Upgrade. A sensor update for version IPSv5 Signature update; S156.0 requires 5.0(1) has started. The sensor Sensor7 can't be locked for updating of configuration, it will be removed from the list of sensors to update. Remove the locks on the sensor, and/or it's parent groups, and retry the operation. The update for version IPSv5 Signature update; S156.0 requires 5.0(1) has completed. Synchronization message to Tomcat sent successfully."
CSCsa85335	MC 2.1: Status window shows 2.0 during db upgrade; Summary showed 201	Symptom: IPS MC 2.1: Status window shows 2.0 during db upgrade. Summary showed 201 Conditions: When upgrading IPS MC 2.0.1 (or 2.0.2) to 2.1 (build 2045), the Summary-titled window (immediately before the upgrade occurs) informs the user that the upgrade will be from 2.0.1 (or 2.0.2) to 2.1. But during the upgrade, the status window displays a message saying that the "2.0" database is being upgraded to 2.1. Workaround: None. Further Problem Description: None.
CSCsa85535	Deploying with all Event Actions enabled works incorrectly	Symptom: Deploying the configuration enabling all the Event Actions does not deploy all Event Actions. Conditions: The user can select Event Actions of the signature individually or by clicking "All" button. When "All" is chosen MC includes all the action except "reset-tcp-connection". Workaround: The option "reset-tcp-connection" should be selected again. Further Problem Description: None.
CSCsa87433	MC2.1-AAA:Granting privilege to helpdesk user in Deploy page doesn't wor	Symptom: MC2.1-AAA:Granting privilege to helpdesk user in Deploy page doesn't work Conditions: If a "Helpdesk" user is given Admin privilege to "Deploy" page (View,Generate,Approve,Deploy), the Quick Deploy icon at the "Actions and Notifications" panel is disabled and says: "You are not authorized to Generate and Deploy configurations" This also occurs for a NetOp/Approver user with Admin privileges to Deploy page. The Delete Button in Deploy->Approve is disabled. Workaround: None. Further Problem Description: None.
CSCsa88926	When SSL Certificate Expires on the IDS MC there is no warning or error	Symptom: The user cannot update IDS sensor signatures from the IDS MC. The update appears to proceed but nothing actually occurs (when logged into the sensor, the IDS MC does not show up when 'sh users' is run, and there is not broadcast indicating services are stopping for the update process). Conditions: SSL Certificate has expired. This can be checked via: $INSTALL_ROOT\CSCOpx\MDC\Apache\conf\ssl> keytool -printcert -file server.cert If the 'valid...until' date is earlier than the current date, the certificate is expired. This occurs on IDS MC 1.2.3. Workaround: Generate a new SSL certificate: 1. Stop the daemon manager (net stop crmdmgtd) 2. From: $INSTALL_ROOT\CSCOpx\MDC\Apache\conf\ssl, run: ..\..\gencert 3. Restart the daemon manager (net start crmdmgtd) Further Problem Description: None.
CSCsa90236	Created by user name is set to system for sensors after update	Symptom: After signature update, MC 2.1 shows the 'created-by' field as "system" instead of correct username Conditions: After successful signature update, MC 2.1 changes the 'created-by' field to 'system' user. This may confuse the user, if the sensor was created by a different user. Workaround: None. Further Problem Description: None.
CSCsa91758	NAT Address to MC Corrupted When Adding Multiple Default Devices	Symptom: In MC 2.1, the NAT Address to MC field gets corrupted when adding sensors as default devices using the "Add multiple devices" feature. Conditions: MC 2.1 does not properly handle the NAT Address to MC field when sensors are added as default devices using the "Add multiple devices" feature. Workaround: Import the device using 'Create default configuration' option. Further Problem Description: None.
CSCsa91964	MC2.1:MC deploys EventActionFilter names incorrectly	Symptom: IPS MC does not re-import filter names correctly and display to the user. Conditions: 1. Add an Event Action Filters in IPS MC (say for example filter1) 2. Generate and deploy the configuration 3. After deployment is successfully, log on to Sensor CLI. 4. Go to filters configuration mode (configure terminal, services event rules0, show settings) 5. The filter named filter1 is displayed along with some sensor specific identity 6. Now re-import the configuration through IPS MC 7. Go to Settings > Configuration > SigEvent Action Filters 8. MC does not display filter name as in Sensor. Workaround: None. Further Problem Description: None.
CSCsa99452	MC 2.1:Modified By fileld is not showing any value in Sensor Version R	Symptom: In MC 2.1, the IDS Sensor Versions report will show 'N/A' as the value for 'Modified By' column for all type of devices. Conditions: MC 2.1 does not properly show the value of 'Modified By' field in IDS Sensor Versions report. Workaround: None. Further Problem Description: None.
CSCsb00157	MC2.1: MC dsiplays event actions not supported for TROJAN-BO2K engine	Symptom: In MC 2.1, the Custom Signature Wizard (CSW) will show event action options that are not supported by some engines (like TROJAN-BO2K, TROJAN-TF2K, TROJAN-UDP) Conditions: MC 2.1 CSW will show unsupported event action options for certain engines (like TROJAN-BO2K, TROJAN-TF2K, TROJAN-UDP) Workaround: Edit the newly created signature and unselect the unsupported event action options. Further Problem Description: None.
CSCsb00375	MC2.1: MC does not retain the user-profile names during deploy	Symptom: IPS MC 2.1: MC does not retain the user-profile names during deploy Conditions: MC overwrites the profile name of the blocking devices during deploy. 1) In an IPS 5.x CLI, configure a user-profile and assign it to a blocking device. For example configure a user-profile called "pix-device" and assign it to Firewall-devices with IP 1.1.1.1. 2) Import the device into MC. 3) Add another blocking device with an IP of 2.2.2.2 in MC. 4) Generate and deploy the configuration to the device. Deploy is successful. But, MC deploys the user-profiles as "profile-for-1.1.1.1" and "profile-for-2.2.2.2". MC should retain the user-profiles during deploy Workaround: None. Further Problem Description: None.
CSCsb00714	Cannot set source or destination address to 0.0.0.0 in filter	Symptom: Creating a filter with a source or destination address of 0.0.0.0 causes the following error: Error Object update failed. Validation exception during object update. The address (0.0.0.0) is not a valid IP address. Conditions: Creation of a filter with a source or destination address of a single address of 0.0.0.0 Workaround: Narrow filter down and specify ANY for the address. Example for Sig 3051 SubSig 0 specify ANY for Destination address. Further Problem Description: None.
CSCsb00962	MC 2.1:Source Addr and Dest Addr Range is not validated in filters	Symptom: Source Address and Destination Address are not validated in Filters Conditions: 1. Add an IPS 4.x Device 2. Choose IDS 4.x and proceed to Settings > Configuration > Filters in TOC 3. Click Add or choose any of the entries and choose "Edit" 4. Validation for Range of IP Addresses (Start and End IP Address) is not done for Source Addresses and Destination Addresses Workaround: None. Further Problem Description: None.
CSCsb01028	MC2.1:MC does not validate alt-tcp-interfaces assigned to interface pair	Symptom: MC does not validate alt-tcp-interface assigned to interface pairs during "Generate". Conditions: When an interface is configured as alt-tcp-interface and also paired with another interface in an interface pair configuration, MC generates the configuration successfully. Workaround: None. Further Problem Description: When queried from the Interfaces page, MC throws an error and hence MC should validate the configuration during "Generate"
CSCsb01664	SigTuning::Group level settings should be shown when Overriding	Symptom: SigTuning:Group level settings should be shown when Overriding Conditions: In the signature tuning, When doing override of group level settings the sigtuning page refreshes and loads with default settings instead loading with group level settings. Workaround: None. Further Problem Description: None.
CSCsb01800	SigTuning::Group Settings should be inherited when device has default va	Symptom: SigTuning:Group Settings should be inherited when device has default value Conditions: When a signature is tuned at the group level, the import overrides the source as device even though the device has default settings. Workaround: None. Further Problem Description: None.
CSCsb02047	Custom Signature Name change is not reflecting in UI	Symptom: Custom Signature name cannot be changed from Sig Tuning Applet for IPS 5.x in IPSMC 2.1 Conditions: As for IDS4.x, user will not be allowed to change the Custom Signature name for IPS5.x in IPSMC 2.1 Workaround: None. Further Problem Description: None.
CSCsb02080	MC2.1: MC does not create EAF with the name given by the user	Symptom: The filter names that are defined by the user are not deployed to the sensor. Conditions: The filter names that are defined by the user are appended with the string "Sensor Name - String Separated by Hyphen" and the resultant string is deployed as filter name. For example, if the user has configured a filter with filter name as "Filter1", the filter name is deployed as "Filter1-sensor7-0-D". The filter name string may vary depending upon the sensor name and the number of filters configured. Workaround: None. Further Problem Description: None.
CSCsb02571	MC 2.1:Viewing the Configuration in History page is not listing MBS	Symptom: Master Blocking Sensors are not displayed in "History Page" for a 4.x device Conditions: When the configuration generated/deployed has Master Blocking Sensor entries, Master Blocking Sensor configuration does not show any Master Blocking Sensor entries for a 4.x device. Workaround: None. Further Problem Description: None.
CSCsb02977	IOS IPS: Phase II Actions Appear in Phase I Devices	Symptom: Unsupported event action options are inherited at device level for IOS IPS phase 1 (IPS subsystem version: 2.000(000)) devices. Conditions: Event action options like denyAttackerInline and denyFlowInline are applicable only for IOS IPS phase 2 (IPS subsystem version: 2.001(001)) devices. Configuring these options at group level with mandatory option set, causes the MC 2.1 to inherit these settings for IOS IPS phase 1 device also. Workaround: 1. Have different sub-groups for IOS IPS phase 1 and phase 2 devices. (or) 2. Edit the signature at device level for IOSIPS phase 1 and unselect the unsupported even action options Further Problem Description: None.
CSCsb03424	MC 2.1:IP Address and Net Mask are not validated in Allowed Hosts	Symptom: MC 2.1:IP Address and Net Mask are not validated in Allowed Hosts Conditions: "IP Address" and "Net Mask" fields are not validated in Internal Networks(4.x) and Allowed Hosts TOC Items. Generate and deploy the Configuration deploy fails if invalid entries are configured. Workaround: None. Further Problem Description: None.
CSCsb03503	SigTuning applet behaving differently for Custom signatures	Symptom: In IPS MC 2.1, the signature tuning applet for IPS 5.x devices may not properly show the 'Changed/default' icon for Custom Signatures. Conditions: IPS MC 2.1 may not properly show the 'Changed/Default' icon in the IPS5.x signature tuning applet for custom signatures. Workaround: Click on the value field and apply the settings. Further Problem Description: None.
CSCsb04106	Sigtuning:EventActions are not selected while editing	Symptom: Sigtuning:EventActions are not selected while editing Conditions: If a signature has more than one event action defined, Editing sig prop is not showing any event action selected. Workaround: None. Further Problem Description: None.
CSCsb04121	MC 2.1 Device Inventory Report is not showing NAT address for IOSIPS	Symptom: For IOSIPS devices imported with NAT address, MC 2.1 will show NAT address value as N/A in Device Inventory Report Conditions: MC 2.1 does not properly show the NAT address value in Device Inventory Report. It will the show the value as N/A even though the device is NAT'ed This happens only for imported device and not for device added with default configuration. Workaround: None. Further Problem Description: None.
CSCsb04133	MC2.1:MC does not support zero value for TVR	Symptom: Target Value Rating for an IP address as "zero value" is not supported in IPS MC. Conditions: When "zero value" is configured Target Value Rating for an IP Address, MC imports it as "medium". Workaround: None. Further Problem Description: 1) In an IPS 5.x CLI, configure an Target value rating for an IP address as "zero value" 2) Import the IPS 5.x device into MC 3) MC displays the TVR as "medium" for IP Address configured in Step 1
CSCsb04175	MC2.1:TVR group settings are not properly handled by MC	Symptom: Configuring Target Value at Group level and device level, IPS MC deploys successfully. But when the configuration is re-imported into MC, TVR page displays values inheriting from Group level. The deletion of values at group level deletes the value at group level but the device level displays the values with source as Sensor. Conditions: After re-import the configuration is inherited from the group (source field clearly indicates the group from which the configuration is inherited). And if the values that are inherited from Group are deleted, the configuration still displays the deleted values but source field is set to Sensor. Workaround: None. Further Problem Description: Since the same configurations are available both at Group and Sensor level, this problem raises. On re-import IPS MC treats the configuration as Sensor configuration and does not see them whether they are relevant to any groups they belong to. And this is the reason for the same configuration to be shown at both Group and device level.
CSCsb04348	Sensor .xml (config) files are on VMS server for anyone to view	Symptom: IPS MC 2.1 stores the XML files (response.xml) imported from IPS 5.x devices in the NMSROOT/MDC/etc/ids/xml directory. These XML files have the device configuration, and anyone who can access the NMSROOT/MDC/etc/ids/xml directory can obtain these files. Conditions:* IPS MC 2.1 stores XML files (response.xml) after they are imported from IPS 5.x devices. Workaround:* None. Further Problem Description: This should be kept in mind from a security viewpoint.
CSCsb04873	MC2.1: Editing IP address in EAF is not handled properly	Symptom: When the user commits Attacker Address Range and Victim Address Range without making any changes during "Edit" operation, the entry is removed from the list. Conditions: The user can Add/Edit Attacker and Victim Addresses to a Event Action Filters. When the user commits IP Address Range during Edit operation without making any changes to the IP Address(es), the chosen entry is deleted from the list. This is applicable for both Attacker and Victim Addresses. The deleted entry should be added to list by the user. Workaround: None. Further Problem Description: None.
CSCsb04945	MC2.1:MC does not provide an option to move EAF to inactive lists	Symptom: IPS MC Event Action Filter does not support INACTIVE LIST supported by IPS 5.x Conditions: If any filters configured in INACTIVE LIST will be imported to IPS MC and when deployed, IPS pushes them into active lists. IPS MC does not have provision to move filters into INACTIVE list. Workaround: None. Further Problem Description: None.
CSCsb06188	MC2.1: VS config is not displayed after Query Interfaces	Symptom: Virtual Sensor Configuration is not displayed in Virtual Sensor page after "Query Interfaces" operation is done in "Edit Virtual Sensor" Page Conditions: Virtual Sensor configuration is not displayed if the user does "Query Interfaces" in edit Virtual Sensor page and saves the configuration in edit page. Virtual Sensor table does not show any configurations, and configuration changes that are done at edit page are not saved. Workaround: Virtual Sensor page has to be refreshed to view Virtual Sensor configuration. Since the configuration changes are not committed, Virtual Sensor (only config change done after "Query Interfaces") has to be re-configured. Further Problem Description: None.
CSCsb06290	Signature Variables are not validated properly.	Symptom: The fields in Signature Variables are not validated, resulting in failure in deployment. Conditions: The signature variables fields are not validated for special characters (such as comma, ampersand and hyphen) which results in deployment failure. Workaround: None. Further Problem Description: None.
CSCsb06398	MC2.1: Deployment does not start immediately	Symptom: Quick deploy may not function properly in IPSMC 2.1 running on Solaris. Conditions: In IPSMC 2.1 running on Solaris, when you hit the Quick Deploy icon, the deploy may not be triggered immediately. Workaround: Check the system time zone settings. Further Problem Description: None.
CSCsb07030	AAA::MC2.1 NetAd does not have privilege to do Quick Deploy	Symptom: Network Administrator cannot do a Quick Deploy. Conditions: Network Administrator does not have Approve privileges and Quick Deploy auto-approves configurations before deploying. Therefore a Network Administrator does not have Quick Deploy privileges. Workaround: None. Further Problem Description: None.
CSCsb07752	MC2.1: SNMP traps destination are not imported into MC	Symptom: Import a 5.0 IPS device that has SNMP trap destinations configured to values other than the default values. In the IDS Sensors Management Center go to Configure>Settings>SNMP (IDS 5.x) Traps Destination page. In the Traps Destination table you will see the imported Traps Destination items all have default values for their settings and do not match the settings configured on the 5.0 IPS device. Conditions: This bug only affects 5.0 IPS devices. Workaround: Configure the SNMP Traps on the 5.0 IPS device via CLI or IDS Sensor Management Center. Do not use IDM to configure SNMP Traps Destinations. Further Problem Description: This is not a defect in the IDS Sensors Management Center, it is a defect in the IDM tool that runs on the 5.0 IPS Device. The reason IDS Sensors Management Center fails to import the SNMP trap destinations that were configured on the device using IDM is because the device sent only the IP address portion of the trap destination data. Hence, the IDS MC assumes the rest of the SNMP trap destination data is defaulted since it is missing. The IDM defect, CSCeh96235, is resolved and will be available in the 5.1 version of the device.
CSCsb07763	MC2.1: Never Block Address not imported correctly	Symptom: MC 2.1 import never-block address twice Conditions: MC 2.1 after import will show two never-block entries for every one entry configured on IPS 5.x device. Workaround: Delete the duplicate entry from Blocking > Never Block Addresses screen. Further Problem Description: None.
CSCsb07767	MC2.1: Device Statistics page doesnt show devices under sub-groups	Symptom: MC 2.1 import never-block address twice Conditions: MC 2.1 after import will show two never-block entries for every one entry configured on IPS 5.x device. Workaround: Delete the duplicate entry from Blocking > Never Block Addresses screen. Further Problem Description: None.
CSCsb07781	MC2.1: IOS IPS default value of max SDEE Subscriptions incorrect	Symptom: For IOS IPS devices added with default configuration, IPS MC 2.1 will incorrectly show the value of Max Subscriptions (under Configuration > Settings > Communications > IOSIPS SDEE Properties) as 2 instead of 1. Conditions: When an IOS IPS device is added with a default configuration, IPS MC 2.1 will incorrectly show the default value of Max Subscriptions as 2 instead of 1. Workaround: Edit settings and change the value from 2 to 1 and apply the settings. Further Problem Description: None.
CSCsb08343	AutoSigDownload Settings are not preserved on Upgrade	Symptom: Autosigdownload settings are not preserved during upgrade Conditions: On Upgrade from 2.0.2 MC to 2.1 MC, the autosigdownload settings are not preserved. The fields are coming blank. Workaround: Note down your password when typing into the MC for the first time. Further Problem Description: 1. Install MC 2.0.2 and configure AutoSigdownload feature settings. 2. Upgrade to MC 2.1 (Build 2506) and checking the same. All the fields are blank. The same happens while backup/restore also.
CSCsb08376	Devices page doesn't reflect the SigUpdate Details for 5.x Sensors	Symptom: After a signature update, the old signature release level is still shown on the device page. Conditions: Install MC 2.1 and perform a signature update with a 5.x update package. Workaround: Close the IPS MC page and reopen it. This forces it to refresh. Further Problem Description: None.
CSCsb09029	MC2.1:Custom Signatures are not listing in Configurations on different S	Symptom: In Configuration Compare tool, Custom Signatures are not displayed when the source is sensor and the destination is another Group/Sensor Conditions: In Config Compare tool, the source can be chosen as a Sensor (or Group) and destination can be chosen as another Sensor (or Group). The custom signatures are displayed in the above scenario. Workaround: None. Further Problem Description: None.
CSCsb09966	MC2.1:Copying Configs across 4.x devices are not listing all Configs	Symptom: Under certain conditions, not all of the eligible configuration settings are displayed in the Copy Wizard. Conditions: When working with a target device and a source device that are at different signature release levels, the Copy Wizard does not display all of the eligible configuration settings. This problem has been observed only for IPS 4.x devices. Example: signature release level of source is S168 and signature release level of target is S117. In this example, the Copy Wizard does not display all of the eligible configuration settings. Workaround: None. Further Problem Description: None.
CSCsb10436	IOS IPS Port Map Not Deployed After Copying from Phase II to Phase I	Symptom: After copying the configuration from IOS IPS phase 2 (2.001(001)) to IOSIPS phase 1 (2.000(001)), IPS MC 2.1 does not properly deploy the IOS IPS phase 1 port map entries. Conditions: IPS MC 2.1 will not deploy IOS IPS phase 1 port map entries if you copy the IOS IPS phase 2 configuration to IOS IPS phase 1 Workaround: Delete the old entries and create new ones for the IOSIPS phase 1 device and try deploy. Further Problem Description: None.
CSCsb10641	MC2.1:page disappears for special chars in EAF parameter fields	Symptom: IPS 5.0 Event Action Filters page throws exception when special characters are given in Add/Edit Event Action Filters page. Conditions: When special characters are given as value in the fields of EAF (text fields like Sig id, Sub Sig Id, Attacker Ports, Victim Ports), Add/Edit field page does not throw error but rather throws exception on the screen. As a result of this Sig Event Action Filters page displays the exception and IPS MC should be re-launched. Workaround: None. Further Problem Description: None.
CSCsb10708	MC2.1: MC does not display the latest signature version properly	Symptom: MC2.1: MC does not display the latest signature version properly Conditions: 1) When MC is installed afresh, the latest signature version for IPS5.x shows as "S152.0" 2) Import a sensor with version 5.0(1)S169. MC successfully imports the sensor into MC. Go to device page and check the latest signature version for IPS5.x. Device page still shows "S152.0". 3) Import a sensor with version 5.0(2)S156. Now the device page shows the latest signature version as "S156". MC displays the latest signature version based on the SP update version. But, MC should display the latest signature version based on "Sxxx" of the sensors managed by it. Workaround: None. Further Problem Description: None.
CSCsb11880	Sig Category and NSDB Updates Not Happen With Service Pack, Minor Update	Symptom: When a service pack or minor update contains a signature update as well, the nsdb and sig category information is not getting updated during the update process. Conditions: The design of the MC contains a check on the type of update. If the update type is anything except signature update, then the MC bypasses updating the NSDB and sig categories. (Note: this check was put in because originally only signature updates could contain NSDB and sig categories. However, this is no longer true.) Therefore, the NSDB and sig categories cannot be updated when doing a major/minor/sp update. Workaround: 2 possible workarounds: Workaround 1: Perform the minor update as normal, then update with the latest sig update (which should be have the same or higher sig level as that sig update within the minor update). Workaround 2: Rename the minor update file to make it look like a sig update file. This workaround only works for minor and sp updates. Further Problem Description: None.
CSCsb12069	MC2.1: SOL: MC inconsistent on Signature Level	Symptom: IOSIPS phase 2 device (IOSIPS subsystem version 2.001(001)) import fails after IPSMC upgraded from 2.0.1 to 2.1 Conditions: After upgrading IPSMC from 2.0.1 to 2.1, importing IOSIPS phase 2 device (IOSIPS subsystem version 2.001(001)) fails with following error: Exception in SystemContext - An error occurred while trying to update the registry with information for sensor version 2.001(001)IOS com.cisco.nm.mdc.ids.common.exceptions.MdcException: An error occurred while trying to update the registry with information for sensor version 2.001(001)IOS Workaround: Do sigupdate and then try IOSIPS phase 2 import Further Problem Description: None
CSCsb12077	SigUpdate applies NSDB and Sig Categories of Older Versions	Symptom: The nsdb and sig categories are applied during application of an older signature version through the local update server option in Security Monitor. Conditions: This happens when there is a higher sensor software version in the MC database with a lower sig level. E.g. If there is the following versions in the MC database: 5.0(2) S10 5.0(1) S20 The MC uses the sig level from "5.0(2) S10" instead of "5.0(1) S20". Workaround: None. Further Problem Description: None.
CSCsb12336	MC2.1:Deploying NTP settings from the group level does not work properly	Symptom: MC2.1:Deploying NTP settings from the group level does not work properly Conditions: NTP server settings cannot be deployed from global level, when NTP settings are configured at device level Workaround: None. Further Problem Description: None.
CSCsb12458	MC2.1:Querying Interfaces cause virtualSensor configuration page to disa	Symptom: MC2.1:Querying Interfaces cause virtualSensor configuration page to disappear Conditions: 1) Import a IPS 5.x device into MC. 2) Go to the edit virtual Sensor page. Assign an interface to the virtual sensor and click ok. MC will display the assigned interface in the UI without any errors 3) Again go the edit Interface page. Click the QueryInterfaces and click OK. MC does not display the assigned interfaces in UI. (The applet shows itself as a blank space) Workaround: Click "Virtual Sensor" from the TOC item. Further Problem Description: None.
CSCsb12753	MC2.1: 5.x Sig event action filters allow duplicate names when editing.	Symptom: MC2.1: 5.x Sig event action filters allow duplicate names when editing. Conditions: On a 5.x sensor with two or more sigEvent actions filters, if one of the EAFs is edited and rename to an already existing EAF, it is allowed by the MC and an exception is throw in the stderr log. Workaround: None. Further Problem Description: None.
CSCsb13334	MC 2.1: Deploy fails after sigupdate if tune specify service ports	Symptom: Tuning the following Normalizer engine parameters in MC for sensor version with signature level S149 or S150 (either at Group level or sensor level), then sigupdate sensor to S151 and beyond will cause deployment to fail with error message from Progress View of: "the union is protected". - sigID 1305 sub sigID 0: Specify Max Partial Datagrams; sigID 1306 sub sigID 1-5: Specify TCP Option Number; sigID 1314 sub sigID 0: All the Specifies And signatures with these parameters - Specify Service Port; Specify Hijack Max Old Ack; Specify SYN Flood Max Embronic Conditions: Problem exists in MC version 2.1 and sensor version with signature level S149, S150 imported Workaround: There are two workaround: 1. Don't tune these parameters in S149, S150 or 2. After seeing the protection error message in the deployment result, go to signature tuning page and restore these parameters to default by clicking the red square on the left of these parameters to make them green. Further Problem Description: This happening is because these parameters are un-protected in signature level S149, S150. It is realized later that these parameters shouldn't be tunable and thus change the typedef and default to make them protected fields in signature level S151 and later.
CSCsb14747	MC2.1: Query Interfaces page throws errors for IPS5.x devices	Symptom: After deleting the interface pair imported from sensor, and re-use one of the interface to create another pair, interface pair configuration is now inconsistent between MC and sensor. Query interface after that will cause error: "An error occured trying to get the interface information. Interface XXX is part of another Interface Pair pair PPP" Conditions: Problem exists in MC version 2.1. Workaround: Once MC modifying the interface pair configuration imported from sensor, e.g., create new pair by using an interface from the delete pair, do not attempt to "Query interface" again in either "Edit Virtual Sensor" page or "Add Interface Pair" page. User can either deploy the changes made from MC to sensor or ignore the changes made in MC by re-import the sensor. Further Problem Description: None.
CSCsb16113	SigUpdate to 4.x Sensor after Upgrade throws a lot of Errors	Basic Description: During a signature update, some conditions are reported as errors in the logging files even though the operation succeeded and the IPS MC has not reported any errors in the user interface. Symptoms: For IPS MC 2.1, the logging file IDS_SensorInterfaceDebug.log will contain one or more lines like the following after a signature update has completed. "** Error: 10.10.10.165 - An error occurred during the deployment. Exception details(An error occurred while trying to get the configuration file VirtualSensor from the sensor. err=(RDEP Error, msg = Command not valid or not supported))" Conditions: This occurs only during a signature update and is the result of the MC waiting for the sensor to complete the signature update. Since the sensor can take 10 minutes or more, depending on the platform and the size of the update, a timeout is used to keep from waiting indefinitely. When this timeout occurs a part of the MC is reporting this as an error but it continues with the update process. This should not be reported as an error in the log files. Workarounds:** This error should be ignored if the user interface of the MC reports that the update has succeeded. If an error is reported from the user interface, additional error messages will be in the log files to help diagnose the problem.
CSCsb16166	MC2.1:MC should validate the reqd params of a custom signatures.	Symptom: When using MC 2.1 to create a custom signature for a 4.x device, MC doesn't validate for all the fields. So if user doesn't tune the custom siganture just created and try to generate and deploy to the device, deployment will fail with a validation error. Conditions: None. Workaround: Make sure always go to signature tuning page to tune the newly created signature before save. Further Problem Description: None.
CSCsb16249	MC2.1:Inconsistency in Param Src after Import	Symptom: MC is showing param src inconsistently for the custome signatures created in MC at the group level, after generate, deploy and reimport a device. Conditions: None. Workaround: None. Further Problem Description: None.
CSCsb17024	MC2.1:Current Vs Running Config is not listing MBS	Symptom: Under certain conditions when using the Configuration Comparison tool, the master blocking sensor configuration doesn't appear on the Configuration Comparison page. Conditions: Select Configuration > Compare > Current Vs Running Workaround: None. Further Problem Description: None.
CSCsb17129	MC2.1:Deploying Filters to sensor fails if sensor name has '-'.	Symptom: Deploy fails with the following message in the real time progress viewer. <sensor name>: Deploy Starting to Deploy... An EditConfigDelta request sent for all the changed components. ECD result for eventActionRules: Error validateError: / -- /_root_/filters/<filter name>/ -- invalid name. Sensor has excepted all/some current config. Conditions: The problem occurs only when the following two conditions exist: 1) the sensor has a name with one or more '-' characters in the name and 2) event action rules are defined on the sensor using IDM or CLI. If these two conditions exist when you import the sensor into IDS Sensor Management Center, the IDS Sensor Management Center creates invalid meta-data and appends it to the filter name. The meta-data is invalid because IDS Sensor Management Center does not handle the '-' in the sensor name correctly. Workaround: Please remove the '-' character(s) from the sensor name. Further Problem Description:** None.
CSCsb17317	Blocking device interface name changed or deletion not deploy to sensor	Symptom: Deleted blocking interface for Router blocking device or VLAN for CAT6K device won't deploy to sensor. Modified blocking interface name for Router blocking device or VLAN for CAT6K device won't deploy to sensor. Conditions: Condition exists in MC version 2.1. Workaround: Instead of deleting blocking interface or VLAN, do these: 1. delete the blocking device 2. deploy to sensor 3. add the blocking device in MC w. correct interface 4. deploy to sensor. Further Problem Description: None.
CSCsb17871	MC 2.1 : Unable to tune 5.x signatures with Hidden RegEx String	See Explanation of CSCsb17871

Explanation of CSCsa43623

Attempting to use graphical reports in Security Monitor will yield an error like the following:

java.lang.InternalError: Can't connect to X11 window server using ':0.0' as the value of the DISPLAY variable.

at java.awt.GraphicsEnvironment.getLocalGraphicsEnvironment(GraphicsEnvironment.java:53)

at com.cisco.nm.uii.reports.grapher.GraphicalReports.createGraph(GraphicalReports.java:211)

at com.cisco.nm.mdc.ids.reports.ui.ReportAction.handleViewReportForm(ReportAction.java:1408)

This occurs if the user installs Common Services Service Pack 3 on top of an existing IPS Management Center/Security

Manually unregistering & re-registering the daemon using the following steps, solves the issue:

Step 2: /opt/CSCOpx/bin/perl /opt/CSCOpx//MDC/bin/ids/setupXvfb.pl -unregister 3270

Step 3: /opt/CSCOpx/bin/perl /opt/CSCOpx//MDC/bin/ids/setupXvfb.pl -register 3270

Explanation of CSCsa98640

"Error:The list of monitored devices could not be loaded from the database - An error occurred with the database, the most likely cause of this problem is that the database is no longer running. Verify that the database is running and retry the operation."

at com.cisco.nm.mdc.ids.reports.ui.ViewReportForm.fillReporterTable(ViewReportForm.java:193)

at com.cisco.nm.mdc.ids.reports.ui.ViewReportForm.reset(ViewReportForm.java:276)

at org.apache.struts.action.ActionServlet.processPopulate(ActionServlet.java:2051)

at org.apache.tomcat.core.ContextManager.internalService(ContextManager.java:917)

at org.apache.tomcat.modules.server.Ajp13Interceptor.processConnection(Ajp13Interceptor.java:341)

at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:516)

The problem will occur in any Windows or Solaris version of Security Monitor (version 1.2.x, or 2.x) that receives data from CSAMC using unicode.

The CSA product supports unicode as an option for data representation. If unicode is embedded in the event data to the Security Monitor, then the CSA reports will not be able to run to completion in the Security Monitor product.

Explanation of CSCsb17871

Bring up the MC tuning page for signatures with hidden regex for tune other field, and OK it would cause the following error string:

[Regex String] Validation Error: Value is too short, must be at least 1 characters.

The followings is the list of signatures which use Regex in S165 (there may be more in later sig level) :

Signature [3318^0] name [DsRolerUpgradeDownlevelServer Request] engine [string-tcp]

Signature [3533^0] name [Cisco IOS Misformed BGP Packet DoS] engine [string-tcp]

Signature [3740^0] name [IMail LDAP Service Buffer Overflow] engine [string-tcp]

Signature [4515^0] name [Cisco IP/VC Embedded Community Names] engine [string-udp]

Signature [4515^1] name [Cisco IP/VC Embedded Community Names] engine [string-udp]

Signature [5379^0] name [Windows Media Services Logging ISAPI Overflow] engine [string-tcp]

Signature [5392^0] name [Internet Explorer XML Object Overflow Type 1] engine [string-tcp]

Signature [5393^0] name [Internet Explorer XML Object Overflow Type 2] engine [string-tcp]

Signature [5395^0] name [Cisco ACNS Authentication Library Buffer Overflow] engine [string-tcp]

Signature [5403^0] name [OpenSSL SSL/TLS Malformed Handshake DoS] engine [string-tcp]

Signature [5429^0] name [WINS Replication Protocol Buffer Overflow] engine [string-tcp]

Signature [5438^0] name [Cisco IOS Call Processing Solutions DoS] engine [string-tcp]

Signature [5483^0] name [IE Content Advisor Buffer Overflow] engine [string-tcp]

Signature [5485^0] name [ISS PAM.dll ICQ Parser Buffer Overflow] engine [string-udp]

Signature [5486^0] name [Apple File Service LoginExt Overflow] engine [string-tcp]

Signature [5486^1] name [Apple File Service LoginExt Overflow] engine [string-tcp]

Signature [6130^0] name [Microsoft Message Queuing Overflow] engine [service-msrpc]

Use the default tuning parameters for these signatures and don't attempt to tune them.

Obtaining Documentation

Cisco documentation and additional literature are available on Cisco.com. Cisco also provides several ways to obtain technical assistance and other technical resources. These sections explain how to obtain technical information from Cisco Systems.

Cisco.com

Product Documentation DVD

Cisco documentation and additional literature are available in the Product Documentation DVD package, which may have shipped with your product. The Product Documentation DVD is updated regularly and may be more current than printed documentation.

The Product Documentation DVD is a comprehensive library of technical product documentation on portable media. The DVD enables you to access multiple versions of hardware and software installation, configuration, and command guides for Cisco products and to view technical documentation in HTML. With the DVD, you have access to the same documentation that is found on the Cisco website without being connected to the Internet. Certain products also have .pdf versions of the documentation available.

The Product Documentation DVD is available as a single unit or as a subscription. Registered Cisco.com users (Cisco direct customers) can order a Product Documentation DVD (product number DOC-DOCDVD=) from the Ordering tool or Cisco Marketplace.

Ordering Documentation

Beginning June 30, 2005, registered Cisco.com users may order Cisco documentation at the Product Documentation Store in the Cisco Marketplace at this URL:

Table 5 Resolved Problems in Management Center for IPS Sensors, Release 2.1
Bug ID	Summary	Additional Information
CSCsa22185	IOS IPS: Deploy fails for IOSIPS when all signatures selected	This problem has been resolved and verified.
CSCsa43631	Custom Signature - Name not getting deployed	This problem has been resolved and verified.
CSCsa53069	Signature update may not work in IDS MC 2.0 in all cases	This problem has been resolved and verified.

Table 6 Known Problems in Monitoring Center for Security, Release 2.1
Bug ID	Summary	Explanation
CSCed19051	RDEP collector does not store last recieved data timestamp in DB	Symptom: The Security Monitor's receiver process builds a collector thread for each sensor in its device table. The collector threads establish a connection and open a subscription on the sensor requesting all future events that meet the "minimum severity level" setting. It then begins issuing "get" requests against the subscription and retrieving event data. The collector thread parses the data and inserts event-recorded elements into an insertion queue. The collector also keeps track of the timestamp for the last event that it stored in the queue. Event records will remain in the queue until the inserter pulls them off the queue and writes the records to the database. Unless the system is under attack, events are processed from the queue very quickly, within fractions of a second. Conditions: If the receiver process is stopped while the system is receiving events, all events that are still in the queue and have not been written to the database are dropped. When the receiver starts up again, the collector thread builds a new subscription requesting events following the saved timestamp. This means that it is possible to skip a few events (particularly those events that were in the insertion queue when the receiver was stopped) when the receiver process is stopped and restarted during operation. Workaround: None. Further Problem Description: None.
CSCei14923	SecMon will not prune Event DB, if it is receiving too many event	Symptom: Pruning is not working in Security Monitor 2.x Conditions: If SecMon gets more than about 100syslog per seconds Workaround: Stop from time to time the IDS_Receiver process under cisco works, so that SecMon can recover from the load Further Problem Description: Event SecMon performance increased compared to SecMon1.2, you can take the 'max' value indications from there: http://www.cisco.com/univercd/cc/td/doc/product/rtrmgmt/cw2000/mon_sec/secmon12/technote.htm#1066921
CSCsa41024	Downstream SecMon not serving TriggerPacket details to Upstream SecMon	Symptom: Trigger packet information is not available at the upstream Security Monitor. Conditions: This issue will occur for all tiered Security Monitor topologies where trigger packet data is enabled on the IPS Sensor devices. Workaround: When the sensor transmits the events containing trigger packet data, the first Security Monitor in the chain will collect and store the trigger packet data. Additionally, trigger packet information may be viewed using that instance of the Security Monitor. Further Problem Description: None.
CSCsa43623	SecMon XvfbServer not running after CMF SP3 install	See Explanation of CSCsa43623.
CSCsa63422	SecMon:Restore - IP Logs do not get restored to the correct directory	Symptom: After upgrade, IPLOG files that were present are placed in the default directories. If the user had configured a non-default directory as the iplog storage location, then the files will not be found in that directory after upgrade. Conditions: Upgrade of the Security Monitor from version 1.2.3 to version 2.0. Upgrade of the Security Monitor from version 2.0.x to version 2.1. Workaround: Locate the files in the default directory and copy them over to the desired directory. Further Problem Description: None.
CSCsa63931	IPLOG Save URL option is not working in SecMon2.1	Symptom: Sensors which are behind a NAT cannot save the IPLOG due to the URL referencing the wrong (non-NATed) address in the URL. Conditions: All versions of Security Monitor on both Windows and Solaris operating systems. Workaround: The user may stop the browser communication (after they initiate the IPLog request by clicking the IPLog ID URL), change the IP address to reflect the external IP address in the browser and restart the request. As an example, for a device addressed at: 10.10.10.35 (10.77.208.186-Natted) The Security monitor tries to open up a connection with the device as below; https://10.10.10.35/cgi-bin/iplog-server?ipLogId=4 This will not work unless the ip address is changed to 10.77.208.186 The following URL will function correctly: https://10.77.208.186/cgi-bin/iplog-server?ipLogId=4 Further Problem Description: None.
CSCsa98640	CSA Unicode not supported by Secmon	See Explanation of CSCsa98640.
CSCsb14022	Security Monitor always referneces 5.x nsdb when view from local server	Symptom: The signature explanation in the Security Monitor event viewer is not correct or missing for the 4.x sensor generated event. Conditions: If the Security Monitor is configured to access the nsdb from the local server, the event viewer retrieves the signature explanation from the 5.x nsdb. As a result, if you apply a 4.x signature update, you must also apply the corresponding 5.x signature update to ensure the locally referenced nsdb is up to date. In addition, the 4.x signature may have slightly different tuning or default parameters from those listed in the 5.x nsdb. Workaround: Apply both the 4.x and 5.x signature update to Security Monitor. If a problem still exists, you may access the 4.x nsdb from your browser at <CSCOpx Installation Directory>/MDC/Apache/htdocs/vms/nsdb. Further Problem Description: None.

Table 7 Resolved Problems in Monitoring Center for Security, Release 2.1
Bug ID	Summary	Additional Information
CSCin62566	Abort DBCompact:Rollback the DB/Not allow the user to abort	This problem has been resolved and verified.
CSCsa34441	SecMon2.0 :: Pruning-idsalarms with -z option has problems	This problem has been resolved and verified.
CSCsa40296	Error while running graphical reports if Date/Time filter is disabled	This problem has been resolved and verified.
CSCin41741	Socket error after restarting EvsServer	This problem has been resolved and verified.
CSCsa41933	Unable to export/email the graphical report while generating the reports	This problem has been resolved and verified.

•

Registered Cisco.com users (Cisco direct customers) can order documentation from the Ordering tool:

•

Instructions for ordering documentation using the Ordering tool are at this URL:

•

Nonregistered Cisco.com users can order documentation through a local account representative by calling Cisco Systems Corporate Headquarters (California, USA) at 408 526-7208 or, elsewhere in North America, by calling 1 800 553-NETS (6387).

Documentation Feedback

You can rate and provide feedback about Cisco technical documents by completing the online feedback form that appears with the technical documents on Cisco.com.

You can submit comments by using the response card (if present) behind the front cover of your document or by writing to the following address:

Cisco Systems
Attn: Customer Document Ordering
170 West Tasman Drive
San Jose, CA 95134-9883

Cisco Product Security Overview

A current list of security advisories and notices for Cisco products is available at this URL:

If you prefer to see advisories and notices as they are updated in real time, you can access a Product Security Incident Response Team Really Simple Syndication (PSIRT RSS) feed from this URL:

Reporting Security Problems in Cisco Products

Cisco is committed to delivering secure products. We test our products internally before we release them, and we strive to correct all vulnerabilities quickly. If you think that you might have identified a vulnerability in a Cisco product, contact PSIRT:

An emergency is either a condition in which a system is under active attack or a condition for which a severe and urgent security vulnerability should be reported. All other conditions are considered nonemergencies.

Tip

We encourage you to use Pretty Good Privacy (PGP) or a compatible product to encrypt any sensitive information that you send to Cisco. PSIRT can work from encrypted information that is compatible with PGP versions 2.x through 8.x.

Never use a revoked or an expired encryption key. The correct public key to use in your correspondence with PSIRT is the one linked in the Contact Summary section of the Security Vulnerability Policy page at this URL:

Obtaining Technical Assistance

Cisco Technical Support provides 24-hour-a-day award-winning technical assistance. The Cisco Technical Support & Documentation website on Cisco.com features extensive online support resources. In addition, if you have a valid Cisco service contract, Cisco Technical Assistance Center (TAC) engineers provide telephone support. If you do not have a valid Cisco service contract, contact your reseller.

Cisco Technical Support & Documentation Website

The Cisco Technical Support & Documentation website provides online documents and tools for troubleshooting and resolving technical issues with Cisco products and technologies. The website is available 24 hours a day, at this URL:

Access to all tools on the Cisco Technical Support & Documentation website requires a Cisco.com user ID and password. If you have a valid service contract but do not have a user ID or password, you can register at this URL:

Note Use the Cisco Product Identification (CPI) tool to locate your product serial number before submitting a web or phone request for service. You can access the CPI tool from the Cisco Technical Support & Documentation website by clicking the Tools & Resources link under Documentation & Tools. Choose Cisco Product Identification Tool from the Alphabetical Index drop-down list, or click the Cisco Product Identification Tool link under Alerts & RMAs. The CPI tool offers three search options: by product ID or model name; by tree view; or for certain products, by copying and pasting show command output. Search results show an illustration of your product with the serial number label location highlighted. Locate the serial number label on your product and record the information before placing a service call.

Submitting a Service Request

Using the online TAC Service Request Tool is the fastest way to open S3 and S4 service requests. (S3 and S4 service requests are those in which your network is minimally impaired or for which you require product information.) After you describe your situation, the TAC Service Request Tool provides recommended solutions. If your issue is not resolved using the recommended resources, your service request is assigned to a Cisco engineer. The TAC Service Request Tool is located at this URL:

For S1 or S2 service requests or if you do not have Internet access, contact the Cisco TAC by telephone. (S1 or S2 service requests are those in which your production network is down or severely degraded.) Cisco engineers are assigned immediately to S1 and S2 service requests to help keep your business operations running smoothly.

Asia-Pacific: +61 2 8446 7411 (Australia: 1 800 805 227)
EMEA: +32 2 704 55 55
USA: 1 800 553-2447

Definitions of Service Request Severity

To ensure that all service requests are reported in a standard format, Cisco has established severity definitions.

Severity 1 (S1)—Your network is "down," or there is a critical impact to your business operations. You and Cisco will commit all necessary resources around the clock to resolve the situation.

Severity 2 (S2)—Operation of an existing network is severely degraded, or significant aspects of your business operation are negatively affected by inadequate performance of Cisco products. You and Cisco will commit full-time resources during normal business hours to resolve the situation.

Severity 3 (S3)—Operational performance of your network is impaired, but most business operations remain functional. You and Cisco will commit resources during normal business hours to restore service to satisfactory levels.

Severity 4 (S4)—You require information or assistance with Cisco product capabilities, installation, or configuration. There is little or no effect on your business operations.

Obtaining Additional Publications and Information

Information about Cisco products, technologies, and network solutions is available from various online and printed sources.

•

Cisco Marketplace provides a variety of Cisco books, reference guides, documentation, and logo merchandise. Visit Cisco Marketplace, the company store, at this URL:

•

Cisco Press publishes a wide range of general networking, training and certification titles. Both new and experienced users will benefit from these publications. For current Cisco Press titles and other information, go to Cisco Press at this URL:

•

Packet magazine is the Cisco Systems technical user magazine for maximizing Internet and networking investments. Each quarter, Packet delivers coverage of the latest industry trends, technology breakthroughs, and Cisco products and solutions, as well as network deployment and troubleshooting tips, configuration examples, customer case studies, certification and training information, and links to scores of in-depth online resources. You can access Packet magazine at this URL:

•

iQ Magazine is the quarterly publication from Cisco Systems designed to help growing companies learn how they can use technology to increase revenue, streamline their business, and expand services. The publication identifies the challenges facing these companies and the technologies to help solve them, using real-world case studies and business strategies to help readers make sound technology investment decisions. You can access iQ Magazine at this URL:

•

Internet Protocol Journal is a quarterly journal published by Cisco Systems for engineering professionals involved in designing, developing, and operating public and private internets and intranets. You can access the Internet Protocol Journal at this URL:

•

Networking products offered by Cisco Systems, as well as customer support services, can be obtained at this URL:

•

Networking Professionals Connection is an interactive website for networking professionals to share questions, suggestions, and information about networking products and technologies with Cisco experts and other networking professionals. Join a discussion at this URL:

•

World-class networking training is available from Cisco. You can view current offerings at this URL:

Table Of Contents