Cisco ASA SYSLOG ASA-6-302016 field error

[rboudreau]

For the following SYSLOG message (ASA-6-302015), Splunk parses it as follows:

%ASA-6-302015: Built outbound UDP connection 425358360 for outside:123.45.67.89/22094 (123.45.67.89/22094) to servers:172.16.8.136/27316 (98.76.54.32/27316)

• src_ip = 172.16.8.136
• dest_ip = 123.45.67.89

However, for SYSLOG message ASA-6-302016, Splunk parses it in the reverse order:

 %ASA-6-302016: Teardown UDP connection 425358360 for outside:123.45.67.89/22094 to servers:172.16.8.136/27316 duration 0:02:31 bytes 540020

• src_ip = 123.45.67.89
• dest_ip = 172.16.8.136

Note that these are still the same connection, identified by the timestamps, ports and connection ID (425358360).

Does anyone know how this can be fixed? As this could cause some misleading data.

Version info:
Splunk Cloud (7.2.9)
Splunk Add-on for Cisco ASA (3.4.0.)

Here is a screenshot of the issue:

Alternate link if they will let you see it: https://i.imgur.com/5LZaNk1.png

[mydog8it]

I took a second look at the Cisco documentation for these two ASA messages and decided to move my earlier answer to a comment. My new answer is, I believe the parsing aligns with Cisco's documentation for the messages.

re: https://www.cisco.com/c/en/us/td/docs/security/asa/syslog/b_syslog/syslogs3.html#con_4770749
AND: https://www.cisco.com/c/en/us/td/docs/security/asa/asa91/configuration/firewall/asa_91_firewall_conf...

I think what looks like a bad parsing is actually due to the way the ASA is building and tearing down the connections based on the traffic flow/firewall rules. I suspect the 'deny' is on the outside interface of the firewall and as such the connection between the inside and outside is built.

In the message %ASA-6-302015 the firewall builds an outbound connection from the internal server to the Google DNS server (8.8.8.8) because a DNS query was issued by the internal server which is configured to use Google DNS.

In %ASA-6-302016 we see the connection get torn down from the DNS server to the internal server because DNS Inspect, which is enabled by default, automatically tears down these connections as soon as a response is sent back from the DNS server. So from the outside to the inside.

So, the ASA establishes the connection from the inside out and tears it down from the outside in, thus the apparent flip-flop of the src_ip in the two messages.

[rboudreau]

I see what you're saying, but i can't say that I agree with you.

I dont believe this has anything to do with the inspection engine, as this will occur with any outbound connection. Additionally, inbound/outbound classification is not impacted by any deny rules or the inspection engine, it is only based on the security levels of the source and destination interfaces.

The same results can be seen with SYSLOG IDs for TCP:

ASA-6-302013
ASA-6-302014

...so long as they are labelled by the firewall as outbound.

Here is an inbound connection that is parsing correctly, where the connection was terminated from the inside.

%ASA-6-302013: Built inbound TCP connection 569198598 for inside:172.16.46.131/64703 (172.16.46.131/64703) to mpls:10.12.3.11/443 (10.12.3.11/443)

• src_ip = 172.16.46.131
• dest_ip = 10.12.3.11

%ASA-6-302014: Teardown TCP connection 569198598 for inside:172.16.46.131/64703 to mpls:10.12.3.11/443 duration 0:01:40 bytes 1338 TCP FINs from inside

• src_ip = 172.16.46.131
• dest_ip = 10.12.3.11

Here's a similar outbound connection that is flipped.

%ASA-6-302013: Built outbound TCP connection 575965019 for cmoutside:12.234.139.10/443 (12.234.139.10/443) to inside:172.16.46.190/61613 (61.61.123.226/61613)

• src_ip = 172.16.46.190
• dest_ip = 12.234.139.10

%ASA-6-302014: Teardown TCP connection 575965019 for cmoutside:12.234.139.10/443 to inside:172.16.46.190/61613 duration 0:00:04 bytes 4002 TCP FINs from inside

• src_ip = 12.234.139.10
• dest_ip = 172.16.46.190

Why would it suddenly be ok to flip the script because it's an outbound connection? I really just think Splunk is parsing the first IP seen as the source, the 2nd as the destination. This does not get flipped around in the SYSLOG message when it's an inbound connection.

[rboudreau]

It appears something like this has happened before:

https://answers.splunk.com/answers/513608/major-problem-with-cisco-asa-add-on.html

I was able to find these strings in transforms.conf (Splunk_TA_cisco-asa):

[reverse_src_dest_for_outbound]
REGEX = [Oo]utbound\s+\S+\s+connection\s+\d+\s+for\s+\S+\s*:\s*([^\s\/\(]+)(?:\/(\w+))?(?:\((\S+)\))?\s*\(?([^\s\/\(]+)?\/?(\d+)?\)?\s+to\s+[^:]+:\s*([^\s\/\(]+)(?:\/(\w+))?(?:\((\S+)\))?\s*\(?([^\s\/\(]+)?\/?(\d+)?\)?
FORMAT = dest_ip::$1 dest_port::$2 dest_user::$3 dest_translated_ip::$4 dest_translated_port::$5 src_ip::$6 src_port::$7 src_user::$8 src_translated_ip::$9 src_translated_port::$10

This seems to handle the flipping of ASA-6-302013 and ASA-6-302015, but since ASA-6-302014 and ASA-6-302016 do NOT contain the word "outbound" in it, maybe it's getting caught by the normal src/dst REGEX:

[cisco_src_dest_ipv4]
REGEX =  (?:(\S+)/)?(\d{1,3}.\d{1,3}.\d{1,3}.\d{1,3})\((\d*)\)\s\->\s(?:(\S+)/)?(\d{1,3}.\d{1,3}.\d{1,3}.\d{1,3})\((\d*)\)
FORMAT = src_zone::$1 src_ip::$2 src_port::$3 dest_zone::$4 dest_ip::$5 dest_port::$6

[mydog8it]

I do not see the same behavior in our environment. We are using the Cisco ASA add-on (https://splunkbase.splunk.com/app/1620/) to parse the fields. I would suggest using this add-on if you are not.

[rboudreau]

[rboudreau]

I am searching in the "Search & Reporting" app to look at and manipulate logs to find stats / correlations.

What is this app going to add for me that I can't already do? Im not keen on the pointless dashboards these things come with.

[rboudreau]

Additionally, i have the following 2x "addons":

Splunk Add-on for Cisco ASA
Cisco Networks Add-on

Im guessing that these are what's parsing the data into fields for Cisco devices?

Edit: Ok so they are the same thing (1620).

I have version 3.4.0.