Security Compliance

Cisco connector best practices in SEM

Some environments use several versions of Cisco devices and Cisco has several operating systems (CatOS, NXOS, and IOS). As a result there are connectors to read from each of these in turn. However, despite their differences Cisco devices send very similar log data which can cause several issues with the SEM.

First published date

10/30/2018 4:16 PM

Last published date

8/3/2022 6:49 AM

Overview

Some environments use several versions of Cisco devices. Cisco has several operating systems (CatOS, NXOS, and IOS).  As a result, there are connectors to read from each of these in turn.  However, despite their differences, Cisco devices send very similar log data which can cause several issues with Security Event Manager (formerly Log & Event Manager).

Product section

Security Event Manager

Cause

N/A

Resolution

Below you will find several issues that Cisco devices can cause when different operating systems are sent to the same Local Facility on the SEM (local0 for instance). The Best Practice for these issues is to have separate Cisco Operating Systems write to their own local facilities. At times it is best to move a noisy device to its own Local Facility as outlined below:

 

Issue One: Unmatched Data

Due to these being Cisco devices the data is very similar when it is logged and sent to the SEM.  It is, however, different and unique per operating system.  As a result there are three primary connectors:
 

  • Cisco PIX and IOS - This covers most modern devices, including ASA firewalls.
  • Cisco CatOS - For the older Catalyst devices.
  • Cisco Nexus NX-OS - Collects events from Cisco Nexus Switches (running NX-OS).


These connectors will read from each of the log types for the Operating System it's designed for, but due to similarities in the log data it is common to see Unmatched Data if they are all reading from the same Local Facility. As a result the Best Practice is to have each Operating System type written to a specific log, for example:
 

  • Cisco PIX and IOS write to local0.
  • Cisco CatOS write to local1.
  • Cisco Nexus NX-OS write to local2.
 

The Local Facility number doesn't matter, it could be any of the 0-7 facilities, but they must each write to a separate facility.  That way Unmatched Data can be determined that it is in fact new data due to an update from Cisco's end or new data being injected into the SEM and handled appropriately from there.

 

Issue Two: High Throughput


Firewalls, specifically Cisco ASAs can log a lot of data.  ASA's can log upwards of 10 GB of data in a day.  If device(s) collectively log in excess of 10 GB in a day the syslog Local Facility can become stuck and no longer rotate daily as it is designed to do.  As a result it is best to have a noisy device such as an ASA moved to its own Local Facility to help relieve this issue.  If several GB of data is logged during the day to a Local Facility this can have performance impact on the SEM and cause several issues.  If even moving the ASA to its own syslog facility doesn't resolve the issue do the following"
 

  1. Open backend of the SEM by either going to the Vsphere Console or using Putty with cmc user.
  2. At the cmc prompt type Appliance.
  3. At the prompt type in setlogrotate change it from the default of Daily to Hourly by hitting yes.
  4. This allows the SEM to compress the files hourly so if the ASA is logging 1 GB an hour it compresses it to 100 MB and now will also store only 50 hours of RAW syslog data from the ASA instead of 50 days.
  5. To increase the 50 hour limit use the command limitsyslog and change to max of 100 which would give you 100 hours


A secondary option is to reduce the logging on the Cisco device, such as setting a different Trap level (changing from Debug to Informational for instance) or by eliminating unwanted events from the ASA directly.  Please seek out Cisco documentation for assistance with this process.

 

Note: The Local Facility configuration is handled from the Cisco device itself.  The SEM is unable to move the data and the sending device is entirely in control of the configuration.  Once the facility is moved or changed you will want to update the Connector on the SEM so that it is reading from the new facility.


Disclaimer: Please note, any content posted herein is provided as a suggestion or recommendation to you for your internal use. This is not part of the SolarWinds software or documentation that you purchased from SolarWinds, and the information set forth herein may come from third parties. Your organization should internally review and assess to what extent, if any, such custom scripts or recommendations will be incorporated into your environment.  You elect to use third party content at your own risk, and you will be solely responsible for the incorporation of the same, if any.