Table Of Contents
Reports and Mitigation Devices Overview
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
Operating Upon Reporting and Mitigating Devices
Upgrade the Device Type to a Newer Version
Delete All Displayed Reporting Devices
Verifying Connectivity with the Reporting and Mitigation Devices
Discovering and Testing Connectivity Options
Activate the Reporting and Mitigation Devices
Layer 2 Discovery and Mitigation
Networks for Dynamic Vulnerability Scanning
Create a Network IP Address for Scanning
Create a Network IP Range for Scanning
Understanding NetFlow Anomaly Detection
Guidelines for Configuring NetFlow on Your Network
Enable Cisco IOS Routers and Switches to Send NetFlow to MARS
Configuring Cisco CatIOS Switch
Enable NetFlow Processing in MARS
Host and Device Identification and Detail Strategies
Discovering Your Network: Layer 3 Topology Discovery
Add a Community String for a Network
Add a Community String for an 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
Configuring Device Resource Usage Data
Enabling the Required SNMP OIDs for Resource Monitoring
Configuring Network Admission Control Features
Integrating MARS with 3rd-Party Applications
Forwarding Alert Data to 3rd -Party Syslog and SNMP Servers
Enable the Syslog Relay Feature
Disable the Syslog Relay Feature
MARS Events, System Rule, and Report Details for the Syslog Relay Feature
Troubleshooting the Syslog Forwarding Feature
Relaying Syslog Messages from 3rd-Party Syslog Servers
Configuring Syslog-ng Server to Forward Events to MARS
Configure Kiwi Syslog Server to Forward Events to MARS
Add Syslog Relay Server to MARS
Adding Devices Monitored by Syslog Relay Server
Reports and Mitigation Devices Overview
After you complete the initial configuration of Local Controller as described in the document Cisco Security MARS Initial Configuration and Upgrade Guide 6X, you must determine a monitoring strategy to use for your network. You must also determine a mitigation strategy, if you choose to take advantage of the MARS mitigation features. For guidance on how to determine the monitoring and mitigation strategies, see Chapter 2, "Security Threat Mitigation (STM) Task Flow Overview".
Note
For information to prepare reporting and mitigation devices to play an effective role in the MARS system, see Configuring Reporting and Mitigation Devices in MARS chapter of Device Configuration Guide for Cisco Security MARS, Release 6.x.
This chapter assumes that you have made corporate-level policy decisions and that you are executing against the Checklist for Provisioning Phase, page 2-3. This chapter provides the following:
•
•
•
•
This chapter contains the following topics:
•
•
•
•
•
•
•
Levels of Operation
Before configuring the MARS Appliance to recognize reporting devices, you should understand the three levels of operation that MARS can achieve.
MARS operates at three discernible levels based on the type of data collected from reporting devices and the features such data enables for the system. These levels focus on the ability to identify attacks from end-to-end, and they are separate from the features enabled by specific types of reporting devices.
•
•
•
Table 3-1 summarizes the levels, their configuration requirements, and the features enabled at that level.
Selecting Devices to Monitor
All monitoring strategies involve selecting the types of devices to monitor and how much data to provide the MARS Appliance. All devices on your network, be they hosts, gateways, security devices, or servers, provide some level of data that MARS can use to improve the accuracy of security incident identification. However, careful consideration of what data to provide can improve the attack identification response time by ensuring that MARS does not perform unnecessary or redundant event correlation and analysis. Unnecessary logging and reporting by reporting devices can also reduce the effectiveness of your network.
We recommend analyzing each network segment to identify the most data rich combination that you can achieve, while identifying and refining your configurations to reduce redundant data.
When determining a monitoring strategy, you must also determine the goals behind the monitoring. Is it just for attack detection? Attack detection and mitigation? Regulatory compliance? Your goals affect which devices you must monitor and what features you must configure on those devices.
Consider distinct goals:
•
•
•
•
•
Finally, you must consider an event tuning method for your monitoring strategy. How you tune your MARS affects your overall operational costs in proportion to the number of devices of a given type that are monitored. Essentially, if you have the bandwidth available, we recommend that you tune the events at the MARS Appliance, which reduces your operational costs by tuning at a single point in the network. However, if bandwidth is limited, you may choose to tune the event propagation at the reporting device level, preventing the events from going onto the network.
Table 3-2 identifies the device types, describes what information they provide, and recommends how to configure these devices within your network.
Table 3-2 Device Types and Data Available
Router
For routers and switches, administrative access is not required; MARS can obtained the information using an SNMP read-only community string. If SNMP read-only access is enabled and you want to perform mitigation, you are prompted to provide a SNMP read-write administrative password as a one-time password.
The device discovery protocol is the one used for administrative access/mitigation. For example, if SSH is used to discover the device, then SSH is the protocol that used to pushed the mitigation command.
The following data is pulled from routers:
•
•
•
•
•
•
•
•
•
Enable the following:
•
•
•
Switch
ARP cache tables are reviewed during investigation and mitigation to resolve the MAC addresses involved in the incident. This data is cached for 6 hours.
SNMP RO Community strings
Forwarding tables, used to map IP address to MAC address
Device status and resource utilization, such as memory, CPU, and interface/port statistics
NetFlow data
802.1x logs generated during NAC sessions
Enable the following:
•
•
•
•
•
Firewall
Interface configurations. Used to populate topology view and determine expected routes, which helps refine correlation of traffic traversing the firewall.
NAT and PAT mappings. Used to identify the point of origin attackers and targets and trace attacks as they spread.
Firewall policies. When discovering ASA, PIX, and FWSM, MARS parses ACLs and conduits (PIX only). For Check Point firewalls, it collects the firewall policy from policy table. MARS uses this information only for path computation and mitigation recommendations. It is not used by any other components, such as rules, reports, and sessionization.
Firewall logs. Accepted and denied sessions logs are used to identify false positives and to determine whether potential attacks were blocked before reaching their targets.
Audit logs. Associate users with authentication sessions and assist in identifying exploited accounts and administrative sessions.
ARP cache tables. Used to map IP address to MAC address.
Device status and resource utilization information. Used to identify anomalous network activities based on memory, CPU, and interface and port statistics.
Enable the following:
•
•
•
VPN
Remote user information. Provides username to IP address mapping. VPN client helps determine the person who logged in and performed specific actions. Clarifies the true point of origin by identifying the host, not the VPN concentrator.
Login/logout records. Help identify worms by tracing outbreaks back to a specific user, and provide network access periods.
Device status information. Identifies whether the device is operational, which allows prediction of possible spread of potential attacks and worms.
Enable the following:
•
Network IDS/IPS
Fired signature alerts. Identify attacks and threats, which helps determine mitigation response; identify potential false positive information and target vulnerability assessment probes conducted by MARS.
Trigger packet information. Provides the payload of the packet that caused the signature to fire. Determines whether an attack was blocked at a specific device. Provides device status information.
Enable the following:
•
•
Host IDSes
Provide host-level validation of exploits and blocked attacks, which improves the accuracy of false positive identification, which in turn improves the ability of the administrator to accurately prioritize the work required to contain attacks.
Anti-Virus
Central anti-virus management servers provide information on which hosts are infected, which hosts have reported attempted infections, etc. The servers also provide the dat or signature file information for managed hosts, which improves the ability to determine whether an attack was likely to have succeeded.
Vulnerability Assessment
Host OS and Patch Level. When a signature fires on an IDS and it is reported to MARS, MARS can either launch a targeted scan using Nessus, or query a vulnerability assessment system that helps determine whether the target was vulnerable.
Enable any vulnerability assessment solutions supported by MARS.
Host OSes
Microsoft Windows Hosts
Events found in the security event log as well application event and system event log.
Install and configure SNARE, which pushes events to MARS in near real time, and scales more efficiently than pulling events from hosts.
Solaris and Linux Hosts
Incoming network session logs, via inetd; and FTP transfer logs, via xferlog. In addition, any events that are written to the system log by applications and services running on host.
•
•
•
Generic Hosts (All OSes)
Includes system-level information, such as privilege escalation and buffer overflow. Helps determine what attacks make it to the host layer. If MARS learns of activity at the host level, then it understands that the attack or exploit has successfully traversed the network. MARS correlates this data with the network level data to discover the whole incident and analyze the exploit method so the administrator can build a better defense. In some cases, MARS recommends actions for mitigating the attack. We recommend that you maintain these recommended blocks as long as similar attacks are expected. Typical blocking techniques, such as IPS shunning, often fail to identify the best chokepoint for containment. As part of the recommended action, MARS does identify the optimal chokepoint where the recommended action should be taken.
Web Server
Same as hosts (SNARE and Perl script agents), need this when the hosts cannot send us the logs via syslog. Agent is basically a transport.
Web Proxy
Mapping from user to site, translations for the IP address mapping, tells us the real address of the host that is likely infected.
Database
Login/logout to determine the actual user (query report tab on the data). Privilege escalation, brute force crack type stuff, or maybe we want to do regulatory compliance.
AAA Server
Login/logout and NAC functionality (deny a person due to privileges, it triggers NAC message)
•
•
•
System Events related to Authentication and Login Attempts, page 14-4
Generic Syslog
Same as host, provides support for additional customer devices.
Generic SNMP
Same as host, provides support for additional customer devices.
Cisco Security Manager
Mapping to any committed policy rules defined in Security Manager that match any ACL rules that could cause the generation of a specific syslog event by a reporting device. This policy lookup feature allows you to debug network issues and understand the cause/effect relationships between event messages and the device policies and traffic that resulted in the generation of the event.
Enable HTTPS on the Security Manager server.
Define an administrative level account on the Security Manager server that CS-MARS can use for policy lookups.
For more information see Security Manager Policy Table Lookup from a MARS Event, page 11-1.
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 either to connect to the device for network-based administrative sessions, or to 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. After MARS has administrative access, it can perform device discovery, which includes settings such as ARP tables, NAT, routes, and active ACLs, all of which help 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 Selecting the Access Type, page 3-10.
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 require 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, whereas 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 the role of the access IP address and reporting IP address. Interface settings represent static information, not discovered or learned information, 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.
Selecting 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 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
Note
Step 2
Step 3
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
Operating Upon Reporting and Mitigating Devices
This section details operations you can perform on reporting and mitigating devices that have been added to the system.
Note
This section contains the following topics:
•
•
•
•
Edit a Device
Step 1
•
•
Step 2
Step 3
Step 4
Upgrade the Device Type to a Newer Version
You can change the Device Type version setting of a hardware-based security device. You cannot upgrade the version for software applications running on a host. To upgrade the software appliance version, you must remove the application from the host and add the newer one.
This version change feature applies only to device types with the same vendor and model but different versions. Specifically, you can change the version for the following device types:
•
•
•
•
For example, you could change the settings for the device type Cisco PIX 6.1 to Cisco PIX 7.0 without having to delete the device and add it again. The benefit of matching the version setting to the deployed device is that it allows MARS to correlate any event types introduced in the more recent version. It also allows you to incrementally upgrade your reporting devices without having to worry about when to add that reporting device to MARS. The events that are correlated under one device type will be associated with the newer device type version when you make the change in MARS.
To change the version of a device, follow these steps:
Step 1
Step 2
The Change the Device Type Version page appears, displaying the device name, vendor, model, and old version type information.
Step 3
Step 4
If any additional changes are available due to the version change, the Edit page appears.
Step 5
Step 6
Delete a Device
When you define a reporting device in MARS, this device is added in two separate pages of the web interface. It appears where you have defined it, on the Admin > Security and Monitoring Devices page, as well as under the general device identification page under Management > IP Management. This duplication of content is based on the different functions that each of these pages serves.
The Security and Monitoring Devices page configures the contact and device type information, whereas the IP Management page is used by the parser module to correlate known devices versus unknown devices. Typically when you delete a device from the Security and Monitoring Device page, you still want to retain the knowledge of that device in MARS so that historical incidents and events and cases can resolve to a known device; therefore, the device is not deleted from the IP Management page.
Note
However, if you need to delete and re-add a device to MARS, you must delete the device from both pages before you attempt to re-add the device.
In addition, as devices are discovered on your network, they are added to the list of devices in the IP Management page. If you want to add a reporting device and find that you cannot, review the list of devices in the IP Management page to ensure that the device has not been auto-populated. If it has, you must first delete that device, then you can add it as a reporting device on the Security and Monitoring Devices page.
To delete a device, follow these steps:
Step 1
•
•
Step 2
Step 3
Step 4
The device is deleted from the selected page.
Delete All Displayed Reporting Devices
You can perform this procedure from the Admin > Security and Monitoring Devices page.
To delete all devices displayed on a page, follow these steps:
Step 1
All displayed devices are selected.
Step 2
A page appears prompting you to confirm that you want to delete the list of devices.
Step 3
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.
Note
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
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 the following devices for connectivity or perform discovery:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Run a Reporting Device Query
Another method to see the added devices, is to run a query with the display format: Reporting Device Ranking.
Note
To run a reporting device ranking query, follow these steps:
Step 1
Step 2
Step 3
Step 4
Step 5
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
Data Enabling Features
Adding the reporting devices and mitigation devices is the primary method of providing MARS with the data required to study the activities on your network. However, other features, both within the web interface and as part of configuring the devices, can provide MARS with additional data, which is used to refine the views it provides and to improve the overall effectiveness of the system. We think of these features as data enabling features.
This section contains the following topics:
•
Enable SNMP community strings to support the discovery of the network topology. This enables mapping to the port level for switches. Combined with 802.1x support required by NAC, this setting can resolve MAC address level settings for attached and wireless nodes on the network.
•
Enables a Nessus-based scan of the targeted hosts. Nessus also uses nmap for OS fingerprinting and port scanning during a vulnerability assessment scan. These scans are conducted in response to suspicious activity to determine whether the attempted attack is successful or likely to succeed based on information such as target operating system type, patch level, and open ports on the host.
•
By enabling NetFlow, MARS can detect anomalies in traffic and network usage by comparing new events with summary data. When anomalies are detected, MARS begins to store full NetFlow data. By default, full NetFlow data is not stored by MARS unless an incident is identified.
•
Details about the reporting devices and the hosts that are on your network aids in the elimination of false positives, and improves the performance of MARS in assessing events.
•
Layer 3 topology discovery aids in attack path analysis and the population of the topology graph in the web interface.
•
Topology update schedules are a critical part of many of the data enabling features, including discovery of Layer 2 and Layer 3 devices and the pulling of information from specific reporting devices.
•
MARS can collect additional data from a select set of reporting devices, which is used to provide reports about CPU utilization, memory utilization, and device saturation. This data can be helpful in detecting anomalies as well in network capacity planning.
•
Describes how to accomplish full NAC awareness, what it provides, and what products are required.
Describes the format of the MARS MIB, which helps integrate with other SNMP-based management applications on your network.
Layer 2 Discovery and Mitigation
Note
Note
MARS does not discover L2 devices automatically as it does with L3 devices.
You can specify which L3 devices to discover by specifying networks and SNMP RO community values, as defined in Discovering Your Network: Layer 3 Topology Discovery, page 3-27.
The reason is MARS does not scan the network for devices. Therefore, you must manually add L2 devices using the web interface or a CSV file. Assuming that device discovery permission has been provided, L3 devices are discovered automatically using the route information provided by monitored gateways. After the devices are loaded/added in the web interface, user can use the topology scheduler feature to update the configuration of both L2 and L3 devices.
For L2 devices, SNMP access type is sufficient with RO community. But for mitigation, MARS requires SNMP RW community access. If SNMP RW community is not possible, select TELNET/SSH access type with SNMP RO Community.
Networks for Dynamic Vulnerability Scanning
With dynamic vulnerability scanning, MARS probes for weaknesses the networks that you have specified. These automatic scans begin after a rule has fired that indicates an attack is in progress. Once an attack is underway, these scans accomplish the following:
•
•
•
•
Select a Network for Scanning
To select a network for scanning, follow these steps:
Step 1
Step 2
Step 3
Step 4
Step 5
Create a Network IP Address for Scanning
To create a network address that you can use to define the scan settings, follow these steps:
Step 1
Step 2
Step 3
Create a Network IP Range for Scanning
To create a range of network addresses that you can use to define the scan settings, follow these steps:
Step 1
Step 2
Step 3
Understanding NetFlow Anomaly Detection
NetFlow is a Cisco technology that supports monitoring network traffic and is supported on all basic IOS images. NetFlow uses an UDP-based protocol to periodically report on flows seen by the Cisco IOS device. A flow is a Layer 7 concept that consists of a session set up, data transfer, and session teardown. For every flow, a NetFlow-enabled device records several flow parameters, including:
•
•
•
•
Periodically, a collection of flows and its associated parameters are packaged in an UDP packet according to the NetFlow protocol and sent to any identified collection points. Because data about multiple flows is recorded in a single UDP packet, NetFlow is an efficient method of monitoring high volumes of traffic compared to traditional methods, including SYSLOG and SNMP.
The data provided by NetFlow packets is similar to that provided by SYSLOG, SNMP, or Checkpoint LEA as reported by enterprise-level firewalls, such as Cisco PIX, NetScreen ScreenOS, and Checkpoint Firewall-1. The difference being that NetFlow is much more efficient. To receive comparable syslog data from a firewall device, the syslog logging level on the firewall must be set to DEBUG, which degrades firewall throughput at moderate to high traffic loads.
If NetFlow-enabled reporting devices are positioned correctly within your network, you can use NetFlow to improve the performance of the MARS Appliance and your network devices, without sacrificing MARS's ability to detect attacks and anomalies. In fact, NetFlow data and firewall traffic logs are treated uniformly as they both represent traffic in the network.
This section contains the following topics:
•
•
•
•
•
How MARS Uses NetFlow Data
When MARS is configured to work with NetFlow, you can take advantage of NetFlow's anomaly detection using statistical profiling, which can pinpoint day-zero attacks like worm outbreaks. MARS uses NetFlow data to accomplish the following:
•
•
•
After being inserted into a network, MARS studies the network usage for a full week, including the weekend, to determine the usage baseline. Once the baseline is determined, MARS switches to detection mode where it looks for statistically significant behavior, such as the current value exceeds the mean by 2 to 3 times the standard deviation.
By default, MARS does not store the NetFlow records in its database because of the high data volume. However, when anomalous behavior is detected, MARS does store the full NetFlow records for the anomalous entity (host or port). These records ensure that the full context of the security incident, such as the infected source and destination port, is available to the administrator. This approach to data collection provides the intelligence required by an administrator without affecting the performance of the MARS Appliance. Storing all NetFlow records consumes unnecessary CPU and disk resources.
MARS supports NetFlow versions 1, 5, 7 and 9, for MARS-supported routers and switches.
MARS supports a variant of NetFlow version 9, called NSEL (NetFlow Security Event Logging) for the ASA 8.1. NSEL uses NetFlow version 9 templates to customize the scope of the security information captured.
Guidelines for Configuring NetFlow on Your Network
NetFlow is most effective when collected from the core and distribution switches in your network. These switches, together with the NetFlow from Internet-facing routers or SYSLOG from firewalls, typically represent the entire network. With this in mind, review the following guidelines before deploying NetFlow in your network:
•
•
•
•
•
•
The taskflow for configuring NetFlow to work with MARS is as follows:
1.
2.
3.
4.
5.
The following tasks provide guidance on the required device configuration:
•
•
•
Enable Cisco IOS Routers and Switches to Send NetFlow to MARS
For more information on NetFlow and configuring the settings in Cisco IOS, refer to:
Before you configure NetFlow from MARS, you must first configure it on the router or switch.
To enable NetFlow on a Cisco IOS router or switch and to push those events to the MARS Appliance, follow these steps:
Step 1
Step 2
Step 3
Step 4
show ip flow export show ip cache flow
Step 5
exit
Configuring Cisco CatIOS Switch
Some Cisco Catalyst switches support a different implementation of NetFlow that is performed on the supervisor. With the cache-based forwarding model, which is implemented in the Catalyst 55xx running the Route Switch Module (RSM) and NetFlow Feature Card (NFFC), the RSM processes the first flow and the remaining packets in the flow are forwarded by the Supervisor. This support is also implemented in the early versions of the 65xx with MSFC. The deterministic forwarding model used in the 65xx with MSFC2 does not use NetFlow to determine the forwarding path, the flow cache is only used for statistics as in the current IOS implementations. In all of these configurations, flow exports arrive from both the RSM/MSFC and the Supervisor engines as distinct streams.
The router-side running IOS is configured as specified in Enable Cisco IOS Routers and Switches to Send NetFlow to MARS, page 3-22. However, to configure the CatIOS NetFlow Data Export, use the following commands:
set mls flow full
set mls nde version 5
set mls nde <MARS_IP_address> 2055
set mls nde enable
From a user's perspective, the switch is only running IOS when the 65xx is running in Native mode.
Enable NetFlow Processing in MARS
After you have enabled NetFlow on your routers, switches, or Cisco ASAs, and you have directed those devices to publish NetFlow data to the MARS Appliance, you must configure the appliance to process that data. This configuration involves determining how to store data, as well as identifying which networks you want to process for anomalous behavior. Both of these options can affect the rate at which MARS can process events: storing the full event data rather than summary data burdens the system with writing large volumes of data rather than processing new incoming events. Also, by not specifying a select set of networks, MARS studies all networks.
Step 1
Figure 3-1 NetFlow Configuration Page (Admin > System Setup > NetFlow Config Info)
Step 2
Note
Step 3
•
•
Step 4
•
•
Step 5
•
–
–
–
–
–
–
•
Selecting No limits the use of Cisco ASA Netflow Security Event Logs to the following:
–
–
–
Step 6
•
•
Note
Note
Step 7
Step 8
Figure 3-2 Networks for Traffic Anomaly Detection Page (Admin > System Setup > Networks for Traffic Anomaly Detection)
Step 9
Tip
Note
Step 10
Step 11
Tip
Step 12
Host and Device Identification and Detail Strategies
MARS studies many events at the network layer, relying on firewalls, routers, and IPS devices to identify anomalies and suspected incidents at a layer above the endpoint hosts that are the source or destination of network sessions. If operating exclusively at this network layer, MARS can generate a number of false positive incidents that must be manually investigated. However, several features exist that allow you to drill down and provide host-level details to MARS:
•
•
•
Discovering Your Network: Layer 3 Topology Discovery
For MARS to reach full operability, you must specify the SNMP community strings and select the networks to discover. Once the appliance discovers these networks, you get 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, page 3-1 for more information.
There are many advantages to discovering your network; for example, the discovery process identifies Cisco routers and gateways, it provides a more complete topology graph on the Dashboard page, and you can refine the discovery parameters to ensure that you do not discover your ISP's network.
Select the Summary > Dashboard page in the MARS web interface for a view of the topologies.
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 read only access to the layer 3 devices is required via an SNMP RO community string.
This process discovers your entire layer 3 network, with two exceptions:
1.
2.
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 CiscoWorks format.
Add a Community String for a Network
To add a community string for a network address, follow these steps:
Step 1
Step 2
Step 3
Step 4
Step 5
Step 6
Add a Community String for an IP Range
To add a community string for an IP range, follow these steps:
Step 1
Step 2
Step 3
Step 4
Step 5
Step 6
You can add multiple community strings for the same network by adding similar entries.
Add Valid Networks to Discovery List
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
The SNMP target is the entry-point where the MARS starts discovering devices on a network. It typically identifies an address on a default gateway of the network.
Step 3
Step 4
Step 5
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, page 3-30. 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
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 or SSH, 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 of the 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 them, 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 includes:
•
•
•
•
Figure 3-3 Example Scheduled Update for eEye REM
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
Note
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
Configuring Device 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 3-3.
Table 3-3 Device Anomaly Resource Monitoring
Cisco IOS 12.2, 12.3, 12.4
Yes
Yes
No
Yes
Cisco Switch IOS 12.2
Yes
Yes
No
Yes
Cisco PIX 6.0, 6.1, 6.3, 7.0, 7.2, 8.0
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
Checkpoint OPSEC NG FP3,NG AI, NGX
No
No
Yes
No
1 For 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 a pre-defined resource utilization inspection rule:
•
•
•
Enabling the Required SNMP OIDs for Resource Monitoring
Table 3-4 on page 3-34 lists the OIDs to enable, on a per device basis, for the supported models and versions.
Table 3-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
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
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
Configuring Network Admission Control Features
Network Admission Control (NAC) is a Cisco Systems sponsored industry initiative that uses the network infrastructure to enforce security policy compliance on all devices seeking to access network computing resources, thereby limiting damage from viruses and worms.
Using NAC, organizations can provide network access to endpoint devices such as PCs, PDAs, and servers that are verified to be fully compliant with established security policy. NAC can also identify noncompliant devices and deny them access, place them in a quarantined area, or give them restricted access to computing resources.
MARS supports the NAC initiative by storing and reporting about the NAC-based events generated by the various reporting devices on your network. The devices include:
•
•
•
•
•
•
To enable NAC reporting on your network, you must ensure that the NAC-specific events are logged by the reporting devices, 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.
The following reports are available to support NAC:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
The following system rules are available to support NAC:
•
•
•
•
•
•
•
•
•
•
Integrating MARS with 3rd-Party Applications
MARS provides multiple integration methods with 3rd -party applications. The following topics describe how to integrate using these methods:
•
•
•
Forwarding Alert Data to 3rd -Party Syslog and SNMP Servers
You can forward alert data from MARS to third-party syslog and SNMP servers. The data is forwarded on a per rule basis. In other words, you must configure those rules for which you want to forward alert data to include either SNMP, syslog, or both as notification methods. When a rule fires, the notifications will be sent in the selected formats to the specified recipients, which should be the desired servers in the case of SNMP and syslog.
For more information on configuring notification methods for a rule, see Setting Alerts, page 4-21. To learn more about the SNMP MIB format sent by MARS, see MARS MIB Format, page 3-42.
Syslog Relay Support
MARS can act as a relay for the syslog messages received from reporting devices to a single collector.
•
•
•
Note
The Local Controller can now act as a relay; it processes the incoming syslog messages locally before it forwards them to the designated collector. The destination port number is 514 for incoming and relayed syslog messages. MARS adheres to RFC 3164: The BSD Syslog Protocol while relaying the syslog messages with the following exceptions:
•
•
•
Note
The Local Controller generates internal events for the dropped packets, and it does not relay internal system and operating system event logs. Dropped packets result when one of the following conditions exist:
•
•
•
You configure the syslog relay feature using the MARS CLI interface; no web interface exists to configure these settings. The configuration process is summarized as follows:
1.
2.
3.
4.
Note
To configure and use this feature, see the following topics:
•
•
•
•
For more information on using the syslog relay feature, see the following commands in the Cisco Security MARS Command Reference, 6.X:
•
•
•
Enable the Syslog Relay Feature
To enable the relay forward, follow these steps:
Step 1
Step 2
The the [pnadmin]$ prompt returns. To verify the address, enter syslogrelay list collector.
Step 3
•
•
If you use ANY, then you may define an exclude list using syslogrelay src exclude ip_address, where ip_address is one or more IP addresses that represent the reporting devices for which syslog messages should not be forwarded.
Step 4
Disable the Syslog Relay Feature
You can disable the syslog relay feature using either of two approaches:
•
•
To disable the relay forward feature, follow these steps:
Step 1
Step 2
•
This the list of syslog relay sources so that messages are forwarded.
•
Step 3
MARS Events, System Rule, and Report Details for the Syslog Relay Feature
Two internal events are defined in the Info/HighUsage/CS-MARS event group in support of this feature:
•
•
The System Rule: Resource Issue: CS-MARS rule includes the MARS-2-100026 event. The Resource Issues: CS-MARS - All Events system report, which includes the Info/HighUsage/CS-MARS event group, summarizes data for the new event types.
Troubleshooting the Syslog Forwarding Feature
The following techniques can assist you in troubleshooting the syslog forwarding feature:
•
•
[pnadmin]$ pnstatusModule State Uptime...pnesloader RUNNING 3-16:18:29pnmac RUNNING 3-16:18:29pnparser RUNNING 3-16:18:23process_event_srv RUNNING 3-16:18:28process_inlinerep_srv RUNNING 3-16:18:28process_postfire_srv RUNNING 3-16:18:28process_query_srv RUNNING 3-16:18:29superV RUNNING 3-16:18:30•
•
[pnadmin]$ tcpdump src host 192.168.3.2 and dst host 192.168.3.4 and udp dst port 514
where 192.168.3.4 is the IP address of the Local Controller and 192.168.3.2 is configured as a syslog source.
•
tcpdump src host 192.168.3.4 and dst host 192.168.1.1 and udp dst port 514
where 192.168.3.4 is the Local Controller and 192.168.1.1 is configured as the syslog collector.
MARS MIB Format
The MARS management information base (MIB) is defined for all MARS releases. The SNMP notification contains the same content as the syslog generated by MARS. The MARS private enterprise number is 16686. All "Top 3" categories display x of y occurrences. where x can be 1 to 3, and y can be 1 to n. The "Count" is the always the count of the firing events that match the rule criteria. The Rule ID number is for internal use only, it has no correspondence to any rule attribute viewable from the MARS GUI or CLI.
The MARS MIB definitions are as follows:
enterprises.16686.1.0 string "MARS-1-101"enterprises.16686.2.0 string "<alert_content>"enterprises.16686.3.0 string "<optional_port_list_for_sudden_traffic_increase_incident>"enterprises.16686.4.0 string "<Top 3 src-dest address pairs>"enterprises.16686.5.0 string "<Top 3 dest TCP/UDP ports>"enterprises.16686.6.0 string "<Top 3 event types>"enterprises.16686.7.0 string "<Top 3 reporting devices>"alert_content: <<priorityInfo>> current_time %MARS-1-101: Rule ruleid (<rulename>) fired and caused color Incident incidentId , starting from start_time to end_time
Optional_port_list_for_sudden_traffic_increase_incident
Top 3 src-dest address pairs:
Top 3 src-dest address pairs sorted by severity and count showing x of y, src_IP -> dest_IP Severity: color Count: countTop 3 dest TCP/UDP ports:
Top 3 TCP/UDP Ports sorted by severity and count showing x of y, dest_port Severity: color Count: countTop 3 event types:
Top 3 event types sorted by severity and count showing x of y, Severity: severity Count: countTop 3 reporting devices:
Top 3 reporting devices sorted by count showing x of y, reporting_device_name Count: count.In the following two examples of the SNMP notification output, 10.1.1.1 is the IP address of the MARS Appliance:
SNMPv2-SMI::enterprises.16686 10.1.1.1 SNMPv2-SMI::enterprises.16686.1.0 "MARS-1-101" SNMPv2-SMI::enterprises.16686.2.0 "<34>Mon Apr 28 20:11:43 2003 %MARS-1-101: Rule 45513 (Nimda Attack) fired and caused red Incident 12265001, starting from Mon Apr 28 19:58:47 2003 to Mon Apr 28 20:11:21 2003"SNMPv2-SMI::enterprises.16686 10.1.1.1 SNMPv2-SMI::enterprises.16686.1.0 "MARS-1-101" SNMPv2-SMI::en¨terprises.16686.2.0 "<34>Wed Feb 4 14:44:09 2009 %MARS-1-101: Rule 306498 (any) fired and caused green¨ Incident 287020054, starting from Wed Feb 4 14:43:15 2009 to Wed Feb 4 14:43:19 2009 on gVaAdGOCE¨W" SNMPv2-SMI::enterprises.16686.4.0 "Top 3 src-dest address pairs sorted by severity and count showin¨g 3 of 6, N/A -> N/A Severity: green Count: 4, 10.4.11.10 -> 10.1.1.16 Severity: green Count: 1, 10.¨4.11.10 -> 10.1.1.17 Severity: green Count: 1" SNMPv2-SMI::enterprises.16686.5.0 "Top 3 dest TCP/UDP ¨Ports sorted by severity and count showing 3 of 4, 21 Severity: green Count: 1, 22 Severity: green C¨ount: 1, 23 Severity: green Count: 1" SNMPv2-SMI::enterprises.16686.6.0 "Top 3 event types sorted by s¨everity and count showing 3 of 3, Built/teardown/permitted IP connection Severity: green Count: 4, U¨nknown Device Event Type Severity: green Count: 4, CS-MARS Miscellaneous authentication message Seve¨rity: green Count: 1" SNMPv2-SMI::enterprises.16686.7.0 "Top 3 reporting devices sorted by count showi¨ng 3 of 6, gq_2 Count: 4, d1_1 Count: 1, d1_3 Count: 1"
Note
Relaying Syslog Messages from 3rd-Party Syslog Servers
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 are no longer required 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 daily network operations proceed without interruption. 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, you can configure those servers to forward messages to the MARS Appliance and identify the syslog servers in MARS. Currently, the devices for which MARS parses the generated syslog messages include following: Cisco PIX, Cisco IOS, Cisco CatOS, Cisco ICS, Cisco ASA, Cisco FWSM, Cisco VPN 3000, Cisco Secure ACS, Snort IDS, Juniper/Netscreen firewalls, Solaris, Linux, and Microsoft Internet Information Server (IIS), Microsoft Windows running the SNARE agent. 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 user interface. You are still required to define the reporting device by IP address and device type in MARS to ensure proper event correlation; however, you are not required to configure the device to publish syslog messages directly to MARS.
To configure MARS to work with a syslog relay server, perform the following tasks:
1.
2.
3.
4.
Configuring Syslog-ng Server to Forward Events to MARS
We recommend the following settings in the configuration options of the syslog-ng.conf file to ensure good integration of syslog-ng with MARS:
options { long_hostnames(off); use_dns(0); keep_hostname(yes); };
where
•
•
•
In addition to configuring the message format, you must specify that the MARS Appliance is a destination loghost on UDP port 514. The following lines must appear in the syslog-ng.conf file:
destination loghost { udp("IP address of MARS Appliance" port(514)); };log { source(src); destination(loghost); };log { source(net); destination(loghost); };Configure Kiwi Syslog Server to Forward Events to MARS
We recommend the following settings in the configuration options of the Kiwi Syslog Daemon to ensure good integration of Kiwi with MARS:
Step 1
Step 2
Step 3
Step 4
•
•
•
•
•
•
This additional header is necessary for the supported device types that do not have HOSTNAME in the syslog messages; thereby allowing MARS to correctly identify the original sending device. However, this option cannot be used on a Kiwi relay of relay. To support a Kiwi relay of relay in MARS, the first relay must have this option selected and must receive syslog messages only from the source devices, and all other relays must have this option cleared and must only receive syslog messages from other Kiwi relays, not directly from devices.
•
Step 5
If this value is selected, tabs appear as <009> in the Windows event logs, which prevents MARS from parsing the events correctly.
Step 6
Add Syslog Relay Server to MARS
In addition to representing each of the potential reporting devices, you must define the syslog relay server so that MARS knows for which messages it should attempt to discover the true reporting device. To add a syslog relay server, you must add it as a security software application running on a host.
To add a syslog relay server, follow these steps:
Step 1
Step 2
•
•
Step 3
•
•
This address represents the physical IP address of the syslog relay server. To learn more about the reporting IP address, its role, and dependencies, see Understanding Access IP, Reporting IP, and Interface Settings, page 3-8.
Step 4
This address represents the physical IP address of the syslog relay server. To learn more about the interface settings, its role, and dependencies, see Understanding Access IP, Reporting IP, and Interface Settings, page 3-8.
Step 5
Step 6
Step 7
Step 8
Generic Syslog Relay ANY appears in the Device Type list.
Step 9
Step 10
The host appears in the Security and Monitoring Information list.
Step 11
Adding Devices Monitored by Syslog Relay Server
Although you do not have to configure each reporting device to forward syslog messages to the MARS Appliance, you must define the device to MARS so that, when it parses the syslog messages forwarded by the relay server, it is able to match the true reporting IP address to that of a known reporting device type. By knowing the reporting device type, MARS can correctly parse the events.
The process for adding these reporting devices is the same as if there were no syslog relay server except that you do not configure the reporting device to forward events to the MARS Appliance. In the MARS web interface, you should still configure the reporting devices so that MARS can discover their settings and to perform any mitigation operations.
