Add dns string length fields which are useful for detecting dns-infiltration and dns-exfiltration

[mbudge]

Hi

I logged this pull request in the beats repo a while ago.

Add dns.string.length to improve detection's of dns exfil and tunnelling - Enhancement #20669
elastic/beats#20669

Would it be possible to add the following fields in ECS?

dns.string.length.question.name: int
dns.string.length.answers.data: int array

dns.string.length.question.name is the length of the dns.question.name string
dns.string.length.answers.data is a string array of the dns.answers.data string lengths.

Please refer to 20669 for more information on why this might be useful.

Thanks

[webmat]

@mbudge Thanks for the suggestion, I like the idea.

I would suggest capturing these lengths as different field names, however. Here's my take:

• dns.question.length
• dns.answers.length

Note that since dns.answers is an array of objects, its sub-field .length would apply to each relevant answer:

{ 
  "dns": {
    "question": { "length": 76, "name": "lotsandlotsandlotsandlotsandlotsandlotsandlotsandlotsofgibberish.example.com"  },
    "answers": [
      { "length":72, "type": "CNAME", "data": "badgerbadgerbadgerbadgerbadgerbadgerbadgerbadgerbadgerbadger.example.com" },
      { "length":42, ... }
    ]
  }
}

Any gotchas we should cover in the definition? Or is a straightforward "count of characters of the question/ answer data" enough?

@dcode @randomuserid Have you been looking at DNS exfiltration so far? Any thoughts about this?

[mbudge]

Sounds good.

Can't think of any edge cases where beats shouldn't count the length of the strings.

If there's a DNS record type the user doesn't want to include, they can always filter this out in their query.

[randomuserid]

I'd be up for running ML functions on the numeric length or byte count sizes of DNS questions and answers with the caveat that I can't currently run functions on array fields but I can use number fields.

[webmat]

@randomuserid Thanks! Are you saying that currently with ML you couldn't use dns.answers.length (see above example)?

If that's the case, we can bring this up with the ML team.

But perhaps a more immediate approach would be to add another single long field to capture the longest answer seen, instead? E.g. dns.max_answer_length

[mbudge]

"But perhaps a more immediate approach would be to add another single long field to capture the longest answer seen, instead? E.g. dns.max_answer_length"

Yes that word work. Not really interested in anything less than the longest string for this use case.

[webmat]

I've opened elastic/elasticsearch#65636 to start the discussion with the Elasticsearch team, on whether we could have ES calculate this automatically.

Having this directly in the mapping would make this much easier to add to a bunch of places, including user customizations.