[Bro] Bro Types Not Following Bro Types Documention

Vlad Grigorescu vlad at grigorescu.org
Mon May 18 08:13:07 PDT 2015


I think that another important point is that this is something that's
occuring in the ASCII writer (a bit of a misnomer, really a
tab-separated value writer). The fact that Bro has the concept of
optional fields means that there's a difference between a field that was
set to a non-empty string, a field that was set to an empty string, and
a field that was never set. Other output formats (e.g. JSON) have a
better way of differentiating between these, but this was the solution
developed for TSV output.

As with much of Bro, you can redef what exactly is written out in these
cases (see:
https://www.bro.org/sphinx-git/scripts/base/frameworks/logging/writers/ascii.bro.html#id-LogAscii::empty_field
and
https://www.bro.org/sphinx-git/scripts/base/frameworks/logging/writers/ascii.bro.html#id-LogAscii::unset_field).

As Johanna mentioned, there should always be a 1:1 mapping between the
log and the record that's being logged. If you're seeing ambiguity,
that's something that we should fix. Fundamentally, a Bro log line
should be as clear as possible.

  --Vlad
-------------- next part --------------
Johanna Amann <johanna at icir.org> writes:

> On Mon, May 18, 2015 at 08:37:04AM -0500, John Omernik wrote:
> [...]
>> That all said... why put anything in a field (as a default) to represent
>> unset or empty? Are we at risk of evasion?
>
> I am not sure what you would should do instead. From a protocol point of
> view, there is often a huge difference between "an empty string was
> transferred" and "this was not seen at all". For example, in HTTP a
> Referrer of "-" means that no referrer header was set at all. "" (the
> empty string) instead means that it was seen, but empty. Same for sets,
> there is a difference between the set was not seen at all ("-"), the set
> was seen but empt ("(empty)") and the set was seen and contains one
> element with an empty string ("").
>
>> Besides obviously breaking typing, what about when the type actually
>> accepts the unset character...  what if the user-agent is - or (empty)
>> couldn't that cause downstream errors?
>
> In that case, the character should be replaced by the escaped version of
> it (i.e. you should find \x[ascii-code] or similar) in the log-file
> instead of the -. Hence, it should still be decideable which of the two
> cases happened.
>
>> "You can change the logs to log however you want" is likely the
>> answer, and correct I can, but shouldn't we try be logical in our approach
>> so assumptions aren't made on the default material?
>
> I hope this helps,
>  Johanna
> _______________________________________________
> Bro mailing list
> bro at bro-ids.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/bro
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 800 bytes
Desc: not available
Url : http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20150518/6681bea8/attachment.bin 


More information about the Bro mailing list