Network array sort

[rkbennett]

#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"
}
}

[TheVastyDeep]

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

val = @network["#{n.to_s}/#{n.prefix()}"]
...
event.set(@target, val)

You would also have to handle val being a Hash, and iterating over it to call event.set.

[rkbennett]

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.

[TheVastyDeep]

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.