Feature - Resolve DNS Enrichment (Forward Lookup)

[morro91]

It would be great if WinlogBeat's DNS processor could resolve IP addresses given a hostname (Forward Lookup).

Especially useful in Windows world, caching would be necessary.

An extension to #7770, similar to Logstash's DNS filter (https://www.elastic.co/guide/en/logstash/current/plugins-filters-dns.html).

To add 'resolve' to Winlogbeat (and/or others) to DNS processor.

[andrewkroh]

Do you have a specific use case you could provide?

[morro91]

The main use case is Windows Event Forwarding, and then putting Winlogbeat on the collector device. As the collector has logs of X machines, it would be good to enrich with the IP address as the log only has computer_name.

[elasticmachine]

Pinging @elastic/integrations (Team:Integrations)

[elasticmachine]

Pinging @elastic/siem (Team:SIEM)

[elasticmachine]

Pinging @elastic/security-external-integrations (Team:Security-External Integrations)

[BenB196]

I'd like to add another use case here, it is slightly more of an edge case, but still a valid one I believe.

If, I am using an integration/module, which pulls/collects data from a remote point, but this remote point also pulls data from somewhere to get the data, then the "host" information is actually the middle point. In theory, if the actual data contains the final target, then you can get the name of the target and set it correctly in the event, but you can't get the IP of the target, which makes things somewhat difficult.

Example:

For SNMP monitoring, Elastic doesn't really have a good solution, but Prometheus does with the snmp_exporter. So, a weird solution is to use the SNMP exporter to handle then SNMP stuff, then use the Metricbeat Prometheus collector module, to scrape the SNMP exporter to collect the data.

This has a few weird side effects though.

1. To be able to use the SNMP exporter, the "host" isn't actually the host you want to scrape metrics from, instead it is the SNMP exporter (example: localhost:9116)
   • The "real" host is stored as a URL query parameter called target.
   • So, a request looks like: http://localhost:9116/snmp?module=<your_snmp_module>&target=host.example.com
2. The above causes a few different issues:
   1. host field information gets set to either the Prometheus SNMP exporter (if both Metricbeat and SNMP Exporter are part of the same Kubernetes pod or host) or doesn't get set at all.
   2. prometheus.labels.instance just shows up as localhost:9116 as technically that is the "host"/"target"
   3. The real information is contained in the field service.address (http://localhost:9116/snmp?module=<your_snmp_module>&target=host.example.com)

You can somewhat work around this issue, by using processors that:

1. Drop host:

- drop_fields:
    fields:
      - "host"
    ignore_missing: true

2. Set host.name correctly:

- dissect:
    tokenizer: "%{}/snmp?module=%{}&target=%{host.name}"
    field: "service.address"
    target_prefix: ''
    overwrite_keys: true
    trim_values: 'all'

3. Set host.hostname correctly:

- copy_fields:
    fields:
      - from: host.name
        to: host.hostname

But, you can never set host.ip correctly, as there is no way to perform a forward lookup on host.name

[botelastic]

Hi!
We just realized that we haven't looked into this issue in a while. We're sorry!

We're labeling this issue as Stale to make it hit our filters and make sure we get back to it as soon as possible. In the meantime, it'd be extremely helpful if you could take a look at it as well and confirm its relevance. A simple comment with a nice emoji will be enough :+1.
Thank you for your contribution!

[BenB196]

still useful

[andrewkroh]

Discuss request: https://discuss.elastic.co/t/is-it-possible-to-gain-an-ip-address-from-a-hostname-in-forwarded-event/341029