Cisco ASA logging format change

[mamborn]

It looks like with 8.3 of Cisco ASA software the logging format has changed some.
Old Version:
Mar 15 13:39:13 192.168.1.1 %ASA-6-302015: Built inbound UDP connection 80311398 for External:192.168.2.29/64493 (192.168.2.29/64493) to Internal:192.168.100.1/53 (192.168.100.1/53) (RobinM)

New Format
Mar 15 13:39:15 192.168.100.100 :%ASA-session-6-302021: Teardown ICMP connection for faddr 172.16.49.19/768 gaddr 192.168.162.2/0 laddr 192.168.162.2/0

The ":%ASA-session" is what has changed. Is there a easy way to fix/modify the inputs. The pre-canned reports don't find the new log entries, and the field extractions are not correct. You can still search manually through splunk though.

[amalamalpm]

Try the following command

   no logging emblem

Actually there is no change in format.
Please reply to this, if it is correct or not.

[stevechege]

Thanks, this helped a lot. I had two instances of Spunk and the transforms.conf fixed formatting issue. Without the fix, it was hard to search for source/destination ports and source/destination IPs.

Older version.(After upgrade to version 6.0)

nano /opt/splunk/etc/apps/Splunk_CiscoFirewalls/local/transforms.conf

Newer version.

nano /opt/splunk/etc/apps/Splunk_for_CiscoASA/local/transforms.conf

[moorebj]

This worked, I had upgraded to 5.0 in Jan and did not notice by cisco_asa source type was missing until I ran an old report today. I put in the transform and restarted and all is well.

[tmeader]

I found the problem. The issue isn't the colon in front of the %ASA, it's that the hyphen after it isn't followed by a number anymore. Here's the built-in transform:

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

Note "%ASA-\d+-\d+". Your old data HAD %ASA-[numbers]-[numbers], whereas your new format has characters, not numerals, instead.

Under /Splunk_Home/etc/apps/[Cisco_app]/local/, create a file called "transforms.conf" and add in the following:

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

Save that and then restart Splunk. That should take care of it. Let me know if that works for you or not.

[kefoster]

This got me up and running!

[cvajs]

ah, good find.

[mamborn]

they are not coming in as sourcetype cisco_asa, and the field extractions are not showing.

[cvajs]

the events dont come in as a source type, they get matched as a source type.

[cvajs]

i am a newb with splunk, but cant you
use SED in props.conf to replace ":%ASA-session" with "%ASA"

[source::your-crisco-source]
SEDCMD-fix = s/:%ASA-session/%ASA/g

[cvajs]

this forum is a pita because it takes a single \ as a special char, so you need to escape them.

%ASA-\w+-\d+-\d+ or even %ASA-S+:

because these will limit the cisco fw match to just the new version syntax vs using a match that matches new and old.

use %ASA-(\w+-)?[67]-\d+

i suggested SED to convert the new syntax back to the old so everything works as is since everything was originally coded for the old ASA syntax, etc.

[kenth]

Why replace it when you can just match it with;

%ASA-\w+-\d+-\d+ or even %ASA-\S+:

I haven't tried the latter one though.

[mamborn]

I have two ASA firewalls logging to the splunk server. The older version 8.0.3 logs correctly and the sourcetype gets set to cisco_asa.

The newer version 8.4.2 the sourcetype gets set to udp:514.

I modified the eventtypes and that didn't seem to change it either.

[root@linux2 local]# more eventtypes.conf
[cisco_firewall]
search = %ASA OR %PIX OR %FWSM OR :%ASA

So the reports etc that are pre-canned don't find the data.

[tmeader]

So you're saying that, even with just a regular search in Splunk (not a canned report from the Cisco Apps) for data from these hosts, even though they are still showing up as sourcetype of cisco_asa, the fields are no longer being extracted properly?

[tmeader]

Were they coming in previously as "sourcetype=cisco_asa" and working properly? Looking at the default props.conf and transforms.conf in the Cisco for Firewalls addon, there's nothing in there that that ":" should've messed up at all.