Cisco Firewalls Log extraction not working

[dominik13]

Hi,
For the Cisco Firewalls App, do I absolutely need to have Cisco ASA traffic coming in on a different port than other syslog traffic (UDP 514)? Right now in my search results its showing that sourcetype=syslog and source=udp:514. In the regular search as well as the Cisco Firewall Search, it doesnt look like splunk is doing proper field extraction. Source/destination IPs and ports are empty. I've been spinning my wheels on this for a long time and would really appreciate it if someone could point me in the right direction.

Thanks!
Dom

[marcosciarrone]

Solved! By mistake in the ASA I flagged "Log message in EMBLEM format".
That's was the issue.

Thank you,
Marco

[marcosciarrone]

Thank you for you precious information but I still having some issue with the Cisco Firewall addon. I have the sourcetype correctly configured as cisco_asa and if I search the data I can see it. The data is correctly displayed into the Cisco Security Suite but I still cannot see data in the Realtime Firewall Dashboard.

Any idea?

Thank you very much,
Marco

[sowings]

The trick with any application and field extraction is that you have to match the sourcetype (set when the data reaches the indexer, and pretty much immutable after that) to whatever they're expecting. Splunk uses the sourcetype of data as one of the primary means of identifying what rules and regexes to use for field extraction. IIRC, this application wants the sourcetype (to find fields such as src / dest IPs) to be cisco_asa.

At present, it sounds like you're logging directly from the device to a syslog stream over UDP to the Splunk indexer or forwarder. What you'll want to do is ensure that you remap the sourcetypes before it goes to the indexer. This is done with a combination of props.conf and transforms.conf. The Splunk for Cisco Firewalls app will attempt to remap any(!) data coming in to the cisco_asa sourcetype with this bit of config:

[force_sourcetype_for_cisco_asa]
DEST_KEY = MetaData:Sourcetype
REGEX = %ASA-\d+-\d+
FORMAT = sourcetype::cisco_asa

If your log events don't have a string like "%ASA-0-1" or similar in them, this transform won't be applied to change the sourcetype of the data to cisco_asa.

If you don't have any data coming in where the sourcetype is cisco_asa (hint: search for sourcetype=cisco_asa), then you'll want to track down why these rules aren't being applied. You've said that your sourcetype is currently set to syslog, and that's coming from your inputs.conf. If there's only Cisco ASA hosts logging to your collector via syslog port 514, you can force the sourcetype by changing your inputs.conf.

Otherwise, you'll want to make sure that the app's rules for remapping the type are being applied. Ask Splunk what the complete set of rules for the "syslog" sourcetype are:

/path/to/splunk/bin/splunk cmd btool props list syslog

You should see an entry like this (from Splunk for Cisco Firewalls):

TRANSFORMS-force-sourcetype_for_cisco_devices = force_sourcetype_for_cisco_pix, force_sourcetype_for_cisco_asa, force_sourcetype_for_cisco_wap, force_sourcetype_for_cisco_fwsm, force_sourcetype_for_cisco_acs, force_sourcetype_for_cisco_ios, force_sourcetype_for_cisco_catchall

Beyond that, we're talking about triaging some stuff specific to your environment, but hopefully this will give you a leg up on figuring out what's going on.

[dominik13]

Thank you very much for that detailed answer, it definitely gave me the edge in troubleshooting this! The source type is showing up correctly now. I must have not tracked my changes well because I'm not 100% sure which one did it, or if there was just a delay in seeing the effect. Thanks again!