Table Of Contents
Release Notes for Cisco Security MARS Appliance 4.3.4
Miscellaneous Changes and Enhancements
Downloading the Upgrade Package from CCO
Checklist for Initial Configuration
Resolved Caveats - Release 4.3.4
Resolved Caveats - Releases Prior to 4.3.4
Obtaining Documentation, Obtaining Support, and Security Guidelines
Release Notes for Cisco Security MARS Appliance 4.3.4
Revised: April 21, 2008, OL-16372-01
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.
These release notes are for use with the Cisco Security Monitoring, Analysis, and Response System (MARS), Version 4.3.4 running on any supported Local Controller or Global Controller as defined in Supported Hardware. They provide the following information:
•
Introduction
Version 4.3.4 is now available as an upgrade to 4.3.3 of your MARS Appliance software. Registered SMARTnet users under the can obtain version 4.3.4 from the Cisco support website at:
http://www.cisco.com/pcgi-bin/tablebuild.pl/cs-mars
Supported Hardware
Cisco Security MARS Version 4.3.4 supports the following Cisco Security MARS and Protego Networks MARS appliances:
Local Controller Appliances
•
•
•
•
•
•
•
•
•
•
•
Global Controller Appliances
•
•
•
•
New Features
In addition to resolved caveats, this release includes the following new features:
•
Miscellaneous Changes and Enhancements
The following changes and enhancements exist in 4.3.4:
•
Additional improved support includes:
–
–
–
–
–
•
In versions prior to x.3.4, all network groups, networks, and devices in the source and destination fields of rules and reports on the Global Controller were converted to IP addresses or IP address ranges prior to sending the rules/reports to the Local Controllers. This conversion removed links to the original objects. The effect was if a network group were edited and that group was referenced in a Global Controller rule, the changes never propagated to the Local Controller because it used a list of IP addresses, not a reference to the network group.
In the x.3.4 releases, the network groups, networks, and devices are passed to the Local Controller in the source and destination fields; they are no longer converted to IP addresses and IP address ranges. Therefore, the rules on the Local Controller now include the network group, network, or device name, not a list of IP addresses.
The following behaviors should be noted:
–
–
–
Note
–
•
•
•
New Vendor Signatures
The following table describes the most recent signatures supported for each product or technology:
Yes
Cisco IDS 4.0,
Cisco IPS 5.x,
Cisco IOS 12.2Current through S317 signature release.
Yes
Snort NIDS 2.6.1
Current through the February 12, 2008 signature release.
Latest signature mapped: 13415.
Yes
ISS RealSecure Network Sensor 6.5 and 7.0, and ISS RealSecure Server Sensor 6.5 and 7.0
XPU 28.010
Release date: January 8, 2008Yes
McAfee IntruShield NIDS 1.5 and 1.8
McAfee Network Intruvert v. 2.5, 4.04.1.19.6
Release date: January 23, 2008Yes
McAfee Entercept HIDS 2.5, 4.0
Current through the January 8, 2008 signature release.
Yes
CheckPoint Application Intelligence
(VPN-1 NG with Application Intelligence R55)
Current through the February 4, 2008 signature release
Yes
Netscreen IDP 2.1, 3.0, 3.1, 4.0, 4.1
Signature version: 4.1.
Release date: February 10, 2008Yes
Enterasys Dragon 6.x, 7.x
Current through the February 8, 2008 signature release.
Yes
Symantec NIDS, v 4.0
Signature package: 92
Release date: December 17, 2007No. EOS.
Symantec Manhunt 3.x
(See Symantec NIDS, v 4.0.)
3.4.3 Update 59
Current through the May 24, 2007 signature release.Yes
Qualys QualysGuard 3.x, 4.7.161-1
Current through the February 9, 2008 signature release.
Yes
E-Eye, Retina Scanner Vulnerability Software, version 5.61
Current through the February 10, 2008 signature release.
Yes
Foundstone, version 4.x
Current through the February 10, 2008 signature release.
Yes
Common Vulnerabilities and Exposures (CVE) Database
Current with the February 10, 2008 definition update.
No
Oracle 11g
Support for new AUDIT_ACTIONS.
1 eEye REM 1.0 is supported in 4.2.x.
Upgrade Instructions
The MARS upgrade packages are the primary vehicle for major, minor, and patch software releases. As administrator of the MARS Appliance, you should check the upgrade site regularly for patch upgrades. In addition to addressing high-priority caveats, patch upgrade packages update system inspection rules, event types, and provide the most recent signature support.
For detailed instructions on planning and performing an upgrade or install, refer to Checklist for Upgrading the Appliance Software, page 6 in the Install and Setup Guide for Cisco Security Monitoring, Analysis, and Response System.
Important Upgrade Notes
To ensure that the upgrade from earlier versions is trouble free, this section contains the notes provided in previous releases according the release number. Please refer to the notes that pertain to the release you are upgrading from and any releases following that one.
General Notes
The MARS Appliance performs a file system consistency check (fsck) on all disks when either of the following conditions is met:
•
•
The fsck operation takes a long time to complete, which can result in significant unplanned downtime when rebooting the system after meeting a condition above. For example, a MARS 50 appliance can take up to 90 minutes to perform the operation.
Upgrade to 4.3.4
No important notes exist for the 4.3.4 upgrade.
In addressing CSCsm57453: Incident not created for some of same events, the behaviour now differs between 4.3.4 and 5.3.4. In the x.3.3 releases, inciddent firing was throttled at 100 inciddents for event bursts from a vulnderability assessement (VA) reporting device. In 5.3.4, incidents firing throttles at over 430 inciddents, and in 4.3.4, the incidents firing throttles at just over 220 incidents.
Upgrade to 4.3.3
No important notes exist for the 4.3.3 upgrade.
Upgrade to 4.3.2
The following important notes apply to the upgrade from 4.3.1 to 4.3.2:
•
If you've edited a system rule on a Global Controller, you may enounter one of two conditions where the rules on the Global Controller are out of sync with those on the Local Controller.
Symptom: The edited rule in the Global Controller disappears from the list of rules on the Local Controller. (CSCsk12130)
Condition: The user edited a rule on the Global Controller and then upgraded to a different version of the MARS system software and then added of a new Local Controller to the Global Controller.
Symptom: A rule that was edited in the Global Controller looks as if it is an empty rule in the Local Controller and be inactive. (CSCsk19730)
Condition: This occurs under in some cases where a Local Controller is added to a newly upgraded Global Controller.
Work Arounds: If the Local Controller is deleted from and re-added to the Global Controller under x.3.2, the issue should resolve itself. However, in conditions with a large topology or many custom rules, we recommend contacting technical support for a work around that avoids the need to delete and re-add the Local Controller.
Another possible work around if the number of edited rules are small is to edit and make further changes to the rule and activate. In this case, the issue should be resolved for that rule.
•
For example, an IOS 12.4 device is added to MARS 4.3.1 as 12.2 and after the upgrade to 4.3.2, when the discovery occurs for that device, the device type is automatically updated to IOS 12.4. The same is true for devices that are running IOS 12.3. However, if you have not enabled device discovery, use the Change Version feature to change between IOS 12.2, 12.3, and 12.4.
•
•
•
Upgrade to 4.3.1
Beginning with the 4.3.1 and 5.3.1 releases, the dynamic IPS signature updates (if enabled) is an aspect of the version of software running on a MARS Appliance. Therefore, in addition to running the same MARS software versions on the Global Controller and Local Controller, the IPS signature version must match or the communications fail.
In a Global Controller-Local Controller deployment, configure the dynamic signature URL and all relevant settings on the Global Controller. When the Global Controller pulls the new signatures from CCO, all managed Local Controllers download the new signatures from the Global Controller.
In addition, CSCsk90015 states that any reporting device representing a Cisco ACS 3.x device that exists prior to the 4.3.1 upgrade is deleted during the upgrade. To resolve the issue after upgrade, you must the remove the reporting device from the host and re-add that device again as Cisco Secure ACS 3.x.
An example process is as follows:
1.
2.
3.
Upgrade to 4.2.8
No important notes exist for the 4.2.8 upgrade.
Upgrade to 4.2.7
No important notes exist for the 4.2.7 upgrade.
Upgrade to 4.2.6
No important notes exist for the 4.2.6 upgrade.
Upgrade to 4.2.5
The 4.2.4(2432) patch was released to address an issue with the MARS system timezone patch in 4.2.4 (2428). The 4.2.5 update includes the patch, and therefore, you are not required to apply the 4.2.4(2432) patch if you are currently running 4.2.4 (2428). This issue, detailed in CSCsi08897, only affects a few timezones; therefore, many customers would never experience the issue.
Upgrade to 4.2.4
No important notes exist for the 4.2.4 upgrade.
Upgrade to 4.2.3
The 4.2.3 upgrade package is approximately 1.6 GB due to the large number of signatures updated and due to the inclusion of a patch to the database software, which was added to address CSCsg02873. Downloading the PKG file may take up to 7 times longer than previous packages.
Note
To upgrade from 4.2.2 to 4.2.3, follow these steps:
Step 1
a.
raidstatus
Tip
For more information on the raidstatus command, see "raidstatus" in Appendix A, Command Reference of the Install and Setup Guide for Cisco Security Monitoring, Analysis, and Response System, Release 4.2.x.
b.
Step 2
a.
diskuage
One of the lines should describe the /u01 partition:
Filesystem Size Used Avail Use% Mounted on/dev/md3 16G 4.6G 10G 31% /u01For more information on the diskusage command, see "diskusage" in Appendix A, Command Reference of the Install and Setup Guide for Cisco Security Monitoring, Analysis, and Response System, Release 4.2.x.
b.
A nightly process runs to clean up any files that accumulate on this partition. If you have less than 3 GB, there is an issue with your appliance that you must resolve prior to upgrading.
Step 3
Note
For more information on performing the upgrade using the command line, see the following information:
•
"pnupgrade" command in Appendix A, Command Reference of the Install and Setup Guide for Cisco Security Monitoring, Analysis, and Response System, Release 4.2.x.
•
Step 4
a.
pnstatus
For more information on the pnstatus command, see "pnstatus" in Appendix A, Command Reference of the Install and Setup Guide for Cisco Security Monitoring, Analysis, and Response System, Release 4.2.x.
b.
If some processes are not running, you must troubleshoot that issue before proceeding with the upgrade.
c.
pnupgrade log
For more information on the pnupgrade log command, see "pnupgrade" in Appendix A, Command Reference of the Install and Setup Guide for Cisco Security Monitoring, Analysis, and Response System, Release 4.2.x.
d.
[pnadmin]$ pnupgrade log--------------------------------------4.2.2 2303 --> 4.2.3 2403--------------------------------------1 Preparing upgrade start1.1 Load the step table start1.1 Load the step table end1.2 Stop pnmonitor start1.2 Stop pnmonitor end1.3 Stop jboss start1.3 Stop jboss end1.4 Stop other applications start1.4 Stop other applications end1 Preparing upgrade end2 Upgrade OS start2.1 Patch OS start2.1 Patch OS end2.2 Patch Oracle start2.2 Patch Oracle end2 Upgrade OS end3 Upgrade schema start3.1 Run upgrade schema script start3.1 Run upgrade schema script end3.2 Backup schema script start3.2 Backup schema script end3 Upgrade schema end4 Upgrade MARS applications start4.1 Untar MARS executable binary start4.2 Untar MARS executable binary end4.3 Modify janus.conf start4.3 Modify janus.conf end4.4 Swap MARS executable binary start4.4 Swap MARS executable binary end4.5 Run post-unpack-deployment start4.5 Run post-unpack-deployment end4 Upgrade MARS applications end5 Upgrade data start5.1 Start jboss start5.1 Start jboss end5.2 Importing signature data start5.2 Importing signature data end5.3 Missing-id fix start5.3 Missing-id fix end5 Upgrade data end6 reboot ...Upgrade from 4.2.2 2303 to 4.2.3 2403 finished.If the log does not include the "Upgrade from 4.2.2 2303 to 4.2.3 2403 finished" line, then a problem occurred during the upgrade regardless of whether the version command reports 4.2.3 (2403).
Special Note for Post Upgrade of a Global Controller/Local Controller Deployment
In a Global Controller/Local Controller deployment upgraded from 4.2.2 to 4.2.3, the communication states between the Global Controller and one or more Local Controllers can be out of sync. This issue is detailed in CSCsh38818.
The Global Controller identifies the Local Controller as Active, and the Local Controller identifies itself as Offline. Toggling "Suspend/Resume" from the Global Controller's Local Controller Management page toggles both states, causing the Global Controller to consider the Local Controller as Suspended while the Local Controller considers itself as Online and resumes pushing information to the Global Controller.
This "out of sync" state affects Global Controller/Local Controller deployments that are upgraded from 4.2.2 to 4.2.3.
To determine whether a Global Controller/Local Controller pair is in this error state, follow these steps:
Step 1
Step 2
Step 3
Step 4
Step 5
Once the error has been identified, follow these steps to exit the error state:
Step 1
Step 2
You can verify that the Global Controller sees each Local Controller as "Suspended" by clicking "Details" for that Local Controller to see if it shows that the Local Controller is no longer Offline - "CS-MARS Local Controller: [hostname]/[zone name]"
Step 3
Step 4
Step 5
Step 6
Step 7
pnreset -j
Step 8
Step 9
Step 10
Upgrade to 4.2.2
The following issues can occur during the standard upgrade process of a MARS Appliance:
•
The following issues can occur when upgrading your reporting devices:
•
Upgrade to 4.2.1
As identified in CSCse17864, CSCse22610 and CSCse22617, the changes in the case management feature requires that you close all cases before upgrading from MARS 4.1.x to 4.2.1. By closing the cases, you ensure that the device, report, and query information is copied to the case, assuming it still exists in the database.
Upgrade to 4.1.5
No important notes exist for the 4.1.4 upgrade.
Upgrade to 4.1.4
No important notes exist for the 4.1.4 upgrade.
Upgrade to 4.1.3
No important notes exist for the 4.1.3 upgrade.
Upgrade to 4.1.2(2042)
The following notes detail changes to the standard upgrade process:
•
Opening file: /etc/data/secondarytables/reports/Report.0.Resource-Issues--IOS-IPS-DTM---All-Events.x mlIf you do not see this line, then a problem occurred during the upgrade regardless of whether the version command reports 4.1.2 (2040).
•
script -b patch_or_04_1_16.sh
The 4.1.2 (2042) image includes an additional command `script' that cleans the database of the data referenced in CSCsc31386. As a result of running the script, the total upgrade process from 4.1.1 to 4.1.2 (2042) may take much longer than previous releases; it depends on the amount of data stored on the MARS Appliance. For a MARS 200, it could double the normal upgrade time to two hours. To determine whether the script is still running, enter the following command and look for `patch_or_04_1_16.sh' anywhere in the output:
sysstatus -n 1 -b
Upgrade to 4.1.1
The following notes relate to changes in your system or configuration as a result of upgrading to MARS 4.1.1.
•
•
Required Upgrade Path
When upgrading from one software version to another, a prerequisite version is always required. This prerequisite version is the minimum level required to be running on the appliance before you can upgrade to the most recent version. Table 1 identifies the upgrade path that you must follow to reach the minimum level required to upgrade to current version.
Table 1 Upgrade Path Matrix
releases prior to 2.5.6
Contact Cisco Support
n/a
2.5.6
3.1.1
pn-3.1.1.pkg
3.1.1
3.2.1
pn-3.2.1.pkg
3.2.1
3.2.2
pn-3.2.2.pkg
3.2.2 or 3.3.2 Beta
3.3.3*
pn-3.3.3.pkg
3.3.3
3.3.4*
pn-3.3.4.pkg
3.3.4
3.3.5*
pn-3.3.5.pkg
3.3.5
3.4.1*
pn-3.4.1.pkg
3.4.1
3.4.2
pn-3.4.2.pkg
3.4.2
3.4.3
pn-3.4.3.pkg
3.4.3
3.4.4
pn-3.4.4.pkg
3.4.4
4.1.1
csmars-4.1.1.pkg
4.1.1
4.1.2 (2042) + script command
csmars-4.1.2.pkg2
4.1.2 (2040) without error
4.1.2 (2042)
csmars-4.1.2.pkg2
4.1.2 (2042)
4.1.3
csmars-4.1.3.pkg
4.1.3
4.1.4
csmars-4.1.4.pkg
4.1.4
4.1.5
csmars-4.1.5.pkg
4.1.5
4.2.1
csmars-4.2.1.pkg
4.2.1
4.2.2
csmars-4.2.2.pkg
4.2.2
4.2.3
csmars-4.2.3.pkg3
4.2.3
4.2.4 (2428)
csmars-4.2.4.pkg
4.2.4 (2428) or (2432)
4.2.5
csmars-4.2.5.pkg
4.2.5
4.2.6
csmars-4.2.6.pkg
4.2.6
4.2.7
csmars-4.2.7.pkg
4.2.7
4.2.8
csmars-4.2.8.pkg
4.2.8
4.3.1
csmars-4.3.1.pkg
4.3.1
4.3.2
csmars-4.3.2.pkg
4.3.2
4.3.3
csmars-4.3.3.pkg
4.3.3
4.3.4
csmars-4.3.4.pkg
1 An asterisk (*) next to a package name in this column identifies that this upgrade must be performed from the command line, as GUI support was lost with the closing of the upgrade.proteogonetwork.com website.
2 To upgrade from 4.1.1 or 4.1.2 (2040) to 4.1.2(2042), please review the special upgrade notes in the Quick Install and Release Notes for Cisco Security MARS Appliance 4.1.2 (2042).
3 The 4.2.3 upgrade package is approximately 1.6 GB due to the large number of signatures updated and due to the inclusion of a patch to the database software. Downloading the ISO image may take longer than previous packages.
Downloading the Upgrade Package from CCO
Upgrade images and supporting software are found on the CCO software download pages dedicated to MARS. You can access these pages at the following URLs, assuming you have a valid CCO account and that you have registered your SMARTnet contract number for your MARS Appliance
•
•
•
•
Note
For information on obtaining a CCO account, see the following URL:
•
Documentation Errata
•
To determine whether specific incidents are false positives, MARS uses Nessus 2.x GPL plug-ins and custom scripts mapped to specific MARS event types. MARS does not use Nessus to perform vulnerability assessments or related reporting.
•
The OpenSSH client used by MARS does not support modulus sizes smaller than 768. For example, you cannot discover a device using a SSH login that has 512-byte key.
Important Notes
The following notes apply to the MARS 4.1.x, 4.2.x, and 4.3.x releases:
•
•
•
•
•
•
The following notes describe new behavior based on the resolution of specific caveats. Be sure to check the upgrade notes for each release for important notes on data migration.
Quick Install Notes
It is recommended that users read the Install and Setup Guide for Cisco Security Monitoring, Analysis, and Response System. However, for those users who simply want to get the MARS Appliance up and running, the following two topics, taken from the Install and Setup Guide for Cisco Security Monitoring, Analysis, and Response System, summarize the hardware installation and initial software configuration:
1.
2.
Installation Quick Reference
Table 2 provides an overview of the installation and initial configuration process. Following installation and initial configuration, see the following publications for information on how to use a browser and the HTML interface to fully configure your MARS Appliance to provide the security threat mitigation (STM) services you want from this installation:
•
•
Table 2 Quick Reference
Use the rack mount kit to install the MARS Appliance in a rack.
Connect the MARS Appliance to an AC power source.
Connect network and console cables.
Turn on the appliance.
Powering on the Appliance and Verifying Hardware Operation, page 8
Verify initial power up.
Powering on the Appliance and Verifying Hardware Operation, page 8
Perform initial configuration of the MARS Appliance.
Configure the MARS Appliance to monitor reporting devices.
Checklist for Initial Configuration
Initial configuration of the appliance accomplishes several goals:
•
•
•
•
•
•
The following checklist describes the tasks required to initially configure your MARS Appliance. Each task might contain several steps; the tasks and steps within should be performed in order. The checklist contains references to the specific procedures used to perform each task.
1.
Initial configuration requires a console connection to access the CLI. You should establish this connection with the power turned off on the MARS Appliance. Three console connection options exist:
•
•
•
After you have chosen and configured your console connection, you must power up the appliance.
Result: The appliance is powered up and you can see the command line prompt through your console connection.
For more information, see:
2.
The command line configuration is separated into three tasks, each task being separated by a reboot of the appliance. The first task involves performing three to four procedures:
•
•
•
•
Each MARS Appliance has two Ethernet interfaces: eth0 and eth1. The eth0 interface is the dedicated interface used for collecting event data and logs from your network. The eth1 interface is intended for use in an out-of-band management (OOBM) network or for a console connection. Therefore, your default gateway and IP address/mask values should focus on the network connections to be used to monitor the data streams of reporting devices, and these settings should be applied to eth0.
Note
Result: The default password is no longer associated with the system administrative account and the appliance is more secure. Also, the eth0 is configured to communicate on your network. When you complete the IP address configuration changes for either, the appliance reboots.
For more information, see:
•
•
•
•
3.
The second task of the CLI configuration involves setting the hostname of the appliance. The hostname is used to uniquely identify which appliance collects a specific log and which appliance fires an inspection rule. This unique identity is especially important in an environment where Global Controller is running. To complete this task, you must:
•
•
Result: The hostname is configured for the appliance. The appliance reboots.
For more information, see:
4.
The third and final task of the initial CLI configuration involves specifying those settings that help ensure the integrity of the event correlation and complete your network connection, allowing access to the appliance from other hosts on the network. In other words, after you complete this phase, you can connect to and complete the appliance configuration using a non-console connection from any host on your network. To complete this task, you must:
•
•
•
•
•
•
Result: Now you have network connectivity. You can access the CLI interface using an Secure Shell (SSH) client on any host that can reach the appliance, and you can log in to the web interface to complete the initial configuration.
For more information, see:
•
•
5.
After you have completed the cable connections to the MARS Appliance, defined the required network connection settings, and specified any additional default routes, you can start the web interface configuration process. Verify the configuration settings of your browser before configuring the MARS Appliance (see Web Browser Client Requirements, page 9).
During this phase, you configure the following:
•
•
•
•
•
•
Result: You have configured your appliance to communicate on the network, properly correlate events, and issue system e-mails to a monitored e-mail address.
For more information, see:
•
•
•
•
•
6.
The software version determines the currency of signatures, system inspection rules, features, and bug fixes. An important part of your security solution is ensuring that you maintain the most up-to-date software on the MARS Appliance. This process involves preparing an upgrade strategy and selecting a method, determining your current version, identifying the most recent version, and downloading and applying all intermediate versions of the software.
Result: The appliance is running the most recent version of software.
For more information, see:
Caveats
This section describes the open and resolved caveats with respect to this release.
•
•
For your convenience in locating caveats in Cisco's Bug Toolkit, the caveat titles listed in this section are drawn directly from the Bug Toolkit database. These caveat titles are not intended to be read as complete sentences because the title field length is limited. In the caveat titles, some truncation of wording or punctuation may be necessary to provide the most complete and concise description. The only modifications made to these titles are as follows:
•
•
•
Note
http://www.cisco.com/support/bugtools
To become a registered cisco.com user, go to the following website:
http://tools.cisco.com/RPF/register/register.do
Open Caveats - Release 4.3.4
The following caveats affect this release and are part of supported devices or compatible products:
Guest
