FirePower TA - eNcore v4.+ Correlation Events converted IP to decimal

[_joe]

UPDATE:

I initially reported this on the 'Cisco Secure eStreamer Client (f.k.a Firepower eNcore) Add-On for Splunk' 4.0.7, but that entire TA turned out to be unstable. More recently I've tested out version 4.6 which is stable, but it also has the same problem I reported a few months ago.

The problem is the FirePower TA (Encore) stopped correctly reporting IP addresses in IPv4 format starting with version 4.x for rec_type=112 rec_type_desc="Correlation Event" events. For example, instead of reporting 10.0.0.1 the TA will now report 167772161 (i.e. The number can be converted back to standard IPv4 with a lot of help).

Apparently very few people actually use these events, all other events are fine. I have tested this on multiple servers with multiple  Defense Centers. It is definitely an issue with the FirePower v4 TA. Even with a Cisco entitlement, Cisco offers almost no support for this TA. 

So, to reiterate, for rec_type=112 rec_type_desc="Correlation Event"
FirePower TA v3.x:
src_ip=10.0.0.1
dest_ip=10.0.0.2

FirePower TA v4.x: 
src_ip=167772161
dest_ip=167772162

[_joe]

This app can be used to fix the issue at search time

splunkbase.splunk.com/app/3490/

[Richfez]

Which app is this?  The only one in Splunkbase for eNcore is still in the version 3.x range, as is the only one archived in Splunkbase.

What do you mean by "to decimal"?  Actual unsigned integers (ranging from negative to positive 2.1 billion or so) like 10.1.0.15 turning into 167837711?  Or just dropping the dots between dotted quads so 10.1.0.15 turns into 101015?

If the former, then I suspect what's actually happening is that the device started reporting them as integers, or always had, and the 'fix them back to dotted quads' conversion is for some reason not working on that page.  Because if they're reporting as actual integers, I can't imagine anyone would write all the terrible conversion code to convert from dotted quad to integer.  Just wouldn't be sensible, so I figure that it's converting the other way, and that other backwards that normally would happen to make them readable is broken for some reason.

If the latter, well, ... that's weird. I guess a sedcmd somewhere?  Or replace or something?  But why would that be *anywhere* in the code?

So, if you could be more specific about the actual app in use, I may be able to take a look. And even if I can't, then probably someone else can!

[_joe]

I am still running into this issue with the newest release, 4.0.9.  For example, if the IP were 69.74.26.104 (which I randomly made up) and the source were 10.0.0.1, the Correlation Event looks like this:

rec_type=112 event_sec=1603290117 policy_uuid=00000000-0000- blocked=No client_id=0 client_version="" dest_ip_country="united states" dest_criticality=None dest_host_type=Host dest_ip=5457451624 est_os_fingerprint_uuid=00000000.............. src_ip=167772161.......

[_joe]

Encore 4.0.9 crashed after a day (Cisco wasn't able to help) and  I ended up downgrading to 3.x.

I got my IP's back!

https://splunkbase.splunk.com/app/3662/

[_joe]

Thanks for responding

- 4.0.7 is available on Splunk base (https://splunkbase.splunk.com/app/3662/), but it is in beta so you have to manually select that version (v3.6.8  comes up by default).  I am playing with it because it is the only version that supports Splunk 8.

- The app is reporting decimal instead of ip, similar to your first example - "167837711" instead of 10.1.0.15

- This change started happening exactly when I migrated from 3.6.8 to 4.0.7 rather than an FMC upgrade. I haven't been able to find another other cause. But again, the app is in beta.