IP Resolve Enricher & Expression¶
IP Resolve enriches the event with canonical hostname and/or IP based on either IP address AND network/space, or any hostname AND network connected to the IP address in the lookup.
IP Resolve lookup ID must contain the following substring: ip_resolve
The lookup record has the following structure:
key: [IP, network]
value: {
"hostnames": [
canonical_hostname,
hostname2,
hostname3
...
]
}
Example¶
Declaration #1 - Enricher¶
---
define:
name: IPResolve
type: enricher/ipresolve
lookup: lmio_ip_resolve # optional
source:
- ip_addr_and_network_try1
- ip_addr_and_network_try2
- hostname_and_network_try3
- [!IP.PARSE ip4, !ITEM EVENT network4]
...
ip: ip_addr_try1
hostname: host_name
Declaration #2 - Expression¶
!IP.RESOLVE
source:
- ip_addr_and_network_try1
- ip_addr_and_network_try2
- hostname_and_network_try3
- [!IP.PARSE ip4, !ITEM EVENT network4]
...
ip: ip_addr_try1
hostname: host_name
with: !EVENT
lookup: lmio_ip_resolve # optional
Input¶
Feb 5 10:50:01 0:0:0:0:0:ffff:1f1f:e001 %ASA-1-105043 test
Output¶
{
'rt': 1580899801.0,
'msg': 'test',
'ip_addr_try1': 281471203926017,
'host_name': 'my_hostname'
}
Section define
¶
This section defines the name and the type of the enricher,
which in the case of IP Resolve is always enricher/ipresolve
.
Item name
¶
Shorter human-readable name of this declaration.
Item type
¶
The type of this declaration, must be enricher/ipresolve
.
Section source
¶
Specify a list of attributes to lookup. Every attribute should be in the following format:
[IP, network]
[hostname, network]
If network is not specified, global
will be used.
The first successful lookup returns the output values (ip
, hostname
).
Section ip
¶
Specify the attribute to store the lookuped IP address in.
Section hostname
¶
Specify the attribute to store the lookuped canonical hostname in.
Canonical hostname is the first in the lookup value's hostnames
.
Loading the lookup from a file¶
The IP Resolve lookup data can be loaded from a file using LogMan.io Collector
input:FileBlock
.
Hence, the data are available in the LogMan.io Parser, where they should be
posted to lookup
target. Thus the lookup will not enter the input
topic,
but the lookups
topic, from where it is going to be processed
by LogMan.io Watcher to update data in ElasticSearch.
The LogMan.io Watcher expects the following event format:
{
'action': 'full',
'data': {
'items': [{
'_id': [!IP.PARSE 'MyIP', 'MyNetwork'],
'hostnames': ['canonical_hostname', 'short_hostname', 'another_short_hostname']
}
]
},
'lookup_id': 'customer_ip_resolve'
}
where action
equals full
signifies, that the existing lookup content should be
replaced with the items
in data
To create this structure, use the following declarative example of Cascade Parser:
---
define:
name: Demo of IPResolve parser
type: parser/cascade
target: lookup
parse:
!DICT
set:
action: full
lookup_id:
!JOIN
items:
- !ITEM CONTEXT filename
- ip_resolve
delimiter: '_'
data:
!DICT
set:
items:
!FOR
each:
!REGEX.SPLIT
what: !EVENT
regex: '\n'
do:
!FIRST
- !CONTEXT.SET
set:
_temp:
!REGEX.SPLIT
what: !ARG
regex: ';'
- !DICT
set:
_id:
- !IP.PARSE
value: !ITEM CONTEXT _temp.0
- MyNetworkOrSpace
hostnames:
!LIST
append:
- !ITEM CONTEXT _temp.1
- !ITEM CONTEXT _temp.2