-
Device Configuration Guide for Cisco Security MARS, Release 6.x
-
Preface
- Part 1: Concepts
- Part 2: Intrusion Detection and Prevention (Network based)
- Part 3: Vulnerability Assessment
- Part 4: Switches
- Part 5: Routers
- Part 6: Firewalls
- Part 7: Network Access Control
- Part 8: Virtual Private Network Gateways
- Part 9: WLAN Controller
- Part 10: AAA Servers
- Part 11: Intrusion Detection and Prevention (Host based)
- Part 12: Virus Protection
- Part 13: Content Management
- Part 14: Database Applications
- Part 15: Web Servers
- Part 16: Web Proxies
- Part 17: Host Nodes
-
Index
-
Table Of Contents
Configuring Reporting and Mitigation Devices in MARS
Taskflow for Adding Devices to MARS
Prioritizing the Devices to Add
Understanding Access IP, Reporting IP, and Interface Settings
Configure SNMP Access for Devices in MARS
Configure Telnet Access for Devices in MARS
Configure SSH Access for Devices in MARS
Configure FTP Access for Devices in MARS
Activate the Reporting and Mitigation Devices
Discovering Your Network: Layer 3 Topology Discovery
Define SNMP Discovery Settings for a Network or IP Range
Add Valid Networks to Discovery List
Remove Networks from Discovery List
Discover Layer 3 Data On Demand
Edit a Scheduled Topology Discovery
Delete a Scheduled Topology Discovery
Run a Topology Discovery on Demand
Troubleshoot Layer 3 Network Discovery
Configuring Resource Usage Data
Enabling the Required SNMP OIDs for Resource Monitoring
Adding Reporting and Mitigation Devices
Adding Security and Monitor Devices Using Automatic Topology Discovery
Add Reporting and Mitigation Devices Individually
Adding Multiple Reporting and Mitigation Devices Using a Seed File
Devices that Require Custom Seed Files
Devices that Require Updates After the Seed File Import
Load Devices From the Seed File
Bulk Update of Device Credentials using Seed Files
Discovering and Testing Connectivity Options
Verifying Connectivity with the Reporting and Mitigation Devices
Configuring Reporting and Mitigation Devices in MARS
Cisco Security Monitoring, Analysis, and Response System (MARS) operates by analyzing the event streams of other network devices. These network devices play one of two roles in the MARS system: reporting devices that provide details about network activities and attacks, or security devices that can report about network activities as well as stop an attack using an access control list or policy rule to block the traffic. This guide describes how to prepare these reporting and mitigation devices so that they play an effective role in the MARS system.
This chapter contains the following topics:
•
Understanding Access IP, Reporting IP, and Interface Settings
•
•
•
•
Preparation Overview
Reporting devices follow a simple preparation process:
1.
2.
3.
4.
5.
Security devices include these five steps and enabling write access to the devices via an administrative username/password and specified connection type (SSH, SNMP, or Telnet).
Taskflow for Adding Devices to MARS
This checklist focuses on the easiest population approach to MARS. The recommended taskflow provides MARS with the most accurate delineation of your network as quickly as possible.
Step 1
The fastest way to populate MARS is through network discovery. During discovery, MARS can identify the layer 3 security and reporting devices, populate the network topology it uses to determine attack paths, and begin collecting data about typical network loads. However, to make this discovery truly effective, you must prepare the layer 3 devices you want MARS to monitor. You should also prepare any layer 2 devices that you plan to add, however, these devices are not automatically discovered. You must manually define the layer 2 devices.
SNMP RO strings or MIB contexts are defined for all devices able to share information. Events are enabled and forwarded to MARS.
For more information, see See references
Step 2
Using either a seed file or manual process, define the key reporting devices, such as IPS and vulnerability assessment devices. The goal here is to begin collecting events from key devices; those focused specifically on network and host-based vulnerabilities.
MARS begins to correlate security-related events from the primary reporting devices on your network.
For more information, see the following references:
1.
2.
3.
4.
Step 3
The discovery process identifies supported reporting and mitigation devices ad adds those devices to the Monitoring and Security Devices list, identifying them by the Reporting IP. You can later edit these discovered devices to provide Access IP information and perform more thorough device-level discovery.
As much of your layer 3 network as possible is mapped out. Important route information and network configuration is available, which helps identify choke points for stopping ongoing attacks.
For more information, see the following references:
1.
2.
3.
Step 4
With the CSV file, you can enter the values, passwords, and information for each device that you want the MARS Appliance to monitor in its appropriate row and column. While the seed file is useful for getting the MARS Appliance started processing event data for most devices, you may need to use the Admin > System Setup > Security and Monitoring Devices page to fine-tune the device manually. In addition, you must Activate the devices that you add using a seed file (see Activate the Reporting and Mitigation Devices).
For more information, see the following references:
1.
2.
3.
Step 5
As not all devices are supported via the seed file import, you must continue defining those security devices that are not discovered or imported via a seed file. In addition, you must manually define any layer 2 devices that you prepared as part of Item 1.
For more information, see the following references:
1.
2.
3.
Step 6
Application hosts are simply hosts on your network that are running important applications. Also, many of the supported reporting devices and security devices cannot be represented in MARS until the base host on which they are running is defined. Such reporting applications include Checkpoint Firewalls and all web servers.
For more information, see the following references:
1.
2.
Prioritizing the Devices to Add
To add a device, you provide MARS with the details required to discover a device's settings and configuration, as well as configured that device to send audit event data to MARS.
Selecting which devices to add to MARS is closely tied to the function of the devices. Devices that detect attacks and false positives, such as intrusion detection or prevention, anti-virus, and vulnerability assessment devices are critical to providing MARS with active attack and efficacy data. You should add them first. Second, you should add those devices that can block an attack, such as Cisco routers and switches.
To further reduce false positives, you can also provide host-based data for the hosts on your network. You want to begin defining the host data for the critical assets on your network, such as servers that house databases of sensitive employee records or financial data.
You can also configure MARS to discover many of the layer 3 devices on your network, as described in Discovering Your Network: Layer 3 Topology Discovery
Bootstrap Summary Table
Table 1-1 summaries the settings that you must configure for the identified reporting and mitigation devices. It also provides links to any required agent downloads and to detailed configuration information.
Table 1-1 Reporting and Mitigation Device Bootstrap Summary
Cisco Router
1.
2.
3.
4.
5.
Cisco Switch (IOS)
Cisco Switch (CatOS)
Extreme ExtremeWare
1.
2.
3.
4.
Generic Router
Cisco PIX
1.
2.
3.
Note
4.
Cisco Adaptive Security Appliance (ASA)
Cisco Firewall Services Module (FWSM)
Cisco IOS Firewall Feature Set
Juniper Netscreen
Checkpoint Opsec NG and Firewall-1
1.
2.
3.
4.
5.
Nokia Firewall (running Checkpoint)
Cisco VPN Concentrator
Cisco Network IDS
Cisco IDSM
1.
2.
–
–
–
Cisco Intrusion Prevention System (IPS), Network IPS
1.
2.
–
–
–
Cisco IPS ASA module
1.
2.
–
–
–
Cisco IOS IPS module
1.
2.
–
–
–
McAfee Intrushield
Juniper Netscreen IDP
Symantec Manhunt
ISS RealSecure
Snort
Enterasys Dragon
Cisco Security Agent
McAfee Entercept
ISS RealSecure Host Sensor
Symantec AntiVirus
Cisco Incident Control System (Cisco ICS), Trend Micro Outbreak Prevention Service (OPS)
McAfee ePolicy Orchestrator
Network Associates VirusScan
eEye REM
Qualys QualysGuard
Foundstone Foundscan
Windows
Do one of the following:
•
•
Syslog (pushed by SNARE agent) or event data pull using MS-RPC
Push Method: Configure Generic Microsoft Windows Hosts, page 36-5
Pull Method: Configure the Microsoft Windows Host, page 36-7
Solaris
—
Syslog (from Device)
Redhat Linux
—
Syslog (from Device)
Microsoft Internet Information Server
—
Syslog (from SNARE agent)
Sun iPlanet
—
HTTP (from MARS Agent)
Install and Configure the Web Agent on UNIX or Linux, page 34-7
Apache
—
HTTP (from MARS Agent)
Install and Configure the Web Agent on UNIX or Linux, page 34-7
NetApp NetCache
—
HTTP
Oracle
TCP
SQLnet (from Host)
Cisco Secure Access Control Sever (ACS)
—
Syslog (from MARS Agent)
Install and Configure the PN Log Agent, page 26-8 (Cisco Secure ACS)
Cisco Secure ACS Appliance 4.x
Publish syslog messages to MARS Appliance.
Cisco Secure ACS Appliance 3.x
Install and configure remote log agent.
Syslog (from MARS Agent) on secondary host
Supporting Cisco Secure ACS Solution Engine 3.x, page 26-2
Install and Configure the PN Log Agent, page 26-8 (Cisco Secure ACS)
Generic Syslog Server
Publish syslog messages to MARS Appliance.
Enable SNMP access by MARS Appliance.
Generic SNMP Server
Enable SNMP access by MARS Appliance.
Understanding Access IP, Reporting IP, and Interface Settings
When defining a reporting or mitigation device in the web interface, MARS allows (and at times, requires) you to specify several IP addresses. Understanding the purpose of the different addresses is important to effectively defining the devices that you want to monitor and manage. It is also important to understand their relationship to other settings that you can identify.
If a device has a single interface and a single IP address associated with that interface, the access and reporting IP addresses are the same as the address assigned to the interface. MARS collects this information separately to support those devices that have multiple interfaces, multiple IP addresses associated with a single interface, or both.
Note
This section discusses the following three addresses and their relationship to other settings:
This section contains the following topics:
Access IP
MARS uses the access IP address to either connect to the device for network-based administrative sessions or connect to a remote server on which a file containing the device's configuration is stored. The expected value is determined by the access type you select. Most devices also require that you explicitly identify the IP addresses of hosts allowed to administer them. The MARS Appliance must be listed among such hosts as part of the device preparation.
The protocol that MARS uses to connect to the device is defined by the access type value, which is a dependency for enabling administrative access. Once MARS has administrative access, it can perform device discovery, which includes settings such as ARP tables, NAT, routes, and active ACLs, all of which helps MARS understand the topology, perform attack path analysis, and identify false positive incidents. Discovery can be performed to varying degrees using any of the access types. For more information on access types, see Selection of the Access Type.
MARS also uses SNMP RO and SNMPwalk to discover the device settings and topology information. However, the two methods of discovery are distinct and have distinct requirements. SNMPwalk requires the access IP address and the SNMP access type. SNMP RO discovery does not requires the SNMP access type, but it does require the access IP address.
Note
In addition, both SNMPwalk and SNMP RO are unrelated to SNMP notifications or SNMP traps. SNMPwalk and SNMP RO both require that MARS initiate the information request, where as SNMP notifications are event notifications published by the reporting device, much the same as syslog messages are. As with syslog messages, SNMP notifications are published over the reporting IP address.
Reporting IP
The reporting IP is the source IP address of event messages, logs, notifications, or traps that originate from the device. MARS uses this address to associate received messages with the correct device. For single-homed devices, the reporting IP address is the same as the access IP; for dual- or multi-homed devices, this address must be explicitly associated with the syslog, NetFlow, and SNMP services running on the reporting device. Most devices also require, for each message type, that you explicitly identify the IP addresses of hosts to which messages should be published. These hosts are commonly referred to as target log servers. The MARS Appliance must be listed among such hosts as part of the device preparation.
The role in MARS of the reporting IP address differs from that of the access IP address in that the reporting IP address is treated passively from the MARS perspective. MARS does not query the device using this address. Such operations are performed using the access IP address and the access type.
MARS accepts only one reporting IP address per device. For devices supporting two message formats, such as NetFlow and syslog, you must ensure that both message formats are bound to the same source IP address (the reporting IP). In Cisco IOS devices, this common association is not the default so you must change either the syslog or the NetFlow reporting IP address to match the other. If the message types do not originate from a common IP address, one of them is seen as originating from an unreported device and MARS does not parse those events correctly.
The supported format of event data varies among reporting devices. Just because the device is able to generate syslog, NetFlow, and SNMP notifications does not mean that MARS processes all three formats. The document, Supported and Interoperable Devices and Software for Cisco Security MARS Local Controller 6.0.x, identifies the event retrieval protocol supported by each device type.
Interface Settings
Interface settings are exclusive to hosts and software applications running on hosts. While MARS can discover the settings of a reporting device that is a software application running on a host, it cannot discover settings about the host itself. The role of interface settings in MARS is different from that the access IP address and reporting IP address. Interface settings represent static information, not discovered or learned, about the host.
When correlating events specific to a host or reporting devices running on that host, MARS needs to understand the number of interfaces installed in the host, their names, and the IP addresses and networks associated with them. MARS uses the interface settings to guide discovery operations, to determine attack path vectors, and to perform Nessus vulnerability assessments.
Selection of the Access Type
The access type refers to the administrative protocol that MARS uses to access a reporting device or mitigation device. For most devices monitored by MARS, you can choose from among four administrative access protocols:
•
Note
•
•
Note
•
Tip
You can use any access scheme in conjunction with an SNMP RO community string. The division between Access IP and Reporting IP is clearly illustrated by an FTP access type example. Assume that you have SNMP RO access to a router, but your configuration discovery (access type) is restricted to a file stored on an FTP server.
When you define a device in MARS, the Access IP is the IP address of the FTP server (not the router), and the authentication information is used to access the FTP server. The Access Method is set to FTP. The Reporting IP is the IP address of the interface over which SNMP traps are published by the router.
This section describes how to configure each access type, identifying the fields that should be completed when a specific access type is selected. For efficiencies sake, these procedures are referenced throughout the specific device configuration topics, as they related to a specific device type.
This section contains the following topics:
•
•
•
•
Configure SNMP Access for Devices in MARS
This procedure assumes you are defining a reporting device or mitigation device and that you were referred to this procedure after selecting SNMP in the Access Type list. To select SNMP as the access type, you must provide MARS with SNMP read-write access.
Note
If you selected SNMP as the access type, follow these steps:
Step 1
•
•
•
Step 2
Note
SNMP Version 1
•
SNMP Version 3
Note
•
•
•
•
•
•
•
Configure Telnet Access for Devices in MARS
This procedure assumes you are defining a reporting device or mitigation device and that you were referred to this procedure after selecting TELNET in the Access Type list.
If you selected TELNET as the access type, follow these steps:
Step 1
Step 2
Step 3
Configure SSH Access for Devices in MARS
This procedure assumes you are defining a reporting device or mitigation device and that you were referred to this procedure after selecting SSH in the Access Type list.
Note
If you selected SSH as the access type, follow these steps:
Step 1
Step 2
Step 3
Step 4
Configure FTP Access for Devices in MARS
This procedure assumes you are defining a reporting device or mitigation device and that you were referred to this procedure after selecting FTP in the Access Type list.
Note
If you selected FTP as the access type, follow these steps:
Step 1
Note
Step 2
Step 3
This path begins at the root of the FTP server's published folder, not at the root directory of server.
Step 4
Note
Activate the Reporting and Mitigation Devices
After you have added reporting devices and mitigation devices to MARS, you must activate those devices before MARS begins to fully process the data provided by those devices. This processing is different from those devices discovered on the network, where the logs sent to the appliance are stored, but your ability to interact with that data is limited to queries and reports. Typically, MARS runs inspection rules and generates notifications only against the data retrieved from activated devices.
Once a device is known to the MARS Appliance, all data provided by that particular device can be normalized and sessionized, which enables that device's data to be used to fire an incident.
Note
Tip
To activate added devices, follow these steps:
Step 1
The Submit action stores the device details in the database. Once you click Submit, your work is saved, even if you drop the administrative connection before clicking Activate.
Step 2
The Activate action differs from Submit in that MARS begins to inspect and generate notifications about the data provided by the devices.
Tip
Discovering Your Network: Layer 3 Topology Discovery
For MARS to reach full operability, you must specify the Simple Network Management Protocol (SNMP) discovery settings and identify which networks to discover. There are many advantages to discovering your network, including identifying Cisco routers and gateways that can act as mitigation devices and providing a more complete topology graph on the Dashboard page that enables a more accurate attack path analysis. Once the appliance discovers these networks, MARS offers a more accurate view of MAC addresses, end-point lookup (attack paths), and network topology. Topology discovery enables operation level three; see "Levels of Operation" for more information.
SNMP is a network management protocol that provides a means to monitor and control network devices, and to manage configurations, statistics collection, performance, and security. Beginning in 6.0.6, MARS supports SNMP version 3.0 (SNMPv3) for Cisco devices, which enables authentication of the manager node (MARS Appliance) by the agent (monitored device) as well as encryption between the two nodes. SNMPv1, available in releases before 6.0.6, is only valid in read-only environments—reading MIB data maintained by the agent. Even in a read-only environment, the data is passed in cleartext. However, SNMPv3 can exist in a network control environment because it supports authenticating the manager before writing to the MIB. SNMPv3 is includes three key services: authentication, privacy, and access control.
In MARS, SNMPv3 support enables the following features:
•
Note
•
•
Note
To view the topologies, select the Summary > Dashboard page in the web interface.
Note
How Layer 3 Topology Discovery Works
Network discovery is an iterative, SNMP-based layer 3 discovery. Starting with the layer 3 seed device (known as the SNMP target), MARS discovers its layer 3 neighbors and then iterates through each neighbor as a layer 3 seed device to discover other devices. SNMP access to layer 3 devices is required. You can choose between SNMPv1 read only access via an SNMP RO community string or various SNMPv3 access options. You can also refine the discovery parameters to ensure that you do not discover your ISPs network (Admin > System Setup > Valid Networks).
This process discovers your entire layer 3 network with two exceptions:
•
•
To work around the first exception, where a device blocks SNMP access, do the following:
1.
2.
The MARS network discovery engine combines the complete topology from the partially discovered topologies of different SNMP targets and devices discovered via Telnet, SSH, Checkpoint CPMI, and so forth. The Layer 3 network discovery is automatic because of next hop address information in routes that can be used to iteratively discover additional devices. However this is not the case for Layer 2 networks, so you must manually configure the Layer 2 devices, their management interfaces, and access credentials (such as SNMP community strings) on MARS. This information can also be imported from a seed CSV file written in a Cisco works format.
Define SNMP Discovery Settings for a Network or IP Range
Once you have identified networks and their associated SNMP community string or authentication information, MARS can discover networks, devices, and interfaces within those networks and IP ranges. This type of discovery improves the topology population and helps identify new mitigation points on your network.
To define the SNMP discovery settings for a network address or IP range, follow these steps:
Step 1
Step 2
•
•
Step 3
SNMP Version 1
•
SNMP Version 3
Note
•
•
•
•
•
•
•
Step 4
Note
Step 5
Step 6
Add Valid Networks to Discovery List
MARS uses SNMP to discover your layer 3 network devices. Beginning with a provided SNMP target, MARS discovers that target's layer 3 neighbors and then uses each neighbor as a new starting point to discover its neighboring devices and so on. Only SNMP read access (RO) is required. Adding valid networks confines the MARS to discover only the networks that you want. MARS uses this information to create topologies, find MAC addresses, and for end-point lookup (attack paths).
Note
To add valid networks, follow these steps:
Step 1
Step 2
•
Step 3
•
•
Step 4
Remove Networks from Discovery List
To remove a network, follow these steps:
Step 1
Step 2
Step 3
Discover Layer 3 Data On Demand
You can schedule topology discovery, as defined in Scheduling Topology Updates. However, you can also initiate an on-demand discovery.
To perform an on-demand discovery, follow these steps:
Step 1
Step 2
Step 3
Scheduling Topology Updates
Scheduled topology updates inform MARS about the hosts on the network, providing details such as IP addresses, operating systems, open ports, and applications running on the hosts. MARS uses this information to populate the cloud segments of its topology with host addresses and determine probable vulnerabilities relative to detected attacks. The scheduled updates also pull event information from reporting devices and via its built-in NMAP process.
You can configure MARS to run automatic topology updates on devices, networks, and groups of networks. Scheduling topology updates is a critical part of keeping the MARS Appliance abreast of changes in the network and of changes to the configuration settings of the reporting devices and mitigation devices. This operation is similar to clicking Discover when defining a reporting device.
Configuration discovery depends on the device type, proper authorization, an access type, such as Telnet, SSH or SNMP, and an access IP address. When device discovery is performed, MARS contacts the device and conducts a topology and configuration discovery. This discovery collects all route, NAT, and ACL-related information for the device or admin context. In addition, the name of the device may change to hostname.domain format if it was not already entered as such. If discovering a device that supports modules or virtualization, MARS also discovers information about modules, admin contexts, and security contexts. Another effect of scheduled updates is that MARS keeps the network diagram and attack paths current in the Dashboard.
This feature also allows you to pull data from those devices that require interval-based polling. The list of devices that require such polling are the following:
•
•
•
•
Figure 1-1 Example Scheduled Update for eEye REM
Depending on the device being discovered, MARS selects from the following management information bases (MIBs) to discover the device's settings:
•
•
•
•
•
•
•
•
Schedule a Network Discovery
To add a network for scheduled discovery, follow these steps:
Step 1
The Topology/Monitored Device Update Scheduler page displays.
Step 2
Step 3
Step 4
•
•
•
Step 5
Tip
Step 6
•
•
•
•
Step 7
Edit a Scheduled Topology Discovery
Step 1
Step 2
Step 3
•
Step 4
•
•
•
•
Step 5
Delete a Scheduled Topology Discovery
Step 1
The Topology/Monitored Device Update Scheduler page displays.
Step 2
Step 3
Run a Topology Discovery on Demand
Step 1
Step 2
Troubleshoot Layer 3 Network Discovery
Configuring Resource Usage Data
By monitoring and reporting on available device usage parameters, MARS can inform you of device health status and any abnormal conditions a device may be encountering.
Although the Monitor Resource Usage box appears on every host and reporting device, only some device types actually provide resource usage data to MARS. The nature and extent of the data provided is shown in Table 1-3.
Table 1-3 Device Anomaly Resource Monitoring
Cisco IOS routers running 12.2, 12.3, 12.4
Yes
Yes
No
Yes
Cisco IOS switches running 12.2
Yes
Yes
No
Yes
Cisco PIX 6.0, 6.1, 6.2, 6.3, 7.0, 8.x
Yes
Yes
Yes
Yes1
Cisco ASA 7.0, 7.2, 8.0, 8.1, 8.2
Yes
Yes
Yes
Yes1
Cisco FWSM 2.2, 2.3, 3.1, 3.2
Yes
Yes
Yes
Yes1
Check Point OPSEC NG FP3, NG AI, NGX
No
No
Yes
No
1For FWSM, ASA, and PIX 7.X and onwards, MARS monitors system context level resources (CPU, memory, connections) via the CLI and per-context resources (CPU, memory, connections, interface utilization, and errors) via SNMP. Therefore, you can monitor three views of the FWSM module: base platform (IOS switch hosting the module), module level (system context), and security context level.
For these devices, MARS can provide data about CPU utilization, memory utilization, and device saturation. For FWSM, MARS monitors system context level resources (CPU, memory, connections) via the CLI and per-context resources (CPU, memory, connections, interface utilization, and errors) via SNMP. Therefore, you can monitor three views of the FWSM module: base platform (IOS switch hosting the module), module level (system context), and security context level.
To enable the collection of resource usage data, you must ensure that the resource usage-specific events are logged by the reporting devices, that the SNMP RO community string is set, that those devices forward the events to MARS, and that the device is defined in the web interface as a reporting device or mitigation device. In addition, you must select Yes in the Monitor Resource Usage box of the General tab for each supported reporting device.
Once configured, MARS uses SNMP to poll the device every 5 minutes for the following SNMP Object Identifiers (OIDs):
•
•
•
•
It also detects anomalous resource utilization if the consumption is significantly higher than the hourly average.
The following resource usage data reports are available:
•
•
•
•
•
•
•
You can define custom rules, reports, and queries about resource usage based on the following events:
•
•
•
•
•
•
•
•
There is also is pre-defined resource utilization inspection rule:
•
•
•
Enabling the Required SNMP OIDs for Resource Monitoring
Table 1-4 lists the OIDs to enable, on a per device basis, for the supported model and versions.
Table 1-4 SNMP OIDs Required for Resource Monitoring
Cisco IOS 12.2, Cisco IOS 12.3, Cisco IOS 12.4
DEVICE_RES_OID_CPU
.1.3.6.1.4.1.9.2.1.56.0
DEVICE_RES_OID_MEMORY_FREE
.1.3.6.1.4.1.9.9.48.1.1.1.6.1
DEVICE_RES_OID_MEMORY_USED
.1.3.6.1.4.1.9.9.48.1.1.1.5.1
DEVICE_RES_OID_INTERFACE_NUMBER
.1.3.6.1.2.1.2.1.0
DEVICE_RES_OID_INTERFACE_IN_BYTES
.1.3.6.1.2.1.2.2.1.10.i
DEVICE_RES_OID_INTERFACE_OUT_BYTES
.1.3.6.1.2.1.2.2.1.16.i
DEVICE_RES_OID_INTERFACE_IN_BANDWIDTH
.1.3.6.1.2.1.2.2.1.5.i
DEVICE_RES_OID_INTERFACE_OUT_BANDWIDTH
.1.3.6.1.2.1.2.2.1.5.i
DEVICE_RES_OID_INTERFACE_IN_ERROR
.1.3.6.1.2.1.2.2.1.14.i
DEVICE_RES_OID_INTERFACE_OUT_ERROR
.1.3.6.1.2.1.2.2.1.20.i
DEVICE_RES_OID_INTERFACE_IN_UCAST_PACKET
.1.3.6.1.2.1.2.2.1.11.i
DEVICE_RES_OID_INTERFACE_IN_NUCAST_PACKET
.1.3.6.1.2.1.2.2.1.12.i
DEVICE_RES_OID_INTERFACE_OUT_UCAST_PACKET
.1.3.6.1.2.1.2.2.1.17.i
DEVICE_RES_OID_INTERFACE_OUT_NUCAST_PACKET
.1.3.6.1.2.1.2.2.1.18.i
DEVICE_RES_OID_INTERFACE_DESCRIPTOR
.1.3.6.1.2.1.2.2.1.2.i
DEVICE_RES_OID_INTERFACE_IN_DISCARDS
.1.3.6.1.2.1.2.2.1.13.i
DEVICE_RES_OID_INTERFACE_IN_UNKNOWN_PROTOS
.1.3.6.1.2.1.2.2.1.15.i
DEVICE_RES_OID_INTERFACE_OUT_DISCARDS
.1.3.6.1.2.1.2.2.1.19.i
Cisco Switch-IOS 12.2
DEVICE_RES_OID_CPU
.1.3.6.1.4.1.9.2.1.56.0
DEVICE_RES_OID_MEMORY_FREE
.1.3.6.1.4.1.9.9.48.1.1.1.6.1
DEVICE_RES_OID_MEMORY_USED
.1.3.6.1.4.1.9.9.48.1.1.1.5.1
DEVICE_RES_OID_INTERFACE_NUMBER
.1.3.6.1.2.1.2.1.0
DEVICE_RES_OID_INTERFACE_IN_BYTES
.1.3.6.1.2.1.2.2.1.10.i
DEVICE_RES_OID_INTERFACE_OUT_BYTES
.1.3.6.1.2.1.2.2.1.16.i
DEVICE_RES_OID_INTERFACE_IN_BANDWIDTH
.1.3.6.1.2.1.2.2.1.5.i
DEVICE_RES_OID_INTERFACE_OUT_BANDWIDTH
.1.3.6.1.2.1.2.2.1.5.i
DEVICE_RES_OID_INTERFACE_IN_ERROR
.1.3.6.1.2.1.2.2.1.14.i
DEVICE_RES_OID_INTERFACE_OUT_ERROR
.1.3.6.1.2.1.2.2.1.20.i
DEVICE_RES_OID_INTERFACE_IN_UCAST_PACKET
.1.3.6.1.2.1.2.2.1.11.i
DEVICE_RES_OID_INTERFACE_IN_NUCAST_PACKET
.1.3.6.1.2.1.2.2.1.12.i
DEVICE_RES_OID_INTERFACE_OUT_UCAST_PACKET
.1.3.6.1.2.1.2.2.1.17.i
DEVICE_RES_OID_INTERFACE_OUT_NUCAST_PACKET
.1.3.6.1.2.1.2.2.1.18.i
DEVICE_RES_OID_INTERFACE_DESCRIPTOR
.1.3.6.1.2.1.2.2.1.2.i
DEVICE_RES_OID_INTERFACE_IN_DISCARDS
.1.3.6.1.2.1.2.2.1.13.i
DEVICE_RES_OID_INTERFACE_IN_UNKNOWN_PROTOS
.1.3.6.1.2.1.2.2.1.15.i
DEVICE_RES_OID_INTERFACE_OUT_DISCARDS
.1.3.6.1.2.1.2.2.1.19.i
PIX 6.2, 6.3, 7.0, 7.2, 8.0, , 8.1, 8.2
DEVICE_RES_OID_CPU
.1.3.6.1.4.1.9.9.109.1.1.1.1.3.1
DEVICE_RES_OID_CONNECTION
.1.3.6.1.4.1.9.9.147.1.2.2.2.1.5.40.6
DEVICE_RES_OID_MEMORY_FREE
.1.3.6.1.4.1.9.9.48.1.1.1.6.1
DEVICE_RES_OID_MEMORY_USED
.1.3.6.1.4.1.9.9.48.1.1.1.5.1
DEVICE_RES_OID_INTERFACE_NUMBER
.1.3.6.1.2.1.2.1.0
DEVICE_RES_OID_INTERFACE_IN_BYTES
.1.3.6.1.2.1.2.2.1.10.i
DEVICE_RES_OID_INTERFACE_OUT_BYTES
.1.3.6.1.2.1.2.2.1.16.i
DEVICE_RES_OID_INTERFACE_IN_BANDWIDTH
.1.3.6.1.2.1.2.2.1.5.i
DEVICE_RES_OID_INTERFACE_OUT_BANDWIDTH
.1.3.6.1.2.1.2.2.1.5.i
DEVICE_RES_OID_INTERFACE_IN_ERROR
.1.3.6.1.2.1.2.2.1.14.i
DEVICE_RES_OID_INTERFACE_OUT_ERROR
.1.3.6.1.2.1.2.2.1.20.i
DEVICE_RES_OID_INTERFACE_IN_UCAST_PACKET
.1.3.6.1.2.1.2.2.1.11.i
DEVICE_RES_OID_INTERFACE_IN_NUCAST_PACKET
.1.3.6.1.2.1.2.2.1.12.i
DEVICE_RES_OID_INTERFACE_OUT_UCAST_PACKET
.1.3.6.1.2.1.2.2.1.17.i
DEVICE_RES_OID_INTERFACE_OUT_NUCAST_PACKET
.1.3.6.1.2.1.2.2.1.18.i
DEVICE_RES_OID_INTERFACE_DESCRIPTOR
.1.3.6.1.2.1.2.2.1.2.i
DEVICE_RES_OID_INTERFACE_IN_DISCARDS
.1.3.6.1.2.1.2.2.1.13.i
DEVICE_RES_OID_INTERFACE_IN_UNKNOWN_PROTOS
.1.3.6.1.2.1.2.2.1.15.i
DEVICE_RES_OID_INTERFACE_OUT_DISCARDS
.1.3.6.1.2.1.2.2.1.19.i
ASA 7.0, 7.2, 8.0
DEVICE_RES_OID_CPU
.1.3.6.1.4.1.9.9.109.1.1.1.1.3.1
DEVICE_RES_OID_CONNECTION
.1.3.6.1.4.1.9.9.147.1.2.2.2.1.5.40.6
DEVICE_RES_OID_MEMORY_FREE
.1.3.6.1.4.1.9.9.48.1.1.1.6.1
DEVICE_RES_OID_MEMORY_USED
.1.3.6.1.4.1.9.9.48.1.1.1.5.1
DEVICE_RES_OID_INTERFACE_NUMBER
.1.3.6.1.2.1.2.1.0
DEVICE_RES_OID_INTERFACE_IN_BYTES
.1.3.6.1.2.1.2.2.1.10.i
DEVICE_RES_OID_INTERFACE_OUT_BYTES
.1.3.6.1.2.1.2.2.1.16.i
DEVICE_RES_OID_INTERFACE_IN_BANDWIDTH
.1.3.6.1.2.1.2.2.1.5.i
DEVICE_RES_OID_INTERFACE_OUT_BANDWIDTH
.1.3.6.1.2.1.2.2.1.5.i
DEVICE_RES_OID_INTERFACE_IN_ERROR
.1.3.6.1.2.1.2.2.1.14.i
DEVICE_RES_OID_INTERFACE_OUT_ERROR
.1.3.6.1.2.1.2.2.1.20.i
DEVICE_RES_OID_INTERFACE_IN_UCAST_PACKET
.1.3.6.1.2.1.2.2.1.11.i
DEVICE_RES_OID_INTERFACE_IN_NUCAST_PACKET
.1.3.6.1.2.1.2.2.1.12.i
DEVICE_RES_OID_INTERFACE_OUT_UCAST_PACKET
.1.3.6.1.2.1.2.2.1.17.i
DEVICE_RES_OID_INTERFACE_OUT_NUCAST_PACKET
.1.3.6.1.2.1.2.2.1.18.i
DEVICE_RES_OID_INTERFACE_DESCRIPTOR
.1.3.6.1.2.1.2.2.1.2.i
DEVICE_RES_OID_INTERFACE_IN_DISCARDS
.1.3.6.1.2.1.2.2.1.13.i
DEVICE_RES_OID_INTERFACE_IN_UNKNOWN_PROTOS
.1.3.6.1.2.1.2.2.1.15.i
DEVICE_RES_OID_INTERFACE_OUT_DISCARDS
.1.3.6.1.2.1.2.2.1.19.i
FWSM 2.2, 2.3, 3.1, 3.2
DEVICE_RES_OID_CPU
.1.3.6.1.4.1.9.9.109.1.1.1.1.3.1
DEVICE_RES_OID_CONNECTION
.1.3.6.1.4.1.9.9.147.1.2.2.2.1.5.40.6
DEVICE_RES_OID_MEMORY_FREE
.1.3.6.1.4.1.9.9.48.1.1.1.6.1
DEVICE_RES_OID_MEMORY_USED
.1.3.6.1.4.1.9.9.48.1.1.1.5.1
DEVICE_RES_OID_INTERFACE_NUMBER
.1.3.6.1.2.1.2.1.0
DEVICE_RES_OID_INTERFACE_IN_BYTES
.1.3.6.1.2.1.2.2.1.10.i
DEVICE_RES_OID_INTERFACE_OUT_BYTES
.1.3.6.1.2.1.2.2.1.16.i
DEVICE_RES_OID_INTERFACE_IN_BANDWIDTH
.1.3.6.1.2.1.2.2.1.5.i
DEVICE_RES_OID_INTERFACE_OUT_BANDWIDTH
.1.3.6.1.2.1.2.2.1.5.i
DEVICE_RES_OID_INTERFACE_IN_ERROR
.1.3.6.1.2.1.2.2.1.14.i
DEVICE_RES_OID_INTERFACE_OUT_ERROR
.1.3.6.1.2.1.2.2.1.20.i
DEVICE_RES_OID_INTERFACE_IN_UCAST_PACKET
.1.3.6.1.2.1.2.2.1.11.i
DEVICE_RES_OID_INTERFACE_IN_NUCAST_PACKET
.1.3.6.1.2.1.2.2.1.12.i
DEVICE_RES_OID_INTERFACE_OUT_UCAST_PACKET
.1.3.6.1.2.1.2.2.1.17.i
DEVICE_RES_OID_INTERFACE_OUT_NUCAST_PACKET
.1.3.6.1.2.1.2.2.1.18.i
DEVICE_RES_OID_INTERFACE_DESCRIPTOR
.1.3.6.1.2.1.2.2.1.2.i
DEVICE_RES_OID_INTERFACE_IN_DISCARDS
.1.3.6.1.2.1.2.2.1.13.i
DEVICE_RES_OID_INTERFACE_IN_UNKNOWN_PROTOS
.1.3.6.1.2.1.2.2.1.15.i
DEVICE_RES_OID_INTERFACE_OUT_DISCARDS
.1.3.6.1.2.1.2.2.1.19.i
CheckPoint OpSec NG FP3, NG AI, NGX
DEVICE_RES_OID_CONNECTION
.1.3.6.1.4.1.2620.1.1.25.3.0
DEVICE_RES_OID_INTERFACE_NUMBER
.1.3.6.1.2.1.2.1.0
1For OIDs ending with '.i', the 'i' represents a variable interface number. Based on the total number of interfaces for that device, device_monitor replaces the 'i' with each interface number and queries the device separately for that interface.
Adding Reporting and Mitigation Devices
Three methods exist for adding reporting devices and mitigation devices to MARS:
•
•
•
From the Security and Monitor Devices page, you can add or edit the reporting devices and mitigation devices that MARS monitors. To access this page, click Admin > System Setup > Security and Monitor Devices. You can search for, add, edit, delete, change display status, and load or update devices from the seed file.
The device support is categorized into three categories:
•
•
You can only define one SW security application for each reporting device. For example, if you have multiple Oracle databases running on a server, you cannot add separate instances to the same host. To work around this issue, use multiple servers or have the different applications report to MARS using unique reporting IP addresses. When using unique IP addresses, each one represents a unique host in MARS on which you can define a single SW security application.
•
The complete list of supported devices is presented in the Supported and Interoperable Devices and Software for Cisco Security MARS Local Controller 6.0.x document. Devices are added to this list on an ongoing basis via software upgrade packages. See the document Cisco Security MARS Initial Configuration and Upgrade Guide 6X for details on how to upgrade your MARS Appliance.
MARS can also support any syslog or SNMP devices, even if they do not appear on the list of devices supported by the MARS. You can enter any syslog or SNMP device into the network topology, configure it to report data to the MARS, and query it using a free-form keyword query. (See To Run a Keyword Query.)
For more information on adding devices, see:
•
•
•
Regardless of the method that you have used to add the devices, you should also perform the following tasks:
•
•
Adding Security and Monitor Devices Using Automatic Topology Discovery
Network discovery provides MARS with the topology and network details required to achieve its highest operation level, level 3.
To present and use topology information, MARS must learn about gateways and connected networks. You can teach MARS about the network's topology in the following ways:
•
•
•
•
On the Admin > System Setup page, under the Topology Discovery Information section, three options exist for defining details to automatically discover security and monitoring devices. These options are the following:
•
•
•
Based on the networks defined within the schedule rules, MARS starts with the first SNMP target associated with those networks or ranges as defined under Valid Networks and attempts to discover that device using SNMP discovery. The discovery process continues as long as the target device provides additional routes and the addresses of such routes are part of the networks in another schedule rule. The process also iterates through each SNMP target that is defined. The entire discovery process is limited based on the schedule rule's bounding networks, the SNMP targets, the valid network and IP ranges, and the SNMP RO community strings, which are defined for each network. Networks and SNMP RO community strings can overlap, in which case MARS tries each string against the gateway addresses discovered within that network. The discovery process only discovers Layer 3 gateway devices, such as routers and firewalls. It does not discover hosts, unless those hosts are defined as the explicit target within a schedule rule (see Scheduling Topology Updates).
As the discovery process identifies supported security and monitoring devices, it adds those devices to the Security and Monitor Devices list (Admin > System Setup), identifying them by their Reporting IP. You can later edit these discovered devices to provide Access IP information and perform more thorough device-level discovery. Once a device is listed under Security and Monitor Devices, it may be rediscovered, but it will not be added again unless it has been properly deleted (see Delete a Device).
For more information on these settings, see the following:
•
Note
Add Reporting and Mitigation Devices Individually
In general, you have two choices for adding devices that you want to monitor into your MARS. You can create a seed file or you can add each device manually. Seed file support is limited to a few device types, see Column E of Table 1-5 for the devices supported.
When manually configuring devices, select the devices that are most interesting to you. Once added, you can come back and edit them as necessary. Manual configuration is also useful when you add or change a single security device on your network.
Note
To add a device manually, follow these steps:
Step 1
Step 2
Step 3
Step 4
Step 5
Adding Multiple Reporting and Mitigation Devices Using a Seed File
The seed file is a comma-delimited file with the file extension .csv (comma-separated value). Most spreadsheet programs let you import and export files as CSV files.
The following is a sample seed file as exported from a popular spreadsheet program:
10.1.1.1,,,,PIX,TELNET,,,cisco,,,,,,,,,,,192.168.229.241,,,,IOS,TELNET,,,csRv$12*,EcsRv$12$,,,,,,,,,,10.1.1.83,,,,PIX,SSH,pix,Vpnspn12,,vPfw1ne,,,,,,,,,,192.168.151.169,,,,PIX,SSH,pix,lpt$12,,pot$1*d1,,,,,,,,,,10.4.2.4,,,,NETSCREEN,SSH,netscreen,nt*$scn25,,,,,,,,,,,,10.4.2.3,,,,NETSCREEN,SSH,netscreen,nt*$scn10,,,,,,,,,,,,10.1.1.241,,,,IOS,TELNET,,,cisco,cisco,,,,,,,,,,10.4.2.1,,,,IOS,TELNET,,,Qa$1*5ft,gt$*j15,,,,,,,,,,10.4.2.2,,,,IOS,TELNET,,,Qa$1*5ft,gt$*j15,,,,,,,,,,wanRouter,public,,,IOS,SNMP,,,,,,,,,,,,,,,myPix63,,,,PIX,SSH,pix,test1,,test1234,,,,,,,,,,,10.2.3.1MyPc,,,,WINDOWS,RPC,myname,mypass,,,,,,,,,,,,,myPix70,,,,PIX7X,SSH,,,,,,,,,,,,,,,myids40,,,,CiscoIDS4x,SSL,,,,,,,,,,,,,,,myids50,,,,CiscoIPS5x,SSL,,,,,,,,,,,,,,,myASA70,,,,ASA,SSH,,,,,,,,,,,,,,,myWindowsNT,,,,WindowsNT,RPC,,,,,,,,,,,,,,,myFWSM23,,,,FWSM,SSH,,,,,,,,,,,,,,,With the CSV file, you can enter the values, passwords, and information for each device that you want the MARS Appliance to monitor in its appropriate row and column. While the seed file is useful for getting the MARS Appliance started processing event data for most devices, you may need to use the Admin > System Setup > Security and Monitoring Devices page to fine-tune the device manually. In addition, you must Activate the devices that you add using a seed file (see Activate the Reporting and Mitigation Devices).
Limitations and Restrictions
The following limitations and restrictions apply to importing devices using a seed file:
•
•
•
•
Devices that Require Custom Seed Files
Some reporting devices represent the management consoles for the actual host- or node-based reporting devices. These consoles often represent centralized log servers for the devices they manage. However, for MARS to correctly correlate the logs for these centralized log servers, you must identify those host- or node-based reporting device. In some cases, MARS is able to dynamically learn of the hosts or nodes by parsing the logs. In other cases, you must use a seed file generated by management console to identify each of the managed reporting devices.
Once you generate the seed file, you must import that seed file under the host that represents the management console in the MARS web interface to load the sensor module information from the CSV or seed file. The device types that use a custom seed file are as follows:
•
•
•
•
Devices that Require Updates After the Seed File Import
When you add specific reporting devices using a seed file, you must edit them to complete the definition of the device before you can monitor them. Typically, these devices are IDS/IPS devices that monitor specific networks. The device types that you must update are as follows:
•
•
•
•
Seed File Header Columns
Table 1-5 describes the columns in the seed files and identifies valid values. If you do not enter a value for a given column, you must enter a comma to delineate that column.
Note
Table 1-5 Seed File Column Description
NAME OR IP
The device's name or IP address. (Mandatory) If the device name is provided and Column U is empty, MARS performs a DNS lookup to identify the address which will be used to populate the Access and Reporting IP fields
Note
SNMP RO/RW Community
The device's SNMP RO community name here.
Note
EMPTY
Empty placeholder column.
EMPTY
Empty placeholder column.
DEVICE TYPE
The device type designator. (case insensitive)
Note
Use the following strings represent the desired device type:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Note
ACCESS TYPE
The Access Type for this device. Your choices are:
•
•
•
•
•
•
In the RPC case, the username field (Column G) should be non-empty. The password can be provided in Column H. If RPC access type and username are given, the PULL flag is set by the backend in addition to the default RECEIVE flag.
USER NAME
The TELNET, SSH, SSL, FTP, or RPC user name. This column is only valid if you have used TELNET, SSH, SSL, or FTP in Column F.
SSH/FTP/RPC PASSWORD
The SSH, SSL, or FTP Password for the device. This column is only valid if you have used SSH, SSL, or FTP in Column F.
TELNET PASSWORD
The Telnet password for the device.
ENABLE PASSWORD
The enable password (applicable only with FWSM, PIX, or IOS devices).
EMPTY
Empty placeholder column.
EMPTY
Empty placeholder column.
EMPTY
Empty placeholder column.
EMPTY
Empty placeholder column.
EMPTY
Empty placeholder column.
EMPTY
Empty placeholder column.
EMPTY
Empty placeholder column.
EMPTY
Empty placeholder column.
EMPTY
Empty placeholder column.
FTP LOCATION [if Access Type =FTP]
The location for the FTP file. This location starts from the FTP root, not the sysroot. If, for example, the file is at <ftproot>/configdata/router1.txt , using ./configdata/router1.txt is correct.
Access/Reporting IP [optional]
The Access IP and Reporting IP address to use when populating this device. The MARS Appliance uses this address to communicate with the device. See Understanding Access IP, Reporting IP, and Interface Settings
Load Devices From the Seed File
Once you have completed the seed file, you must place the CSV file on to the FTP server from which the MARS Appliance will load it.
To load the file into the MARS, follow these steps:
Step 1
Step 2
The FTP path starts from the FTP root, not from the sysroot for the configuration path.
Step 3
Once you have loaded devices from the seed file, return to each device. Continue to configure the devices and to add information such as reporting IP addresses, and SNMP information.
Step 4
Note
Bulk Update of Device Credentials using Seed Files
Using a seed file, you can also update the credentials of some monitoring and reporting devices previously defined in MARS. If we re-import the devices based on the credentials ID, MARS will update that device. The configuration and discovery of the various devices requires different fields. Table 1-6 identifies which devices and credentials and fields that can be updated.
Discovering and Testing Connectivity Options
When you add a device, you should check its connectivity or perform the discovery. Checking a device's connectivity or discovery analyzes the device's configuration, checks that MARS can process its events, and that MARS can understand its NAT information.
You can test these devices for connectivity or perform discovery:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Verifying Connectivity with the Reporting and Mitigation Devices
After loading the seed file or manually adding devices, you can verify that the devices were loaded by clicking Admin> System Setup > Security and Monitor Devices. You should see the devices that you have added populating this page.
You can test the devices by checking the box next to the name of the device and clicking Edit. On the device's page, click Discover or Test Connectivity. The UI displays a "holding pattern" screen while it connects to the device. When complete, it shows you the device's discovery screen.
Note
