Table of Contents

Release Notes for Management Center for IDS Sensors 1.2 and Monitoring Center for Security 1.2
New Features
IDS MC 1.2 and Security Monitor 1.2 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 and Monitoring Center for Security 1.2

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

IDS MC manages configurations for up to 300 Cisco Intrusion Detection System Sensors. You use a series of web-based screens to manage all aspects of sensor configuration. You can manage individual sensors, and you can manage groups of sensors having a common configuration. The sensor configuration data resides in a database.

Security Monitor is a separate but closely related application that provides event collection, viewing, and reporting capability for network devices. Security Monitor uses a series of web-based screens that have the same look and feel as those used by IDS MC.

These release notes contain the following information:

New Features

Release 1.2 contains the following new features:

IDS MC 1.2 and Security Monitor 1.2 Documentation

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 and Monitoring Center for Security 1.2

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

    a. Log in to

    b. 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

    a. Log in to

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

  • 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

    a. Log in to

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

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

Using Monitoring Center for Security 1.2

  • PDF on the product CD-ROM.
  • On

    a. Log in to

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

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

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

1. Log in to

2. 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

1. Log in to

2. 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, 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 or Security Monitor 1.2:

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 attempt to resolve IP addresses to a hostname when the IP address does not exist in DNS or WINS. Security Monitor will automatically disable 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 if you observe an excessively long report generation time.

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 file name. 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 file name, 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.

Known and Resolved Problems

The known and resolved problems are divided into the following categories:

Known and Resolved Problems for IDS MC 1.2

Table 2 describes problems known to exist in this release of IDS MC; Table 3 describes problems resolved since the previous release of IDS MC.

Table 2   Known Problems in IDS MC 1.2

Bug ID  Summary  Explanation 


Deployment of newly upgraded 4.0 sensor doesn't work

After upgrading a 4.0 sensor with IDS MC, you are not able to deploy further config to it.


Delete the sensor from the MC and re-import it.


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.


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: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.


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.


Install should not allow database on Mapped Network Drive

[not available]


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.

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:

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 2.


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.


Sig Updates do not work past IDS 4.0(2)S42

This defect has been resolved in IDS MC 1.2.

In earlier versions of IDS MC, you cannot apply signature updates to a sensor using any port other than 443. Resolution of this problem is dependent upon the resolution of IDS Software Defect CSCeb29744. To work around this problem, you can apply updates separately to the IDS MC and the sensors.


MC fails to import when the webserver is busy

This problem has been resolved.

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

Known and Resolved Problems in Security Monitor 1.2

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

Table 4   Known Problems in Security Monitor 1.2

Bug ID  Summary  Explanation 


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.


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


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).

Further Problem Description:

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.


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.


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.

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:

Table 5   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:

Caution   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.)

More information on the script is available in Discussion of the Script. For instance, that section discusses the script with ONLY 3.x sensors and with both 3.x and 4.x sensors.

Discussion of the Script

The script in Security Monitor executes a query against the database and outputs all matching alarms for the event filter to a temp file. It then finds the most recent alarm in the set, parses the alarm fields, and calls the Security Monitor utility with the alarm field arguments. The script in Security Monitor is applicable to event rules only, not database rules.

The alarm data passed to the script is not necessarily the exact alarm that crossed the threshold due to the intervals used for threshold processing.

Security Monitor provides local and UTC timestamps in time_t format, but this data is not available via the script. These values are passed to the script as 0 every time.

Caution   The 4.x sensor introduces a new alarm format that is so different from 3.x alarms that older CSPM scripts are not compatible. If your network contains ONLY 3.x sensors, the script (and existing CSPM scripts) will still work. However, if any 4.x sensors are present in your network, the script will not work as desired. Existing CSPM scripts cannot be used to support 4.x alarms. 3.x alarms are converted automatically to the new format. Therefore, mixed environments are supported. However, 4.x alarms cannot be converted to the old format, so mixed environments cannot be supported with 3.x format.

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

Table 6 describes problems known to exist in IDS MC and Security Monitor for Solaris; Table 7 describes the problems that have been resolved since the previous release of IDS MC and Security Monitor for Solaris.

Table 6   Known Problems in IDS MC 1.2 and Security Monitor 1.2 for Solaris

Bug ID  Summary  Explanation 


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".


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.


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.


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.


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


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.


Solaris Restore DB after password change fails

During backup and restore of the MC database if the users change the database password after backup then restore will fail. Users will not be able to connect to the database after restore.


Change the database password to the older password using the Database credentials before restoring the database if the database password was changed after backup.


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.


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.


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.


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.


Sensor Invalid Configuration error not handled correctly

Starting with sensor version 4.0(2) the CLI syntax for the Invalid Configuration error message was changed. The impact is that the sensor's event error log is not added to the audit log so the user is left wondering what is invalid in the configuration.


When you see an Invalid Configuration error message, ssh to the sensor and issue a show events error command.

Table 7   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

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 and Security Monitor 1.2 Documentation" section.

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

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