> when we say:
> conn_val = new RecordVal(connection_type);
>
> How many fields are there in the created record ?
8, since that's how many are defined for the corresponding type in bro.init.
> Now after that when we say...
> conn_val->Assign(12, new StringVal(tm_string)); or
> conn_val->Assign(13, new StringVal(tm_string));
I don't know where you got those lines, but they won't work if you execute
them (follow the code executed by RecordVal::Assign).
> Is the size of the record increased dynamically depending on how many
> Assigns we make ?
No. You have to manually make sure that your assignments to the record
value in the event engine are consistent with the number of fields *and their
types* as defined in bro.init.
Vern
> I'm using bro version 07a90 .I have read the documentation to know how
> the scripts work, and make some change to adapt the analyzers to the net
> configuration.But the documentation is missing for 4 script:
> code-red,backdoor,stepping and intercon.
code-red (which is renamed "worm" in subsequent releases, but 0.7a90 is
still the latest public release) was added recently, and hasn't yet been
documented. backdoor, stepping, and interconn are experimental Bro
features (corresponding to the "Detecting Backdoors" and "Detecting
Stepping Stones" papers in doc/), which likewise haven't yet been
documented.
> The problem is the fourth, what does what it serve? and how
> work?
interconn implements the generic "interactive connection" backdoor detector
described in the Detecting Backdoors paper. It's not supported. If you
want to play with it, "@load interconn" should suffice to activate it,
and it will log apparent interactive backdoors to interconn.$BRO_ID. I don't
currently use it operationally (I do use code-red, backdoor, and stepping),
so it may not work properly due to bit-rot.
Vern
Hi,
I'm using bro version 07a90 .I have read the documentation to know how
the scripts work, and make some change to adapt the analyzers to the net
configuration.But the documentation is missing for 4 script:
code-red,backdoor,stepping and intercon.
The first and the second are enough easy to understand,for the third i
found in internet a your documet "Detecting Stepping Stones" i think may
help me. The problem is the fourth, what does what it serve? and how
work?
Thanks.
Pierfrancesco Porcu.
The most likely problem is that you're not specifying what network interface
to read from, using either -i or the "interfaces" policy variable. If you
don't, then Bro doesn't read any network traffic.
If you are, then the next thing to do is to record the network traffic using
tcpdump -s 8192 -w trace.file
and then (once you verify that the traffic was properly captured) running
Bro from that file using
bro -r trace.file mt.bro
- Vern
Hi, folks:
I have installed Bro and done some experiments on it. I connected my
desktop adn laptop then setuped a tiny LAN network. Bro runs on the laptop
(RH7.1) and I use the desktop (windows2000) to attack Bro.
I tried to perform finger test to Bro (running with policy file
finger.bro) . I sent finger requests to the laptop under that desktop ,
but Bro gave out no notification on the screen even when I fingered some
hot names. Like finger root(a)192.168.1.2
And, I tried to perform a port scan to bro too, it gave out no
notification either ( running with the policy file scan.bro) . I think it
should according to the documentation.
Could anybody give some possible reasons ?
Many thanks.
Tao Zhang
-Tao Zhang (zhangtao(a)cc.gatech.edu)
Hi, folks:
I am in a project in which we will do experiments and evaluate bro's performance. I think many of you have done the similiar work, could you give me some useful pointers and references? So I can continue my work on the base of others'.
Many thanks!.
Tao Zhang
> I would like to have reports cyclically of my network usage beside the
> intrusion detection, so I have a short script like the attached file.
> Unfortunatelly, bro seems do nothing with reporting. It isn't documented, so
> can you draw me a way of doing that?
Your script has the right idea. The main thing missing is that "schedule"
only schedules an event to occur once, so you need to reschedule it if
you want it to repeat. So change:
event report_status()
{
local res = resource_usage();
log fmt("Up time: %s; Max used memory ..."
}
to:
event report_status()
{
local res = resource_usage();
log fmt("Up time: %s; Max used memory ..."
schedule +1min { report_status() };
}
The other problem you may be running into is that Bro uses the
timestamps of the incoming packet stream as its clock. So if the
packet filter isn't accepting any packets, then "time" doesn't
in fact advance, and timers don't expire. (Clearly, this is a
deficiency.) So that may be why you never got any output at all.
Also, a note. You extended the existing bro_init() to schedule
the event:
event bro_init()
{
if ( restrict_filter == "" && capture_filter == "" )
print "tcp or not tcp";
else if ( restrict_filter == "" )
print capture_filter;
else if ( capture_filter == "" )
print restrict_filter;
else
print fmt("(%s) and (%s)", capture_filter, restrict_filter);
schedule +1 min { report_status() };
}
but it works just as well to instead define a *new* bro_init event handler:
event bro_init()
{
schedule +1 min { report_status() };
}
This handler will be invoked *in addition* to the already existing one.
Vern
> Lot of OS probes works by sending a combination of flags like
>
> SFU12, SF12 etc and seeing how the OS behaves. I was wondering how to detect
> these kind of probes using bro .
>
> I know it can be done easily in the TCPConnection::NextPacket()
> where you have the syn,fin,rst and other flags in separate variables.
> Probably i could look for those pattern call the Weird().
>
> But is that the way to go about it ? Or should the detection be done
> at the bro-script level.
The right way to do it is either via Weird(), or (better) by introducing
a new event handler, something like:
event strange_TCP_flag_combo(c: connection, SYN: bool, FIN: bool, RST: bool, ACK: bool, PSH: bool, URG: count)
Your policy script could then decide how to react to specific combinations.
Vern
