Try.Bro.Org Table Creation Inquiry

All,

I am trying to test a script to create a table at try.bro.org that I am having some trouble getting to work and was hoping to get some insight as to how to fix the issue. The intention is to create a table that I can read from for some additional monitoring. The testing I am doing is for what I believe is a simple use case, but the long term intention is to have a foundation for which I might create additional monitoring triggers. BTW - I have not gotten to the actual trigger script yet. I am still at the table creation portion of this process.

The intention of the table is to log “active” scanner IP sources, timestamps, and notes from the notice.log and compare these to the conn.log to trigger if a scanner actually reaches and gets a response from an internal host. I have 2 scripts that independently work on the try.bro.org site, but I am trying to get them to work at the same time. The second script only works if I manually add the file (space delimited) in try.bro.org before I run the script.

Ideally I’d like to have the table build live by reading in fields from either the current/notice.log or current/scanners.log I created from the first script, or even native tables created by the core bro environment. When I have these both run at the same time from try.bro.org site, I get an error opening the file source called in the second script being created by the first script. Any pointers or help on this would be greatly appreciated.

SCRIPT 1: creates a new log file called scanners.log (btw - I have this running fine in my local dev environment)

event bro_init()

{

Add a new filter to the Notice::LOG stream that logs only

timestamp, note, and scanner address.

local scanner_filter: Log::Filter = [$name=“active-scanners”,

$path=“scanners”,

$include=set(“ts”, “src”, “note”),

$pred(rec: Notice::Info) = { return rec?$sub && rec$sub == “remote” && rec$note == Scan::Port_Scan ||

rec$note == Scan::Address_Scan && rec$sub == “remote”; }];

Log::add_filter(Notice::LOG, scanner_filter);

}

SCRIPT 2: reads in the scanners.log file, creates the scanners table, and prints it for confirmation that it worked.

redef InputAscii::separator = " ";

type Idx: record {

src: addr;

};

type Val: record {

ts: time;

note: string;

};

global scanners: table[addr] of Val = table();

event bro_init() {

Input::add_table([$source=“scanners.log”, $name=“scanners”,

$idx=Idx, $val=Val, $destination=scanners]);

Input::remove(“scanners”);

}

event Input::end_of_data(name: string, source: string) {

now all data is in the table

print scanners;

}

It isn't working on try.bro.org because it's running against a pcap and the bro process only runs for a fraction of a second before exiting. At startup the file doesn't exist yet and the initial read will fail.

This won't work properly on a live cluster though due to issues that only recently got fixed with the input framework. The next version of bro will re-try input files that couldn't be read at startup. Previously, the input framework would stop trying after the initial failure.

In any case.. what you are trying to do doesn't actually require the use of files. You can just add a Notice::policy hook and add the scanner ip directly to the scanners table.

Justin,

Thanks for the use of hook pointer. I’m able to retrieve the data elements directly from the hook, but I am still struggling for feeding this data into a table. All the searching I find only speaks of feeding data in from a file. I can’t find any source for how to feed this “live” data into a table.

UPDATED CODE:

hook Notice::policy(n: Notice::Info)

{

if ( n$sub == “remote” && n$note == Scan::Port_Scan || n$note == Scan::Address_Scan && n$sub == “remote”)

{

local ssrc = n$src;

local sts = n$ts;

local snote = n$note;

print ssrc, sts, snote;

}

}

Try this

hook Notice::policy(n: Notice::Info)
{
    if ( n$sub == "remote" && (n$note == Scan::Port_Scan || n$note == Scan::Address_Scan))
        scanners[n$src] = [$ts=n$ts, $note=cat(n$note)];
}

n$note is actually a notice type enum so to fit in the table you described in your previous email you need to stringify it.