Reporting and Mitigation Devices Overview
Available Languages
Table Of Contents
Reporting and Mitigation Devices Overview
Selecting the Devices to Monitor
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
Adding Reporting and Mitigation Devices
Add Reporting and Mitigation Devices Individually
Upgrade the Device Type to a Newer Version
Delete All Displayed Reporting Devices
Add 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
Adding Reporting and Mitigation Devices Using Automatic Topology Discovery
Verify Connectivity with the Reporting and Mitigation Devices
Discover 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
Configuring 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
To edit a scheduled topology discovery
To delete a scheduled topology discovery
To run a topology discovery on demand
Configuring 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
Configure Syslog-ng Server to Forward Events to MARS
Configure Kiwi Syslog Server to Forward Events to MARS
Add Syslog Relay Server to MARS
Add Devices Monitored by Syslog Relay Server
Reporting and Mitigation Devices Overview
Revised: November 30, 2007, OL-14647-02After you complete the initial configuration of Local Controller as described in Install and Setup Guide for Cisco Security Monitoring, Analysis, and Response System, you must determine a monitoring strategy to use for your network. You must also determine a mitigation strategy, if you chose to take advantage of the MARS mitigation features. For guidance on how to determine the monitoring and mitigation strategies, see STM Task Flow Overview, page 1-1.
This chapters assumes that you have made corporate-level policy decisions and that you are executing against the Checklist for Provisioning Phase, page 1-2. This chapter provides the following:
•
Guidance on selecting and configuring reporting devices and mitigation devices
•
•
•
It contains the following sections:
•
•
•
•
Before configuring the MARS Appliance to recognize reporting devices, you should understand the three levels of operation that MARS can achieve.
Levels of Operation
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 2-1 summarizes the levels, their configuration requirements, and the features enabled at that level.
Selecting the 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 necessary 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:
•
•
•
•
•
Last, you must consider an event tuning method for your monitoring strategy. How you tune your MARS affects your overall operational costs proportionally to the number of device of a give 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 a precious commodity, you may chose to tune the event propagation at the reporting device level, preventing the events from going onto the network.
Table 2-2 identifies the device types, describes what information they can provide, and recommends how to configure these devices within your network.
Table 2-2 Device Types and Data Available
Router
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
During investigation and mitigation, the ARP cache tables are reviewed 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 using 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 determine if potential attacks were blocked before reaching their targets.
Audit logs. Associates users with authentication sessions and assists 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. Helps identifies worms by tracing outbreaks back to a specific user and provides network access periods.
Device status information. Identifies whether the device is operational, which allows prediction of possible spread of potential attacks and worms.
•
Network IDS/IPS
Fired signature alerts. Identifies 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.
Determine whether an attack was blocked at a specific device.
Device status information
Host IDSes
Provides 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 inted, 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 effected.
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 who is likely infected. URLs and also filtering...regulatory compliance.
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)
•
•
•
Supporting Cisco Secure ACS Server, page 15-2
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.
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:
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 Selecting 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 Devices and Software Versions for Cisco Security MARS Local Controller 4.3.x and 5.3.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.
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 among four administrative access protocols:
•
Note
•
•
Note
•
Note
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.
The following topics describe 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.
•
•
•
•
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.
If you selected FTP as the access type, follow these steps:
Step 1
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
Bootstrap Summary Table
Table 2-3 summaries the settings that you must configure for reporting devices and mitigation devices. It also provides links to any required agent downloads and to detailed configuration information.
Table 2-3 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 IDS 3.1 Sensors, page 7-1
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 11-5
Pull Method: Configure the Microsoft Windows Host, page 11-6
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 13-7
Apache
—
HTTP (from MARS Agent)
Install and Configure the Web Agent on UNIX or Linux, page 13-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 15-7 (Cisco Secure ACS)
Cisco Secure ACS Appliance
Install and configure remote log agent.
Syslog (from MARS Agent) on secondary host
Supporting Cisco Secure ACS Solution Engine, page 15-2
Install and Configure the PN Log Agent, page 15-7 (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.
Cisco Security Manager
Enable HTTPS access by MARS Appliance
Checklist for Policy Table Lookup from MARS, page 17-13
Bootstrapping Security Manager Server to Communicate with MARS, page 17-15
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 devices from the seed file.
The device support is categorized into three categories:
•
•
Note
•
The complete list of supported devices is presented in the Supported Devices and Software Versions for Cisco Security MARS Local Controller 4.2.x and 5.2.x document. Devices are added to this list on an ongoing basis via software upgrade packages. See Install and Setup Guide for Cisco Security Monitoring, Analysis, and Response System 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 query. (See To Run a Free-form Query, page 21-2.)
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:
•
•
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 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
Edit a Device
Step 1
Step 2
Step 3
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
Add 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).
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 2-4 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 2-4 Seed File Column Description
Column A
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
Column B
SNMP RO/RW Community
The device's SNMP RO community name here.
Note
Column C
EMPTY
Empty placeholder column.
Column D
EMPTY
Empty placeholder column.
Column E
DEVICE TYPE
The device type designator. (case insensative)
Note
Use the following strings represent the desired device type:
•
ASA: for Cisco ASA devices•
CiscoIDS4x: for applaince running Cisco IPS 4.x (not modules)•
CiscoIPS5x: for appliance running Cisco IPS 5.x (not modules)•
FWSM: for Cisco FWSM 2.3•
FWSM3: for Cisco FWSM 3.1•
PIX: for Cisco PIX 6.0, 6.1, 6.2, and 6.3 devices•
PIX7X: for Cisco PIX 7.0 devices•
IOS: for Cisco IOS 12.2 (default)•
SWITCH-CATOS: for Cisco Switch in Hybrid Mode•
SWITCH-IOS: for Cisco Switch in Native Mode•
EXTREME: for Extreme ExtremeWare 6.x•
NETSCREEN: for ScreenOS 4.0 and 5.0•
WINDOWS: for Window host•
Windows2000: for Windows 2000 host•
Windows2003: for Windows 2003 host•
WindowsNT: for Windows NT 4.x host.•
SOLARIS: for Solaris host•
LINUX: for Linux hostNote
Column F
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.
Column G
USER NAME
The TELNET, SSH, FTP, or RPC user name. This column is only valid if you have used TELNET, SSH, or FTP in Column F.
Column H
SSH/FTP/RPC PASSWORD
The SSH or FTP Password for the device. This column is only valid if you have used SSH or FTP in Column F.
Column I
TELNET PASSWORD
The Telnet password for the device.
Column J
ENABLE PASSWORD
The enable password (applicable only with FWSM, PIX, or IOS devices).
Columns K
EMPTY
Emplty placeholder column.
Column L
EMPTY
Emplty placeholder column.
Column M
EMPTY
Emplty placeholder column.
Column N
EMPTY
Emplty placeholder column.
Column O
EMPTY
Emplty placeholder column.
Column P
EMPTY
Emplty placeholder column.
Column Q
EMPTY
Emplty placeholder column.
Column R
EMPTY
Emplty placeholder column.
Column S
EMPTY
Emplty placeholder column.
Column T
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.txtis correct.Column U
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
Adding Reporting and Mitigation Devices Using Automatic Topology Discovery
On the Admin page, under the Topology Discovery Information section, three links exist, allowing you to define the settings required to discover reporting and mitigation devices automatically. These links are:
•
•
•
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 on a per network basis. Networks and SNMP RO community stings 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 reporting and mitigation devices, it adds those devices to the Monitoring and Security Devices list (Admin > Monitoring and Reporting Devices), 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. Once a device is listed under Monitoring and Reporting 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:
•
Note
Verify 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
Discover 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:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
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 a 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 assist in the improving 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 the network topology. Allows for 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 reporting devices and the hosts that are on your network aids in the elimination of false positives, as well as improves the performance of MARS in assessing events.
•
Layer 3 topology discovery aids in attack path analysis, as well as 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, as well as pulling 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.
Layer 2 Discovery and Mitigation
Make sure that all the L2 devices have the SNMP RO community strings specified in the web interface for L2 mitigation, even if the access type is not SNMP. (See False Positive Confirmation, page 20-6 for more information on mitigating an attack.)
The SNMP RO community string is always required on Layer 2 devices for L2 mitigation. L2 devices must be added manually—there is no automatic discovery for these device.
Note
MARS does not discover L2 devices automatically as it does with L3 devices.
Note
You can specify which L3 devices to discover by specifying networks and SNMP RO community values, as defined in Configuring Layer 3 Topology Discovery.
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. Once devices are loaded/added in the web interface, user can use the topology scheduler feature to update the configuration of both L2 and L3.
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, the MARS probes the networks that you have specified for weaknesses. These automatic scans commence 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 record 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 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.
Note
Guidelines for Configuring NetFlow on Your Network
Ideally NetFlow should be 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:
•
•
•
http://www.cisco.com/en/US/tech/tk812/technologies_white_paper0900aecd802a0eb9.shtml
•
•
•
Note
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:
http://www.cisco.com/en/US/docs/ios/netflow/configuration/guide/12_4/nf_12_4_book.html
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 do 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. However, to configure the he 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
Once you have enabled NetFlow on your routers or switches 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
Step 2
Note
ip flow-export destination" command when configuring the router (see Enable Cisco IOS Routers and Switches to Send NetFlow to MARS. Also, verify you have enabled this traffic to flow between the router or switch and the MARS Appliance on any intermediate gateways, such as routers and firewalls.
Step 3
•
•
Step 4
•
•
Step 5
•
Note
•
Step 6
Step 7
Before MARScan start detecting anomalies based on NetFlow data, it must first develop a baseline for network behavior. It takes a full week, including the weekend, for MARS to develop such a baseline. After this period has elapsed, MARS can start generating incidents based on NetFlow's anomaly detection.
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 provide host-level details to MARS:
•
–
–
–
•
•
Configuring Layer 3 Topology Discovery
For the MARS to reach full operability, you must specify its community strings and select the networks that you want 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 for more information.
See Figure 18-20 on page 18-12 for a view of the topologies.
Note
Add a Community String for a Network
To add a community string for a network IP, 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 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. 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.domainformat 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 to devices that require such polling are:
•
•
•
•
Figure 2-1 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
•
Step 6
•
•
•
•
Step 7
To edit a scheduled topology discovery
Step 1
Step 2
Step 3
•
Step 4
•
•
•
•
Step 5
To delete a scheduled topology discovery
Step 1
Step 2
To run a topology discovery on demand
Note
Step 1
Step 2
Configuring Resource Usage Data
While the Monitor Resource Usage box appears on every host and reporting device, only three device types actually provide resource usage data to MARS:
•
•
•
•
•
•
For these six 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 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 2-5 lists the OIDs to enable, on a per device basis, for the supported model and versions.
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:
•
•
•
•
•
•
•
•
•
•
For information on configuring reporting devices and mitigation devices with NAC support, see Enable NAC-specific Messages, page 4-4.
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 a 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 22-23. To learn more about the SNMP MIB format sent by MARS, see MARS MIB Format.
Syslog Relay Support
In 4.3.1/5.3.1, 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:
•
•
•
Tip
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 condition 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 this feature, see the following commands:
Enable the Syslog Relay Feature
To enable the relay forward, follow these steps:
Step 1
Step 2
Result: 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 or 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 514where 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 514where 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 MIB definition is 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>"The MARS private enterprise number is 16686 and <alert_content> is defined as follows:
<<priorityInfo>> <current_time> %MARS-1-101: Rule <ruleid> (<rulename>) fired and caused <color> Incident <incidentId>, starting from <starttime> to <endtime>.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::enterprises.16686.2.0 "<34>Wed Mar 14 12:28:24 2007 %MARS-1-101: Rule 489722 (System Rule: Sudden Traffic Increase To Port) fired and caused red Incident 204368256, starting from Wed Mar 14 12:28:14 2007 to Wed Mar 14 12:28:14 2007" SNMPv2-SMI::enterprises.16686.3.0 "sudden traffic increase to ports: 445 "
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, MARS parses the syslog messages generated by the following devices: 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 (ISS), 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 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.
Configure 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.
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.
Step 5
Step 6
Step 7
Step 8
Result: Generic Syslog Relay ANY appears in the Device Type list.
Step 9
Step 10
Result: The host appears in the Security and Monitoring Information list.
Step 11
Add Devices Monitored by Syslog Relay Server
While 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, then 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.
Feedback