Greetings
I am integrating bro into a larger system so that I can use it to keep track
of connections (which seems easier than trying to write a method from
scratch with pcap). I thought it would be straightforward to grep for print
or email or alarm statements to figure out where to put the hooks for an IPC
message but so far it eludes me. Is there a principal module for outputting
the notifications?
Thanks
Mike
It's been a couple weeks since I had a problem, so now I've got two. :)
1) hex-string to addr type conversion
I've got a udp packet that contains an IP address in the packet
contents[*]. I can easily grab it with sub_bytes() and end up with a
string like "\x8d\x8e\xde!" [**]. I'd like to convert that to an addr
so I can do comparisons easily. After looking though the *.bif.bro
files for conversion functions I'm stuck. There's to_addr(), but the
string would need to actually be the IP address and not a hex
representation.
2) table of set initialization (curiosity)
I have something like this that works:
global myset: set[addr] = {192.168.1.1};
global mytable: table[string] of set[addr] = {
["blaa"] = myset,
};
When I try to combine that into one it breaks:
global mytable: table[string] of set[addr] = {
["blaa"] = 192.168.1.1,
};
bad tag in Val::CONVERTER (addr/table)
I read somewhere that 'bad tag' is an internal error and I should never
see it. I saw it. :)
-Mike
[*] -- It's a klog request for afs-kaserver3 through kaforwarder and
fakeka. So the originating requester's IP is stored in the epoch time
field of the RX packet. Whee!
[**] -- 141.142.222.33
Hi all,
Do you ever use Broccoli to config, register or implement your own event
handlers on remote Bro agents from the central one? Is there any docs or
experiences on doing that?
Thanks,
Bach Hai Duong
Someone updated a few things on the bro machine and changed over the MTA
from sendmail to exim. What needs to be done to get BRO working again
here? What config script do I need to run to set BRo up to work through
exim?
David Caldwell
Colsa/HMT
Hi,
I was experimenting on BRO 1.2 version. I could see that
the value of IPPROTO_ICMP defined in bro.init. But it looks like
the source files (eg. Discard.cc) are taking the value from the system file /usr/include/netinet/in.h.
Is it supposed to work this way? or am I hitting on a bug?
Regards,
Bindiya
Hi,
I have an HTTP trace where I downloaded a 20 meg executable (no encoding).
The trace was created by tcpdump, not bro. It was suggested in the archives
that if one gets a lot of ContentGap errors when processing a trace off-line
it is likely because there are missing packets in the trace. I'm sure my
trace has all of the packets because if I run tcpflow on the trace and
remove all of the HTTP headers from the larger of the two resulting files, I
get a file that is the same size as the executable I downloaded.
When I process the trace offline with bro (I have a custom policy that
writes the HTTP data out using the http_entity_data event) I get a lot of
ContentGap errors. The size of the written file is smaller than the size of
the executable. When I add up all of the missing bytes reported by the many
ContentGap notices, the sum is exactly the difference between the size (in
bytes) of the executable and the size of the written file. Therefore, I
assume that Bro is not passing the "missing" data to the http_entity_data
handler.
When all of the packets are in the trace and my filter (according to
print-filter) is "tcp or icmp or udp", what else is a common cause of the
ContentGap notice? Is there some tweak that I need to make to account for
larger gaps/windows?
Eric Thomas
edthoma [you know what to do] sandia.gov
Hi all,
I am having trouble matching same signature for packets in different connections,its matching one connection but its not matching for another connection but the packets have same payload.
The signature that is to be matched is the following:
signature gtalk_test {
event "gtalk test received"
payload /\x17\x03\x01/
}
I tried the following signature also
signature gtalk_one {
event "gtalk one received"
payload /.{0,0}\x17/
payload /.{1,1}\x03/
payload /.{2,2}\x00/
}
The pcap that is not matching is attached along with this mail.
can any one help me to know how the signature matching happens in bro-1.2.1
Thanks
Ayyappa
Hi,
I am quite new in Bro. I have been experimenting
with it for a couple of days by now, and couldn't
figure out the reason for the problem below (I went
through the archives as much as I can but nothing
popped up).
I am running the following simple bro script on the
test data using the steps below:
$cat a.bro
@load weird
event new_connection(c: connection)
{
print fmt("new connection=%s",c);
}
$tcpdump -r test.1 -n -tt
reading from file test.1, link-type EN10MB (Ethernet)
1007672739.741946 IP 190.84.172.89.2278 >
222.37.1.55.80: S 3585205640:3585205640(0) win 5840
<mss 1460,sackOK,timestamp 4795498 0,nop,wscale 0>
1007672740.081079 IP 222.37.1.55.80 >
190.84.172.89.2278: S 3552369456:3552369456(0) ack
3585205641 win 1460 <mss 1460,sackOK,timestamp
658637388 4795498,nop,wscale 0>
1007672740.083354 IP 190.84.172.89.2278 >
222.37.1.55.80: . ack 1 win 5840 <nop,nop,timestamp
4795532 658637388>
1007672740.090794 IP 190.84.172.89.2278 >
222.37.1.55.80: P 1:626(625) ack 1 win 5840
<nop,nop,timestamp 4795532 658637388>
1007672740.443563 IP 222.37.1.55.80 >
190.84.172.89.2278: . ack 626 win 31856
<nop,nop,timestamp 658637423 4795532>
1007672743.331707 IP 222.37.1.55.80 >
190.84.172.89.2278: P 1:206(205) ack 626 win 31856
<nop,nop,timestamp 658637723 4795532>
1007672743.334165 IP 190.84.172.89.2278 >
222.37.1.55.80: . ack 206 win 6432 <nop,nop,timestamp
4795857 658637723>
1007672743.478567 IP 190.84.172.89.2278 >
222.37.1.55.80: P 626:1262(636) ack 206 win 6432
<nop,nop,timestamp 4795871 658637723>
1007672743.692464 IP 222.37.1.55.80 >
190.84.172.89.2278: P 206:410(204) ack 1262 win 31856
<nop,nop,timestamp 658637762 4795871>
1007672743.694853 IP 190.84.172.89.2278 >
222.37.1.55.80: . ack 410 win 7504 <nop,nop,timestamp
4795893 658637762>
1007672743.838441 IP 190.84.172.89.2278 >
222.37.1.55.80: P 1262:1895(633) ack 410 win 7504
<nop,nop,timestamp 4795907 658637762>
1007672744.048642 IP 222.37.1.55.80 >
190.84.172.89.2278: P 410:614(204) ack 1895 win 31856
<nop,nop,timestamp 658637799 4795907>
1007672744.051076 IP 190.84.172.89.2278 >
222.37.1.55.80: . ack 614 win 8576 <nop,nop,timestamp
4795929 658637799>
1007672751.518485 IP 190.84.172.89.2278 >
222.37.1.55.80: F 1895:1895(0) ack 614 win 8576
<nop,nop,timestamp 4796676 658637799>
1007672751.835071 IP 222.37.1.55.80 >
190.84.172.89.2278: . ack 1896 win 31856
<nop,nop,timestamp 658638566 4796676>
1007672751.835299 IP 222.37.1.55.80 >
190.84.172.89.2278: F 614:614(0) ack 1896 win 31856
<nop,nop,timestamp 658638566 4796676>
1007672751.839189 IP 190.84.172.89.2278 >
222.37.1.55.80: . ack 615 win 8576 <nop,nop,timestamp
4796708 658638566>
$bro -r test.1 ./a.bro
new connection=[id=[orig_h=190.84.172.89,
orig_p=2278/tcp, resp_h=222.37.1.55, resp_p=80/tcp],
orig=[size=0, state=1], resp=[size=0, state=0],
start_time=1007672739.74195, duration=0.0, service=,
addl=cc=1, hot=0, history=]
(I REMOVED HTTP CONTENT GAP EVENTS FOR CONCISENESS)
new connection=[id=[orig_h=190.84.172.89,
orig_p=2278/tcp, resp_h=222.37.1.55, resp_p=80/tcp],
orig=[size=0, state=0], resp=[size=0, state=0],
start_time=1007672751.83919, duration=0.0, service=,
addl=, hot=0, history=]
$
From the timestamp, it looks to me that the second
new connection is triggered by the last ACK. But this
ACK is the ACK of the FIN packet from server, so we
should not receive a second new_connection event. Is
there anything I am missing here, or is it the
expected behavior?
Note: I am using bro-1.2.1 and did not change anything
in the policy directory.
Thanks for all your time,
____________________________________________________________________________________
Finding fabulous fares is fun.
Let Yahoo! FareChase search your favorite travel sites to find flight and hotel bargains.
http://farechase.yahoo.com/promo-generic-14795097
sorry,there're something wrong with my mailer this morning.
Thank you for your answer
How does bro be aware of the close of ftp data connection if she can't
capture the corresponding tcp session packet? via the interactive info
appeared in the ftp control connection?
And ,To dynamically capture some certain traffic without including all
packet, it feels feasible to create a new thread/process to run another bro
to capture and analyze,but is this process so long as to miss some packets
in that certain session?
On Thu, Mar 15, 2007 at 12:01 +0800, you wrote:
> So how does it dynamically add the filter string to capture the
> temporary traffic?
It doesn't. Dynamically changing the BPF filter is too expensive as
it would need to be recompiled every time (and the filter would
quickly get huge).
If you want Bro to analyze the content of ftp-data sessions, you
need to manually override the pcap filter to include all packets,
e.g., by running with "-f tcp".
Robin
--
Robin Sommer * Phone +1 (510) 931-5555 * robin(a)icir.org
LBNL/ICSI * Fax +1 (510) 666-2956 * www.icir.org