Network array sort #25
Conversation
Change sorts the network array by cider descending When used in combination with the first match wins method, will always result in most restrictive match being selected
Add the following configuration settings:
network_type => "Array||Hash" (type for the network object, defaults to Array)
network_return => true||false (do you want to return the value of a matching subnet key, defaults to false)
target => "anystring" (the destination field for the returned value, defaults to 'result')
You can then point the network_path to a json formatted file which would be structured something like this:
{
"10.1.0.0/16": "my internal network",
"192.168.1.0/24": "my other internal network"
}
Alternatively, you can just call the plugin from within the pipeline like this:
cidr {
address=> [ "10.1.1.1" ]
target => "network"
network_return => true
network => {
"10.1.0.0/16" => "my internal network"
}
}
You are also able to nest hashes inside the network hash keys, allowing for even more advanced tagging.
|
If you match an array of IPs against an array of networks then setting just one target field will be an issue. If you make the target an array it will have to have the same number of entries as the input, which means non-matching IPs will need a placeholder. Processing the resulting array will probably require a ruby filter. Soooo not logstash! I think you would need an interface where the network option is an hash of hashes, and entries in the hash are added to the event. This instead of just handling You would also have to handle val being a Hash, and iterating over it to call event.set. |
|
I could be misinterpreting this, because it's been over a year since I wrote that code, but the reason it takes an array of addresses and then only outputs a hash is because it matches the most restrictive subnet match. This was intentional for my use case. For instance if you supplied a definition for 192.168.10.0/24 and 192.168.10.1/32, the definition for the /32 would be what was used to annotate the flow. |
|
That makes perfect sense when there are multiple entries for the network option. The problem is when there are multiple entries in the address option. |
#16
Sorts network array by cidr (descending)
Enhances the current first match wins method by making the first match the most restrictive
With ["10.0.0.0/8","10.1.0.0/16"], currently 10.1.0.1 would match 10.0.0.0/8, even though it's not the best match
This new method allows this example to match to 10.1.0.0/16, regardless of the initial array order
Also adds hash support for network objects, adds the following fields:
network_type => "Array||Hash" (type for the network object, defaults to Array)
network_return => true||false (do you want to return the value of a matching subnet key, defaults to false)
target => "anystring" (the destination field for the returned value, defaults to 'result')
You can then point the network_path to a json formatted file which would be structured something like this:
{
"10.1.0.0/16": "my internal network",
"192.168.1.0/24": "my other internal network"
}
Alternatively, you can just call the plugin from within the pipeline like this:
cidr {
address=> [ "10.1.1.1" ]
target => "network"
network_return => true
network => {
"10.1.0.0/16" => "my internal network"
}
}