Table of Contents

Release Notes for Management Center for IDS Sensors 1.2.3 and Monitoring Center for Security 1.2.3
New Features
IDS MC 1.2.3 and Security Monitor 1.2.3 Documentation
Additional Information Online
Important Notes
Known and Resolved Problems
Obtaining Documentation
Obtaining Technical Assistance
Obtaining Additional Publications and Information

Release Notes for Management Center for IDS Sensors 1.2.3 and Monitoring Center for Security 1.2.3

These release notes are for use with Management Center for IDS Sensors 1.2.3 (IDS MC) and Monitoring Center for Security 1.2.3 (Security Monitor).

These release notes contain the following information:

New Features

Release 1.2.3 is a minor update to the 1.2 release of IDS MC and Security Monitor. It incorporates several IDS MC 1.2 and Security Monitor 1.2 patches (see Known and Resolved Problems) and contains the following new features:

Note   Versions 1.2.1 and 1.2.2 of IDS MC and Security Monitor are not available as standalone updates. IDS MC and Security Monitor 1.2.1 is available in VMS 2.2 Update 1 (when installed on a server running IDS MC and Security Monitor 1.2), and the IDS MC and Security Monitor 1.2.2 release was combined with the 1.2.3 release.

Release 1.2 contained the following new features:

IDS MC 1.2.3 and Security Monitor 1.2.3 Documentation

IDS MC 1.2.3 and Security Monitor 1.2.3 use the same documentation set as IDS MC 1.2 and Security Monitor 1.2; only these release notes have changed.

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

Table 1 describes the product documentation that is available.

Table 1   Product Documentation

Document Title  Available Formats 

Release Notes for Management Center for IDS Sensors 1.2.3 and Monitoring Center for Security 1.2.3

  • Printed document that was included with the product.
  • On

Select Products & Services > Network Management CiscoWorks > CiscoWorks Management Center for IDS Sensors > Technical Documentation > Release Notes.

Installing Management Center for IDS Sensors 1.2 and Monitoring Center for Security 1.2

  • PDF on the product CD-ROM.
  • On

Select Products & Services > Network Management CiscoWorks > CiscoWorks Management Center for IDS Sensors > Technical Documentation > Installation Guides.

  • Printed document available by order (part number DOC-7815662=).1

Using Management Center for IDS Sensors 1.2

  • PDF on the product CD-ROM.
  • On

Select Products & Services > Network Management CiscoWorks > CiscoWorks Management Center for IDS Sensors > Technical Documentation > User Guides.

  • Printed document available by order (part number DOC-7815664=).1

Using Monitoring Center for Security 1.2

  • PDF on the product CD-ROM.
  • On

Select Products & Services > Network Management CiscoWorks > CiscoWorks Monitoring Center for Security > Technical Documentation > User Guides.

  • Printed document available by order (part number DOC-7815663=).1

Supported Devices and Software Versions for Management Center for IDS Sensors 1.2

  • On

Select Products & Services > Network Management CiscoWorks > CiscoWorks Management Center for IDS Sensors > Technical Documentation > Device Support Tables.

Supported Devices and Software Versions for Monitoring Center for Security 1.2

  • On

Select Products & Services > Network Management CiscoWorks > CiscoWorks Monitoring Center for Security > Technical Documentation > Device Support Tables.

Context-sensitive online help

  • Select an option from the navigation tree, and then click Help.
  • Click the Help button in the dialog box.
See the "Obtaining Documentation" section.

Additional Information Online

You can download signature updates for IDS MC and Security Monitor by logging in to at .

Important Notes

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

Importing Files Archived by IdsPruning

Security Monitor 1.2 introduces the ability to import archive files created by the IdsPruning utility. To import the pruning archive files, you use the IdsImportArchivedData utility.

The IdsImportArchivedData utility can only import archived data created with the IdsPruning utility that shipped with Security Monitor 1.2. To import pruning archives that were created by Security Monitor 1.1, you must first convert those files to the 1.2 format using the IdsConvertArchive11_12 utility.

Note   You cannot import or convert pruning archive files that were created by Security Monitor 1.0.

You can easily determine if a pruning archive file needs to be converted before importing by looking at the filename. Files created by Security Monitor 1.1 (and earlier) use the naming convention Table_Date_Time.txt. Files created by Security Monitor 1.2 use the naming convention Table_1-2_Date_Time.txt. If 1-2 does not appear in the pruning archive filename, you need to run the conversion utility before importing the data.

After converting the legacy pruning archive files to the 1.2 format, you can use the IdsImportArchivedData utility to import the archived data. Refer to the product documentation for more information about using the IdsImportArchivedData utility. Refer to the following topics for more information about converting and importing pruning archive files:

About The IdsConvertArchive11_12 Utility

IdsConvertArchive11_12 is a command-line utility used to convert pruning archive file from the 1.1 format to the 1.2 format. Converting the files allows you to import archived data from archives that were produced by the Security Monitor 1.1 IdsPrunning utility.

Command Syntax

IdsConvertArchive11_12 -r"TableList" -t"date_time" [-w"directoryName"] [-v]

Command Options


Specifies the table to convert:

  • syslog—converts the syslog event table.
  • alert—converts the alert table.
  • auditlog—converts the audit log table.

You can specify more than one table to be converted by separating the values with commas. For example, to import all three tables from the archive files, you would use -r"syslog,alert,auditlog".

This option is required.


Specifies the date and time portion of the name of archive files being converted. For example, if the archive file being converted is named alert_11072002_121647.txt, you would use -t"11072002_121647".

This option is required.


Specifies the location of the archive files. Do not use a filename with this option.

Note Version 1.1 pruning archive files use the naming convention TableType_Date_Time.txt. You do not need to specify the filename because you have already provided the table type and the date and time.

If this option is not specified, the current working directory is used by default.


Specifies verbose output during command execution.

Notes for Using the IdsImportArchivedData Utility

The following problems may occur when you are importing pruning archive files:

System Parameter Tuning on Solaris

During installation, IDS MC sets the following system parameters in the /etc/system file on Solaris:

forceload: sys/shmsys 
forceload: sys/semsys 
set shmsys:shminfo_shmmax=4294967295 
set shmsys:shminfo_shmmin=1 
set shmsys:shminfo_shmmni=256 
set shmsys:shminfo_shmseg=10 
set semsys:seminfo_semmni=4096 
set semsys:seminfo_semmsl=160 
set semsys:seminfo_semmns=4096 
set semsys:seminfo_semopm=100 
set semsys:seminfo_semvmx=32767 
set semsys:seminfo_semaem=65535 
set semsys:seminfo_semmap=66 
set semsys:seminfo_semmnu=1660 
set semsys:seminfo_semume=64 
set rlim_fd_cur=120 

If you are running other applications that use these parameters, you must increment them according to application documentation. If you change these parameters, you must reboot the system for the changes to take effect.

You can find general information about tuning the system parameters on the Sun Microsystem website:

Known and Resolved Problems

Known and resolved problems are divided into the following categories:

Resolved Problems

Resolved Problems in IDS MC 1.2.3 and Security Monitor 1.2.3

Table 2 lists known problems that have been resolved in IDS MC 1.2.3 and Security Monitor 1.2.3.

Table 2   Resolved Problems in IDS MC 1.2.3 and Security Monitor 1.2.3

Bug ID  Summary  Additional Information 


Consolidated bug to track patches for 1.2 (#3)

See the following individual bugs for more information:


sensor update S53 introduced new busy message



Not detecting errors during update



Only works in US Western version of OS

You no longer need to have the Regional Option set to English (United States). However, you still need to be using the US English version of Windows.


Sensor SP update immediately followed by sig update locks up sensor



1.4.1_02 JPI causes problems with event viewer heartbeat and EXIT



Deployment of newly upgraded 4.0 sensor doesn't work



Enhancement in sigupdate



Sensor Invalid Configuration error not handled correctly

Resolved in the Windows version of IDS MC only. This problem still applies to the Solaris version of IDS MC.


MC blocks succeeding deploys while deploying to a busy sensor



Malformed XML sent from RDEP device causes receiver to hang.



Custom Signature having problems when using special character ^

The Regexstring handles the ^ and ' characters correctly in custom signatures.


kick_registry table contains multiple entries after system restart



IDS_DbAdminAnalyzer terminates.



Stop receiving all alerts when monitoring CSAMC.



VMS2.2.x-BT: Attempts to pulldown Java Plugin 1.3.1



Restore of 1.1.1 backup to 1.2 fails



Solaris Restore DB after password change fails

Resolved in VMS 2.2 Update 1.


Java Daemons fills up daemons.log with Uninitialized event failure


Resolved Problems in IDS MC 1.2 and Security Monitor 1.2

Table 3 lists known problems that were resolved in IDS MC 1.2.

Table 3   Resolved Problems in IDS MC 1.2

Bug ID  Summary  Additional Information 


Import: Failure to import inconsistently

This is still a known problem, but it occurs in a different format. Refer to CSCin38402 in Table 6.


Signature updates over slow links fail

This problem has been resolved by a patch that is included in IDS MC 1.1.1. It has been resolved in IDS MC 1.2 also.

Also, you can work around this problem by using the procedure in Workaround for CSCea55080.


MC fails to import when the webserver is busy

This problem has been resolved.

Table 4 lists known problems that were resolved in Security Monitor 1.2.

Table 4   Resolved Problems in Security Monitor 1.2

Bug ID  Summary  Additional Information 


Unable to launch event viewer with SSL enabled

This problem has been resolved. You no longer need to use the workaround published in Release Notes for Management Center for IDS Sensors 1.0 and Monitoring Center for Security 1.0.


Event Rule doesn't trigger if device natted and Orig Dev selected

This problem has been resolved.


Rcvr Data Insertion stops if only get 1 event every 4 hrs or more

This problem has been resolved. You no longer need to use the workaround available through the Cisco Software Bug Toolkit.


Names for Custom Signatures do not display properly in event view

This problem has been resolved in IDS MC 1.2. In previous versions, the names for custom signatures are not displayed properly in the Event Viewer. The names for custom signatures are not propagated appropriately to the Event Viewer.

If the user creates custom signatures, all custom signatures show up under the same signature name (user defined) under the Security Monitor Event Viewer and Security Monitor Reports.

To work around this problem, for version 1.1.1 and 1.1, patch "idsmdc1.1.1-win-CSCeb128521.tar" is available on


Legacy parameters are not available by using

The script calls the Alarm Export utility IdsAlarms. (The Alarm Export utility is a command-line utility that provides external access to events stored in the database.)

In Security Monitor 1.1, the script did not execute properly because it contained an error. (The error was the omission of the -on parameter, which, under specific conditions with specific devices and specific software versions, causes output to be produced in NrLog format.) That error has been corrected, and the script now executes as intended, subject to the following caveat:

Note The script produces output in NrLog format, and NrLog format is valid only for version 3.x sensors. (Version 3.x sensors use the postoffice communications protocol.) The script cannot be used with data from 4.x sensors. (Version 4.x sensors use the RDEP communications protocol.)

Workaround for CSCea55080

This workaround applies to CSCea55080, "Signature updates over slow links fail."

To work around this problem, use the following procedure:

Signature updates are terminated prematurely on remote sensors. The transfer process terminates before completion and causes the signature updates to be unsuccessful over slow WAN links. This is caused by a timeout value that is too low for some networks.

To change the timeout value:

Go to the CSCOpx directory then search and locate all tucson.jar files. (If IDS  MC and Security Monitor are installed, there will be three. If only IDS MC or Security Monitor is installed, there will be two.)

Pick one and open it using your favorite zip utility.

There should be the following file in the archive: com\cisco\nm\mdc\ids\common\sigupdate\updateinfo.xml

Extract it from the archive. Now edit it. Look for /Update/IDSUpdate/Control/TransferTimeout. The value should be 1800. That's the timeout value in seconds for a transfer of the update. If you are getting about half of the transfer complete before timing out, then double this value.

Save the updateinfo.xml file.

Place the modified updateinfo.xml back into the archive, making sure that the path name to the updateinfo.xml file is correct. It should be com/cisco/nm/mdc/ids/common/sigupdate/updateinfo.xml.

Now copy the modified archive, tucson.jar, over the other two copies of it that you located in the first step.

Restart the system by executing the following commands from the <installdir>/bin directory:

pdcmd -K
pdcmd -H

Resolved Problems in IDS MC 1.2 and Security Monitor 1.2 for Solaris

Table 5 lists known problems that were resolved in the 1.2 version of Solaris IDS MC and Security Monitor.

Table 5   Resolved Problems in IDS MC 1.2 and Security Monitor 1.2 for Solaris

Bug ID  Summary  Explanation 


Install: Database location is not validated.

All special characters except ! and * are validated.


PostOffice: Changing the PostOffice Settings gives error in UI

Changing the PostOffice settings no longer causes the NRPostOfficeD and IDS_Receiver
daemons to fail.


Help contents for Syslog settings page need changes

The online help for the Syslog Settings page now reflects the procedures for setting syslog on Solaris and Windows servers.


Help page have to be updates for SSH key usage in Solaris.

The help pages now contain the SSH information for Solaris.


IDS MC & Sec Mon: Broken help links on Glossary

The broken link has been removed. For glossary information, refer to the Cisco Press book Internetworking Terms and Acronyms. This book is available (at no charge) on at the following URL: wk/ita/index.htm

Known Problems

Known Problems for IDS MC 1.2.3

Table 6 describes problems known to exist in this release of IDS MC.

Note   A "—" in the Explanation column indicates that no information was available at the time of publication. You should check the Cisco Software Bug Toolkit for current information.

Table 6   Known Problems in IDS MC 1.2.3

Bug ID  Summary  Explanation 


Uninstall should cleanup

When IDS MC/Security Monitor is uninstalled, a directory and possibly some files are not removed.

After uninstalling IDS MC/Security Monitor, cd to the directory pointed to by the TEMP environment variable. Delete the subdirectory deploy and any files in the subdirectory.


When clicking on the IDS MC link it spawns multiple windows


License Expired error when Sybase down or not available


SYS: severity never set to 5 in sensor


IDS Processes not releasing Semaphores

The IDS MC processes do not release semaphores and shared memory when the Daemon Manager is stopped. This may cause problems when the IDS MC processes are restarted.


The stray semaphores and shared memory can be removed by executing the cleanup routine (/opt/CSCOpx/MDC/bin/ids/ after stopping the daemons.

Optionally, you can download and install a patch (cmf2.2-sol-CSCin437221.tar.Z) that executes the cleanup routine when Daemon Manager is stopped.


Change in computer name and/or ip address needs re-install


wrong watchdog error message


Copy-Paste with custom sigs gives strange behaviour


Solaris: Netscape 4.76 with Java plug-ins 1.3.1 doesn't work

The Release Notes for CD One, 5th Edition on Windows 2000 (Page 10, under the heading "Support Information") claim that Solaris 2.8, Netscape 4.76, and Java Plug-in 1.3.1 constitute a supported version. However, this doesn't seem to work to access the IDS/MC component.

What does happen is this:

  • client connects to https://server:1742/
  • SSL certificate negotiations
  • client is redirected to http://server:1741/
  • Then nothing.

Using View Source to examine the final result shows Javascript which diagnoses the browser version and loads a Java applet. However, this doesn't seem to work.

When using a Windows 2000 client with Netscape 4.79 and Java VM 1.3.1, the applet loads correctly, logins are allowed, the IDS Management Center can be accessed, and sensor management functions are available.


Cannot back out a signature update


If a bad signature update is installed it cannot be backed out


Call the TAC.


Integration with MC does not work when HTTPS is on

This problem is in ACS.


By default in v.3.1, ACS can accept both HTTP and HTTPS connections for administration. The VMS MCs can only register with ACS using HTTP. In v.3.1 this is not a problem. In v.3.2, however, ACS will only accept HTTPS by default to ensure a higher security status by default. This will cause MC registration to fail if no further action is taken.

When registering a VMS MC with ACS v.3.2, turn on HTTP communications prior to registering the MC. After the MC is registered, turn off HTTP acceptance. The proper fix is to have the VMS MC communicate with ACS using HTTPS during registration.


IP address not discovered right when multi NIC present on server


When installing IDS MC/Security Monitor on a machine that has multiple NIC (Network Interface Cards), the installation program does not give the user the choice of which NIC address to use. The installation program picks the "first" NIC found.


If the machine has multiple NIC.


Use the procedure in Workaround for CSCeb21533



Customer may detect the following error in the IDS_DBAdminAnayzer.log, Execing: cmd.exe /C dir c:\PROGRA~1\CSCOpx\MDC\Sybase\DB\IDS\idsmdc.db

An unexpected exception has been detected in native code outside the VM.

Unexpected Signal: EXCEPTION_ACCESS_VIOLATION occurred at PC=0x1204683a

Function name=DOM_Node::getNodeName


There is no known workaround.


TLS: does not check if signing keys are authorized for signing

This problem is in the IDS software.

Refer to Explanation of CSCeb30898.


IDS 4.0(2) sig updates don't work if CSAMC is installed on VMS


IDS MC audit log indicates that the signature update succeeded but the checking the sensor, the signature update did not complete. This happens only if IDS MC and CSAMC is installed.


IDS MC with CSAMC installed and you are trying to update a signature or service pack from version IDS 4.0(2).


Upgrade your sensor to IDS 4.1(1). This can be done either manually by upgrading the sensor and the IDS MC separately or you should upgrade the sensor to IDS 4.1(1) before installing CSAMC onto the VMS server.


Misleading log entry on faulty IDS V4 config deployment


Sig Update terminates prematurely


Signature updates on multiple sensors quits working.


If one of the sensor has a problem, the whole process of signature updating terminates.


The user must stop the system remove the bad sensor from the update list and restart the system. This will clear an internal flag and allow updating to continue.

Further Problem Description:

Sometimes when updating a group of sensors, one of the signature updates will fail. This can happen if the password entered is incorrect or the sensor is down. When this happens, a flag is set and no more signature updates is allowed. The only way to clear this flag is to reset the system.


IDS MC 1.2 gives Page not found error since upgrade from v1.1


One of my Customer upgraded from VMS 2.1 to 2.2 which includes IDS MC 1.2. When I click on "IDS sensors" under VMS, I get a "page cannot be found" IE page.


Errors in mod_jk.log file:

[Thu May 29 12:02:14 2003]  [jk_ajp13_worker.c (381)]: Error ajp13_process_callback - write failed
[Thu May 29 12:02:14 2003]  [jk_ajp13_worker.c (383)]: 

Errors in (Apache) error.log file:

[Wed Jul 30 11:44:33 2003] [warn] Loaded DSO modules/mod_jk.dll uses plain Apache 1.3 API, this module might crash under EAPI! (please recompile it with -DEAPI)
[Wed Jul 30 11:44:34 2003] [notice] Initializing etag from d:/program files/cscopx/mdc/apache/etag-state
[Wed Jul 30 11:44:34 2003] [notice] Initializing etag from d:/program files/cscopx/mdc/apache/logs/etag-state


None at this time


MC:Improper error handling, for failed sig updates


Install : Temporary directory not cleared after install is over

After installing IDS MC/Security Monitor, temporary installation files are left on the machine.

To fix, check the directory that the TEMP environment variable is set to. Remove any temporary files/directories that are not needed.


NSDB need not be installed again after Config install.


Install : Temp environment variable not read properly.

After installing IDS MC/Security Monitor, temporary installation files are left on the machine.

If the TEMP environment variable is not in the DOS 8.3 file name format, the temp directory is incorrectly created.

To fix, check to see if the TEMP environment variable is in DOS 8.3 file name format. If not, check at each directory level for directories/files that were left over.

If the TEPM environment variable is c:\1\2\3, check c:\1 for left over files. Check c:\1\2 for left over files. Check c:\1\2\3 for left over files.


Multiple pscp existence problem


Copy/Paste throws error on copying blocking device after import


Daemons.log getting increased in size by db exceptions

The size of the daemons.log file increases unbounded when one or both of the following conditions occur:

  • The free space in /opt partition becomes very low
  • The licence expires that will end up crashing /var file system

When either of these conditions occur, the daemons throw exceptions to the daemons.log file. This results in quick increase in size of daemons.log file; within 10 minutes the size can increase to more than 600 MB.


Verify that you have a valid license file. If you are using a 90-day evaluation license, make sure you upgrade the license before the 90-day evaluation period expires.

Make sure /opt partition does not run out of free disk space.


NSDB notes have to be preserved after reinstall


INSTALL: uninstalling application should remove data from db

Data from a previous installation may appear when either IDS MC or Security Monitor are reinstalled on the server.

When IDS MC and Security Monitor are installed on the same server, they share a common database. When only one of the two applications are uninstalled, the data for that application remains in the database. This causes data that may have been entered in a previous installation to appear in the application when it is reinstalled.


Before uninstalling the application, delete all device configuration information from the application.


License: Editing device throws license exceeded error

If 20 Device license installed on IDS MC/Sec Mon server, the system will allow us to add up to 20 devices in MC as well as Sec Mon, where as if we try to edit one of the 20 device, the system will not allow to save the changes. It will throw the error message of device license exceeding.


For editing any field in one of the 20 device, we can delete the respective device first and add it again, or we can delete some other device and edit the respective device and then we can add the deleted device.


Notification not sent when deploying more than 200 sensors


Installation Fails if common framework not uninstalled


IP Address Duplications not taken care in Copy/Paste


MC does not recognize IDS3.x when sensor prompt changed.


Import fails to bring filter if it contains SystemVariables on it


Object update failed for string signatures of 3.x


Problems with the filtering on the sensorname for Reports

When selecting a device for a Config Import Report via the report filter, records for other devices may be included in the report body along with the selected device.

In order to see the problem, the selected device name must be a substring of the name of another device which is managed by the application.

There are no known workarounds.

When generating a report, each record's text is searched for a match on the device name selected via the report filter. When one device name happens to be a substring of another device in the system, a positive match will occur when records for the other device are encountered.


Max Entries should be taken care in MC


Notification for large sensor deployment contains less information


Enabling or disabling of signatures does not work properly

If the user "Enables" all signatures, user can not revert back to previous configuration of signatures even if changes are not saved. This will also happen when "Disabling" all the signatures.There is no workaround for this.


Multiple Destination entries in filters not taken care during dep

While configuring filters using IDS MC, if the user specifies "Internal" or "External" and then append more IP addresses in the Destination Address portion of the filter, the appended IP Addresses may not get written in the sensor configuration.


Split the Destination Address portion so that "Internal" or "External" stays alone in one filter and the rest in a different filter.


Import fails inconsistently when service.mssql custom sigs exist

To work around this problem, import the sensor again. You may need to re-import the sensor more than once.


MC reports deploy status as error when a sensor is deployed wit

When any changes to the Webserver service is done to an IDS4.x and deployed to the sensor MC might report that deploy failed and it could not deploy the config to the sensor during the specified watchdog timeout. Deploy would have completed properly but MC will not be able to confirm whether the sensor has properly started after rebooting. Users may need to check manually whether the changes have been pushed to the sensor in this case.


Sigupdate fails in certain scenarios


Sig update fails, when using SSH keys for IDS 3.x sensors


Downgrading Signature version using query sensor does not update

Downgrading a sensor is not considered a normal activity. Support for downgrading a sensor will be added to a future version of IDS MC.

A workaround is to remove the sensor from the MC, downgrade it, then add the sensor back to the MC.


Signatures not getting loaded in sunfire boxes

Sometimes the signatures are not listed after installing IDS MC and Security Monitor on sunfire machines.


Run the script under: <install_dir>/MDC/bin/ids/loadsig

Restart the process, any sensors added before running this script will not list its signatures. To list the signatures the sensor needs to be deleted and added again into the MC.


MC does not handle range of Internal networks for IDS3.x and I


Sometimes signature page shows 0 of 0 after sigupdate.


MC:Deploying to a 4.x sensor does not deploy the configuration pr


MC:Deploy to a sensor fails when NAC is not responding


A deploy does not work and the IDS_DeployDaemon.log file shows Invalid CLI Command.


This occurs if the sensor processes are in an unusable state. Example is the NAC is not responding. You can determine this by logging on to the sensor and typing "show version". The sensor will show the state of all its running processes. If the Network Access Controller (NAC) or any other process is not "running" then the IDS MC cannot deploy to that sensor.


Restart the sensor and retry the deploy.


Import/Deploy using keys will not work for IDSM3.0(5)

IDS MC will not be able to communicate with IDSM using keys with versions less than 3.0(6). Users need to move to IDSM service pack version IDSM3.0(6) if they want the IDS MC to manage IDSM using keys.


Install says sunfire as not a recommended model

While installing IDS MDC, the following warning message might appear on a sunfire machine:

WARNING: Not a recommended computer model. Please refer to the
WARNING: prerequisites chapter of the install guide.


None. This message does not cause any harm and can be safely ignored. The install will proceed normally.


Install should not allow database on Mapped Network Drive


Tomcat Hogs After Database Restore

After restoring a backed-up database and restarting the daemons, Tomcat may hog the system resources. This problem is not as bad in later versions of IDS MC.


Management Center: Object selector stops working sometimes.

The object selector under the Configurations tab does not work reliably with Netscape Navigator on Solaris. Some of the issues are:

  • Launching the Configuration screen causes the browser to stop responding.
  • The object selector functions normally at first, but stops functioning after heavy usage.
  • You are not able to select sensor/group from the object selector.


Reload the configuration screen. You can then select the device and proceed with configuration.


Blocking Devices should not be allowed in groups


MC:UI doesn't validate Internal Networks netmask properly


Uninstalling after a custom path reinstall fails to remove DB.

The database in custom path does not get removed during the uninstall in the following scenario:

  • Install CMF in custom path /opt/CSC, Database in /opt/MDCDB
  • Install MC and Sec Mon
  • Reinstall MC and Sec Mon
  • Uninstall both MC and Sec Mon

The idsmdc.db is not removed. The bug is reproduced during reinstall.


Remove the database manually.

Note If you uninstall only one of the two applications, do not delete the database. IDS MC and Security Monitor share a database, and deleting the database will cause your remaining application to stop functioning.


MC:Upgrade from 1.1 to 1.2 does not show the IDS Sensor versions


IDS MC cannot manage IDSM3.x using keys.

Public key communication with IDSM3.0(6)S42 will not work if the user changes the password of the IDSM after adding the MC's public key. More detailed information can be found in CSCeb62365.


3.x Sigupdate fails in MC if sensor is deleted from MC

A 3.x Signature Update to MC fails in the following scenario:

Add a 3.x sensor to MC & attempt to do a SigUpdate to it.

During SigUpdate enter invalid root password when asked.

Signature Update will fail due to this.

Now delete the sensor from MC & try applying the same SigUpdate to the MC (not the sensor).

Signature Update to MC fails with an Error:

Object update failed. Unable to start update for the sensors, an error occurred creating the sensor list.

SigUpdate proceeds fine, when the deleted sensor is imported again into MC.


Upgrade of Sensor from 3.x to 4.x crashes Tomcat with wrong uid/password


One gets and Invalid screen on the browser after attempting to upgrade a sensor from 3.x to 4.x in IDS MC.


Sensor is manually update from IDS 3.x to IDS 4.x.

The password is changed on the sensor.

The user tries to upgrade the sensor (Configuration->Upgrade) without correcting the userid/password.


Restart Tomcat if necessary.

Go to the Settings->Identification page and correct the userid/password.

Then proceed with upgrade.

Explanation of CSCeb30898

This problem is in the IDS software.


An attacker can create a TLS host certificate and sign it with a certificate that is not authorized for signing if the attacker is in possession of the certificate and its associated private key.


The victim is running IDS sensor software 4.1(1). To resolve a connectivity problem, CSCeb30820, exposed this vulnerability. It was decided that the vulnerability's severity is low enough that the connectivity issue was of greater importance.



Further problem description:

The IDS software TLS client processes X.509 certificates without checking if the certificate is authorized for signing. This was not an issue until CSCeb30820 changed the maxCertificateChainDepth to 2. (In IDS software versions 4.0[1] and 4.0[2], it had been 1.)

Suppose a sensor "S" trusts a TLS server "A". An attacker is able to compromise "A" and gain access to its certificate and private key. The attacker creates a new certificate "V" that is signed by "A". Now the attacker sets up an attack server, and configures it to return the certificate chain ("V", "A").

Finally, the attacker tricks "S" into visiting "V". "S" connects to "V" without complaint, because "V" is signed by "A", and "S" trusts "A".

The IDS sensor ships with no predefined trusted root CAs, so there is no single certificate "A" that an attacker can exploit. This attack will therefore require that the attacker be able to compromise "A" and trick "S".

Workaround for CSCeb21533

This workaround applies to CSCeb21533, "IP address not discovered right when multi NIC present on server."

To work around this problem, use the following procedure:

Stop CiscoWorks Daemon manager.

Edit the following file: <install dir>\CSCOpx\MDC\etc\ids\xml\SystemConfig.xml

Find the line that looks like: <HostIP>x.x.x.x</HostIP>.

Change x.x.x.x to the correct IP address.

If you have IDS MC installed, copy the file just edited to <install dir>\CSCOpx\MDC\Tomcat\vms\ids-config\web-inf\classes\com\cisco\nm\mdc\ids\common\SystemConfig.xml.

If you have Security Monitor installed, copy the file just edited to <install dir>\CSCOpx\MDC\Tomcat\vms\ids-monitor\web-inf\classes\com\cisco\nm\mdc\ids\common\SystemConfig.xml.

Restart CiscoWorks Daemon Manager.

Caution   Observe the following notes for IDS MC and Security Monitor installations.

If IDS MC is installed:

If Security Monitor is installed:

Known Problems in Security Monitor 1.2.3

Table 7 describes problems known to exist in this release of Security Monitor.

Note   A "—" in the Explanation column indicates that no information was available at the time of publication. You should check the Cisco Software Bug Toolkit for current information.

Table 7   Known Problems in Security Monitor 1.2.3

Bug ID  Summary  Explanation 


Security Monitor cannot properly validate cert for NATed sensors


Timezone starts showing BST from 30 Mar03 instead of GMT


Table Of Contents in IE GUI covered in Grey Lines

Under certain circumstances customers may observe grey lines covering the TOC fields on IDSMC 1.1 and the Security Monitor.


Use Netscape.


Apache errors if SecMon SA MC device created w/o CSAMC

This defect is caused when a CSAMC device is added to the monitored device table before it has been installed. The work around is to install the CSAMC software before placing the device in the table. If the device has already been added, delete it and then install the CSAMC software and re-add it to the table.


SecMon 1208: CSAMC collector client exception

This message indicates that the Security Monitor attempted to connect to the CSAMC and failed. This failure is due to the fact that the CSAMC was placed in the Security Monitor device table before installing CSAMC and this is the expected behavior. The device should not be added to the device table until it is ready to receive requests from Security Monitor. Security Monitor is designed to begin polling for information from its devices as soon as they are in the device table.


Tomcat consumes 99% cpu (no loss of network connectivity)


VMS2.2-BT: Browser crashes when EV is launched from XP client


Netscape crashes when launching or using Security Monitor event viewer on a Windows XP client.


Netscape 4.79, Windows XP, Security Monitor release 1.0 and 1.1.


Either upgrade to later version of Netscape, or, use Internet Explorer instead.


Top Sources Report doesn't include alarm details w/dest specified

If you use Security Monitor to generate reports you will not see the "Source Alarm Details" section if you specify a destination IP address when generating the report.

In Security Monitor if you go to Reports > Generate and keep the Destination IP Address as any and generate a report you will get "Source Alarm Summary" and "Source Alarm Details" outputs. If you specify an address with "single" at "Destination Address" and generate a report you will only get the "Source Alarm Summary" output with the report.

This worked with 1.0, not 1.1 or 1.1.1


IDS_backup log error: TIB/Rendezvous Error not handled


VMS2.2-ST:Session Timeout message displayed when EV is launched


In certain install configurations, users will notice that the Event Viewer's session to the server will time out.


This is seen when the Security Monitor is installed on the same server with certain other CiscoWorks applications (e.g., RME) that require the SSLInitializer plugin. The presence of the SSLInitializer plugin causes connections from Java applets to the server to be made outside of the context of the rest of the client's (browser's) connection space. This causes connection validation attempts to fail. When the server cannot validate the Event Viewer's connection, it will not proceed to allow that applet to update it's activity flags. Thus, when the Event Viewer applet is open on the screen for longer than the timeout period (on the order of 2 hours), it cannot update its session activity flags, and it will time out.


The Event Viewer operates as expected (without timing out) when the SSLInitializer plugin is not installed on that server. The timeout can also be remedied by moving off of the Event Viewer page and then back onto it (re-launching the Event Viewer).

This issue will be resolved when the 1.4.1 Java Runtime Environment plugin is provided by CiscoWorks, since it will eliminate the need for the SSLInitializer.


Tomcat stderr log:


SecMon installs --> ajp13_process_callback - write fail


-on/-oo options of idsalarms.exe do not work

Can not generate nrlog/oracle format log from IDS Event generated by MC.


idsalarms.exe -oo(or -on) command can be issued but 0 sized file are generated. But can generate xml format log which is the default.

Affected SW

-IDS MC 1.0

-IDS MC 1.2




DB deadlock when audit log is pruned while report is generating


Application Status options is not available

Under Monitor menu, the Application Status options is not available although it is documented under


Monitor: File not found error found in error_log file


Event Viewer allows to work even if the user logs out from CORE


All EViewers hanged if any one of the EViewer hangs


Using Discover PO settings does not show device name in EV


Unable to launch event viewer, generate reports when temp dir full

Report Scheduler will fail to generate report if the temp directory is not having enough space. Since report scheduler will store the report in the temporary location before moving into the database if enough space is not there then report will not be created.


Clean the temporary directory "/var/tmp" or "/tmp".


dbsrv7 process using 85% to 90% of cpu cycles


Socket error after restarting EvsServer.

Stopping the EvsServer using pdterm and restarting it immediately causes the EventViewer to not function correctly and throws a "Socket communication error".

When the EvsServer is terminated using pdterm, EvsServer tears down the connection and makes the Tomcat Applet client to go to TIME_WAIT state. The Solaris OS will not release the port number until tcp_time_wait_interval, 240000ms (4min), expires.


After stopping the EvsServer, wait for 5 minutes before restarting the daemon.


IDS_EvsServer doesn't start after a restart from browser.

When you install a CiscoView package, the installer restarts the server. After the server restart, IDS_EvsServer does not restart.


After installing a CiscoView package, manually restart the server using the following commands:

/etc/init.d/dmgtd stop
/etc/init.d/dmgtd start


Audit Log timestamp for syslog events mismatch with system time


CSV Reports: Rule filter for listbox is not working for NS4.76


Older versions of Netscape do not render screens properly.

For the CSV Report "CSA Events By Severity" the Rule filter is not shown as a list box. All of the rule filters are listed but there is no scroll bar.


Windows 2000 server being accessed by Solaris Netscape 4.76 client.


The user can view all data included in this field when the field is selected.

Upgrading Netscape client may also provide a workaround.


Reports:IP address fields are showing only 1 character in NS4.76


Older versions of Netscape do not render screens properly. IP numbers on the report filter screen do not display with three digit width.

IP formats of x12.y12.z12 may display as x.y.z on the report filter input fields.


Windows 2000 server being accessed by Solaris Netscape 4.76 client.


User may scroll each field x,y,z to see all characters.

Upgrading Netscape client may also provide a workaround.


Backup-Restore fires notification emails


VMS2.2-BT:NSDB does not come up after running changeport utility


NSDB (database) lookups from the Security Monitor Event viewer may fail after executing the changeport utility in VMS 2.2 bundle. The changeport utility can be found at the following location:

<CSCOpx dir>\lib\web\changeport


After running this utility any further attempt to use the NSDB will fail.


Use of the changeport utility is not recommended.

Changing the port back to the original port setting will correct this problem.


Guest user able to launch CSMC UI from Event Viewer


Users logged into Security Monitor with less than write permissions may be able to access the Security Agent MC with a higher level of permission. This is done by selecting the "Launch CSAMC Details" menu item from the Event Viewer when viewing SA events. By manually manipulating the URL, access to the entire SA MC can be gained.


When the SA MC is entered as a device in Security Monitor, the privileges for the specified username/password are used when authenticating the URL used to launch the CSAMC details. This is to say that connection and authentication to the SA MC are independent of the privileges that the user currently logged in to Security Monitor is afforded. Therefore, if the SA MC was entered with administrator privileges, the CSAMC details will be launched with administrator privileges even though the current Security Monitor user may be logged in with guest privileges.


If the Security Monitor user wishes to restrict permissions on the SA MC, an appropriate username/password combination for the desired privilege level should be provided when entering the SA MC device into the Security Monitor. I.e., to restrict SA MC access to helpdesk level, provide a username and password for a user account having only helpdesk privileges. All access to that SA MC via the Security Monitor will be at the level afforded the specified login account, regardless of the privilege level of the Security Monitor user.


Eviewer not able to parse src address for FragDBLimitExd in FWSM


Event Viewer cannot extract the src address from the following syslog message from the Firewall Service Module:

209003: Fragment database limit of 0 exceeded: src =, dest =, proto = icmp, id = 11788

src address is shown as n/a in the Security Monitor event viewer if you open the following event type:

PIX Fragment DB Limit Exceeded.


Every instance of the FragDbLimitExd syslog message


There is no workaround.


IDSImportArchivedData waits forever when trying to import alerts


The utility IdsImportArchivedData waits forever when trying to import alert data.


This occurs when some combination of daemons and utilities running leaves a database lock on the table storing the alert data. This lock prevents the data from being imported.


Refer to Workaround for CSCin46479.


IdsImportArchivedData fails if alarms are in DB with same ID


Running the utility IdsImportArchivedData, you get output similar to the following:

Error Loading Data: Error writing ALERT Data: SybaseESql::executeSql EXECUTE Primary key for table 'ALERT_TABLE' is not unique.

Alert Import Terminated.


The database uses a unique id for each record stored. The IdsImportArchivedData utility brings data back into the database using a reload data command. This utility does not generate a unique ID for the database, but uses the ID in the exported record. If for some reason the exported ID has been re-used, the data can not be imported.

When the data inserter (IDS_Receiver) is started, it searches the database for the largest currently used unique id and then starts counting from there. If a user deletes all data in the database or deletes the newest data in the database and then restarts IDS_Receiver, unique ID's that were exported may be re-used. This would keep data from being able to be re-imported.


The workaround for this issue is to delete the data in the database with the overlapping unique IDs. IdsPruning can be used to archive data in the database to allow importing of previously archived data.


Event Rule doesn't trigger for natted CSAMC if Orig Device selected

If a NATted address must be used to contact a CSA MC device, the user should not reference that device as the "Originating Device" in a clause of the event rule filter. Instead the user should use "Originating Device Address" and specify the local address (not the NATted address) of the CSA MC device.

The originating device in this context refers to the CS Agent residing on the same box as the CSA MC. Messages sent to Security Monitor through the CSA MC that did not come from the CS Agent on that box will not trigger the rule.


Solaris Secmon with VMS megapatch not opening EV


TCP Wrapper could block Event Viewer functionality.

If TCP Wrapper is configured to block the tcp communication between two applications running on the vms server. Then it will block the communication between EvsServer and EventViewer.


EventViewer will not launch in such cases.

On debugging the issue, observed that following log messages appears in the ~/MDC/tomcat/logs/stdout.log.

sendUserActionToServerNoRetry, writeUTF failed. Broken pipe
sendUserActionToServerNoRetry failed...
attempting to reinitialize the connection... 


To fix this issue, the TCP Wrapper configuration which blocks the tcp connection between two services need to be removed and the vms server need to be restarted.


Add the following line to /etc/hosts.allow



Remove the following line from /etc/hosts.deny



Abort DBCompact:Rollback the DB/Not allow the user to abort


The user can check if there is any backed up copy of the database (named idsmdc.db.orig) in the location <install-dir>\MDC\Sybase\Db\IDS and retrieve it following the steps below.

1. Stop the daemon manager.

2. Rename the idsmdc.db and idsmdc.log from <install-dir>\MDC\Sybase\Db\IDS to say, idsmdc.db.old and idsmdc.log.old

3. Copy the idsmdc.db.orig to <install-dir>\MDC\Sybase\Db\IDS\idsmdc.db

4. Copy the idsmdc.log.orig to <install-dir>\MDC\Sybase\Db\IDS\idsmdc.log

5. Start the daemon manager.


Error while delete and adding PO Device using discover settings


DBCompact:Check for sufficient disk space before starting DB compact

Workaround for CSCin46479

This workaround applies to CSCin46479, "IDSImportArchivedData waits forever when trying to import alerts."

When this problem occurs, all systems that could possibly access the alert data must be shut down.

The following daemon subsystems must be shut down:

Daemon subsystems can be shut down through the GUI or through the command line.

To stop the daemon subsystems through the GUI, follow these steps:

Step 1   Log in to CiscoWorks.

Step 2   Select the Server Configuration drawer.

Step 3   Select Administration > Process Management > Stop Process.

Step 4   Select each process and click Finish.

To stop the daemon subsystems through the Command Line, enter the following at the command prompt:

The following utilities must not be run at the same time as IdsImportArchivedData:

After completing the data import, you can restart the daemons from either the GUI or the command line:

To restart the daemon subsystems from the GUI, follow these steps:

Step 1   Log in to CiscoWorks.

Step 2   Select the Server Configuration drawer.

Step 3   Select Administration > Process Management > Start Process.

Step 4   Select each process and click Finish.

To restart the daemon subsystems from the Command Line, enter each of the following at the command prompt:

Obtaining Documentation

Cisco provides several ways to obtain documentation, technical assistance, and other technical resources. These sections explain how to obtain technical information from Cisco Systems.

You can access the most current Cisco documentation on the World Wide Web at this URL:

You can access the Cisco website at this URL:

International Cisco websites can be accessed from this URL:

Documentation CD-ROM

Cisco documentation and additional literature are available in a Cisco Documentation CD-ROM package, which may have shipped with your product. The Documentation CD-ROM is updated regularly and may be more current than printed documentation. The CD-ROM package is available as a single unit or through an annual or quarterly subscription.

Registered users can order a single Documentation CD-ROM (product number DOC-CONDOCCD=) through the Cisco Ordering tool: ool_launch.html

All users can order annual or quarterly subscriptions through the online Subscription Store:

Ordering Documentation

You can find instructions for ordering documentation at this URL:

You can order Cisco documentation in these ways:

Documentation Feedback

You can submit comments electronically on On the Cisco Documentation home page, click Feedback at the top of the page.

You can send your comments in e-mail to

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

We appreciate your comments.

Obtaining Technical Assistance

For all customers, partners, resellers, and distributors who hold valid Cisco service contracts, the Cisco Technical Assistance Center (TAC) provides 24-hour, award-winning technical support services, online and over the phone. features the Cisco TAC website as an online starting point for technical assistance.

Cisco TAC Website

The Cisco TAC website ( ) provides online documents and tools for troubleshooting and resolving technical issues with Cisco products and technologies. The Cisco TAC website is available 24 hours a day, 365 days a year.

Accessing all the tools on the Cisco TAC website requires a user ID and password. If you have a valid service contract but do not have a login ID or password, register at this URL:

Opening a TAC Case

The online TAC Case Open Tool ( ) is the fastest way to open P3 and P4 cases. (Your network is minimally impaired or you require product information). After you describe your situation, the TAC Case Open Tool automatically recommends resources for an immediate solution. If your issue is not resolved using these recommendations, your case will be assigned to a Cisco TAC engineer.

For P1 or P2 cases (your production network is down or severely degraded) or if you do not have Internet access, contact Cisco TAC by telephone. Cisco TAC engineers are assigned immediately to P1 and P2 cases to help keep your business operations running smoothly.

To open a case by telephone, use one of the following numbers:

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

For a complete listing of Cisco TAC contacts, go to this URL:

TAC Case Priority Definitions

To ensure that all cases are reported in a standard format, Cisco has established case priority definitions.

Priority 1 (P1)—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.

Priority 2 (P2)—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.

Priority 3 (P3)—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.

Priority 4 (P4)—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. protocol_journal.html

This document is to be used in conjunction with the documents listed in the "IDS MC 1.2.3 and Security Monitor 1.2.3 Documentation" section.

Copyright © 2003, Cisco Systems, Inc. All rights reserved.

Posted: Thu Dec 18 13:26:26 PST 2003
All contents are Copyright © 1992--2003 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.