[Bro] Log an Arbitrarily Long Collection

[Christian Buia]

Jon, Seth,

Thank you both for the responses.  I have a much better sense now for how
to organize my scripts within the folder structure, and have found the
relevant documentation on this subject.

Jon, I took your advice and used header-names.bro as a template.  However,
it seems to be that header-names.bro in the policy folder has a couple of
key logic flaws.  The const type boolean types allow  both client and
server headers to be enumerated.  However, if you look at the "http_header"
handler, you can see that this function will return immediately for any
event that is not "is_orig", in other words it will return for server
responses with no work done.  Furthermore, if you set the const boolean
value for server responses to True (T), the logic in the event handler is
such that you will just get the client header names populated in the server
header names vector.

I have attached a (lightly tested) modified and expanded version of this
script called header-names-and-vals.bro.  Happy to hear if I am mistaken in
my understanding of the bro code, as this is the first time I write my
own.  Also, happy to hear feedback/best practices on how to escape commas
in a vector listing (I just gsubbed them with &#2c).

Thanks for your attention.

Regards,
Christian


On Wed, Sep 11, 2013 at 10:54 AM, Siwek, Jonathan Luke
<jsiwek at illinois.edu>wrote:

> >  server_headers:                vector of HeaderValue &log &optional;
> >  server_headers_count:        count &default=0;
> >
> > I decided to use a vector because I want to keep track of header order.
>  Further down on the http_header event handler, I add each header to the
> appropriate vector, indexed by the count field which increments.
>
> A minor point: you don't really have to store the count since it's
> implicit in the vector if you use `|…|` to get the size of the container.
>  E.g.
>
>         |c$http$server_headers|
>
> in this case would be equivalent to:
>
>         c$http$server_headers_count
>
> > error in /usr/local/bro/share/bro/base/protocols/http/./main.bro, line
> 83: &log applied to a type that cannot be logged (&log)
> >
> > So presumably Bro doesn't like the idea of generating a log entry that
> includes a vector type (no less consisting of record members, I'm not even
> sure what that would have looked like but was hoping to find out).
>
> A vector of an atomic type, say `vector of string`, should work.  So an
> option would be to store the header names and values in two different
> vectors.
>
> > The next best thing I can think of doing is recording this information
> with some custom delimeter in a single string field
>
> That could work also and might be better if you're more concerned w/ human
> readability.
>
> > Also, I have a feeling that directly editing http/main.bro is a bad
> practice.  Should I instead be adding this script to the policy branch,
> redefining the HTTP Info object and handling the http header event in there?
>
> Take a look at "policy/protocols/http/header-names.bro".  Copy that to
> your own script (possibly storing it in $prefix/share/bro/site) and modify
> it to do what you want (log header name+value in whatever format).  Then
> have bro load that script: if you're already loading local.bro, adding an
> @load in there for the new script is one way.
>
> - Jon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20130911/5c932134/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: header-names-and-vals.bro
Type: application/octet-stream
Size: 1720 bytes
Desc: not available
Url : http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20130911/5c932134/attachment.obj