Table Of Contents
Quick Install and Release Notes for Cisco Security MARS Appliance 4.2.1
Introduction
New Features
Cisco Security Manager (Security Manager) Policy Lookup Integration
Increased Ease of Deployment via Relayed Syslog Handling Feature
Low-Latency, Real-Time Event Query
XML Incident Notification
Disk Usage via CLI, Events, Inspection Rules, and Reports
Improved Performance of Software Upgrades
Low-End Monitoring Solution: MARS 20R
Distributed Threat Management (DTM) Enhancements
Case Management Enhancements
Using ISS Site Protector to Configure ISS NIDS and HIDS
Miscellaneous Changes and Enhancements
New Vendor Signatures
Upgrade Instructions
Important Upgrade Notes
Upgrade to 4.2.1
Upgrade to 4.1.5
Upgrade to 4.1.4
Upgrade to 4.1.3
Upgrade to 4.1.2(2042)
Upgrade to 4.1.1
Required Upgrade Path
Downloading the Upgrade Package from CCO
Important Notes
Quick Install Notes
Installation Quick Reference
Checklist for Initial Configuration
Caveats
Open Caveats - Release 4.2.1
Resolved Caveats - Release 4.2.1
Resolved Caveats - Releases Prior to 4.2.1
Product Documentation
Obtaining Documentation, Obtaining Support, and Security Guidelines
Quick Install and Release Notes for Cisco Security MARS Appliance 4.2.1
Revised: December 20, 2006, 78-17784-01
These release notes are for use with the Cisco Security Monitoring, Analysis, and Response System (MARS), Version 4.2.1 running on either a Local Controller or on a Global Controller. They provide the following information:
•
Introduction
•New Features
•Upgrade Instructions
•Important Notes
•Quick Install Notes
•Caveats
•Product Documentation
•Obtaining Documentation, Obtaining Support, and Security Guidelines
Introduction
Version 4.2.1 is now available as a patch upgrade to 4.1.5 of your MARS appliance software. Registered SMARTnet users under the can obtain version 4.2.1 from the Cisco support website at:
http://www.cisco.com/cgi-bin/tablebuild.pl/cs-mars
New Features
In addition to resolved caveats, this release includes the following new features:
•Cisco Security Manager (Security Manager) Policy Lookup Integration
•Increased Ease of Deployment via Relayed Syslog Handling Feature
•Low-Latency, Real-Time Event Query
•XML Incident Notification
•Disk Usage via CLI, Events, Inspection Rules, and Reports
•Improved Performance of Software Upgrades
•Low-End Monitoring Solution: MARS 20R
•Distributed Threat Management (DTM) Enhancements
•Case Management Enhancements
•Using ISS Site Protector to Configure ISS NIDS and HIDS
•Miscellaneous Changes and Enhancements
•New Vendor Signatures
Cisco Security Manager (Security Manager) Policy Lookup Integration
This feature allows you to map a traffic-related syslog message back to the firewall policy that triggered the syslog, thus helping you to fix firewall configuration-related network problems, configuration errors, and to fine-tune existing firewall policies.
Policy lookup is achieved by integrating MARS, the monitoring product and Security Manager, the device management product. The MARS web interface now includes a new Security Manager Policy Table Lookup icon
in the session/event display for all syslog events related to traffic. When you click this icon, MARS securely connects to Security Manager, retrieves the policy list, and displays it with the access rule that triggered the traffic syslog selected.
This integration enables policy lookup for the following device types:
•Cisco IOS 12.x
•Cisco PIX 6.x and 7.0
•Cisco Switch-IOS 6.x
•Cisco ASA 7.0
•Cisco FWSM 2.x
Note This feature is available beginning with MARS 4.2.1 and Security Manager 3.0. In Security Manager 3.1, you can open the MARS web interface.
The following caveats exist for the Security Manager integration:
Reference Number
|
Description
|
CSCse03254
|
Issue: Inconsistent population of CSM icon for ICMP messages
Description: The same events received by MARS can display the Security Manager Policy Table Lookup icon inconsistently between the low-latency, real-time event query and standard queries, such as sessions ranked by time. Specifically, the icon will not appear in the low-latency, real-time query, but it may appear in queries against sessionized events.
This behavior is expected. When MARS receives events, they are parsed, sessionized, written to an event shared buffer, and then written to the database. Because sessionization takes time, sometimes keeping an event in cache for 2 minutes, the low-latency event query displays events right after parsing, but before sessionization. Displaying the event at this point allows the low-latency query to achieve a close to real-time effect. For some events, parsing cannot determine some part of the 5-tuple data, such as a destination address. Later, sessionization later fills in such missing data using configuration data. As a result, the 5-tuple data displayed by the low-latency event query can be different from values stored in the database, which are used to populate the standard queries.
Workaround: None.
|
CSCse19392
|
Issue: CSM: Policy query for ICMP traffic
Description: An error can occur with the policy query if you discover a device configuration with Security Manager but do not submit it in Security Manager. The following error message is an example of this issue:
<190>2312080: *May 9 23:50:02.199: %SEC-6-IPACCESSLOGDP: list permit-all
permitted icmp 10.2.3.8 -> 10.4.21.2 (0/0), 1 packet
An error occurred while querying policies from Cisco Security Manager. Reason:
Failed to retrieve policy information from CSM. Reason: Cisco Security Manager
Internal error: Failed to get interfaces in the device!
The device LC2DTM was discovered by CSM without any errors.
Workaround: Before you perform policy queries, verify that all discovered devices have been submitted in Security Manager.
|
CSCse20041
|
Issue: CSM policy query icon for NetFlow events
Description: The Security Manager Policy Table Lookup icon displays for NetFlow events even though they are not triggered by an ACL. This extra event data allows you to determine whether there is a policy permitting that traffic, which ensures you are able to tune accordingly.
Note Because this is NetFlow data, it may not match the exact ACL or match multiple ACLs.
Workaround: None.
|
CSCse20691
|
Issue: CSM:Policy query icon
Description: The Security Manager Policy Table Lookup icon displays only for those events with 5-tuple event data (source and destination address, protocol, source and destination port). In the MARS web interface, the all matching events query displays the text "session five tuple" for events with no 5-tuple event data. These events will not have a policy query icon.
Workaround: None.
|
Increased Ease of Deployment via Relayed Syslog Handling Feature
You can rapidly deploy MARS by forwarding messages from existing syslog-ng or Kiwi syslog servers. This feature eliminates the network and device changes required to insert MARS into an operational network. You no longer have to configure each network device to publish its syslog messages directly to MARS, which saves time, avoids device change approval processes, preserves packet processing performance of the network devices, and ensures that daily network operations proceed uninterrupted.
Note Solaris/Linux syslogd is not supported as its message format does not include the host and timestamp information for the device that originates the message.
This relay feature also allows the correlation and inspection of syslog messages from reporting devices, such as those on the DMZ, for which corporate policies might prohibit the existence of or connection to configuration information.
If your network devices already publish syslog messages to syslog-ng or Kiwi syslog servers, simply configure those servers to forward messages to the MARS Appliance and identify the syslog servers in MARS. MARS parses the syslog messages generated by the following devices: Cisco PIX, Cisco IOS, Cisco CatOS, Cisco ASA, Cisco FWSM, Cisco VPN 3000, Cisco Secure ACS, Snort IDS, Juniper/Netscreen firewalls, Solaris, Redhat Linux, and Microsoft Internet Information Server (ISS). For other devices, you can define custom log parsers.
The MARS Appliance can begin processing and storing the events while you define the reporting devices using the MARS web interface. You still must define the reporting device by IP address and device type in MARS to ensure proper event correlation; however, you are not required to configure device to publish syslog messages directly to MARS.
Low-Latency, Real-Time Event Query
MARS can now display incoming raw events in real-time with a real-time event viewer query option. Previous releases of MARS had a real-time event query that sessionized and stored events before displaying them. This could incur delays of at least 2 minutes. The real-time raw event viewer operates in memory and has a 5-second delay. All parsed raw events are passed to the sessionizing module for further analysis.
To access the real-time event viewer, define a new query with All Matching Events, or All Matching Event Raw Messages as the Result Format, then select Raw events as the Real Time parameter.
XML Incident Notification
The new XML incident notification feature enables automated workflow integration with help desk and ticketing systems. XML incident notification is configured as an alert action of a rule. An XML data file is e-mailed to a specified recipient or group when the rule fires.
Based on the published schema (XSD file), you can develop custom parsing scripts to drive your ticketing or help desk system. You can also compress the e-mailed XML data file using gzip compression. XML incident notification benefits are as follows:
•The XML data file includes all information related to the incident that can be seen on the web interface, except for Path/Mitigation information
•Recipients do not have to log in to MARS to view the incident data
•The XML schema definition allows integration of the XML notifications with third-party applications
Disk Usage via CLI, Events, Inspection Rules, and Reports
To address the operational planning needs of storage and archive, MARS 4.2.1 includes two new CLI commands that provide database and disk usage information. It also includes a new event, inspection rule, and report to provide the information and notify the administrators of upcoming purging events.
The two new commands are dbusage, which identifies current database usage and future allocation plans through either unused partitions or purging of oldest data, and diskusage, which displays the amount of disk space available on all partitions.
The new event, CS-MARS DB partition filling up causing the next partition to be purged soon, notifies the administrators when the current partition is 75% full and switching to the next partition will result in data being purged from a previously used partition. The system inspection rule and report allow you to monitor when this event fires. The inspection rule is System Rule: CS-MARS Database Partition Usage, and the report is Resource Utilization: CS-MARS-All Events.
Improved Performance of Software Upgrades
Because MARS relies on frequent signature updates to stay abreast of the most recent known attacks and issues, software updates are an integral part of any operational plan. Even on small appliances that monitor low volume traffic, this upgrade can consume valuable time, both as system downtime and in terms of administrative monitoring and verification.
Beginning with release 4.2.1, the software upgrade uses binary differential updates rather than complete image updates. As a result, both signature update and system patch performance is greatly improved.
Low-End Monitoring Solution: MARS 20R
The MARS 20R provides the same functionality as the MARS 20 with the restriction of accepting only 50 events per second and 1,500 NetFlow flows per second. It is restricted to operate as a standalone Local Controller and cannot be managed by a Global Controller. This entry-level product is positioned as a low-cost replacement for Monitoring Center for Security found in the VMS 2.x suite. However, it is orderable through regular channels. No upgrade option exists for this model.
Distributed Threat Management (DTM) Enhancements
The system parameters controlling the DTM features of MARS now provide improved control and the ability to specify the frequency of synchronization and default action of the N signatures being reported as active on Cisco.com/MySDN. Specific enhancements are as follows:
•(Enhancement) Signature Inactivity Interval For Deletion. Users can now specify the time period for which signatures are kept on IOS IPS routers with IPS support before they are deleted. This setting replaces the previous DTM Deletion Interval setting.
•(New) Top N Signature Pulling Interval From CCO (default 15 minutes). MARS pulls the CCO Top N signatures each time this interval expires. MARS then pushes these Top N signatures to all DTM-enabled IOS routers. (any IOS router that included in any DTM Rule action).
•(New) Top N IPS Signature Action. Applies a global action to the Top N signatures retrieved from CCO. This action is applied only to the CCO Top N Signatures.
•(New) Support for NATed IOS IPS devices. Previously, MARS did not support IOS IPS devices that did not reside on a network that was directly connected to the eth0 interface of the MARS Appliance. This feature enables access to IOS IPS devices that reside behind NATed gateways.
•(Enhancement) Support for additional signature actions. The notification action for DTM now includes the deny attackers and deny flow actions, which are applied to the signatures published to the IOS IPS routers that are targets of the notification.
Case Management Enhancements
The following enhancements to case management are included in the MARS 4.2.1 release:
•The filter, Open Cases, displays all open cases.
•In releases before 4.2.1, information was copied to a case when it was closed. This timing allowed the possibility that information might be deleted before the case was closed. Now, information is copied as it is attached to the case.
•In releases before 4.2.1, you could e-mail a case to its owner only. Now, you can e-mail a case to anyone who has an account in MARS, and you can select multiple recipients.
•The ability to show and hide attachments. In 4.2.1, two view buttons appear on the Case Management page: Show All and Show Included. The default view is Show All, which displays all information associated with the case and is consistent with previous releases. Show Included allows you to display only those attachments that are selected.
•In releases before 4.1.5, query results were limited to 100 entries. In release 4.1.5, the limit was increased to 5,000. If the number of results is larger than the paging size, you are presented with a popup window that identifies how many results there are, the paging size, and prompts you to specify how many to display. The upper limit of 5,000 results in a query still exists; however, you can reduce the number of results if the paging size is greater than the number of records.
•You can no longer edit a closed case or change the name of the case. You can view, e-mail it, and add a comment.
A general issue with case management still exists where attachments can take while to appear in the case, particularly if that attachement is large. Therefore, if you add something to a case but the attachment does not appear when you review the case, allow some time to pass and try again. It simply takes a while for large attachment to be associated with the case.
Using ISS Site Protector to Configure ISS NIDS and HIDS
MARS supports ISS NIDS and HIDS event retrieval via SNMP. However, when configuring ISS RealSecure sensors (NIDS) and hosts (HIDS), you must configure each active signature to send an alert to the MARS Appliance. This task can be tedious because you must configure each sensor and after each signature upgrade, as an upgrade resets the redirect configuration. You can simplify this task by using the ISS Site Protector management console to define these changes globally and apply them to each sensor.
ISS Site Protector 2.0 allows you to centrally manage SNMP alert destinations, such as the MARS Appliance, for group policies. You can then push these group policies to all desired host and network sensors. For each ISS signature update, you must specify the MARS Appliance as an SNMP alert destination before you apply the downloaded signatures to sensors using Site Protector.
Note The configuration was qualified using an ISS Proventia G100 appliance (NIDS) and Site Protector 2.0 (Management Console).
Miscellaneous Changes and Enhancements
The following changes and enhancements are the result of caveats fixed in the 4.2.1 release:
•Feedback button behavior changes. The Feedback button now sends an e-mail to the logged on user, who can forward it to the appropriate support personnel. If the logged on user does not have an e-mail address configured, a pop-up window instructs the user to define one.
•Pink Box behavior changes. A pink box appears when a system error in the web interface is detected. In releases before 4.2.1, you could send the error log and related information to Cisco using the Report Error button. In the 4.2.1 release, you can choose to e-mail the error log directly to Cisco TAC. The log can be attached to an existing TAC case, which requires that you provide a valid TAC case number or create a case.
•Device version upgrade support. Previously, if you upgraded the software version of a support device, you could not reflect that change in MARS. To do so, you had to delete the old device and then add a new device with the correct software version. In the 4.2.1 release, the Change Version button appears on the Security and Monitoring Devices page, allowing you to identify such changes on defined reporting devices.
•Severity of a syslog changed in the originating device. In the 4.2.1 release, MARS ignores the severity of the event in the message while parsing IOS, PIX, and FWSM messages. This enhancement allows you to change the severity of a syslog server without breaking the MARS parser. This change addresses issues defined in CSCpn03044.
•Blocked packet from the sensor can now be seen. In releases before 4.2.1, MARS made no indication whether an IPS device blocked a detected attack. In the 4.2.1 release, MARS displays "Block-YES" in IPS raw message if the reporting device blocked the attack. This enhancement allows you to generate reports on the attacks that are blocked by an IPS device. This change addresses issues defined in CSCsb70121.
•Discovery of Symantec agents. In the 4.1.4 release, MARS learned, through discovery, of agents managed by Cisco Security Agent and McAfee ePO management consoles. In the 4.2.1 release, this functionality has been extended to the Symantec AntiVirus management console. This change addresses issues defined in CSCsc30044.
•Automatically add Reporting IP as part of the SNMP Discovery process. In the 4.2.1 release, MARS defines the Reporting IP of devices discovered during the discovery processes. This change addresses issues defined in CSCsc50789.
•Alert if MARS is dropping events. A system inspection rule, System Rule: Resource Issue: CS-MARS, has been defined that alert when the MARS Appliance begins to drop events rather than process them due to system resource limitations, such as exceeding storage capacity, dropped events due to rate limits being exceeded, capacity limitations, and so on. This feature applies to standard events and NetFlow records. Four new event types (found in the Info/HighUsage/CS-MARS group) are included in the rule definition. These event types identify the following:
–First dropped event in one hour
–Dropped event count in one hour
–First dropped NetFlow in one hour
–Dropped NetFlow count in the hour
A new System: CS-MARS Issue report, Resource Issues: CS-MARS - All Events, is provided to summarize these notifications. These changes address issues defined in CSCsc33942:
•Configurable event summary display on the Summary > Dashboard page. Previously, MARS displayed the last 24 hours of statistical event information. You can now select the interval for displaying summary event results. Choose from the past day, two days, week, month, or year.
New Vendor Signatures
The following table describes the most recent signatures supported for each product or technology:
Product
|
Signature Version Supported
|
Cisco IDS 4.1/IPS 5.x
|
S229
|
McAfee Entercept HIDS 4.1
|
Agent Version 40-56
|
ISS RealSecure Network Sensor 7.0
|
24.36
|
ISS RealSecure Server Sensor 7.0
|
24.36
|
McAfee IntruShield NIDS 1.8
|
1.8.75.4
|
Snort NIDS
|
2.3.3
|
Netscreen IDP 2.1
|
Idp2.1r3 Update 254
|
Enterasys Dragon 6.x
|
Latest signatures as of 06-01-2006
|
Symantec Manhunt
|
3.4.3 Update 53
|
Qualys QualysGuard 3.x
|
Latest Knowledge Base XML file as of 02-07-2005
|
Common Vulnerabilities and Exposures (CVE) Database
|
Latest as of 09-08-2005
|
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 weekly 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 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.
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:
•If you completed the 4.1.1 to 4.1.2 (2040) upgrade, verify whether the upgrade failed by entering `pnlog mailto <SMTP server> <sender> <recipient>' at the CLI. This commands mails the MARS Appliance logs to the recipient. Open the e-mailed file attachment, and then open the newest upgrade*.log found in /var/log/. Successful upgrades from 4.1.1 (2022) to 4.1.2 (2040) include the following line:
Opening file:
/etc/data/secondarytables/reports/Report.0.Resource-Issues--IOS-IPS-DTM---All-Events.x
ml
If you do not see this line, then a problem occurred during the upgrade regardless of whether the version command reports 4.1.2 (2040).
•To upgrade from 4.1.1 or a successful or unsuccessful 4.1.2 (2040) to 4.1.2 (2042), download the package, perform the upgrade as defined in Checklist for Upgrading the Appliance Software. If you are upgrading from 4.1.1, you must also execute the following command at the CLI of the upgraded MARS Appliance:
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.
•Prior to the 4.1.1 release, CSA was identified by the device type name Cisco CSA 4.0. As part of an upgrade, any Cisco CSA 4.0 devices were renamed as Cisco CSA 4.x. This new name includes support for Cisco CSA 4.0 and 4.5.
•The new case management replaces the Escalate Incident functionality in MARS 3.4.4 and earlier. However, escalated incidents are not converted to cases during the upgrade process. Therefore, you must close all open escalations before upgrading to MARS 4.1.1 (CSCsb52057).
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
From Version
|
|
Upgrade Package
|
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
|
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
•Top-level page: http://www.cisco.com/cgi-bin/tablebuild.pl?topic=279644034
•Upgrade files: http://www.cisco.com/cgi-bin/tablebuild.pl/cs-mars
•Recovery image files: http://www.cisco.com/cgi-bin/tablebuild.pl/cs-mars-recovery
•Supporting files: http://www.cisco.com/cgi-bin/tablebuild.pl/cs-mars-misc
Note If you are upgrading from a version earlier than those posted on CCO, please contact Cisco support for information on obtaining the required images. Do not attempt to skip versions along the upgrade path.
For information on obtaining a CCO account, see the following URL:
•http://www.cisco.com/en/US/applicat/cdcrgstr/applications_overview.html
Important Notes
The following notes apply to the 4.2.1 release:
•Do not to use DISTINCT or SAME in queries, and do not run multi-line queries in Release 4.2.1. If you run such a query, the system time outs after 20 minutes without returning any results. The message "Timeout Occurred" appears instead. You can use DISTINCT and SAME in a Query to create a rule with the Query interface.
•For Symantec AntiVirus, the Symantec agent hostname (AV client computer name) appears in the "Reported User" column of the event data. Therefore, you can define a query, report or rule related to this agent based on the "Reported User" value.
•The False Positive and Query pages (multi-column result format) have changed. You can now query on firing events that triggered false positives within a time interval. Such queries will render events that did not appear on the False Positive page. To ensure performance, the False Positive page only displays false positives from the most recent 10,000 firing events. To view additional false positives, you must perform a query.
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. Installation Quick Reference
2. Checklist for Initial Configuration
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:
•User Guide for CS-MARS Local Controller Version 4.2.x
•User Guide for CS-MARS Global Controller Version 4.2.x
Checklist for Initial Configuration
Initial configuration of the appliance accomplishes several goals:
•Introduces the two user interfaces to MARS: the command line interface (CLI) and the web interface.
•Licenses the appliance.
•Prepares the appliance to monitor and communicate on your network.
•Configures the system time so that event correlation works properly.
•Ensures the system administrative account is configured properly.
•Ensures appliance is running the most recent version of software.
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.
|
Task
|
|
1. Establish a console connection to the appliance.
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:
•A direct console connection to the appliance using a keyboard and monitor
•A standard serial console connection between a computer and the appliance using a terminal emulation package
•An Ethernet console connection between a computer and the appliance using a terminal emulation package
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:
•Establishing a Console Connection
|
|
2. Command Line Configuration: Setting the system administrative account's default password and configuring the interfaces.
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:
•Collect the information required to configure the appliance to operate optimally on your network.
•Log in to the appliance and change the password associated with the system administrative account (pnadmin).
•Configure the eth0 network interface, specifying the default gateway and IP address and network mask pair for that interface.
•(Optional) Configure the eth1 network interface, specifying the IP address and network mask pair for that interface.
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 The MARS Appliance does not allow you to configure both of its interfaces on the same network.
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:
•Configuring Basic Network Settings at the Command Line
•Change the Default Password of the System Administrative Account
•Specify the IP address and Default Gateway for the Eth0 Interface
•(Optional) Specify the IP Address and Default Gateway for the Eth1 Interface
|
|
3. Command Line Configuration.
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:
•Log in to the appliance using the system administrative account and the new password.
•Set the hostname of the appliance.
Result: The hostname is configured for the appliance. The appliance reboots.
For more information, see:
•Specify the Appliance Hostname
|
|
4. Command Line Configuration.
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:
•Log in to the appliance using the system administrative account and the new password.
•Set any additional static routes.
•Set the clock.
•Set the NTP server settings.
•Set the DNS domain name.
•Connect the appliance to the network (that is, plug in the Cat 5 cables.)
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:
•Specify the Time Settings
•Set Up Additional Routes
•Completing the Cable Connections
|
|
5. Complete initial configuration using the web interface.
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).
During this phase, you configure the following:
•Appliance license
•Zone identification (Global Controller only)
•E-mail server identification
•DNS addresses
•E-mail address for the system administrative account (pnadmin)
•TACACS/AAA login prompt settings
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:
•Completing the Configuration using MARS web interface
•Licensing the Appliance
•Verifying and Updating Network Settings
•Specifying the DNS Settings
•Configure E-mail Settings for the System Administrative Account
•Configure TACACS/AAA Login Prompts
|
|
6. Upgrade the appliance to the most recent software version.
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:
•Checklist for Upgrading the Appliance Software
|
Caveats
This section describes the open and resolved caveats with respect to this release.
•Open Caveats - Release 4.2.1
•Resolved Caveats - Release 4.2.1
•Resolved Caveats - Releases Prior to 4.2.1
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:
•Commands are in boldface type.
•Product names and acronyms may be standardized.
•Spelling errors and typos may be corrected.
Note If you are a registered cisco.com user, view Bug Toolkit on cisco.com at the following website:
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.2.1
The following caveats affect this release.
Reference Number
|
Description
|
CSCse56692
|
Issue: Policy query should not be case sensitive with interface names
Description: The policy table lookup feature in MARS is case sensitive when performing queries that match against interface names, such as outside and Outside. The two names are considered exclusive by MARS, while they are equivalent in Security Manager. As a result, name logged in the syslog event may not match the name in Security Manager. Syslog message lowercase all interface names.
Workaround: Use lowercase for all interface names an in the definition of interface roles in Security Manager.
|
CSCse56473
|
Issue: High pnparser CPU usage in processUserInfo thread
Description: One pnparser consumes 99% of the CPU for extended periods of time. As a result, you may notice:
•Events continue to be processed and saved into database but reported users contained in events are not extracted.
•Therefore, rules/queries/reports that match on reported users in events will not produce correct results.
Workaround: None.
|
CSCse54808
|
Issue: The time stamp shown by the pndbusage command is incorrect
Description: Two consecutive uses of the pndbusage command display a different current partition starting time.
Workaround: None.
|
CSCse53573
|
Issue: false alarm error in janus_log: corruption in shared buffer
Description: MARS processes use a shared buffer for event and incident data. Data is written in the form of fixed sizes where the size depends on the MARS Appliance model and whether type of shared data. Previously, the maximum size was 100,000, and therefore, an error message such as "corruption in shared buffer: encountered a large (>=100000) length chunk component, currentSize = 220260" would indicate data corruption that results in MARS skipping some events or incidents. However, fixing the defect CSCse24869 increased the maximum size to 300000 and therefore an error printed in the logs for data larger than 100000 is a false alarm as it can legitimately occur.
Workaround: You can safely ignore this error message when it refers to a chunk size smaller than 300,000.
|
CSCse51438
|
Issue: No GUI message to indicate a real-time event viewer timeout
Description: The real-time event viewer session will timeout if paused for more than 30 minutes. No error message will appear to indicate that the real-time event viewer is inoperative. Because the MARS login session timeout is also 30 minutes, you are directed to the MARS login screen when you click any GUI control after 30 minutes. After you login to MARS, the behavior is as follows depending on the GUI control you clicked:
•Tab—a blank page appears with a URL similar to the following:
https://172.16.16.16/Query/LLRTQueryStop.jsp?requestType=STOP&maxRows=40
•Submit button—The default Query Event Data dialog appears.
•Resume button —MARS displays the contents of a buffer then stops. The buffer contains the events that were not yet displayed when you clicked Pause.
•Restart button—MARS clears the paused display and does not display new events.
Workaround: Click Clear and submit a new real-time event viewer query.
|
CSCse45884
|
Issue: Real-Time (raw events) query causes client CPU to go to 100%
Description: At a high rate of incoming events, i.e., 100 events per second, the low latency query page consumes 100% of the CPU on the web interface client.
Workaround: None.
|
CSCse40803
|
Issue: Parsing error for FWSM-3-106011
Description: MARS fails to parse the FWSM syslog message "Error Message %FWSM-3-106011: Deny inbound (No xlate) string".
Workaround: None.
|
CSCse40779, CSCse23051
|
Issue: Query: Save as report with Mac Addr report criteria throws an Exception
Description: If you create a report using the query type: MAC addresses report, an exception (pink box) occurs.
Workaround: None.
|
CSCse38565
|
Issue: Re-importing Symantec AV client CSV doesn't work
Description: If you import Symantec AntiVirus agents into the MARS web interface using the CSV file format and then delete those agents, you cannot re-import them. Attempts to re-import will result in the error, "Error Occurred: Status: DbDevice", and none of the agents will be created.
Workaround: None.
|
CSCse34600
|
Issue: CPU utilization is not reported for PIX device
Description: When you select Yes in the Monitor Resource Usage box of the General tab for a PIX device, the CPU utilization is not reported for that device.
Workaround: None.
|
CSCse34407
|
Issue: Query Tab > Multi column query returns wrong results.
Description: When running a multi-column (custom column) query for a short duration of time, the results returned might contain a lot more data then actually expected.
Workaround: For correct results, run a regular query inline. In other words, do not choose custom column option for Result Format.
|
CSCse33688
|
Issue: no events under Cisco Switch-IOS 12.2
Description: With an IOS switch device, received logs should appear under Cisco Switch-IOS 12.2, However, they are being sorted under Cisco IOS 12.2 instead. In addition, under Management > Event Management, if you select Cisco Switch-IOS 12.2, no events appear.
Workaround: There is no work around to the incorrect sorting. To see the logs received from a Cisco Switch-IOS device, query using Cisco IOS 12.2 instead.
|
CSCse32591
|
Issue: dealing with duplicate hostnames in VA import
Description: While importing VA data from any one of the supported devices, MARS does the following:
1. For each device included in the report, MARS checks whether a device with the same name exists in the database.
2. If the device with the same name already exists in the database, then MARS changes the name of the new device according to the convention "devicename (count)", where "count" is the number of devices that exist in the database and have the same "devicename" substring. Using the new "devicename (count)" name, MARS adds the device to the database.
This issue is that when importing data about a given device, such as a router with multiple interfaces, MARS defines multiple, separate devices.
Workaround: None.
|
CSCse31722
|
Issue: Cloud toggle only works on first page of reporting devices
Description: You cannot expand or collapse devices within a cloud on pages other than the first page in the Security and Monitor Devices page. If you select this option on the second or later pages, the first page is displayed.
Workaround: None.
|
CSCse29860
|
Issue: UTC and GMT time zone missing
Description: In 4.1.5, the UTC standard is no longer available as an option for setting the clock on the MARS Appliance.
Workaround: None.
|
CSCse23176
|
Issue: MARS Global Controller not producing alerts when losing Local Controller communication
Description: The Global Controller is not generating alerts when it loses communication with the Local Controller. The user must determine this manually.
Workaround: At the command line on the Global Controller, run pnlog to determine whether the Local Controller is generating "Data timed out errors" or to run tcpdump to verify the Local Controller communication.
|
CSCse22751
|
Issue: Case management fails to 'Expand All' for attached report
Description: The Expand All option may not display sub-events that are attached to case. For example, if you attach the results of a batch query for all matching sessions to an existing case, where the results returned more than 5,000 sessions and so only the page displayed was added).
Workaround: None.
|
CSCse21936
|
Issue: Daylight savings time affects the custom parser's received time field
Description: The hour string in the parsed value field of user-created templates, shows an hour after the actual log timestamp on and after daylight savings time. (April 2, 2006)
Workaround: None.
|
CSCse21626
|
Issue: Clicking activate is not taking effect
Description: After disabling some DTM rules and enabling others, clicking Activate does not effect the changes.
Workaround: If Activate does not work, perform a pnstop and then a pnstart operation at the command line.
|
CSCse20593
|
Issue: CSM device type could not be added one time (OK most times)
Description: Rarely, when adding a Cisco Security Manager device type, a run-time scripting error occurs. This issue appears when there is a timeout situation in either the parent or child browser window, or when one window is unexpectedly closed.
Workaround: This issue rarely occurs. To work around the issue, repeat the add operation.
|
CSCse18865
|
Issue: scalability issues in My Reports page
Description: If you have a large number of reports (e.g., 70 or more) on the My Reports page, and displaying them takes a long time.
Workaround: None.
|
CSCse18816
|
Issue: UI takes 99% CPU, hanging browser and slowing system while expanding all
The client window (Internet Explorer) becomes unresponsive, the cursor state shows the application is processing information and remains in this state for 5+ minutes and/ or Windows marks the browser as 'Not Responding'. This issue occurs when the user clicks the '+' sign or 'Expand All' in the query results page where >1000 events are grouped together based on the query criteria.
Workaround: The following options are available:
•Instead of using Expand All, expand one group at a time.
•To resolve the hung process. close the client (Internet Explorer) or kill the process using Task Manager and open a new window to re-run the query.
|
CSCse17936
|
Issue: 5K Lines Custom Query fails
Description: In some cases, custom query can result in errors on the rendered page, as well as an incomplete page appears. In the known cases, this issue appears to have been the result of using the "raw message" field in the custom query.
Workaround: Removing the raw message column from the Query resolves the issue. This issue does not appear in all custom queries that include the raw message field.
|
CSCse17864, CSCse22610, CSCse22617
|
Issue: Device info was lost after migration
Description: Case Management migration from 4.1.x to 4.2.x can result in lost reports, queries, and devices that are associated with open cases.
Workaround: Close all Case Management cases before migrating to 4.2.x. 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.
|
CSCse13038
|
Issue: CS-MARS - learning of McAfee agents with invalid names
Description: McAfee ePO agents with non-ASCII hostname/character set, that are imported automatically into MARS 4.1.4 and later, will add devices with invalid names. Events reported from such agents may have:
•An invalid device name in the reporting device column
•Invalid characters in raw message.
This issue is caused by the lack of I18N support in the current MARS release. The following are likely causes of this issue:
•Invalid characters in the raw message sent from the ePO agent
•ePO agent names that contain some additional text, such as date or time
Workaround: Identify such invalid devices in MARS web interface and delete them periodically.
|
CSCse11258
|
Issue: After group is deleted, items under All group not shown
Description: This is a minor/cosmetic defect, as the delete is performed correctly, but the display is incorrect.
Workaround: Click the tab again, or any other selection that leads to a page refresh, to see all items in the All group.
|
CSCse10945
|
Issue: Summary Page Graphs Spontaneously Change Displayed Size (w/ multi-head)
Description: Graphs on the Summary Dashboard, Network Status, and My Reports pages can change display sizes when using a multi-head display. This issue can appear on both the Global Controller and Local Controller when the display period is in minutes. The content displayed is correct, however, the size of the display changes.
Workaround: Do not use a multi-head display.
|
CSCse09127
|
Issue: Failed load from csv returns incorrect status
Description: When a Load from csv operation fails, no errors are reported. Instead, the status is reported as OK. This issue appears when the user has configured an FTP server that does not allow passive transfer. The symptom is that the status is reported as OK, but there are no devices loaded in the MARS web interface.
Workaround: Other than using an FTP that supports passive transfer, no work around exists.
|
CSCse03134
|
Issue: More control is needed over retrieve raw messages and cleanup
Description: Repeated use of the `Retrieve Raw Messages' feature results in the following error message:
ava.io.IOException: No space left on device.
This occurs if `Retrieve Raw Messages' is used excessively within a short period of time.
Workaround: None. These files are cleaned up automatically after 2 weeks time.
|
CSCse00668
|
Issue: rule definition changes can lead to empty reports
Workaround: You can avoid this issue by defining a Rule Group for every rule that is to be used in a scheduled report.
|
CSCse00626
|
Issue: IP Management device group displays hosts only
Description: The View > Host option on Management >IP Management page filters all devices defined on the Security and Monitor Devices page from the IP Management page, including from Device groups, which in itself is expected behavior. However, this introduces an inconsistency as any type of device can be added to a Device Group through the Edit/Add Group button. After clicking Submit, the group lists only the Host entries, typically a subset of all devices belonging to a group, and this can be confusing to the user.
Workaround: To view the actual contents of a group, Select a device group and click the Edit Group button.
|
CSCse00251
|
Issue: process_inlinerep_srv ignores Rule Groups as selection/filtering criteria
Description: Rule groups are ignored as selection criteria in an inline report.
Workaround: You can avoid this issue by defining a Rule Group for every rule that is to be used in a scheduled report.
|
CSCsd96070
|
Issue: Data refreshes can take a long time when attempting to view the report data associated with that case.
Description: Due to the issues identified in CSCsd96067, viewing all of the data contained in a case that contains multiple reports can take a long time to load.
By default, reports attached to cases limit their results to 25 per page. Due to each report having its own paging value and the issues identified in CSCsd96067, attempting to view all of the data in each report attached to a case by changing to pagi |
