[Bro-Dev] active_conns

[Seth Hall]

On Mar 17, 2011, at 5:57 PM, Robin Sommer wrote:

>       # This is where users can get access to the active Log record for a
>       # connection so they can extend and enhance the logged data.
>       global active_conns: table[conn_id] of Log;
> 
> What kind of data do you see this extended with?

Initially the stuff that would have gone into the $addl field before.  I don't like that field much and a lot of different scripts seem to want to add various and fairly unstructured things to it.  I'm not *totally* sure how the extension would play out with the conn.bro script, but it also didn't feel right for that script to not be extensible like all of the other scripts are and will be.  I've really been trying to push myself toward consistency across all of the scripts so that without even reading the documentation or source, someone would be able to guess how each of the shipped scripts works and what variables will be named if they know the general convention.

I think that the existence of the active_conns variable is documented in one of the manuals too, but that may have been from the active.bro script that was removed with release 1.1.  I don't exactly like the extension model applied to the conn.bro script either, but it has the benefit of being regular (i.e. like the other new scripts).

> I'm asking because one thing that always struck me as suboptimal is
> how currently many scripts are maintaining their own session table.
> E.g., the HTTP analyzer has http_sessions[conn_id] where it's stores
> its stuff.

Hm, I guess I hadn't even thought about that at all

> With the new record extension mechanisms we could instead do the other
> extreme: no script gets its own table anymore, the additional things
> just get added to a central record, like this Conn::Log.

Hm, I hadn't even considered it from that approach.  I'll think about it some more.

> (Note that if it were really Conn::*Log* that gets extended, this
> would interfere with logging obvioysly. But we could separate the two
> notions, and just have a central Connection record which everybody
> extends.). 

This is actually the model I've already moved to with most of the other scripts already.  I create an ::Info type that is kept in a conn_id indexed table, then inside the Info variable, there is an instance of a ::Log type.  Data is stored sort of haphazardly (which I don't particularly like) in either ::Info or ::Log depending on if it's an internal state tracking detail or if it's something that would conceivably ever need to be logged.

What if we make a Conn::Info (maybe different name?  I'm awful at naming) type that contains a Conn::Log type record that we could extend that with all of the ::Info typed variables for each individual script?  I think I may have to implement it to see how it looks and how it would be used.

  .Seth

--
Seth Hall
International Computer Science Institute
(Bro) because everyone has a network
http://www.bro-ids.org/