[Bro-Dev] scheduling events vs using &expire_func ?
Azoff, Justin S
jazoff at illinois.edu
Thu Apr 19 07:29:31 PDT 2018
> On Apr 19, 2018, at 7:03 AM, Aashish Sharma <asharma at lbl.gov> wrote:
>
> aggregating across all proxies is still distributing data around. So the way I
> see is you are moving the problem around :) But as I said, I don't know more how
> this works since I haven't tried new broker stuff just yet.
I think the part that you are missing is that the data is PARTITIONED across the proxies.
So say you saw a few scan attempts:
attacker.1 -> local.1:22
attacker.2 -> local.1:22
attacker.1 -> local.2:22
attacker.3 -> local.1:80
attacker.4 -> local.1:23
attacker.2 -> local.3:80
attacker.1 -> local.3:22
To do scan detection they need to be grouped into a table like this:
attacker.1 -> [local.1:22, local.2:22, local.3:22]
attacker.2 -> [local.1:22, local.3:80]
attacker.3 -> [local.1:80]
attacker.4 -> [local1:23]
This is how scan-ng, simple-scan work now.
Currently this needs to be aggregated in a single place (the manager) but with publish_hrw, bro
will do something like this:
hash(attacker.1) == proxy-1
hash(attacker.2) == proxy-2
hash(attacker.3) == proxy-2
hash(attacker.4) == proxy-1
Which will distribute the data across the proxies and you will end up with:
Data stored on proxy-1:
attacker.1 -> [local.1:22, local.2:22, local.3:22]
attacker.4 -> [local1:23]
Data stored on proxy-2:
attacker.2 -> [local.1:22, local.3:80]
attacker.3 -> [local.1:80]
Each proxy will have a consistent view of a single scanner but not need to store all data
for all scanners.
—
Justin Azoff
More information about the bro-dev
mailing list