> 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
> 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
Hi,
I have a doubt regarding the use of RecordVal type.
when we say:
conn_val = new RecordVal(connection_type);
How many fields are there in the created record ?
It depends on the type of record. But where do we define that recordtype
connection_type has to have say 12 fields ?
Now after that when we say...
conn_val->Assign(12, new StringVal(tm_string)); or
conn_val->Assign(13, new StringVal(tm_string));
Is the size of the record increased dynamically depending on how many
Assigns we make ? or will it stop assigning when the size of the record is
reached ?
Any pointers is welcome ....
thanks a lot
ashley
hi,
I am using bro version 0.7a48. I was using bro-0.7a48 on linux
i had made some small changes. Later i moved it to openbsd 2.9.
(I had tarred the whole directory)
I did a ./configure and make on the new platform.
Should this cause a problem ?
The problem i am facing is this:
when a ftp connection is initiated.. the 'service' variable in Sessions.cc
is becoming '5376' instaed of '21'.
Sessions.cc has:
int service = ntohs(pkt_dst_port);
pkt_dst_port is '21' and the ntohs is making it '5376'.
I think it is because i had been using bro before in Linux which is a little endian and Openbsd is a big-endian machine.
Is there a way to rectify this without remiving the ntohs ??
I used another version which was not used on linux and it is working fine.
thanks
ashley
> I had a general question regarding Bro.
> Can we classify it under Rule based or Anomaly based as usually IDSs are
> classified ?
> I would guess it is a Rule based one. Is there any anomaly detection in
> Bro ?
I think of Bro as somewhat different from both of these notions. The term
I've used is "activity based", meaning that its core notion is to first
describe network activity in generic terms (this is done by the event
engine), and then to compare that activity against a site's local poilcy
for policy violations (done by the script interpreter). That said, it's
in general closer to rule-based than anomaly-based, and a number of the
attacks detected by the default set of scripts are certainly rule-based/
signature-based. But some of its detection, such as stepping stones and
backdoors, is more along the lines of anomaly detection, except you need
to define the "normal" behavior (e.g., which stepping stones and backdoors
are benign) by hand. This isn't fundamental to Bro's design - you could
picture extending it to learn likely normal behavior in this regard - but
it doesn't do so presently.
> When it is stated that an IDS can withstand upto or greater than 'X'
> Mbps,
> do we make any assumptions regarding the number of rules in the
> rule-based IDS ?
Well, certainly.
> I would think as the rules increases, the traffic that the IDS can
> withstand should decrease.
In general, yes, though you look for rules that can be matched in parallel.
For example, by using regular-expression matching, you can look for large
numbers of text patterns in packet payloads or connection byte streams
all at the same time, without having to back up.
Vern
