I am reviewing my source code and scripts for the ICAP Analyzer that I presented last week at BroCon, with the intent of releasing the new analyzer to the Bro community. There is one key aspect which I designed a certain way, but I wonder if it would be acceptable by the community or if it would introduce problems. I appreciate your feedback.
In the ‘main.bro’ script for the ICAP Analyzer, I redefine the ‘conn_id’ record to include a new element, as follows:
redef record conn_id += {
orig_u : string &log &optional;
}
where ‘orig_u’ is derived from the ICAP header ‘X-Authenticated-User’ and is associated with the userid on the local domain that originated the HTTP request.
At the time I wrote the code, it made perfect sense to extend the ‘conn_id’ record to include the ‘orig_u’ element, and it works very well in my operational environment. However, now that I am preparing to release the code to a wider audience, it occurs to me that perhaps it may not be acceptable to the community of users to extend the ‘conn_id’ record. To be clear, the ‘orig_u’ element would be present within every log file that records the ‘conn_id’ record, such as http.log, ftp.log, dns.log, etc. However, the values are meaningful only for http.log. In the other log files, the ‘orig_u’ column would contain a dash ‘-‘ value indicating the value is unset.
Design guidance: is it acceptable to redefine/extend the ‘conn_id’ record as described above?
I appreciate your feedback.
Thanks!
Mark I. Fernandez
You probably don't want to extend the conn_id record. There are some cases where it can cause trouble doing lookups because the conn_id is used at a table index in a lot of places.
Is there somewhere else you could stash the information that you need?
.Seth
Seth,
Is there somewhere else you could stash the information that you need?
Yes, I re-worked the script yesterday to redef/extend the HTTP::Info record and store the information there. But I notice it works differently than before, and I must do some extra effort to store it in the HTTP::Info record.
Originally, in my 'icap_header' event handler within main.bro, I would check c?$http and create one if it did not exist yet for this connection. Within the same event, if the ICAP header is 'X-Authenticated-User', then I would copy that value into the modified 'conn_id' record within the 'c$http$id$orig_u' field. Easy peasy, the orig_u column would be added to every log file that prints the conn_id record, and that column would contain the correct value.
But what I encountered yesterday when extending the HTTP::Info record to include the 'orig_u' field, it did not work so easily. Within the 'icap_header' event handler, I did everything the same except that I copied the value into 'c$http$orig_u' field (instead of 'c$http$id$orig_u'). However, it behaved differently: while the orig_u column would be added as the final column of the http.log (as expected), the value would be a dash '-', as if the value was unset. This was troubling me because I explicitly set the value within the 'icap_header' event handler. To remedy this, I had to create an event handler for 'http_request' and therein set the value of 'c$http$orig_u' accordingly. Fortunately, this worked, but I wonder why it did not work within 'icap_header', why the value was lost?
Thanks!
Mark I. Fernandez