> I was thinking of doing the same thing for MySQL logging, but there seems
> to be little value in that: the logs are pretty much free form text and no
> sensible schema can be designed.
Note that with Bro 0.8's "ALERT" framework, there's an opportunity to now
define such schemas. That indeed was one of the motivations behind
instituting it, though the policy scripts don't yet make full use of it.
Vern
> # bro -r trace.1 ./mypolicy.bro | dbi-bro.pl
>
> But when I use live traffic, I can't pipe or redirect the log output to
> the script, even a file. I don't know why. :(
Could it simply be due to buffering? Bro's stdout is block-buffered unless
you add a call to flush_all() in your policy script.
Vern
> Is there any documents that will help install Bro on Red Hat Linux. Thanks
The only documentation is the stuff that comes with it, the user manual
and auxiliary documents in doc/.
What problems are you running into?
Vern
Is there any documents that will help install Bro on Red Hat Linux. Thanks
Abera Gaston
_________________________________________________________________
Is your computer infected with a virus? Find out with a FREE computer virus
scan from McAfee. Take the FreeScan now!
http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
You can find a patch for the bro "CURRENT" release which enables you to
log in a MySQL database at http://manux.rstack.org/bro_mysql.
It requires the library MySQL++.
It uses a new bro bif called log_external which logs alerts according to
a method passed as an argument.
With this patch the only supported method is ALERT_LOG_EXTERNAL_SQL
which logs in a MySQL database.
A basic bro script that uses this method is given as an example
(policy/test.bro).
For instance:
[paul@duncan bro-pub-0.8a48.dev-mysql]$ ./bro -r
example-attacks/ftp-site-exec.trace test
976284129.459304 0.91239 other-3914 431 0 38.33.11.127 131.243.169.116 SF X
976284140.775142 0.567636 other-3915 304 0 38.33.11.127 131.243.169.116 SF X
...
mysql> select * from conn_bro;
+-----+------------------+----------+-----------------+-----------------+-----------+-----------+--------------+-----------+-----------+-----------+-------+------+------+
| cid | start_time | duration | orig_addr | resp_addr
| orig_port | resp_port | addl | conn_type | orig_size |
resp_size | state | type | code |
+-----+------------------+----------+-----------------+-----------------+-----------+-----------+--------------+-----------+-----------+-----------+-------+------+------+
| 1 | 976284129.459304 | 1 | 38.33.11.127 | 131.243.169.116
| 20/tcp | 3914/tcp | Hello world! | 0 | 431 |
0 | SF | 0 | 0 |
| 2 | 976284140.775142 | 1 | 38.33.11.127 | 131.243.169.116
| 20/tcp | 3915/tcp | Hello world! | 0 | 304 |
0 | SF |
...
Other methods should come out : RRD and SPOs(Snort Plugin Output); If
anyone has already done that, I would like to share from you.
Feed back would be appreciated.
Manu
"Anton Chuvakin, Ph.D." wrote:
>
> >I am wondering whether anyone has tried direct bro log into mysql
table or not.
> Well, what do you mean by "log"? All contents of all files or alert.log
> contents only?
>
> I was thinking of doing the same thing for MySQL logging, but there seems
> to be little value in that: the logs are pretty much free form text
and no
> sensible schema can be designed. RDBMS will be just as good as a plain
> text file...
>
> >Otherwise I will create simple perl/DBI interface by myself.
> Do share the code, if/when its created.
>
> --
> Anton Chuvakin, Ph.D., GCIA, GCIH
> Senior Security Analyst
> Product Management Group
> netForensics - http://www.netForensics.com
> 732-393-6071
Hi,
I am attempting to write a policy script for IMAP signatures
adapted from Snort using 'snort2bro'. Is this the right way
to write a policy script for the sample signatures below? I
am not sure how to treat the 'tcp-state' part? Also, is it
neccessary to use 'eval' each time?
Suggestions/Pointers??
Thanks,
-N*
---------------------------------------------
## imap.bro
@load signatures
@load software
@load log
redef capture_filter +=
"tcp port 143 and (src net 10.0)";
event bro_init()
{
set_buf(sig_file, F);
set_buf(bro_log_file, F);
set_buf(software_file, F);
}
function has_imapauthoverflow_been_attempted(state: signature_state): bool
{
local result =
has_signature_matched("sid-1930",
state$conn$id$orig_h, state$conn$id$resp_h);
return result;
}
function has_imaplsublitof_been_attempted(state: signature_state): bool
{
## do I need to use 'has_signature_matched here'??
## is there an alternative way of detecting signatures?
return T;
}
----------------------------------------------------------------
======sample signature file====
signature sid-1930 {
header ip[9:1] == 6
header ip[12:4] == 10.0.2.1
header ip[16:4] == 10.0.1.1
header tcp[2:2] == 143
payload /.* [aA][uU][tT][hH]/
payload /.*\{/
event "IMAP auth overflow attempt"
tcp-state established,originator
}
signature imap_auth_overflow {
requires-signature sid-1930
eval has_imapauthoverflow_been_attempted
event "Host may have been probed for IMAP auth overflow"
}
signature sid-1902 {
header ip[9:1] == 6
header ip[12:4] == 10.0.2.1
header ip[16:4] == 10.0.1.1
header tcp[2:2] == 143
payload /.* LSUB \x22/
payload /.*\x22 \{/
event "IMAP lsub literal overflow attempt"
}
signature imap_lsublit_overflow {
requires-signature sid-1902
eval has_imaplsublitof_been_attempted
event "Host may have been probed for IMAP lsub literal overflow"
}
---------------------------------------------
Hello all,
Is there a trick/option to make bro work with 802.1Q-tagged VLANs? I
have an interface that receives tagged frames, but it appears bro does
not reliably use the correct frame offsets. I suspect this may be an
artifact of the way libpcap handles vlans, but that's just a guess.
Perhaps I'm missing something obvious, so any suggestions are welcome.
Thanks,
Kevin Schmidt kps(a)ucsb.edu
Campus Network Programmer (805) 893-7779
Office of Information Technology (805) 893-5051 FAX
University of California, Santa Barbara
North Hall 2124
Santa Barbara, CA 93106-3201
Hi All,
I keep getting segmentation faults while I attempt to run Bro 0.8a48 on
OpenBSD3.3.
I've gone back and tried some older versions and the last version I can run
without
seg faults is 0.8a32. None of the versions after that one seem to work for
me. Has
anyone faced this problem before??
- I am running this on a P3-600 MHz, 200 MB memory system. Is that too
slow?
- The size of the 'bro.core' file upon the seg-fault is of the order of 500
MB.
Isn't that weird? The response time of my system also increases drastically
when I start Bro (other than version 0.8a32 - where it remains very normal).
----------------------------------------------------------------------------------------------------------
bash-2.05b# ./bro -i fxp0 -t trace.txt -w dump.txt -S mt
Execution tracing ON.
Segmentation fault (core dumped)
-------------trace.txt is appended at the end of this
mail--------------------
bash-2.05b# ls -la bro.core
-rw------- 1 root wheel 536426260 Nov 10 12:08 bro.core
-----------------------------------------------------------------------------------------------------------
- I tried without the '-S' option but that didn't help either.
- attaching a gdb snapshot below. Each time I've seen some or the other
function
related to 'md5' here. The bro src. file 'md5.c' hasn't changed in a while.
What's
causing this?
--------------------------------------------------------------------------------------------------------------
bash-2.05b# gdb -c bro.core -s bro
GNU gdb 4.16.1
Copyright 1996 Free Software Foundation, Inc.
This GDB was configured as "i386-unknown-openbsd3.3"...
Core was generated by `bro'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/libexec/ld.so...done.
Reading symbols from /usr/lib/libcrypto.so.9.0...done.
Reading symbols from /usr/lib/libssl.so.7.0...done.
Reading symbols from /usr/lib/libtermcap.so.9.0...done.
Reading symbols from /usr/lib/libpcap.so.2.0...done.
Reading symbols from /usr/lib/libpthread.so.1.0...done.
Reading symbols from /usr/lib/libstdc++.so.31.0...done.
Reading symbols from /usr/lib/libm.so.1.0...done.
Reading symbols from /usr/lib/libc.so.29.0...done.
#0 0x13e2a1 in md5_process ()
(gdb) bt
#0 0x13e2a1 in md5_process ()
Cannot access memory at address 0x13e298.
(gdb) i r
eax 0xcf3fe178 -817897096
ecx 0x0 0
edx 0x8 8
ebx 0xcf3fe160 -817897120
esp 0xcf3fe000 0xcf3fe000
ebp 0xcf3fe0ac 0xcf3fe0ac
esi 0x38 56
edi 0x0 0
eip 0x13e2a1 0x13e2a1
eflags 0x10286 66182
cs 0x1f 31
ss 0x27 39
ds 0x27 39
es 0x27 39
fs 0x27 39
gs 0x27 39
(gdb) q
----------------------------------------------------------------------------------------------------------
- Could it be a problem with the glibc on my system (it's a standard
install). ?
Whats so different after version 0.8a32 so as to cause this?
Any help is greatly appreciated.
thanks,
-MdK
-------trace.txt----------
0.000000 <no location>:0 function called: open_log_file(tag = 'log')
0.000000 <no location>:0 function called: log_file_name(tag =
'log')
0.000000 policy/bro.init:195 Builtin Function called:
getenv(var = '
BRO_ID')
0.000000 policy/bro.init:195 Function return:
0.000000 policy/bro.init:196 Builtin Function called:
fmt(va_args =
'%s.%s', vararg0 = 'log', vararg1 = 'log')
0.000000 policy/bro.init:196 Function return: log.log
0.000000 policy/bro.init:196 Function return: log.log
0.000000 policy/bro.init:201 Builtin Function called: open(f =
'log.log')
0.000000 policy/bro.init:201 Function return: <no value
description>
0.000000 policy/bro.init:201 Function return: <no value description>
0.000000 <no location>:0 function called: open_log_file(tag =
'alert')
0.000000 <no location>:0 function called: log_file_name(tag =
'alert')
0.000000 policy/bro.init:195 Builtin Function called:
getenv(var = '
BRO_ID')
0.000000 policy/bro.init:195 Function return:
0.000000 policy/bro.init:196 Builtin Function called:
fmt(va_args =
'%s.%s', vararg0 = 'alert', vararg1 = 'log')
0.000000 policy/bro.init:196 Function return: alert.log
0.000000 policy/bro.init:196 Function return: alert.log
0.000000 policy/bro.init:201 Builtin Function called: open(f =
'alert.log')
0.000000 policy/bro.init:201 Function return: <no value
description>
0.000000 policy/bro.init:201 Function return: <no value description>
-----end of trace-------
_________________________________________________________________
Is your computer infected with a virus? Find out with a FREE computer virus
scan from McAfee. Take the FreeScan now!
http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
> Is there a trick/option to make bro work with 802.1Q-tagged VLANs?
Your diagnosis is correct, the problem is that libpcap doesn't set up
the offset correctly.
Vinod Yegneswaran has contributed a patch to support tunnel offsets. I'm
aiming to include it in the next public release. If you want it early,
let me know and I'll send it to you (not yet integrated), though with the
caveat that it was actually developed for IP-in-UDP tunneling as opposed
to VLAN tunneling, though in principle it should work for either.
Vern
> I get a segmentation fault now :(... Do I need to load some
> additional files to process the signature rules converted from
> Snort?
Yes, per the comment in policy/sigs/ex.web-rules.sig, you need to also
load snort.bro and signatures.bro (as well as mt.bro).
When I do this, it works for me; but I don't get a core dump if I leave
them off, either.
In general, when reporting Bro bugs it really helps if you can include a
tcpdump trace (perhaps generated using bro -w) that reproduces the problem.
Vern
