Splunk Add-on for Cisco ASA: Is parsing of src_ip and dest_ip incorrect when direction=outbound?

[mikaelbje]

A customer recently asked me how to correctly understand the format of the ASA message code 302013:

 Built (Inbound|Outbound) ....

He was a bit confused as he saw events with direction=outbound with his internal IPs as destination IP. He advised that the order of src_ip and dest_ip should have been reversed in case of outbound events. I agreed, but I thought that there must surely be a reason why Cisco did it this way. However, I had to look up the original Cisco ASA message code reference and found the following:

Error Message %ASA-6-302013: Built {inbound|outbound} TCP connection_id for interface : real-address / real-port ( mapped-address/mapped-port ) [( idfw_user )] to interface : real-address / real-port ( mapped-address/mapped-port ) [( idfw_user )] [( user )]
...
Explanation A TCP connection slot between two hosts was created.
 connection_id —A unique identifier
 interface , real-address , real-port— The actual sockets
 mapped-address, mapped-port —The mapped sockets
 user —The AAA name of the user
 idfw_user— The name of the identity firewall user
...
If inbound is specified, the original control connection was initiated from the outside. For example, for FTP, all data transfer channels are inbound if the original control channel is inbound. If outbound is specified, the original control connection was initiated from the inside.
Recommended Action None required.

One would have expected src_ip to always come first, then dest_ip, but since there is no reference in the original docs to where the src_ip and dest_ip are located in the event you need to look at the direction to fully understand the event.
So looking at the events:

direction=outbound:
src_ip=EXTERNAL.IP.ADD.RESS dest_ip=INTERNAL.IP.ADDRESS
INCORRECT. The two fields should have been the opposite

direction=inbound
src_ip=EXTERNAL.IP.ADD.RESS dest_ip=INTERNAL.IP.ADDRESS
CORRECT. The fields are populated correctly

Have I understood Cisco's implementation correctly? Should the regex in the Add-on be changed?
This probably also applies to the access-list event and a few others as well. Possible also the teardown event.

[wbleiberschnig]

Hi,
I can confirm this bug on 3.2.6. But in my case the fields for src and dest are correct for teardown logs and reversed for build logs.
kind regards

[jcoates_splunk]

Hi, are you on the Add-on for Cisco ASA version 3.1.0? There was a bug on this subject in an earlier version.

[mikaelbje]

Hi Jack,

I'm on 3.1.0. No difference there. The transform in the app for direction is stand-alone and doesn't differentiate on the location of src_... and dest_... in the event.

I believe the regexes will have to be rewritten so that you reverse the order of the src_... and dest_... fields if direction == outbound.

I can provide you with a patch in about two weeks time like I did for the enriched extractions plus lookups I sent you last time. You can have a look at it then and merge it. In the meantime I will test it at different sites and see if the behaviour is identical at different sites.

[jcoates_splunk]

thanks Mikael, filing a bug and will dig into this at more detail.

[jcoates_splunk]

Hi all, we've released v3.2.1 with improvements in this area, please check it out.

[mikaelbje]

Hi Jack!

I just tested 3.2.1. It didn't solve the issue with the order of the src_ip and dest_ip fields. Looks like the [reverse_...] stanza you added has "inside" hard-coded. This is an arbitrary value defined by the interface name where the packet is received/sent from, not a hard coded value.

[jcoates_splunk]

Hi Mikael,

Ah, I see it. Reopening.

[jkessler5081]

Hi,

I'm still seeing this issue in 3.2.6. For the teardown logs, all src and dest fields are reversed in the extractions.

Is this bug still open?

[mikaelbje]

Here's an example:

%ASA-6-302015: Built outbound UDP connection 80032440 for Outside:8.8.8.8/53 (8.8.8.8/53) to lnk_Guests:10.200.193.244/43678 (212.62.232.134/43678)

dest_interface is lnk_Guests, dest_ip is 10.200.193.244, dest_port is 43678

I believe that should have been the other way around. The outbound connection is originating from 10.200.193.244 on a high port with Google's public DNS (8.8.8.8) as dest_ip and the DNS service on port 53 as dest_port. dest_interface should have been Outside

[mikaelbje]

And here's a "patch" that changes the order of the dest_ and src_ fields for sessions that are built:

transforms.conf:


[direction_for_cisco]
REGEX = ([i|I]nbound)
FORMAT = direction::$1

[outbound_for_cisco_asa]
REGEX = (?[O|o]utbound) (?TCP|tcp|UDP|udp|ICMP|icmp) connection (?\d+) for (?\S+):(?\d{1,3}.\d{1,3}.\d{1,3}.\d{1,3})\/(?\d+)\s*(?(?\d{1,3}.\d{1,3}.\d{1,3}.\d{1,3})?\/?(?[\w\d]+)?)?\s+(?:to|dst(?! user)) (?\S+):(?\d{1,3}.\d{1,3}.\d{1,3}.\d{1,3})\/(?\d+)\s*(?(?\d{1,3}.\d{1,3}.\d{1,3}.\d{1,3})?\/?(?[\w\d]+)?)?

props.conf:

[cisco:asa]

REPORT-outbound_for_cisco_asa = outbound_for_cisco_asa

The problem with this is that the src_ and dest_ fields will be in the wrong order in the Teardown event as there is nothing indicating the direction in those events. This means that you cannot create a transaction based on dest_ip and dest_port, but if you do it based on session_id it will work, it's just that the order in the Teardown event is "wrong".

Still not really sure how to understand the syslog messages received from the ASA.

[ronogle]

You have another instance of the same log entry that the regex will not handle. Sometimes, we have names in our ASA logs instead of IP addresses. Your regex only checks for IPv4, not IPv6 nor names.

Example log entry:
Dec 18 05:37:49 10.163.19.1 %ASA-6-302013: Built outbound TCP connection 1372634579 for outside:54.235.189.180/443 (54.235.189.180/443) to inside:IND062GFP016/29631 (216.37.41.4/56892)

[mikaelbje]

I used the regex for IPv4 from the Cisco ASA Add-on as a bae. For the sake of this test/proof of concept I didn't bother with IPv6 or hostnames. A larger rewrite of the regexes will have to be done in order to account for the src_ip and dest_ip order.

I'm not the author of the ASA Add-on, so it's not my goal to get it fixed. I'm simply trying to figure out if the app's regex rules for this particular event is "off".

If you can shed some light on the matter that would be great.