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.
Support for the VMS Management and Monitoring Centers (VMMC) installer on Solaris.
Simplified installation when using the VMMC installer application. You do not have to reboot the server after installing Security Monitor if other components are selected for installation. You now have to reboot only after all selected components have been installed.
Elimination of the requirement to have the Microsoft Windows Regional Options set to English (United States).
Release 1.2 contained the following new features:
Support for IDS 4.1 software.
IdsDbCompact, a new command-line utility for compacting the database.
IdsImportArchivedData, a new command-line utility that allows you to reload archived syslog messages, alert messages, and audit log messages.
IdsConvertArchive11_12, a new command-line utility that allows you to convert Security Monitor version 1.1 archive files output from IdsPruning to Security Monitor 1.2 format. After conversion, the 1.2 format files can be imported into the Security Monitor 1.2 database using the IdsImportArchivedData command-line utility.
Configuration of more than one sensing interface on a sensor if that sensor is operating with IDS 4.1 software.
Support for Security Agent MC servers. You can receive alarm data from a Security Agent MC server, view the alarms in the Event Viewer, and generate reports based on those alarms.
URLs in the Event Viewer that enables you to navigate to Security Agent MC, and from there to the rule that caused a particular event to be reported.
Support by Security Monitor for Cisco Catalyst Firewall Service Module (FWSM) and Cisco PIX Security appliance syslog reports.
The ability to save the column order in the Event Viewer display.
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 Cisco.com
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.
The following information is important to you as a user of IDS MC 1.2.3 or Security Monitor 1.2.3:
Refer to the VPN/Security Management Solution 2.2 Quick Start Guide for updated installation instructions.
Use VMS Common Services 2.2 with IDS MC 1.2.3 and Security Monitor 1.2.3. (VMS Common Services 2.1 was used with IDS MC 1.1 and Security Monitor 1.1.)
Before installing VMS 2.2, you may want to upgrade your sensors to IDS 4.1(x). For more information, refer to CSCeb33006.
Use static IP addresses for the host or hosts where IDS MC and Security Monitor are installed, because DHCP is not supported for IDS MC or Security Monitor.
Do not use download accelerator programs such as DAP, because they are not supported.
You cannot use SSH keys in IDS MC if you intend to use a sensor as a master blocking sensor.
If you see that the idsmdc.log file is growing too large with unwanted data, you can reset its size to 0 (zero) by backing up the database. Then, you can delete the backup file. (The idsmdc.log file is in the same directory as idsmdc.db, the directory that was specified for the database at installation.) Also, you can use IdsDbCompact (listed in New Features).
We strongly recommend that you do not connect to the database directly; doing so can cause performance reductions and unexpected system behavior.
Event Viewer in Security Monitor versions 1.2.3 and earlier does not support blocking when you are using sensors that are operating with IDS 4.x software.
If you do not specify the -f"filename" option when using the IdsImportIdiom command-line utility, the program reads "standard input" for data. As a result, the program waits forever for input; it will not time out or return, and you will need to abort it. Although this is not a defect, you need to be aware of this behavior to avoid misunderstanding when you use this command-line utility.
Caution: If IDS_ReportScheduler (a CiscoWorks2000 process), CiscoWorks2000, or Windows 2000 is stopped, any scheduled report that is running at the time is interrupted and its content is lost. In IDS MC 1.2, Security Monitor 1.2, and later versions of both, the Audit Log Report contains an entry noting the interruption and the lost content. But in versions earlier than 1.2, the Audit Log Report contains no such entry. This caution is particularly important if reports are scheduled to be generated repeatedly.
You can forward syslog messages on the basis of IP address/hostname and port. The IP address/hostname is a required field whose default value is localhost. If a DNS name is entered, it must resolve to an IP address at data entry time. If at any time during syslog forwarding a DNS name cannot be resolved to an IP address, an appropriate error message will be logged to the Audit Log.
When firewall reports are generated, performance may be degraded as a result of configuring both WINS and DNS on Windows 2000 servers, because it may take a long time to 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.
When firewall reports are generated, no correlation is done for sessions that involve more than one connection (such as FTP and RTSP). Each connection in a session will appear independently in the report. If the port numbers used by connections do not map to standard port numbers, they will be categorized as Unknown TCP or UDP service.
Several Security Agent MC reports have been added since the publication of Using Management Center for IDS Sensors 1.2, Using Monitoring Center for Security 1.2, and the associated context-sensitive online help. There are now seven reports available in this report group.
The ability to import 1.1 archive files into a 1.2 database has been added since the publication of Using Monitoring Center for Security 1.2 and the associated context-sensitive online help. More information on this ability using specific archive files and specific command-line utilities is presented in Importing Files Archived by IdsPruning.
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:
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.
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.
-t"date_time"
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.
-w"directoryName"
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.
-v
Specifies verbose output during command execution.
Notes for Using the IdsImportArchivedData Utility
The following problems may occur when you are importing pruning archive files:
If you receive the message Error Loading Data:, refer to CSCin46637, for more information.
If the IdsImportArchivedData utility appears to be in a wait state, refer to CSCin46479, for more information.
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:
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
CSCdx32094
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.
CSCea50683
Event Rule doesn't trigger if device natted and Orig Dev selected
This problem has been resolved.
CSCea79522
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.
CSCeb12852
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 www.cisco.com/cgi-bin/tablebuild.pl/mgmt-ctr-ids
CSCin38443
Legacy parameters are not available by using legacyIf.pl
The script LegacyIf.pl 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 LegacyIf.pl 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 LegacyIf.pl now executes as intended, subject to the following caveat:
Note The script LegacyIf.pl 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 LegacyIf.pl 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
CSCin20159
Install: Database location is not validated.
All special characters except ! and * are validated.
CSCin24314
PostOffice: Changing the PostOffice Settings gives error in UI
Changing the PostOffice settings no longer causes the NRPostOfficeD and IDS_Receiver daemons to fail.
CSCin39129
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.
CSCin41807
Help page have to be updates for SSH key usage in Solaris.
The help pages now contain the SSH information for Solaris.
CSCin44704
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 Cisco.com at the following URL:
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
CSCdx09624
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.
CSCdy10799
When clicking on the IDS MC link it spawns multiple windows
—
CSCdy46083
License Expired error when Sybase down or not available
—
CSCdy66754
SYS: severity never set to 5 in sensor
—
CSCdy68738
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.
Workaround/Solution:
The stray semaphores and shared memory can be removed by executing the cleanup routine (/opt/CSCOpx/MDC/bin/ids/rsema.sh) 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.
CSCdz11633
Change in computer name and/or ip address needs re-install
—
CSCea21026
wrong watchdog error message
—
CSCea25679
Copy-Paste with custom sigs gives strange behaviour
—
CSCea76408
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.
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.
CSCeb06855
Cannot back out a signature update
Symptom:
If a bad signature update is installed it cannot be backed out
Workaround:
Call the TAC.
CSCeb16875
Integration with MC does not work when HTTPS is on
This problem is in ACS.
Workaround:
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.
CSCeb21533
IP address not discovered right when multi NIC present on server
Symptom:
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.
IDS 4.0(2) sig updates don't work if CSAMC is installed on VMS
Symptom:
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.
Conditions:
IDS MC with CSAMC installed and you are trying to update a signature or service pack from version IDS 4.0(2).
Workaround:
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.
CSCeb55919
Misleading log entry on faulty IDS V4 config deployment
—
CSCeb58263
Sig Update terminates prematurely
Symptom:
Signature updates on multiple sensors quits working.
Conditions:
If one of the sensor has a problem, the whole process of signature updating terminates.
Workaround:
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.
CSCeb82796
IDS MC 1.2 gives Page not found error since upgrade from v1.1
Symptom:
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.
MC:Improper error handling, for failed sig updates
—
CSCin03858
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.
CSCin05666
NSDB need not be installed again after Config install.
—
CSCin05675
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.
CSCin14528
Multiple pscp existence problem
—
CSCin16694
Copy/Paste throws error on copying blocking device after import
—
CSCin19553
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.
Workaround/Solution:
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.
CSCin21186
NSDB notes have to be preserved after reinstall
—
CSCin21355
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.
Workaround/Solution:
Before uninstalling the application, delete all device configuration information from the application.
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.
Workaround:
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.
CSCin24622
Notification not sent when deploying more than 200 sensors
—
CSCin26446
Installation Fails if common framework not uninstalled
—
CSCin28783
IP Address Duplications not taken care in Copy/Paste
—
CSCin28793
MC does not recognize IDS3.x when sensor prompt changed.
—
CSCin32177
Import fails to bring filter if it contains SystemVariables on it
—
CSCin32349
Object update failed for string signatures of 3.x
—
CSCin34497
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.
CSCin35233
Max Entries should be taken care in MC
—
CSCin36019
Notification for large sensor deployment contains less information
—
CSCin37870
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.
CSCin37983
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.
Workaround:
Split the Destination Address portion so that "Internal" or "External" stays alone in one filter and the rest in a different filter.
CSCin38402
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.
CSCin38428
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.
CSCin40294
Sigupdate fails in certain scenarios
—
CSCin40419
Sig update fails, when using SSH keys for IDS 3.x sensors
—
CSCin42474
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.
CSCin42998
Signatures not getting loaded in sunfire boxes
Sometimes the signatures are not listed after installing IDS MC and Security Monitor on sunfire machines.
Workaround/Solution:
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.
CSCin44035
MC does not handle range of Internal networks for IDS3.x and I
—
CSCin44038
Sometimes signature page shows 0 of 0 after sigupdate.
—
CSCin44586
MC:Deploying to a 4.x sensor does not deploy the configuration pr
—
CSCin44590
MC:Deploy to a sensor fails when NAC is not responding
Symptom:
A deploy does not work and the IDS_DeployDaemon.log file shows Invalid CLI Command.
Conditions:
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.
Workaround:
Restart the sensor and retry the deploy.
CSCin45548
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.
CSCin45934
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.
Workaround/Solution:
None. This message does not cause any harm and can be safely ignored. The install will proceed normally.
CSCin46418
Install should not allow database on Mapped Network Drive
—
CSCin47088
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.
CSCin48168
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.
Workaround/Solution:
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.
Workaround/Solution:
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.
CSCin49207
MC:Upgrade from 1.1 to 1.2 does not show the IDS Sensor versions
—
CSCin50426
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.
CSCin61493
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.
CSCsa06100
Upgrade of Sensor from 3.x to 4.x crashes Tomcat with wrong uid/password
Symptom:
One gets and Invalid screen on the browser after attempting to upgrade a sensor from 3.x to 4.x in IDS MC.
Conditions:
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.
Workaround:
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.
Symptom:
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.
Conditions:
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.
Workaround:
None.
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 you have configured any 3.x sensors you must modify each sensor and change the IP address for the Remote Host to the new IP address of the box for each sensor. IDS MC > Configuration > Settings > Communications > Remote Hosts. Then do a generate/deploy to that sensor.
If you have configured any 4.x sensors you must modify each sensor and change the IP address for the Allowed Host to the new IP address of the box for each sensor. IDS MC > Configuration > Settings > Communications > Allowed Hosts. Then do a generate/deploy to that sensor.
If Security Monitor is installed:
The IP address of the Server Postoffice Settings will have to be changed. Security Monitor > Admin > System Configuration > PostOffice Settings > Server IP Address.
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
CSCea44060
Security Monitor cannot properly validate cert for NATed sensors
—
CSCea93893
Timezone starts showing BST from 30 Mar03 instead of GMT
—
CSCeb07136
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.
Workaround/Solution:
Use Netscape.
CSCeb13553
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.
CSCeb13677
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.
CSCeb13836
Tomcat consumes 99% cpu (no loss of network connectivity)
—
CSCeb15029
VMS2.2-BT: Browser crashes when EV is launched from XP client
Symptom:
Netscape crashes when launching or using Security Monitor event viewer on a Windows XP client.
Conditions:
Netscape 4.79, Windows XP, Security Monitor release 1.0 and 1.1.
Workaround:
Either upgrade to later version of Netscape, or, use Internet Explorer instead.
CSCeb15558
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
CSCeb15809
IDS_backup log error: TIB/Rendezvous Error not handled
—
CSCeb18384
VMS2.2-ST:Session Timeout message displayed when EV is launched
Symptom:
In certain install configurations, users will notice that the Event Viewer's session to the server will time out.
Conditions:
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.
Workaround/Solution:
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.
Monitor: File not found error found in error_log file
—
CSCin06982
Event Viewer allows to work even if the user logs out from CORE
—
CSCin14637
All EViewers hanged if any one of the EViewer hangs
—
CSCin39693
Using Discover PO settings does not show device name in EV
—
CSCin39970
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.
Workaround/Solution:
Clean the temporary directory "/var/tmp" or "/tmp".
CSCin40903
dbsrv7 process using 85% to 90% of cpu cycles
—
CSCin41741
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.
Workaround/Solution:
After stopping the EvsServer, wait for 5 minutes before restarting the daemon.
CSCin42265
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.
Workaround/Solution:
After installing a CiscoView package, manually restart the server using the following commands:
/etc/init.d/dmgtd stop
/opt/CSCOpx/MDC/bin/ids/rsema.sh
/etc/init.d/dmgtd start
CSCin43215
Audit Log timestamp for syslog events mismatch with system time
—
CSCin44099
CSV Reports: Rule filter for listbox is not working for NS4.76
Symptom:
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.
Conditions:
Windows 2000 server being accessed by Solaris Netscape 4.76 client.
Workaround:
The user can view all data included in this field when the field is selected.
Upgrading Netscape client may also provide a workaround.
CSCin44100
Reports:IP address fields are showing only 1 character in NS4.76
Symptom:
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.
Conditions:
Windows 2000 server being accessed by Solaris Netscape 4.76 client.
Workaround:
User may scroll each field x,y,z to see all characters.
Upgrading Netscape client may also provide a workaround.
CSCin45202
Backup-Restore fires notification emails
—
CSCin45809
VMS2.2-BT:NSDB does not come up after running changeport utility
Symptom:
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
Conditions:
After running this utility any further attempt to use the NSDB will fail.
Workaround:
Use of the changeport utility is not recommended.
Changing the port back to the original port setting will correct this problem.
CSCin45785
Guest user able to launch CSMC UI from Event Viewer
Symptom:
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.
Conditions:
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.
Workaround:
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.
CSCin45873
Eviewer not able to parse src address for FragDBLimitExd in FWSM
Symptom:
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 = 10.77.201.92, dest = 172.20.107.92, 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.
Conditions:
Every instance of the FragDbLimitExd syslog message
Workaround:
There is no workaround.
CSCin46479
IDSImportArchivedData waits forever when trying to import alerts
Symptom:
The utility IdsImportArchivedData waits forever when trying to import alert data.
Conditions:
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.
IdsImportArchivedData fails if alarms are in DB with same ID
Symptom:
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.
Conditions:
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.
Workaround:
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.
CSCin47050
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.
CSCin54212
Solaris Secmon with VMS megapatch not opening EV
—
CSCin61552
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.
Conditions:
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.
java.io.IOException: Broken pipe
sendUserActionToServerNoRetry failed...
attempting to reinitialize the connection...
Workaround/Solution:
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.
ie.
Add the following line to /etc/hosts.allow
ALL:127.0.0.1: ALLOW
Or
Remove the following line from /etc/hosts.deny
ALL:ALL:deny
CSCin62556
Abort DBCompact:Rollback the DB/Not allow the user to abort
Workaround:
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.
CSCin63099
Error while delete and adding PO Device using discover settings
—
CSCsa05905
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:
IDS_Receiver
IDS_ReportScheduler
IDS_Analyzer
IDS_EvsServer
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:
pdterm IDS_Receiver
pdterm IDS_ReportScheduler
pdterm IDS_Analyzer
pdterm IDS_EvsServer
The following utilities must not be run at the same time as IdsImportArchivedData:
IdsAlarms
IdsPruning
IdsImportIdiom
IdsImportNrLog
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:
pdexec IDS_Receiver
pdexec IDS_ReportScheduler
pdexec IDS_Analyzer
pdexec IDS_EvsServer
Note If this workaround does not work for you, stop and restart your CiscoWorks
system and the try the workaround again.
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.
Cisco.com
You can access the most current Cisco documentation on the World Wide Web at this URL:
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 Cisco.com users can order a single Documentation CD-ROM (product number DOC-CONDOCCD=) through the Cisco Ordering tool:
Nonregistered Cisco.com users can order documentation through a local account representative by calling Cisco Systems Corporate Headquarters (California, USA) at 408 526-7208 or, elsewhere in North America, by calling 800 553-NETS (6387).
Documentation Feedback
You can submit comments electronically on Cisco.com. On the Cisco Documentation home page, click Feedback at the top of the page.
You can send your comments in e-mail to bug-doc@cisco.com.
You can submit comments by using the response card (if present) behind the front cover of your document or by writing to the following address:
Cisco Systems Attn: Customer Document Ordering 170 West Tasman Drive San Jose, CA 95134-9883
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. Cisco.com features the Cisco TAC website as an online starting point for technical assistance.
Cisco TAC Website
The Cisco TAC website (http://www.cisco.com/tac ) 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 Cisco.com user ID and password. If you have a valid service contract but do not have a login ID or password, register at this URL:
The online TAC Case Open Tool (http://www.cisco.com/tac/caseopen ) 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:
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.
The Cisco Product Catalog describes the networking products offered by Cisco Systems, as well as ordering and customer support services. Access the Cisco Product Catalog at this URL:
Cisco Press publishes a wide range of networking publications. Cisco suggests these titles for new and experienced users: Internetworking Terms and Acronyms Dictionary, Internetworking Technology Handbook, Internetworking Troubleshooting Guide, and the Internetworking Design Guide. For current Cisco Press titles and other information, go to Cisco Press online at this URL:
Packet magazine is the Cisco quarterly publication that provides the latest networking trends, technology breakthroughs, and Cisco products and solutions to help industry professionals get the most from their networking investment. Included are networking deployment and troubleshooting tips, configuration examples, customer case studies, tutorials and training, certification information, and links to numerous in-depth online resources. You can access Packet magazine at this URL:
iQ Magazine is the Cisco bimonthly publication that delivers the latest information about Internet business strategies for executives. You can access iQ Magazine at this URL:
Internet Protocol Journal is a quarterly journal published by Cisco Systems for engineering professionals involved in designing, developing, and operating public and private internets and intranets. You can access the Internet Protocol Journal at this URL:
