Infoblox TA has dest and src swapped

[asvoboda]

When looking at the search time extractions being done by the Infoblox TA, it seems like the src and dest fields are a little bit mixed up. What I would expect to see as the src (in the example event, the client making the request) shows up as the dest and vice versa.

The transforms.conf included in the app seems to be doing the wrong thing, where it assigns dest as the server_ip if the message is a response. If I'm thinking about network flow, the response is coming from the server, and so should be the src, not the dest. In the case where the message type is not a response, the TA returns the dest as the dns_request_client_ip, which feels like it should instead be the src.

As a bit of a side note, the CIM wording on this feels somewhat ambiguous:

dest: The destination of the network resolution event
src: The source of the network resolution event

So based on that definition I could also see either being correct.

Example event:

<30>Mar  2 20:46:36  infobloxhostname 10.160.10.12 named[30577]: client 10.156.27.56#58392 (debug.opendns.com): query: debug.opendns.com IN TXT +E (10.160.10.12)

src  = 10.160.10.12
dest = 10.156.27.56

transforms.conf:

EVAL-dest           = if(match(message_type,"response"),server_ip,if(command == "dhcp_updater_default", infoblox_ip, dns_request_client_ip))
EVAL-src            = coalesce(src_req,src_resp,src_ip)

[marycordova]

just for fun...the cisco CWS TA has the same issue 😄

i really need to make a post about that...

[mghocke]

We are experiencing the exact same thing. Intuitively one would think that the destination is the name server and the source is the client when it comes to query logs. We turned on reply logging on our Grid and now the field extractions make more sense, even though theoretically it should still be switched around, i.e. the source is now the name server and the destination is the client. Personally, I think this is confusing and I am going to change the extraction so that src will always be the client and dest the name server, no matter if it is a query or a reply log.

All that said, we also have the ISC BIND add-on and in there the src and dest are extracted the way we think it should be. I'll open a case with Splunk (both TAs are provided by Splunk) and see how they want to handle this.

[mghocke]

Splunk opened a bug report for me and we'll see how it shakes out. The inconsistency between the Infoblox and the ISC BIND add-on is reason enough that something needs to be fixed.

[rgqt918]

I know I am resurrecting a very old post, but did they say it's expected? I noticed the InfoBlox TA is still "backwards" with src and dest.

[chamayer]

To make it more interesting, in the ES correlation search for Excessive DNS Failures it's using the src field to measure hosts that are getting a lot of DNS failures (which seems to be consistent with the infoblox parsing).

In Splunk Stream when collecting DNS there is a conflicting behavior (when it picks up both the QUERY and RESPONSE the client will be the src, when it picks up only a RESPONE the client will be dest.

[Splunk_rocks]

We have situation like

we are getting events to splunk only query and request events
source and destination info is mismatching when use the splunk_TA.
we can make adjustment as custom fields but is there any work around any one found.

[asvoboda]

It also looks like infoblox_dhcp_extract_field_2 might need to be tweaked to include the offered-duration and optional uid that infoblox returns at the end of a DCHPOFFER event type. The quick fix would be to add that extraction in and remove the trailing $

(DHCPOFFER)\son\s(\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})\sto\s([0-9a-zA-Z]{2}(?:\:[0-9a-zA-Z]{2}){5})\s(?:\(([^\)]+)\)\s)?via\s(.+)\srelay\s(\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})\slease\-duration\s(\d+)$

turns into

(DHCPOFFER)\son\s(\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})\sto\s([0-9a-zA-Z]{2}(?:\:[0-9a-zA-Z]{2}){5})\s(?:\(([^\)]+)\)\s)?via\s(.+)\srelay\s(\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})\slease\-duration\s(\d+)\soffered-duration\s(\d+)