[Bro-Dev] Call for opinions on logging framework syntax problem

[Bernhard Amann]

Adding the protocol to the port column in the logging framework would be a (for me) very easy solution - and probably also the cleanest one. However, apparently that is not desired, because it makes the port field more difficult to parse.

It also would fix another problem. At the moment is possible to have sets or vectors of ports in a single line of the log file. That could e.g. be used to note several ports a host is active on, e.g.

#fields host services
12.12.12.12 53,80,8080

When adding the protocol directly to the port information, the log line would e.g. look like

12.12.12.12 53/udp,80/tcp,8080/tcp

When using a second column one could probably do something like

12.12.12.12 53,80,8080 udp,tcp,tcp

but that is not really easy to read.

Bernhard


On Nov 29, 2011, at 7:04 PM, Gregor Maier wrote:

> I'm wondering whether we should maybe start including the protocol in the same column in the log files. I.e., the column would then be "80/tcp"....
> 
> Or we could handle ports similar to embedded records in the log file. I.e., if we log a port variable named "orig_p" we would get two columns:
>  orig_p.port orig_p.proto
> I actually like this variant!
> 
> 
> cu
> Gregor
> 
> On 11/29/11 16:53 , Bernhard Amann wrote:
>> Hello,
>> 
>> I am currently working on the input framework for bro -- which allows reading previously written log files back into bro -- and have encountered a little problem when reading port fields. There are several different methods to solve this problem and I wanted to get a little bit of feedback before implementing any of these solutions.
>> 
>> First to describe the problem...
>> When the logging framework is used to log port information, the information does not include the protocol -- this is usually stored in a second column.
>> Hence, a logfile storing port information will usually look something like this
>> 
>> #fields host_a host_p proto
>> 12.12.12.12 80 tcp
>> 
>> The input framework uses record types to define, what fields should be read from a previously written logfile.
>> To read the fields, one could e.g. define a record like this:
>> 
>> type Values: record {
>> 	host_a: addr;
>> 	host_p: port;
>> }
>> 
>> The problem with this approach is, that now host_p does not contain the protocol of the port, because it is stored in a different, unrelated column.
>> Hence, the input framework needs a (preferably syntactically nice, easy to understand) way to identify the column that is used to store the port information.
>> 
>> The easiest solution would be just to assume a fixed column name (e.g. host_p_port if the port is stored in host_p), but this is probably not a very good idea for a number of reasons.
>> 
>> The nicest way we could think of at the moment is to use annotations for this; for our example one could e.g. use
>> 
>> type Values: record {
>> 	host_a: addr;
>> 	host_p: port&protocol_column=proto;
>> }
>> 
>> This has the disadvantage of introducing a new, very specialized annotation that is only used for this one case.
>> 
>> Does anyone else have any ideas / suggestions?
>> 
>> Bernhard
>> _______________________________________________
>> bro-dev mailing list
>> bro-dev at bro-ids.org
>> http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
> 
> 
> -- 
> Gregor Maier
> <gregor at icir.org>  <gregor at icsi.berkeley.edu>
> Int. Computer Science Institute (ICSI)
> 1947 Center St., Ste. 600
> Berkeley, CA 94704, USA
> http://www.icir.org/gregor/