I have revised the proposed API a bit, see
http://www.bro.org/development/projects/pacf.html
I would be interested in feedback regarding if (1) the User API is
generally expressed at a good level, and (2) if this covers the
functionality that people have implemented, or plan to, for
interfacing with their network gear.
Any other thoughts are welcome too, of course.
(The details for individual operations aren't cast in stone yet and
could certainly be adjusted/extended).
Robin
This lines up pretty well with the features that I’d want from this. I think the API is at a good level to be usable yet customizable.
A few comments I had:
I believe Rule$target should be of type Target and not TargetType (which is undefined).
Some other options to consider for EntityType:
Should Rule have both orig and resp Entity fields? i.e. I could see a use case for filtering traffic from an IP, to it, or both.
More generally, should Rule have an optional BPF? Perhaps this is one of the use cases of arg_str.
I’ve also been considering a feature that would allow a clean shutdown of a worker node. I’m not sure if this would be even remotely possible, or if it’d be a job for the PACF, but what I envision is Bro reaching out to the hardware frontend, removing one of the active output ports from the load balancing, and somehow transferring state on the in-progress connections to the other workers. The reverse would also be nice (adding a worker node), though there’d be more state to transfer.
–Vlad
- I believe Rule$target should be of type Target and not TargetType (which
is undefined).
Ack.
- Some other options to consider for EntityType:
* Subnet
* MAC address
* User? (I believe some devices allow filtering based on user, if they
authenticate via VPN, 802.1X or something similar)
Ack, as well.
For subnets, we could even just use them generally instead of
addresses, and specify addresses as /32.
User is an interesting thought.
One general question for the API is how much to standardize. A plugin
can always just extend the RuleType if it has a specific cability no
one else has. My hunch would be going with a small set initially
that's likely supported by a majority of systems we're going to
interface to.
- Should Rule have both orig and resp Entity fields? i.e. I could see a use
case for filtering traffic from an IP, to it, or both.
Yes. Or alternatively, we could add ORIG and RESP to the EntityType
instead?
- More generally, should Rule have an optional BPF? Perhaps this is one of
the use cases of arg_str.
I'm reluctant to use BPF, for two reasons. One is that it's having
some low-level problems, like VLANs etc. But more importantly, it's
very generic and hence hard to map device capabilities. Basically it
would only be supported by devices which indeed have full BPF
capabilities; and other than host-based implementations filtering with
libpcap that's probably not many (or, alternatively: Bro itself would
need to do the filtering, which is kind of counterprodutive).
I see the rules more as an (almost) lowest common denominator in terms
of expressing filters that a range of devices can support efficiently.
From that perspective, I would rather aim to identify specific use
cases ("drop IP") than provide a generic filter language.
That said, I can see some hybrid in the future where we provide more
complex filters than just simple entities, as long as they do map
easily to a range of hardware. Asim has been looking at that for a bit
already. For now we're going with the simple model for his work
though.
Robin
Besides all of Vlad's excellent points, I might add that OpenFlow
related activity should be pointed at a controller rather than an
individual switch. This might be one way to address the load
balancing issues as well.
The other question that I have is how you would identify the flow
direction in the conn_id object in the instance where I want to shunt
out one side of a connection?
Might be nice to have a count() as well since many hardware devices
have hard limits on what they can deal with. This also might make a
nice example for an extension of the RuleType.
Looks like you might have answered the flow question already via
ORIG/RESP?
thanks!
scott
Besides all of Vlad's excellent points, I might add that OpenFlow
related activity should be pointed at a controller rather than an
individual switch.
Yeah, the OpenFlow-related code in there is just some dummy code. Once
we start writing an actual OpenFlow plugin, we can see how to
structure that internally. I guess we may even end up having several
ones if we want to interface to different controllers.
The other question that I have is how you would identify the flow
direction in the conn_id object in the instance where I want to shunt
out one side of a connection?
You would specify EntityType::FLOW and then, by definition,
conn_id$orig would be the source side and conn_i$resp the destination.
I admit that might be a bit confusing, so we could also extend Entity
with a separate flow_id item so that things don't get mixed up with
standard connection semantics for conn_id.
Might be nice to have a count() as well since many hardware devices
have hard limits on what they can deal with.
What would it count? Number of rules put in so far? At the level of
the API (i.e., number of add() calls), or at the hardware level? (one
add() could translate into multiple hardware filters I suppose).
Thanks,
Robin