I'm still trying to get a handle on script writing, but I have a
question on one of the events.
http_all_headers I've got a script that _should_ be processing the headers
like:
for (i in hlist )
{
local hdr = hlist[i];
Log::write(BrowserHeaders::LOG, ...)
....
}
I've tried using both the NOTICE facility and creating my own log to
at least log to see if any header values are getting processed. I'm
not sure if I'm doing it wrong or if http_all_headers doesn't do what
I think it should when I think it should. I can attach the script if
necessary, but I'm curious how I can get more information or even a
basic way to verify that one of these events is even happening.
On the upside a broctl check returns ok when I have my script loaded,
but just because there aren't any errors doesn't mean I did it right.
Thanks for any input.
-=Mike
for (i in hlist )
{
local hdr = hlist[i];
Log::write(BrowserHeaders::LOG, ...)
....
}
This create a log record for each header. Is that what you want? Or would you
like to record HTTP headers for each request/reply in a single line?
I've tried using both the NOTICE facility and creating my own log to
at least log to see if any header values are getting processed. I'm
not sure if I'm doing it wrong or if http_all_headers doesn't do what
I think it should when I think it should.
You could inserting bare print statements and then running the script on a
small trace using just the Bro binary, e.g.,
bro -r your_trace your_script
and observe the output on STDOUT.
I can attach the script if necessary, but I'm curious how I can get more
information or even a basic way to verify that one of these events is even
happening.
That would always help to give you feedback.
On the upside a broctl check returns ok when I have my script loaded,
but just because there aren't any errors doesn't mean I did it right.
Right, some bugs (often value initialization) only manifest at runtime and are
not detectable at the time when you do 'broctl check.'
Matthias
You may need to send along more of the script for use to help debug it. One thought I have though, is did you make sure and include the &log attribute on the record type that you are logging?
.Seth
This create a log record for each header. Is that what you want? Or would you
like to record HTTP headers for each request/reply in a single line?
Yeah, this was done more to figure out what was going on and to wrap
my head around the syntax
You could inserting bare print statements and then running the script on a
small trace using just the Bro binary, e.g.,
bro -r your_trace your_script
and observe the output on STDOUT.
I did include the log attribute, I'll conquer that next. More
questions first.
This was just what I needed, thanks!
I did include the &log attribute, but I still have no actual clue
what I'm doing. The price of learning.
Another question, is there a way to force (enable) headers to be
matched in a case sensitive way?
In other words I'm interested in "normal" looking headers. Accept: is
pretty standard accross browser implementation where as accept: or
ACCEPT are outliers. I noticed when I print the headers they are all
uc'd, didnt know if there was a way around this.
Reason behind all of these odd questions. I've been working on some
passive identification of browsers so I can ask the question of "what
browser tells me it's msie via the user-agent string, but doesn't
behave like it". With my current implentation I've got about a 72%
accuracy/detection rate, however it's currently implemented in another
product (commercial) that not everybody can afford. So I figured I'd
port it over and learn bro in the process so I could give it back to
the community.
Thanks for putting up with the questions.
-=Mike
Another question, is there a way to force (enable) headers to be
matched in a case sensitive way?
Yeah, this has always bothered me a little bit too. I'd like to change that for 2.1, we have some other changes that we are already planning on making to the HTTP analyzer for 2.1 anyway and we can work this in there. (in other words, no, with 2.0 you are stuck with upper-cased header names unless you change the HTTP analyzer in the core and rebuild)
I've been working on some
passive identification of browsers so I can ask the question of "what
browser tells me it's msie via the user-agent string, but doesn't
behave like it".
Awesome! Have you checked out my script to detect browsers by the headers they send and the order they send them? Feel free to take any code from that script if it helps you with your browser detection.
https://github.com/sethhall/bro_scripts/blob/master/testing/http-watch-header-order.bro
With my current implentation I've got about a 72%
accuracy/detection rate
Cool, which detection techniques you have implemented so far?
.Seth
Another question, is there a way to force (enable) headers to be
matched in a case sensitive way?
Seth answered that question already, but just to be clear: Bro
normalizes the headers to upper case. That is, each header name has one
unique (uppercase) representation at the scripting layer.
So I figured I'd port it over and learn bro in the process so I could
give it back to the community.
We're looking forward to it!
Matthias