Dear sir,
I have found a bug in the event called http_header. The value : string it
returns has a space at the beginning. Like "www.yahoo.com" will be
returned as " www.yahoo.com".
I am posting You a script where I found it
@load weird
@load alarm
@load http
global path: string;
global urls: set[string] ={"www.yahoo.com","mail.google.com","www.ieee.org
","www.youtube.com","www.bro-ids.org"} ;
global shanz_log = open_log_file("http") &redef;
redef ignore_checksums = T;
event http_request(c: connection, method: string, original_URI: string,
unescaped_URI: string, version: string)
{
path = original_URI;
}
event http_header(c: connection, is_orig: bool, name: string, value: string)
{
if(name == "HOST" )
{
local v = edit(value," ");
if( v in urls)
{
print shanz_log,
fmt("%s:%s->%s:%s",c$id$orig_h,c$id$orig_p,c$id$resp_h,c$id$resp_p);
}
}
}
If I simply compare the value it doesn't match. or even if I print the value
its printing with one whitespace prefixed at the beginning.
Regards,
Sanmeet
Hi,
I'm trying to run Bro on traces with packet payloads removed and ran
across a problem where an analyzer seems to be trying to do a large
allocation due to payload that isn't in the trace. I haven't made any
modifications to Bro or its policy scripts.
I ran across the problem using Bro 1.3.2:
(gdb) run -r <trace> mt
Starting program: /n/banquet/db/tkho/bin/bro -r <trace> mt
bro: out of memory in new.
Program received signal SIGABRT, Aborted.
0x004437a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
(gdb) bt
#0 0x004437a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
#1 0x00484815 in raise () from /lib/tls/libc.so.6
#2 0x00486279 in abort () from /lib/tls/libc.so.6
#3 0x08053220 in out_of_memory ()
#4 0x0804f730 in bro_new_handler () at main.cc:373
#5 0x0091944a in operator new () from /usr/lib/libstdc++.so.6
#6 0x081a5243 in std::vector<unsigned char, std::allocator<unsigned
char> >::reserve (this=0xa045e78, __n=892614210)
at /usr/lib/gcc/i386-redhat-linux/3.4.6/../../../../include/c++/3.4.6/ext/new_allocator.h:81
#7 0x081bc674 in binpac::SunRPC::RPC_Opaque::Parse (this=0xa045e68,
t_begin_of_data=0xa02ed60 "546B07", t_end_of_data=0xa02ed7c "",
t_byteorder=0) at rpc_pac.cc:577
#8 0x081bcf42 in binpac::SunRPC::RPC_OpaqueAuth::Parse
(this=0xa045b28, t_begin_of_data=0xa02ed5c "BNPI546B07",
t_end_of_data=0xa02ed7c "", t_byteorder=0) at rpc_pac.cc:654
#9 0x081bd10a in binpac::SunRPC::RPC_Call::Parse (this=0xa045c68,
t_begin_of_data=0xa02ed4c "", t_end_of_data=0xa02ed7c "",
t_context=0xa040bf0, t_byteorder=0) at rpc_pac.cc:191
#10 0x081be1a9 in binpac::SunRPC::RPC_Message::Parse (this=0xa046688,
t_begin_of_data=0xa02ed44 "", t_end_of_data=0xa02ed7c "",
t_context=0xa040bf0) at ../src/rpc_pac.h:155
#11 0x081be421 in binpac::SunRPC::RPC_Flow::NewData (this=0xa047910,
t_begin_of_data=0xa02ed44 "", t_end_of_data=0xa02ed7c "") at
rpc_pac.cc:1062
#12 0x0813139e in RPC_UDP_Analyzer_binpac::DeliverPacket
(this=0xa0409b8, len=56, data=0xa02ed44 "", orig=true, seq=-1,
ip=0xbff786c0, caplen=8) at RPC.cc:608
#13 0x0806e496 in Analyzer::ForwardPacket (this=0xa0467d8, len=56,
data=0xa02ed44 "", is_orig=false, seq=-1, ip=0xbff786c0, caplen=8) at
Analyzer.cc:363
#14 0x0817f6b4 in UDP_Analyzer::DeliverPacket (this=0xa0467d8, len=56,
data=0xa02ed44 "", is_orig=true, seq=-1, ip=0xbff786c0, caplen=8) at
UDP.cc:179
#15 0x0807c2b3 in Connection::NextPacket (this=0xa046d9c,
t=1138500525.8319471, is_orig=1, ip=0xbff786c0, len=64, caplen=8,
data=@0x0, record_packet=@0xbff78638, record_content=@0xbff7863c,
hdr=0xa02e728, pkt=0xa02ed1a "", hdr_size=14) at Conn.cc:241
#16 0x08153270 in NetSessions::DoNextPacket (this=0xa03edc8,
t=1138500525.8319471, hdr=0xa02e728, ip_hdr=0xbff786c0, pkt=0xa02ed1a
"", hdr_size=14) at Sessions.cc:584
#17 0x081537d1 in NetSessions::NextPacket (this=0xa03edc8,
t=1138500525.8319471, hdr=0xa02e728, pkt=0xa02ed1a "", hdr_size=14,
pkt_elem=0x0) at Sessions.cc:294
#18 0x0811960e in net_packet_dispatch (t=1138500525.8319471,
hdr=0xa02e728, pkt=0xa02ed1a "", hdr_size=14, src_ps=0xa02e6f0,
pkt_elem=0x0) at Net.cc:402
#19 0x081198b2 in net_packet_arrival (t=1138500525.8319471,
hdr=0xa02e728, pkt=0xa02ed1a "", hdr_size=14, src_ps=0xa02e6f0) at
Net.cc:464
#20 0x08126036 in PktSrc::Process (this=0xa02e6f0) at PktSrc.cc:216
#21 0x08119d21 in net_run () at Net.cc:491
#22 0x080508ee in main (argc=4, argv=0xbff78c64) at main.cc:1009
(gdb)
and it also occurs in Bro 1.3.27 (rev 5632) I just pulled from SVN:
(gdb) run -r <trace> mt
Starting program: /n/banquet/db/tkho/bin/bro -r <trace> mt
terminate called after throwing an instance of 'std::bad_alloc'
what(): St9bad_alloc
Program received signal SIGABRT, Aborted.
0x004437a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
(gdb) bt
#0 0x004437a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
#1 0x00484815 in raise () from /lib/tls/libc.so.6
#2 0x00486279 in abort () from /lib/tls/libc.so.6
#3 0x0091b1bb in __gnu_cxx::__verbose_terminate_handler () from
/usr/lib/libstdc++.so.6
#4 0x00918ed1 in ?? () from /usr/lib/libstdc++.so.6
#5 0x00918f06 in std::terminate () from /usr/lib/libstdc++.so.6
#6 0x0091904f in __cxa_throw () from /usr/lib/libstdc++.so.6
#7 0x0091949c in operator new () from /usr/lib/libstdc++.so.6
#8 0x081aef57 in std::vector<unsigned char, std::allocator<unsigned
char> >::reserve (this=0x9454400, __n=892614210)
at /usr/lib/gcc/i386-redhat-linux/3.4.6/../../../../include/c++/3.4.6/ext/new_allocator.h:81
#9 0x081cb75c in binpac::SunRPC::RPC_Opaque::Parse (this=0x9455d48,
t_begin_of_data=0x943a900 "546B07", t_end_of_data=0x943a91c "",
t_byteorder=0) at rpc_pac.cc:577
#10 0x081cc02e in binpac::SunRPC::RPC_OpaqueAuth::Parse
(this=0x9454620, t_begin_of_data=0x943a8fc "BNPI546B07",
t_end_of_data=0x943a91c "", t_byteorder=0) at rpc_pac.cc:654
#11 0x081cc1f6 in binpac::SunRPC::RPC_Call::Parse (this=0x944e728,
t_begin_of_data=0x943a8ec "", t_end_of_data=0x943a91c "",
t_context=0x94557c0, t_byteorder=0) at rpc_pac.cc:191
#12 0x081cd295 in binpac::SunRPC::RPC_Message::Parse (this=0x94543d0,
t_begin_of_data=0x943a8e4 "", t_end_of_data=0x943a91c "",
t_context=0x94557c0) at ../src/rpc_pac.h:155
#13 0x081cd50d in binpac::SunRPC::RPC_Flow::NewData (this=0x944e8d0,
t_begin_of_data=0x943a8e4 "", t_end_of_data=0x943a91c "") at
rpc_pac.cc:1062
#14 0x08136b42 in RPC_UDP_Analyzer_binpac::DeliverPacket
(this=0x944e190, len=56, data=0x943a8e4 "", orig=true, seq=-1,
ip=0xbff8b2a0, caplen=8) at RPC.cc:610
#15 0x0806bfa2 in Analyzer::ForwardPacket (this=0x944e480, len=56,
data=0x943a8e4 "", is_orig=false, seq=-1, ip=0xbff8b2a0, caplen=8) at
Analyzer.cc:371
#16 0x0818826b in UDP_Analyzer::DeliverPacket (this=0x944e480, len=56,
data=0x943a8e4 "", is_orig=true, seq=-1, ip=0xbff8b2a0, caplen=8) at
UDP.cc:181
#17 0x0807a163 in Connection::NextPacket (this=0x944d7ec,
t=1138500525.8319471, is_orig=1, ip=0xbff8b2a0, len=64, caplen=8,
data=@0x0, record_packet=@0xbff8b218, record_content=@0xbff8b21c,
hdr=0x943a2c8, pkt=0x943a8ba "", hdr_size=14) at Conn.cc:263
#18 0x08159f60 in NetSessions::DoNextPacket (this=0x944a968,
t=1138500525.8319471, hdr=0x943a2c8, ip_hdr=0xbff8b2a0, pkt=0x943a8ba
"", hdr_size=14) at Sessions.cc:675
#19 0x0815a50d in NetSessions::NextPacket (this=0x944a968,
t=1138500525.8319471, hdr=0x943a2c8, pkt=0x943a8ba "", hdr_size=14,
pkt_elem=0x0) at Sessions.cc:319
#20 0x0811e8ce in net_packet_dispatch (t=1138500525.8319471,
hdr=0x943a2c8, pkt=0x943a8ba "", hdr_size=14, src_ps=0x943a290,
pkt_elem=0x0) at Net.cc:417
#21 0x0811eb5a in net_packet_arrival (t=1138500525.8319471,
hdr=0x943a2c8, pkt=0x943a8ba "", hdr_size=14, src_ps=0x943a290) at
Net.cc:479
#22 0x0812b61a in PktSrc::Process (this=0x943a290) at PktSrc.cc:216
#23 0x0811efce in net_run () at Net.cc:508
#24 0x0805004a in main (argc=4, argv=0xbff8b854) at main.cc:965
(gdb)
-Tom
Can Bro be configured to look for Unicode code points in network traffic
then execute event-oriented analyzers that compare the activity with
patterns known bad traffic? I saw a reference language called BINPac that
may be able to do this. Thoughts?
Hello.
I am trying to understand the scanning algorithm, and am having some
slight problems understanding when certain events are generated. Below
I have included a list of the events I am interested in and my best
understanding:
connection_established
A TCP handshake has been completed successfully.
partial_connection
?
connection_attempt
A TCP SYN packet has been sent.
connection_rejected
A TCP RST was seen in response to a TCP SYN.
connection_pending
I am not too sure about this one. Can this only happen if the
analyzer is shut down in the middle of a connection?
connection_half_finished
Is this when one side of a connection attempts to close a
non-existant connection?
Also, slightly unrelated, I noticed in the udp-common.bro, the code
relating to "use_TRW_algorithm" is commented out... Is there a special
reason for this?
Thanks,
Cameron Hertel
Hi,
I have a question regarding running Bro on a application-level TCP byte
stream, and was wondering which implementation option to choose. Any help is
much appreciated! Details below.
I have access to a application-level byte stream (eg: say, a http session
consisting of http put and get packets) that I would like to run Bro on it
in an online fashion (I specifically plan to use its trace anonymization
capabilities). I do not have access to the corresponding TCP byte stream /
IP byte stream, but I do have the TCP state information required
(source/dest addr, source/dest port). I am wondering how to have Bro process
these packets. I can think of the following ways by reading the various
docs, but am not sure whether there is anything else I have missed.
1. Cook up fake link-layer, TCP,IP headers, and feed Bro via a FIFO.
2. Use Brocolli to send really low-level events (events being "so and so
bytes seen on so and so conn"). These events have to be low-level because I
am trying to minimize any application-specific parsing before sending to
Bro.
3. Use the Bro source code directly, and somehow instantiate an analyzer
directly on the byte-stream. Any state needed (such as connection endpoints)
have to be cooked up.
After reading the source code and various docs, I am tending towards (3),
since it won't have the performance hit of a FIFO/broccoli, but am wondering
whether the state is seperable enough for me to do this.
Thanks in advance, and if anything is not clear, please let me know,
Jayanth
Hi,
could you possibly point me towards which files or functions I should look
at to get rid of these sanity checks? I know I'm not exactly using Bro for
its proper use - I just need it to provide a ground truth for all flows
inside of a trace. So far I've had no problems with full tcpdump traces, but
if I could just find a way for it to handle partial tcpdump traces then it
would suit my needs perfectly.
Thanks.
Daniel.
On Tue, Apr 22, 2008 at 6:02 PM, Robin Sommer <robin(a)icir.org> wrote:
>
> On Tue, Apr 22, 2008 at 08:36 -0700, I wrote:
>
> > I think yes, it should. My guess would have also been that it's the
> > checksum check which prevents Bro from doing the matching. I'll try
> > it later to see what I can find.
>
> So I looked briefly into this: there are more sanity checks inside
> the TCP analyzer which prevent the payload from reaching the
> signature engine. Nothing we'd really want to change though I think.
>
> Robin
>
> --
> Robin Sommer * Phone +1 (510) 666-2886 * robin(a)icir.org
> ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org
>
Hello:
There is always a dialog-box poped up with a connection problem every time i tried to download the current version of Bro. Can any nice guy take the trouble to send me a copy via email. Thanks!
Shaw
shaw_yxf
2008-04-23