Hello,
when i execute "bro -i eth0 -i eth1 login.bro",bro only capture and deal with packets from eth0 and drop all from eth1.
"1103734623.487821:ContentGap:NOTICE_ALARM_ALWAYS::192.168.10.10:2422/tcp:192.168.10.77:23/tcp::::::192.168.10.10/2422 > 192.168.10.77/telnet content gap (> 69/11):"
after that,i emove "capture-filter ......" fom login.bro and try again,bro can capture and do rightly.
why? and how can i solve this problem?
sorry,i am not familiar whit BRO.
---------------------------------
Do You Yahoo!?
注册世界一流品质的雅虎免费电邮
Thanks for passing these along! I don't see a problem with integrating
any of these (let me know if I'm missing something in this regard), so
will put them on the to-do list.
Vern
> We are running Bro 0.9a8.14 on our Linux system. We notice that
> / is often 100% full because of huge /var/log/messages, which
> seems filled with the Bro alerts that are also recorded in its
> own alarm log file.
You shouldn't be recording a huge number of alarms. The philosophy is
that alarms should be of potential operator interest; while "notices" are
of general informational interest, but not something that should be
alarmed/syslog'd. If you send me the alarms (privately) I can suggest
some ways to filter them down.
> would we be missing any Bro alerts if we delete /var/log/messages?
They'll still be recorded in alarm.$BRO_LOG_SUFFIX, but deleting
/var/log/messages is the wrong way to fix the problem!
Vern
I've made the attached changes locally to get bro to compile under gcc
3.4 with warnings turned all the way up. I'm not suggesting that you
merge this patch directly into the code base, but it shows what areas
need to be addressed and will get bro to compile for anyone who just
wants to get it working.
Brian
> when i execute "bro -i eth0 -i eth1 login.bro",bro only capture and deal
> with packets from eth0 and drop all from eth1.
I'm unable to reproduce this problem. That is, I'm able to run Bro on
two interfaces and, regardless of the order of the two, it always sees
their traffic.
Are your two interfaces identical? (Same link layer type, neither vlan'd.)
> "1103734623.487821:ContentGap:NOTICE_ALARM_ALWAYS::192.168.10.10:2422/tcp:192.168.10.77:23/tcp::::::192.168.10.10/2422 > 192.168.10.77/telnet content gap (> 69/11):"
>
> after that,i emove "capture-filter ......" fom login.bro and try again,bro can capture and do rightly.
What does "do rightly" mean here? That without the capture_filters in
login.bro, using both interfaces works correctly?
What happens if you trace each interface at the same time using
tcpdump -s 0, and then replay the traces using bro -r trace0 -r trace1 .... ?
Vern
We are running Bro 0.9a8.14 on our Linux system. We notice that
/ is often 100% full because of huge /var/log/messages, which
seems filled with the Bro alerts that are also recorded in its
own alarm log file.
Is there any way to turn off logging those Bro alerts via syslog? If
not, would we be missing any Bro alerts if we delete /var/log/messages?
Thanks!
Jaeyeon
> i'm fighting with some problems:
> i encountered problems with the &*_expire attributes of table entries.
> it seems that they have no influence, nothing happens at all.
>
> i wrote the policy script below (don't ask for the purpose of this
> script, i just wrote it to learn bro) and i thought it should alarm more
> than once, if a host contacts unreachable hosts after a while. well, it
> does it only once and the function test is never called:
> > 1103883009.796358 TRWAddressScan x.x.x.x scanned a total of 4 hosts
> > 1103883009.796358 x.x.x.x connected 10 unreachable hosts
> > 1103883010.358487 AddressScan x.x.x.x has scanned 100 hosts (ftp-data)
> > 1103883010.358487 x.x.x.x connected 100 unreachable hosts
> > 1103883013.343568 x.x.x.x connected 1000 unreachable hosts
> > 1103883013.343568 AddressScan x.x.x.x has scanned 1000 hosts (ftp-data)
> > 1103883036.284724 TRWScanSummary x.x.x.x scanned a total of 4 hosts
What do you mean it should "alarm more than once"? It is indeed generating
multiple alarms (10 unreachable, 100 unreachable, 1000 unreachable).
Also, you need to clarify why would you expect "test" to be called.
All of the expirations you set:
> > global failed_connection_counter: table[addr] of count &read_expire=30sec
> > &write_expire=30sec &create_expire=30sec &expire_func=test;
are for 30 seconds after the last of different types of activity, yet the
timestamps of the alarm output you show span just a few seconds, so this
doesn't appear to be enough time for any of the expirations to occur.
Vern
> - i'm not quite sure about the future plans of bro. will there be
> a lot of big changes from now to the release of 1.0? incompatibilities?
We don't have a precise roadmap, but of the anticipated changes, I don't
think any upcoming ones would be viewed as "big" for most Bro users. There
also will be some incompatibilities, but likewise I don't imagine these
will be viewed as major by most Bro users.
> - there exists a detection method which is based on the entropy of
> ip headers (tuple: src, dst, src_port, dst_port). the algorithm stores
> this table of tuples every minute in a file and compresses it using
> the LZO-compression-algorithm. then the size of the file is an indicator
> for network anomalies.
(Hmmmm, that seems a lot more coarse-grained than something like Bro's
TRW detector ....)
> now my question: how can i best implement this with bro? how can i use
> the lzo-algorithm (which is available in C, java, perl...) to compress
> my file every minute and get back the resulting file size?
If you really want to do that, the natural way would be to add it as a
built-in function (see src/bro.bif for how these are defined). Ideally,
the function would compute it in an incremental fashion, so the result can
be updated a piece at a time in real-time. Computing it in a batch every
minute or so, with a corresponding large CPU burst required, is not in
keeping with real-time analysis & detection.
Vern
hi
i'm fighting with some problems:
i encountered problems with the &*_expire attributes of table entries.
it seems that they have no influence, nothing happens at all.
i wrote the policy script below (don't ask for the purpose of this
script, i just wrote it to learn bro) and i thought it should alarm more
than once, if a host contacts unreachable hosts after a while. well, it
does it only once and the function test is never called:
> 1103883009.796358 TRWAddressScan x.x.x.x scanned a total of 4 hosts
> 1103883009.796358 x.x.x.x connected 10 unreachable hosts
> 1103883010.358487 AddressScan x.x.x.x has scanned 100 hosts (ftp-data)
> 1103883010.358487 x.x.x.x connected 100 unreachable hosts
> 1103883013.343568 x.x.x.x connected 1000 unreachable hosts
> 1103883013.343568 AddressScan x.x.x.x has scanned 1000 hosts (ftp-data)
> 1103883036.284724 TRWScanSummary x.x.x.x scanned a total of 4 hosts
btw: count_failed_attempts is called by the event connection_attempt in
conn.bro.
> @load notice
> @load conn
> @load hot
>
> redef table_expire_interval = 1 min;
> redef table_expire_size = 200;
> redef table_expire_delay = 0.01 secs;
>
> global test: function(t: table[addr] of count, idx: any): interval;
>
> global failed_connection_counter: table[addr] of count &read_expire=30sec
> &write_expire=30sec &create_expire=30sec &expire_func=test;
>
>
> function count_failed_attempts(c: connection)
> {
> local host = c$id$orig_h;
> if(host !in failed_connection_counter)
> failed_connection_counter[host]=1;
> else
> ++failed_connection_counter[host];
>
> local n = failed_connection_counter[host];
>
> if(n == 10)
> alarm fmt("%s connected 10 unreachable hosts", host);
> if(n == 100)
> alarm fmt("%s connected 100 unreachable hosts", host);
> if(n == 1000)
> alarm fmt("%s connected 1000 unreachable hosts", host);
> }
>
> function test(t: table[addr] of count, idx: any): interval
> {
> alarm "test";
> return 0 secs;
> }
thanx
christoph
hi
i'm currently working on my masterthesis here at the swiss federal
institute of technology in zurich.
it's about "scan detection based identification of worm-infected hosts"
in small LANs.
now, i'm evaluating bro and try to use it for my purposes.
i'm currently using bro 0.9a7 on a linux pc and i'm trying to implement
some existing scan detection approaches.
here my questions:
- i'm not quite sure about the future plans of bro. will there be
a lot of big changes from now to the release of 1.0? incompatibilities?
- there exists a detection method which is based on the entropy of
ip headers (tuple: src, dst, src_port, dst_port). the algorithm stores
this table of tuples every minute in a file and compresses it using
the LZO-compression-algorithm. then the size of the file is an indicator
for network anomalies.
now my question: how can i best implement this with bro? how can i use
the lzo-algorithm (which is available in C, java, perl...) to compress
my file every minute and get back the resulting file size?
thanx
christoph
