Topic I'd like to have bro not dump non-rfc compliant syslog messages in the weird file. How can I go about doing that? Thank you.
James
Topic I'd like to have bro not dump non-rfc compliant syslog messages in the weird file. How can I go about doing that? Thank you.
James
Topic I'd like to have bro not dump non-rfc compliant syslog
messages in the weird file. How can I go about doing that? Thank you.
Add a filter for the log might be an option:
https://www.bro.org/sphinx-git/frameworks/logging.html#filter-log-records
Jan
Thanks Jan. So I did more digging...this used to work in 2.4.1:
http://mailman.icsi.berkeley.edu/pipermail/bro/2014-July/007178.html
But now no longer...I guess I don't want to see binpac exceptions in weird. Any folks have any thoughts on this? Thank you.
James
Thanks Jan. So I did more digging...this used to work in 2.4.1:
http://mailman.icsi.berkeley.edu/pipermail/bro/2014-July/007178.html
But now no longer...I guess I don't want to see binpac exceptions in
weird. Any folks have any thoughts on this? Thank you.
So if disabling the syslog analyzer completely is ok for you that should
just work fine with 2.5. Do you see any errors?
Jan
Thanks Jan,
I got this to fly with disabling the analyzer, but as I look at the weird.log there are several items I’d like to filter out. For example:
dns_unmatched_msg
inappropriate_FIN
and others. I’ve looked at the code snippet as shown below:
function http_only(rec: Conn::Info) : bool
{
return rec?$service && rec$service == “http”;
}
event bro_init()
{
local filter: Log::Filter = [$name=“http-only”, $path=“conn-http”,
$pred=http_only];
Log::add_filter(Conn::LOG, filter);
}
and, as usual when I stare at bro code snippets, I’m completely lost. I get that the above creates a new log and only http from conn.log, but I have no idea how to tweak this to filter out things from weird.log. I’ve looked at:
http://try.bro.org/#/?example=logs-filter-logs
http://blog.bro.org/2012/02/filtering-logs-with-bro.html
https://www.bro.org/development/projects/logging-api.html
I see a lot of these are about splitting into new logs or filtering out fields…none of which I want to do. Any additional guidance on negating entries from logs would be excellent. Thank you…bro always makes me feel stupid 8-/
James
Hi James,
Specifically to weird logging, you can redef individual messages:
redef Weird::actions["dns_unmatched_msg"] = Weird::ACTION_IGNORE;
redef Weird::actions["dns_unmatched_reply"] = Weird::ACTION_IGNORE;
https://www.bro.org/sphinx/scripts/base/frameworks/notice/weird.bro.html
Re-reading, didn't realize there were more actions than IGNORE(and LOG).
Smart.
Thanks!
Shane
Specifically to weird logging, you can redef individual messages:
redef Weird::actions["dns_unmatched_msg"] = Weird::ACTION_IGNORE;
redef Weird::actions["dns_unmatched_reply"] = Weird::ACTION_IGNORE;
Just remembered that as I read "dns_unmatched_reply". Thanks for helping
out, Shane!
Re-reading, didn't realize there were more actions than IGNORE(and LOG).
Smart.
That's the reason why this mechanism would be preferred for filtering weird.
Thanks,
Jan
Perfect...thanks Shane and Jan...I'll give it a go and report my findings.
James
Well I'm certainly close. Thanks to the redef I'm able to squelch out a lot of noise, but alas, not the binpac exception. If I disable the analyzer I don't get any syslog.log file, so that's not what I need in this case. I'll keep digging..thanks again for all the help.
James
Hi James,
Well I'm certainly close. Thanks to the redef I'm able to squelch out a
lot of noise, but alas, not the binpac exception. If I disable the
analyzer I don't get any syslog.log file, so that's not what I need in
this case. I'll keep digging..thanks again for all the help.
if that particular notice is not listed in Weird::actions you can still
just filter manually. Something like that might work for you:
http://try.bro.org/#/trybro/saved/130377
Jan
Thanks a bunch Jan…I’ll give that a test and report my findings
James
Well I gave it a shot...no go though:
1489425830.509505 CD8sYx3dttq6ynlg2c x.x.x.x 51132 x.x.x.x 514 binpac exception: string mismatch at /home/build/bro-2.5/src/analyzer/protocol/syslog/syslog-protocol.pac:8: \x0aexpected pattern: "[[:digit:]]+"\x0aactual data: "<snip>x09MSWinEventLog\x091\x09Application\x09674838\x09Mon Mar 13 11:23:50 <snip> \x0a" - F worker-3-5
Ok Seth...how does stop either a) weird from analyzing a protocol, or b) logging binpac errors? Thanks.
James
Hi James,
Well I gave it a shot...no go though:
1489425830.509505 CD8sYx3dttq6ynlg2c x.x.x.x 51132
x.x.x.x 514 binpac exception: string mismatch at
/home/build/bro-2.5/src/analyzer/protocol/syslog/syslog-protocol.pac:8:
\x0aexpected pattern: "[[:digit:]]+"\x0aactual data:
"<snip>x09MSWinEventLog\x091\x09Application\x09674838\x09Mon Mar 13
11:23:50 <snip> \x0a" - F worker-3-5
How did you customize the filter_weird function to match that line?
Looks like the name field also contains some context-dependent info, so
that you might need a regex. However, if you see a lot of this, it might
be a good idea to dig deeper into the analyzer. Can you provide a pcap
for testing?
Jan
Hi Jan,
Thanks for looking at this...I don't want to be a pest and we can take this off list if we need to so as not to drive all the smart people crazy Here's what I added:
function filter_weird (rec: Weird::Info) : bool
{
return rec$name ! in set("binpac exception");
}
event bro_init()
{
local filter: Log::Filter = Log::get_filter(Weird::LOG, "default");
filter$pred=filter_weird;
Log::add_filter(Weird::LOG, filter);
}
This is getting "syslogs" from Windows machines via a third party app. Clearly not adhering to the RFC. As for pcap, I cannot as this is sensitive data I can share more details off list if needed. Thank you.
James
Big thanks to Jan...I have so much to learn about bro 8-| Anyway solution below for filtering out binpac exception:
function filter_weird (rec: Weird::Info) : bool
{
return /binpac exception/ ! in rec$name;
}
event bro_init()
{
local filter: Log::Filter = Log::get_filter(Weird::LOG, "default");
filter$pred=filter_weird;
Log::add_filter(Weird::LOG, filter);
}
Thanks again Jan!
James