Morning Bro List,
I’ve noticed in my scripting attempts that I can’t seem to identify the worker that matched an item from the intel framework.
This works for instance when trying to get the peer_description into the conn log like this ( after a redef ):
event connection_state_remove(c: connection) {
if (c?$conn)
c$conn$worker_name = peer_description;
}
But if the same thing is tried with the Intel framework:
event Intel::match(s: Intel::Seen, items: set[Intel::Item]) {
if (s?$conn)
s$worker_name = peer_description;
}
The worker_name remains “manager”.
Are intel framework hits processed from worker to manager in a way that loses the peer_description tied to the intel hit?
Is there a way to script around this and deliver the peer_description to the intel notice? Am I doing something wrong?
Thanks.
Ian Richmond
I’ve noticed in my scripting attempts that I can’t seem to identify the worker that matched an item from the intel framework.
This works for instance when trying to get the peer_description into the conn log like this ( after a redef ):
Arg! Total design oversight on my part!
event Intel::match(s: Intel::Seen, items: set[Intel::Item]) {
if (s?$conn)
s$worker_name = peer_description;
}
This makes sense because the Intel::match event is actually generated on the manager in clusters right now. It's even documented. 
https://www.bro.org/sphinx-git/scripts/base/frameworks/intel/main.bro.html#id-Intel::match
Is there a way to script around this and deliver the peer_description to the intel notice? Am I doing something wrong?
It would be easy to add that into the intel framework. I'll do a commit now that adds it (but it will only be in the master branch of our git repository for now).
.Seth
I lied. It's in fastpath instead of master, but we'll make sure and get it there soon. The only change is that in the seen record, you will have a field named "node" that will have the name of the node where the match happened.
.Seth