All Apps and Add-ons

The proper way to get Cisco AnyConnect NVM data into Splunk (documentation unclear/unconventional)?

woodcock
Esteemed Legend

I have been working from the documentation here:
https://www.cisco.com/c/en/us/support/docs/security/anyconnect-secure-mobility-client/200600-Install...
And, to a lesser degree, this blog:
https://www.splunk.com/blog/2018/09/27/a-cisco-splunk-security-integration-everyone-should-be-using....

My understanding is that the way that it works, is that the acnvm service needs to listen for incoming UDP NVM data netflow feed on port 2055 (default/arbitrary). As data comes in, acnvm processes and separates the data and sends it back out on UDP ports 20519 (for flowdata) and 20520 (for sysdata). This part is clear and fine.

We all know that it is a poor practice to use Splunk (even IHF) to directly receive network inputs, even though it is capable of doing so. Therefore, I have planned to setup acnvm on my syslog server and use syslog to receive the 20519/20520 feeds. This is where things get strange. The Cisco apps both contain an inputs.conf file with this:

[udp://20519]
connection_host = ip
source = cisconvmflowdata
sourcetype = syslog

[udp://20520]
connection_host = ip
source = cisconvmsysdata
sourcetype = syslog

[udp://20521]
connection_host = ip
source = cisconvmifdata
sourcetype = syslog

Even worse, the TA-Cisco-NVM/default/eventtypes.conf file contains this:

[cisco_nvm_data]
search = source=cisconvmflowdata sourcetype=syslog
#tags = network,communicate

And the TA-Cisco-NVM/default/props.conf file contains this:

[source::cisconvmflowdata]
FIELDALIAS-dp-for-nvm = dp as dest_port
...

These make clear that the authors of the app expect that the source and sourcetype values to remain unchanged with these very unsatisfactory and unconventional values.

Short of a VERY good explanation of why I should not, I am planning to make the following changes:
Deploy the apps with this local/inputs.conf:

[udp://20519]
disabled = true

[udp://20520]
disabled = true

[udp://20521]
disabled = true

Instead, I am going to configure syslog-ng to receive this information. Obviously this means that the source value will change. In addition, I plan on using these sourcetypes: { cisco:nvm:flowdata, cisco:nvm:sysdata, cisco:nvm:ifdata }

This also means that I must make analogous accommodating changes to props.conf, eventtypes.conf, and *.xml dashboard files. Hopefully the authors of this app will consider doing the same. What do you say, readers? Also, @nvzFlow, why was it not done/documented this way in the first place?

0 Karma

nvzFlow
Path Finder

This will be addressed shortly in version 2.0 which has a number of new and exciting enhancements.

woodcock
Esteemed Legend

Be sure to post a followup announcement here when it drops!

0 Karma

nvzFlow
Path Finder

Let us know what you think of the new 2.x version

woodcock
Esteemed Legend

I will followup here. Thank you for considering my suggestions.

0 Karma

Besmir
Loves-to-Learn

Dear Colleagues,

Any improvement in this case ! I see the same situation with Cisco NVM Addons Version 2.0.187 .

Thank you .

0 Karma

nvzFlow
Path Finder

Hi, versions 2 and later have the mappings in the TA (https://splunkbase.splunk.com/app/4221/) as described in this thread. Is there some other issue you are seeing?

0 Karma
Get Updates on the Splunk Community!

Routing Data to Different Splunk Indexes in the OpenTelemetry Collector

This blog post is part of an ongoing series on OpenTelemetry. The OpenTelemetry project is the second largest ...

Getting Started with AIOps: Event Correlation Basics and Alert Storm Detection in ...

Getting Started with AIOps:Event Correlation Basics and Alert Storm Detection in Splunk IT Service ...

Register to Attend BSides SPL 2022 - It's all Happening October 18!

Join like-minded individuals for technical sessions on everything Splunk!  This is a community-led and run ...