From kanthimyneni at gmail.com  Thu Nov  1 08:59:33 2007
From: kanthimyneni at gmail.com (kanthi myneni)
Date: Thu, 1 Nov 2007 11:59:33 -0400
Subject: [Bro] help to understand more about bro
Message-ID: <6db04b6c0711010859o463c4223pd7daaee07c0955a8@mail.gmail.com>

Hi,

I am Kanthi Myneni, working as Research Assistant in West Virginia
University. As a Part of my research I need to know more about bro. I tried
to learn it from the materials you provided. But still I am not cleared. Can
you help me to fix these problems.

1.  How bro detects unkown detects. What are the Policy rules you used, on
what based they are considered.

2. Does bro do clustering.

3. Are there any techical researches that are connected with bro.

Sorry for taking your valuable time.

Thanks & Regards,
Kanthi Myneni.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20071101/6cb27cd7/attachment.html 

From robin at icir.org  Thu Nov  1 11:56:31 2007
From: robin at icir.org (Robin Sommer)
Date: Thu, 1 Nov 2007 11:56:31 -0700
Subject: [Bro] [Fwd] Vacancy
Message-ID: <20071101185621.GA21577@icir.org>

Just in case anybody here is looking for a change, there's a vacancy
in the security group at the Lawrence Berkeley National Lab. 

Robin

----- Forwarded message from Dwayne Ramsey <DGRamsey at lbl.gov> -----

From: Dwayne Ramsey <DGRamsey at lbl.gov>
Date: Thu, 01 Nov 2007 10:39:16 -0700
Subject: Vacancy 
Message-ID: <472A0F44.80707 at lbl.gov>

We currently have a vacancy in the computer protection program. 
Potential candidates are encouraged to apply.

http://jobs.lbl.gov/LBNLCareers/details.asp?jid=21118&p=1


Best,


Dwayne

----- End forwarded message -----

-- 
Robin Sommer * Phone +1 (510) 931-5555 * robin at icir.org 
ICSI/LBNL    * Fax   +1 (510) 666-2956 *   www.icir.org


From gregor at net.t-labs.tu-berlin.de  Fri Nov  2 12:16:54 2007
From: gregor at net.t-labs.tu-berlin.de (Gregor Maier)
Date: Fri, 02 Nov 2007 20:16:54 +0100
Subject: [Bro] Bytes in conn.log is way to large
In-Reply-To: <20071101221325.GA23149@icir.org>
References: <472A05F2.1080001@net.t-labs.tu-berlin.de>
	<20071101221325.GA23149@icir.org>
Message-ID: <472B77A6.1010906@net.t-labs.tu-berlin.de>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

I got some problems with the number of byte values in conn.log, they are
way too large [1]. My Bro's running offline on traces.


To get rid of this issue, I tried use large-conns.bro, but it looks like
that large-conns.bro has a problem when reading a trace from stdin. I
tried it with bro-1.3.2 and with a current branch from Robin.



I get the following error when reading from stdin:
/home/bro-conn-log/bin/bro: problem with trace file - - bad dump file format

replay:/data/gregor/blub# /home/bro-conn-log/bin/bro -r - gm_conn <
/data/pcap/slice-0000.cr.pcap
/home/bro-conn-log/bin/bro: problem with trace file - - bad dump file format

replay:/data/gregor/blub# cat /data/pcap/slice-0000.cr.pcap |
/home/bro-conn-log/bin/bro -r - gm_conn
/home/bro-conn-log/bin/bro: problem with trace file - - bad dump file format

But reading the file directly works:
replay:/data/gregor/blub# /home/bro-conn-log/bin/bro -r
/data/pcap/slice-0000.cr.pcap gm_conn weird
..... this works.


Since my traces contain contain of several slices, I really do want to
read from stdin.





[1]
 I had this problem with two different traces. The first is only
uni-directional, i.e., bro sees only one side of the connection. The
traces contained 50GB of IP data. The sum of the bytes from conn.log was
 approx. 2TB(!) however. I then checked for particular large connections
(i.e., > 1GB). All of them had a state with RSTs and judging from the
duration the # bytes was clearly bogus.

I also tried it on a second trace. This one had both directions. 600GB
IP data and conn.log reported 1.9TB. The total # of connections in the
trace is 29M. Of these 62.000 are larger than 1GB. From these large
flows only XXX were terrminated without RSTs.


[2]
# cat gm_conn.bro:
const number_of_regions = 64;
const regin_size = 32 * 1024;
@load large-conns

#@load dpd
@load conn


redef Scan::suppress_scan_checks = T;
redef ignore_checksums = T;

redef dpd_conn_logs = F;

# If we see only one side of a conn, we must reduce these
# timers
redef tcp_inactivity_timeout = 60 secs;
redef udp_inactivity_timeout = 45 secs;
redef icmp_inactivity_timeout = 30 secs;




- --
Gregor Maier                             gregor at net.t-labs.tu-berlin.de
TU Berlin / Deutsche Telekom Labs             gregor.maier at tu-berlin.de
Sekr. TEL 4, FG INET                        www.net.t-labs.tu-berlin.de
Ernst-Reuter-Platz 7
10587 Berlin, Germany



From gregor at net.t-labs.tu-berlin.de  Fri Nov  2 12:44:56 2007
From: gregor at net.t-labs.tu-berlin.de (Gregor Maier)
Date: Fri, 02 Nov 2007 20:44:56 +0100
Subject: [Bro] Bytes in conn.log is way to large
In-Reply-To: <472B77A6.1010906@net.t-labs.tu-berlin.de>
References: <472A05F2.1080001@net.t-labs.tu-berlin.de>
	<20071101221325.GA23149@icir.org>
	<472B77A6.1010906@net.t-labs.tu-berlin.de>
Message-ID: <472B7E38.6050505@net.t-labs.tu-berlin.de>


> I also tried it on a second trace. This one had both directions. 600GB
> IP data and conn.log reported 1.9TB. The total # of connections in the
> trace is 29M. Of these 62.000 are larger than 1GB. From these large
> flows only XXX were terrminated without RSTs.

sorry, I sent the Mail too early:

of the 29M connections, 628 are > 1GB and of those  487 are terminated
with a RST.
A lot of these large connections furthermore had very short duratinos
(<<1sec) and had only "traffic" in one direction.


What about adding some sanity checks, so that the byte values are
meaningful even if not using large-conns.bro? Otherwise one cannot rely
at the byte values in conn.log at all.
Maybe such checks could be:
* a "maximum bandwidth" a connection must not exceed
* require that bytes/packets are seen in both directions



cu
gregor

-- 
Gregor Maier                             gregor at net.t-labs.tu-berlin.de
TU Berlin / Deutsche Telekom Labs             gregor.maier at tu-berlin.de
Sekr. TEL 4, FG INET                        www.net.t-labs.tu-berlin.de
Ernst-Reuter-Platz 7
10587 Berlin, Germany


From vern at icir.org  Fri Nov  2 15:09:54 2007
From: vern at icir.org (Vern Paxson)
Date: Fri, 02 Nov 2007 15:09:54 -0700
Subject: [Bro] Bytes in conn.log is way to large
In-Reply-To: <472B77A6.1010906@net.t-labs.tu-berlin.de> (Fri,
	02 Nov 2007 20:16:54 BST).
Message-ID: <200711022209.lA2M9ujm008366@pork.ICSI.Berkeley.EDU>

> To get rid of this issue, I tried use large-conns.bro, but it looks like
> that large-conns.bro has a problem when reading a trace from stdin.

Hmmm, indeed it does.  It's because the secondary filter needs to reopen
the packet source, and in this case a second open of stdin gets in trouble
because both filters share the same kernel file descriptor.

It works if you instead use -r filename.

> Since my traces contain contain of several slices, I really do want to
> read from stdin.

Note, you can use "ipsumdump --collate -w whole-shebang.trace *.trace" to
glue together multiple pcap files into a single coherent trace.

		Vern


From vern at icir.org  Fri Nov  2 15:10:57 2007
From: vern at icir.org (Vern Paxson)
Date: Fri, 02 Nov 2007 15:10:57 -0700
Subject: [Bro] Bytes in conn.log is way to large
In-Reply-To: <472B7E38.6050505@net.t-labs.tu-berlin.de> (Fri,
	02 Nov 2007 20:44:56 BST).
Message-ID: <200711022211.lA2MB035008388@pork.ICSI.Berkeley.EDU>

> What about adding some sanity checks, so that the byte values are
> meaningful even if not using large-conns.bro? Otherwise one cannot rely
> at the byte values in conn.log at all.
> Maybe such checks could be:
> * a "maximum bandwidth" a connection must not exceed
> * require that bytes/packets are seen in both directions

These are reasonable features to add, but I don't think we'll give them much
priority ourselves.  (I.e., if you want to contribute it, we'll integrate it.)

		Vern


From robin at icir.org  Fri Nov  2 16:23:11 2007
From: robin at icir.org (Robin Sommer)
Date: Fri, 2 Nov 2007 16:23:11 -0700
Subject: [Bro] Bytes in conn.log is way to large
In-Reply-To: <472B7E38.6050505@net.t-labs.tu-berlin.de>
References: <472A05F2.1080001@net.t-labs.tu-berlin.de>
	<20071101221325.GA23149@icir.org>
	<472B77A6.1010906@net.t-labs.tu-berlin.de>
	<472B7E38.6050505@net.t-labs.tu-berlin.de>
Message-ID: <20071102232311.GB5944@icir.org>


On Fri, Nov 02, 2007 at 20:44 +0100, Gregor Maier wrote:

> * a "maximum bandwidth" a connection must not exceed

Yeah, various post-processing scripts are using such heuristics to
avoid the problem when analyzing connection logs.

Robin

-- 
Robin Sommer * Phone +1 (510) 931-5555 * robin at icir.org 
ICSI/LBNL    * Fax   +1 (510) 666-2956 *   www.icir.org


From jp.luiggi at free.fr  Fri Nov  2 16:28:14 2007
From: jp.luiggi at free.fr (jean-philippe luiggi)
Date: Fri, 2 Nov 2007 19:28:14 -0400
Subject: [Bro] help to understand more about bro
In-Reply-To: <6db04b6c0711010859o463c4223pd7daaee07c0955a8@mail.gmail.com>
References: <6db04b6c0711010859o463c4223pd7daaee07c0955a8@mail.gmail.com>
Message-ID: <20071102192814.3cc4ef37@localhost>

Hello,

On Thu, 1 Nov 2007 11:59:33 -0400
"kanthi myneni" <kanthimyneni at gmail.com> wrote:

> Hi,
> 
> I am Kanthi Myneni, working as Research Assistant in West Virginia
> University. As a Part of my research I need to know more about bro. I
> tried to learn it from the materials you provided. But still I am not
> cleared. Can you help me to fix these problems.
> 
> 1.  How bro detects unkown detects. What are the Policy rules you
> used, on what based they are considered.

What do you mean ? 
Do you speak about anomaly detection ?

> 2. Does bro do clustering.

Please see : http://www.bro-ids.org/wiki/index.php/Bro_Cluster
 
> 3. Are there any techical researches that are connected with bro.

I think so, at least, there's a friend of mine (hello
Julien... :-) ) who's working hard with Bro and IPv6.

> Sorry for taking your valuable time.

Don't worry.


Best regards,

Jean-philippe.


From kanthimyneni at gmail.com  Fri Nov  2 22:26:00 2007
From: kanthimyneni at gmail.com (kanthi myneni)
Date: Sat, 3 Nov 2007 01:26:00 -0400
Subject: [Bro] help to understand more about bro
Message-ID: <6db04b6c0711022226w4ec8a01fr67e990b4d19b61a8@mail.gmail.com>

Thanks for reply.

Actually very recently I started bro on linux. Its working with
installing some missed packages. I am enthusiastic to know how is it
working.

Yeah I mean about anomaly detection. This must have been done based on
some site policies right. What are those policies based on. Like they
vary from site to site right.  How those are taken.

Thanks&Regards,
Kanthi Myneni.
- Show quoted text -


From pclin at cis.nctu.edu.tw  Mon Nov  5 15:04:58 2007
From: pclin at cis.nctu.edu.tw (Po-Ching Lin)
Date: Tue, 06 Nov 2007 07:04:58 +0800
Subject: [Bro] Segmentation fault when installing a rotate timer in BroFile
Message-ID: <20071106062257.2F73.PCLIN@cis.nctu.edu.tw>


     I encountered a segmentation fault when executing Bro with a trace
I captured on my laptop. Tracing the problem with gdb, I found the
fault happened in installing a rotate timer:

...

Breakpoint 1, BroFile::InstallRotateTimer (this=0x8fa3a90) at File.cc:562
562             timer_mgr->Add(rotate_timer);
(gdb) c
Continuing.

Breakpoint 1, BroFile::InstallRotateTimer (this=0x903fd78) at File.cc:562
562             timer_mgr->Add(rotate_timer);
(gdb) c
Continuing.

Breakpoint 1, BroFile::InstallRotateTimer (this=0x90404e0) at File.cc:562
562             timer_mgr->Add(rotate_timer);
(gdb) c
Continuing.

Breakpoint 1, BroFile::InstallRotateTimer (this=0x90b4030) at File.cc:562
562             timer_mgr->Add(rotate_timer);
(gdb) c
Continuing.

Breakpoint 1, BroFile::InstallRotateTimer (this=0x90b4030) at File.cc:562
562             timer_mgr->Add(rotate_timer);      <-- < the 23rd execution of timer_mgr->Add(rotate_timer);
(gdb) s

Program received signal SIGSEGV, Segmentation fault.
0x080eed0d in BroFile::InstallRotateTimer (this=0x90b4030) at File.cc:562
562             timer_mgr->Add(rotate_timer);

The command line to execute Bro is as follows.

> bro --use-binpac brolite -r ./misc.pcap

What might the problem be?

-- 
Po-Ching Lin <pclin at cis.nctu.edu.tw>




From vern at icir.org  Mon Nov  5 22:38:06 2007
From: vern at icir.org (Vern Paxson)
Date: Mon, 05 Nov 2007 22:38:06 -0800
Subject: [Bro] Segmentation fault when installing a rotate timer in
	BroFile
In-Reply-To: <20071106062257.2F73.PCLIN@cis.nctu.edu.tw> (Tue,
	06 Nov 2007 07:04:58 +0800).
Message-ID: <200711060638.lA66c81d007459@pork.ICSI.Berkeley.EDU>

> Program received signal SIGSEGV, Segmentation fault.
> 0x080eed0d in BroFile::InstallRotateTimer (this=0x90b4030) at File.cc:562
> 562             timer_mgr->Add(rotate_timer);

This came up a little while ago on the mailing list.  See if the following
does the trick.

		Vern


Date:  Wed, 19 Sep 2007 12:50:23 +0800
From:  "CS Lee" <geek00l at gmail.com>
Subject:  Re: [Bro] Rotate log time issue - bro seg fault
To:  "Vern Paxson" <vern at icir.org>
Cc:  bro at icsi.berkeley.edu

------=_Part_17020_2333909.1190177423900
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi Vern,

The patch works! There's no more segfault after the patch is applied.

Thanks.

On 9/19/07, Vern Paxson <vern at icir.org> wrote:
>
> > The bro-1.3.2. that we installed having the same revision which is 4657
> -
>
> Ah.  Then please try this one.
>
>                 Vern
>
>
> Index: File.cc
> ===================================================================
> --- File.cc     (revision 4763)
> +++ File.cc     (revision 4773)
> @@ -539,6 +539,9 @@
>
> void BroFile::InstallRotateTimer()
>         {
> +       if ( terminating )
> +               return;
> +
>         if ( rotate_timer )
>                 {
>                 timer_mgr->Cancel(rotate_timer);
>



-- 
Best Regards,

CS Lee<geekooL[at]gmail.com>

------=_Part_17020_2333909.1190177423900
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi Vern,<br><br>The patch works! There&#39;s no more segfault after the patch is applied. <br><br>Thanks.<br><br><div><span class="gmail_quote">On 9/19/07, <b class="gmail_sendername">Vern Paxson</b> &lt;<a href="mailto:vern at icir.org">
vern at icir.org</a>&gt; wrote:</span><blockquote class="gmail_quote" style="margin-top: 0; margin-right: 0; margin-bottom: 0; margin-left: 0; margin-left: 0.80ex; border-left-color: #cccccc; border-left-width: 1px; border-left-style: solid; padding-left: 1ex">
&gt; The bro-1.3.2. that we installed having the same revision which is 4657 -<br><br>Ah.&nbsp;&nbsp;Then please try this one.<br><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Vern<br><br><br>Index: File.cc<br>===================================================================
<br>--- File.cc&nbsp;&nbsp;&nbsp;&nbsp; (revision 4763)<br>+++ File.cc&nbsp;&nbsp;&nbsp;&nbsp; (revision 4773)<br>@@ -539,6 +539,9 @@<br><br> void BroFile::InstallRotateTimer()<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;{<br>+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; if ( terminating )<br>+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; return;<br>+<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;if ( rotate_timer )
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;{<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;timer_mgr-&gt;Cancel(rotate_timer);<br></blockquote></div><br><br clear="all"><br>-- <br>Best Regards,<br><br>CS Lee&lt;geekooL[at]gmail.com&gt; 

------=_Part_17020_2333909.1190177423900--


From pclin at cis.nctu.edu.tw  Mon Nov  5 23:42:17 2007
From: pclin at cis.nctu.edu.tw (Po-Ching Lin)
Date: Tue, 06 Nov 2007 15:42:17 +0800
Subject: [Bro] Segmentation fault when installing a rotate timer in
	BroFile
In-Reply-To: <200711060638.lA66c81d007459@pork.ICSI.Berkeley.EDU>
References: <20071106062257.2F73.PCLIN@cis.nctu.edu.tw>
	<200711060638.lA66c81d007459@pork.ICSI.Berkeley.EDU>
Message-ID: <20071106154054.21F7.PCLIN@cis.nctu.edu.tw>

Thanks, Vern.

The segmentation fault disappears after the patch is applied.

Po-Ching

On Mon, 05 Nov 2007 22:38:06 -0800
Vern Paxson <vern at icir.org> wrote:

> > Program received signal SIGSEGV, Segmentation fault.
> > 0x080eed0d in BroFile::InstallRotateTimer (this=0x90b4030) at File.cc:562
> > 562             timer_mgr->Add(rotate_timer);
> 
> This came up a little while ago on the mailing list.  See if the following
> does the trick.
> 
> 		Vern
> 
> 
> Date:  Wed, 19 Sep 2007 12:50:23 +0800
> From:  "CS Lee" <geek00l at gmail.com>
> Subject:  Re: [Bro] Rotate log time issue - bro seg fault
> To:  "Vern Paxson" <vern at icir.org>
> Cc:  bro at icsi.berkeley.edu
> 
> ------=_Part_17020_2333909.1190177423900
> Content-Type: text/plain; charset=ISO-8859-1
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
> 
> Hi Vern,
> 
> The patch works! There's no more segfault after the patch is applied.
> 
> Thanks.
> 
> On 9/19/07, Vern Paxson <vern at icir.org> wrote:
> >
> > > The bro-1.3.2. that we installed having the same revision which is 4657
> > -
> >
> > Ah.  Then please try this one.
> >
> >                 Vern
> >
> >
> > Index: File.cc
> > ===================================================================
> > --- File.cc     (revision 4763)
> > +++ File.cc     (revision 4773)
> > @@ -539,6 +539,9 @@
> >
> > void BroFile::InstallRotateTimer()
> >         {
> > +       if ( terminating )
> > +               return;
> > +
> >         if ( rotate_timer )
> >                 {
> >                 timer_mgr->Cancel(rotate_timer);

-- 
Po-Ching Lin <pclin at cis.nctu.edu.tw>



From dhanesh at tataelxsi.co.in  Tue Nov  6 20:26:13 2007
From: dhanesh at tataelxsi.co.in (Jaya Dhanesh)
Date: Wed, 7 Nov 2007 09:56:13 +0530
Subject: [Bro] Signtaure Match for TCP packets.
Message-ID: <000a01c820f6$55143350$0637a8c0@telxsi.com>


Hi,

I have problems in signature matching. I have a signature like:

signature tcp_http {
	dst-port == 80
	event "HTTP Packet"
}

This should match all packets sent to port 80 including the handshake
packets. But no match was happening when I sent HTTP traffic.

In RuleMatcher::InitEndpoint, the DO_MATCH_OR is called only if 'ip' (IP_Hdr
*ip) is not NULL. For a TCP packet, the
PIA_TCP::DeliverStream calls DoMatch with ip set to 0. This makes sure that
the match doesn't happen for TCP packets with signatures only with
destination ports. Is there any reason for passing a NULL as the last
parameter for DoMatch?


Thanks,
Dhanesh.


The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments contained in it.

Contact your Administrator for further information.


From adayadil.thomas at gmail.com  Wed Nov  7 11:54:26 2007
From: adayadil.thomas at gmail.com (Adayadil Thomas)
Date: Wed, 7 Nov 2007 14:54:26 -0500
Subject: [Bro] Bro: TCP, regex
Message-ID: <fb7befa20711071154m7b712dd8sa99f1dc0f01c5528@mail.gmail.com>

Greetings.

I have a question regarding bro's analysis.

Consider a TCP connection, as the segments come in they are being
'deliver'ed to different analyzers.
If there are out of order segments, then the TCP Reassembler stores
them and delivers them in order.
Now at the later stages, if a regular expression matching is done,
will it match across different deliveries?
For e.g. if a regex is trying to match across 'N' bytes where N is
large (say 1MB). Is this possible with Bro?
Or the window for matching is smaller?

e.g.

TCP connection established
<start of data> (regular expression partially matched)
<more data>
...1MB data
<end of data> (regular expression match completed)

Is a regular expr match like this possible with bro?


From geek00l at gmail.com  Wed Nov  7 12:29:21 2007
From: geek00l at gmail.com (CS Lee)
Date: Thu, 8 Nov 2007 04:29:21 +0800
Subject: [Bro] Bro Digest, Vol 19, Issue 4
In-Reply-To: <mailman.1.1194465606.5773.bro@ICSI.Berkeley.EDU>
References: <mailman.1.1194465606.5773.bro@ICSI.Berkeley.EDU>
Message-ID: <1bb5dd90711071229xb0037acm89fa43127ba9e729@mail.gmail.com>

Hi Dhanesh,

BPF to the rescue?

-- 
Best Regards,

CS Lee<geekooL[at]gmail.com>

http://geek00l.blogspot.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20071108/57538397/attachment.html 

From robin at icir.org  Wed Nov  7 12:58:05 2007
From: robin at icir.org (Robin Sommer)
Date: Wed, 7 Nov 2007 12:58:05 -0800
Subject: [Bro] Bro: TCP, regex
In-Reply-To: <fb7befa20711071154m7b712dd8sa99f1dc0f01c5528@mail.gmail.com>
References: <fb7befa20711071154m7b712dd8sa99f1dc0f01c5528@mail.gmail.com>
Message-ID: <20071107205804.GA8999@icir.org>


On Wed, Nov 07, 2007 at 14:54 -0500, Adayadil Thomas wrote:

> Now at the later stages, if a regular expression matching is done,
> will it match across different deliveries?

Yes, it will if you're refering to Bro's signatures. Signature
matching is performed on the payload *stream* independent of any
packet boundaries (this is different from Snort, or at least is was
different when I last looked at it; perhaps things have changed
these days). 

On the scripting layer things work a bit different. You can use
regepxs there to match on a string but the string needs to be
available completely at that time. You cannot save the matching
state so that you could later pass in more data. However, that's
usually not a problem because the core already extracts the right
semantic units from the protocols on which you can then match. A
typical example are URLs from HTTP sessions: the core will take care
that a script always sees complete URLs; the stream reassembly
happens before the HTTP decoder extract the URLs. So matching a
regexp on the URL you get from the core will work fine even if in
the original packet stream the URL crosses packet boundaries. 

Robin

-- 
Robin Sommer * Phone +1 (510) 931-5555 * robin at icir.org 
ICSI/LBNL    * Fax   +1 (510) 666-2956 *   www.icir.org


From adayadil.thomas at gmail.com  Wed Nov  7 16:15:52 2007
From: adayadil.thomas at gmail.com (Adayadil Thomas)
Date: Wed, 7 Nov 2007 19:15:52 -0500
Subject: [Bro] Bro: TCP, regex
In-Reply-To: <20071107205804.GA8999@icir.org>
References: <fb7befa20711071154m7b712dd8sa99f1dc0f01c5528@mail.gmail.com>
	<20071107205804.GA8999@icir.org>
Message-ID: <fb7befa20711071615j65103b23tf3481ce7502a2b25@mail.gmail.com>

> Yes, it will if you're refering to Bro's signatures.
..
> On the scripting layer things work a bit different.

Does the Bro signatures work on a different layer than the
scripting/policy layer ?

>Signature
> matching is performed on the payload *stream* independent of any
> packet boundaries (this is different from Snort, or at least is was
> different when I last looked at it; perhaps things have changed
> these days).

In the code, which are the relevant files I need to look to understand
whether this is done like you mentioned?

RE.cc, TCP_Contents.cc ?


Thanks





On Nov 7, 2007 3:58 PM, Robin Sommer <robin at icir.org> wrote:
>
> On Wed, Nov 07, 2007 at 14:54 -0500, Adayadil Thomas wrote:
>
> > Now at the later stages, if a regular expression matching is done,
> > will it match across different deliveries?
>
> Yes, it will if you're refering to Bro's signatures. Signature
> matching is performed on the payload *stream* independent of any
> packet boundaries (this is different from Snort, or at least is was
> different when I last looked at it; perhaps things have changed
> these days).
>
> On the scripting layer things work a bit different. You can use
> regepxs there to match on a string but the string needs to be
> available completely at that time. You cannot save the matching
> state so that you could later pass in more data. However, that's
> usually not a problem because the core already extracts the right
> semantic units from the protocols on which you can then match. A
> typical example are URLs from HTTP sessions: the core will take care
> that a script always sees complete URLs; the stream reassembly
> happens before the HTTP decoder extract the URLs. So matching a
> regexp on the URL you get from the core will work fine even if in
> the original packet stream the URL crosses packet boundaries.
>
> Robin
>
> --
> Robin Sommer * Phone +1 (510) 931-5555 * robin at icir.org
> ICSI/LBNL    * Fax   +1 (510) 666-2956 *   www.icir.org
>


From kanthimyneni at gmail.com  Wed Nov  7 17:35:56 2007
From: kanthimyneni at gmail.com (kanthi myneni)
Date: Wed, 7 Nov 2007 20:35:56 -0500
Subject: [Bro] need help on bro
Message-ID: <6db04b6c0711071735r49abc979n12018d6bf2759ad6@mail.gmail.com>

Thanks for reply.

Actually very recently I started bro on linux. Its working with
installing some missed packages. I am enthusiastic to know how is it
working.

Yeah I mean about anomaly detection. This must have been done based on
some site policies right. What are those policies based on. Like they
vary from site to site right.  How those are taken.

Thanks&Regards,
Kanthi Myneni.


From robin at icir.org  Wed Nov  7 21:21:09 2007
From: robin at icir.org (Robin Sommer)
Date: Wed, 7 Nov 2007 21:21:09 -0800
Subject: [Bro] Bro: TCP, regex
In-Reply-To: <fb7befa20711071615j65103b23tf3481ce7502a2b25@mail.gmail.com>
References: <fb7befa20711071154m7b712dd8sa99f1dc0f01c5528@mail.gmail.com>
	<20071107205804.GA8999@icir.org>
	<fb7befa20711071615j65103b23tf3481ce7502a2b25@mail.gmail.com>
Message-ID: <20071108052109.GB11909@icir.org>


On Wed, Nov 07, 2007 at 19:15 -0500, you wrote:

> Does the Bro signatures work on a different layer than the
> scripting/policy layer ?

Yes, the signature matching is done inside the core. Only if there's
a match, an event is passed to the policy layer.

> In the code, which are the relevant files I need to look to understand
> whether this is done like you mentioned?

The code implementing the signatures is in Rule*.{h,cc}.

Robin

-- 
Robin Sommer * Phone +1 (510) 931-5555 * robin at icir.org 
ICSI/LBNL    * Fax   +1 (510) 666-2956 *   www.icir.org


From robin at icir.org  Wed Nov  7 21:55:02 2007
From: robin at icir.org (Robin Sommer)
Date: Wed, 7 Nov 2007 21:55:02 -0800
Subject: [Bro] Signtaure Match for TCP packets.
In-Reply-To: <000a01c820f6$55143350$0637a8c0@telxsi.com>
References: <000a01c820f6$55143350$0637a8c0@telxsi.com>
Message-ID: <20071108055502.GG12091@icir.org>


On Wed, Nov 07, 2007 at 09:56 +0530, you wrote:

> signature tcp_http {
> 	dst-port == 80
> 	event "HTTP Packet"
> }
> 
> This should match all packets sent to port 80 including the handshake
> packets. But no match was happening when I sent HTTP traffic.

Just tried it and it works for me.

How exactly are you starting Bro? One random guess: is the packet
filter including HTTP packets? Try running with "-f tcp".

> In RuleMatcher::InitEndpoint, the DO_MATCH_OR is called only if 'ip' (IP_Hdr
> *ip) is not NULL. For a TCP packet, the
> PIA_TCP::DeliverStream calls DoMatch with ip set to 0.

Without double-checking the code, the important thing here is that
for TCP only the first packet of each connection is matched against
the header conditions. This is because the payload-conditions match
streamwise and semantics would be unclear if we'd match against all
packet headers (e.g., what happens if a payload match crosses a
packet boundary but the header-conditions only match one of the two
packets?). So the basic model is that the header conditions pick out
the *connections* on which then payload matching is performed. 

Robin

-- 
Robin Sommer * Phone +1 (510) 931-5555 * robin at icir.org 
ICSI/LBNL    * Fax   +1 (510) 666-2956 *   www.icir.org


From jp.luiggi at free.fr  Thu Nov  8 04:42:37 2007
From: jp.luiggi at free.fr (jean-philippe luiggi)
Date: Thu, 8 Nov 2007 07:42:37 -0500
Subject: [Bro] need help on bro
In-Reply-To: <6db04b6c0711071735r49abc979n12018d6bf2759ad6@mail.gmail.com>
References: <6db04b6c0711071735r49abc979n12018d6bf2759ad6@mail.gmail.com>
Message-ID: <20071108074237.6bd82b69@localhost>

Hello,

The "anomaly detection" idea isn't so easy to both
understand and use.

If one disregards concepts as neural networks, SOM, etc. it would
already be necessary to define what is the normality from a network
point of view, which is normal for then giving alarms on what leaves the
framework. 

Best regards,

Jean-philippe.

On Wed, 7 Nov 2007 20:35:56 -0500 "kanthi myneni"
<kanthimyneni at gmail.com> wrote:

> Thanks for reply.
> 
> Actually very recently I started bro on linux. Its working with
> installing some missed packages. I am enthusiastic to know how is it
> working.
> 
> Yeah I mean about anomaly detection. This must have been done based on
> some site policies right. What are those policies based on. Like they
> vary from site to site right.  How those are taken.
> 
> Thanks&Regards,
> Kanthi Myneni.
> _______________________________________________
> Bro mailing list
> bro at bro-ids.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/bro
> 
> 
> 
> 
> 
> !DSPAM:1,47326ac9157913708835974!


From vern at icir.org  Thu Nov  8 08:15:39 2007
From: vern at icir.org (Vern Paxson)
Date: Thu, 08 Nov 2007 08:15:39 -0800
Subject: [Bro] need help on bro
In-Reply-To: <20071108074237.6bd82b69@localhost> (Thu,
	08 Nov 2007 07:42:37 EST).
Message-ID: <200711081615.lA8GFivg009942@pork.ICSI.Berkeley.EDU>

> already be necessary to define what is the normality from a network
> point of view, which is normal for then giving alarms on what leaves the
> framework. 

Yes, this is a powerful approach, and one for which Bro is well suited.
In the research world it's termed specification-based intrusion detection,
but this hasn't yet caught on as a term in the commercial world.

		Vern


From vern at icir.org  Thu Nov  8 12:30:08 2007
From: vern at icir.org (Vern Paxson)
Date: Thu, 08 Nov 2007 12:30:08 -0800
Subject: [Bro] need help on bro
In-Reply-To: (Thu, 08 Nov 2007 08:15:39 PST).
Message-ID: <200711082030.lA8KUD3g015145@pork.ICSI.Berkeley.EDU>

> > already be necessary to define what is the normality from a network
> > point of view, which is normal for then giving alarms on what leaves the
> > framework. 
> 
> Yes, this is a powerful approach, and one for which Bro is well suited.
> In the research world it's termed specification-based intrusion detection,
> but this hasn't yet caught on as a term in the commercial world.

Let me be a bit more precise.  You don't define what is *normal*, but
rather what is *allowed* (including rare-but-okay forms of activity).
So you form a specification of allowed behavior and flag any activity
that doesn't comply with it.

The main drawback of this approach is that it takes considerable manual
effort to form the specifications and keep them up to date.  (If instead
you automatically learn the specifications, then you're back to doing
anomaly detection.)

		Vern


From jp.luiggi at free.fr  Thu Nov  8 18:38:59 2007
From: jp.luiggi at free.fr (jean-philippe luiggi)
Date: Thu, 8 Nov 2007 21:38:59 -0500
Subject: [Bro] need help on bro
In-Reply-To: <200711082030.lA8KUD3g015145@pork.ICSI.Berkeley.EDU>
References: <200711082030.lA8KUD3g015145@pork.ICSI.Berkeley.EDU>
Message-ID: <20071108213859.35ee02e6@localhost>

Hello Everybody,

On Thu, 08 Nov 2007 12:30:08 -0800
Vern Paxson <vern at icir.org> wrote:

> > > already be necessary to define what is the normality from a
> > > network point of view, which is normal for then giving alarms on
> > > what leaves the framework. 
> > 
> > Yes, this is a powerful approach, and one for which Bro is well
> > suited. In the research world it's termed specification-based
> > intrusion detection, but this hasn't yet caught on as a term in the
> > commercial world.
> 
> Let me be a bit more precise.  You don't define what is *normal*, but
> rather what is *allowed* (including rare-but-okay forms of activity).
> So you form a specification of allowed behavior and flag any activity
> that doesn't comply with it.

Ok, i understand the difference and this makes sense.

> The main drawback of this approach is that it takes considerable
> manual effort to form the specifications and keep them up to date.

Yes, it's the same drawback as of signature's NIDS i think (considering
the rules as specifications).
And it's why i use Bro for some times. :-)

> (If instead you automatically learn the specifications, then you're
> back to doing anomaly detection.)

Speaking of specifications here, do you mean all the traffic ?

In all the cases with approachs likes this, we may have to make
corrections as with neural networks for example (where we'll have to
specify upon a result if it's correct or not).

Best regards,

Jean-philippe.




From vern at icir.org  Fri Nov  9 00:30:11 2007
From: vern at icir.org (Vern Paxson)
Date: Fri, 09 Nov 2007 00:30:11 -0800
Subject: [Bro] need help on bro
In-Reply-To: <20071108213859.35ee02e6@localhost> (Thu,
	08 Nov 2007 21:38:59 EST).
Message-ID: <200711090830.lA98UGl1025832@pork.ICSI.Berkeley.EDU>

> Yes, it's the same drawback as of signature's NIDS i think (considering
> the rules as specifications).

Pretty much.  Two differences are (1) signatures are easy to share, since
they describe attacks, while specifications aren't, since they describe
local environments, and (2) signatures are bad at detecting unknown types
of attack, while specifications can do this quite well.

> Speaking of specifications here, do you mean all the traffic ?

Yes, ideally.

> In all the cases with approachs likes this, we may have to make
> corrections as with neural networks for example (where we'll have to
> specify upon a result if it's correct or not).

Well, then it starts drifting away from specification-based and towards
anomaly detection.  In true specification-based intrusion detection,
corrections are done manually, to ensure they correspond with intended
specification updates.

		Vern


From jean-philippe.luiggi at didconcept.com  Fri Nov  9 04:34:05 2007
From: jean-philippe.luiggi at didconcept.com (jean-philippe luiggi)
Date: Fri, 9 Nov 2007 07:34:05 -0500
Subject: [Bro] need help on bro
In-Reply-To: <200711090830.lA98UGl1025832@pork.ICSI.Berkeley.EDU>
References: <20071108213859.35ee02e6@localhost>
	<200711090830.lA98UGl1025832@pork.ICSI.Berkeley.EDU>
Message-ID: <20071109073405.58c0c7c7@localhost>

On Fri, 09 Nov 2007 00:30:11 -0800
Vern Paxson <vern at icir.org> wrote:

> > Yes, it's the same drawback as of signature's NIDS i think
> > (considering the rules as specifications).
> 
> Pretty much.  Two differences are (1) signatures are easy to share,
> since they describe attacks, while specifications aren't, since they
> describe local environments, and (2) signatures are bad at detecting
> unknown types of attack, while specifications can do this quite well.

Sure, it's why i really like the approach used by Bro and specifically
the use of policies. With them, i'm able to define my environment and
to regulate the parameters of detection compared to this last.

> > In all the cases with approachs likes this, we may have to make
> > corrections as with neural networks for example (where we'll have to
> > specify upon a result if it's correct or not).
> 
> Well, then it starts drifting away from specification-based and
> towards anomaly detection.  In true specification-based intrusion
> detection, corrections are done manually, to ensure they correspond
> with intended specification updates.

I agree with you, i was not rather precise in my remarks and was
speaking of anomaly-based detection using something likes ANN
(artificial neural network). :-)

I guess you may have some traffic at Berkeley so how do you manage
defining "allowed" things ?
At first a cartography of flows has being made, then you choose to
"allow" a few of them  and build the specifications ?

Best regards,

Jean-philippe.


From diogo_c at brturbo.com.br  Fri Nov  9 09:15:44 2007
From: diogo_c at brturbo.com.br (Diogo Corteletti de Oliveira)
Date: Fri, 09 Nov 2007 14:15:44 -0300
Subject: [Bro] HTTP Question
In-Reply-To: <mailman.1.1194465606.5773.bro@ICSI.Berkeley.EDU>
References: <mailman.1.1194465606.5773.bro@ICSI.Berkeley.EDU>
Message-ID: <473495C0.4030104@brturbo.com.br>

Hello,

            Can BRO alarm on non-http traffic over port 80?


From jp.luiggi at free.fr  Fri Nov  9 10:54:03 2007
From: jp.luiggi at free.fr (Jean-Philippe Luiggi)
Date: Fri, 09 Nov 2007 13:54:03 -0500
Subject: [Bro] HTTP Question
In-Reply-To: <473495C0.4030104@brturbo.com.br>
References: <mailman.1.1194465606.5773.bro@ICSI.Berkeley.EDU>
	<473495C0.4030104@brturbo.com.br>
Message-ID: <4734ACCB.7050208@free.fr>

Diogo Corteletti de Oliveira a ?crit :
> Hello,
>
>             Can BRO alarm on non-http traffic over port 80?
> _______________________________________________
> Bro mailing list
> bro at bro-ids.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/bro
>   

Hello Diogo,

I think so if you use DPD (dynamic protocol detection).
Please note there's already a file "detect-protocols.bro" which
is able to find connections with protocols on non-standard ports.

Best regards,

Jean-philippe.



From jp.luiggi at free.fr  Fri Nov  9 10:54:19 2007
From: jp.luiggi at free.fr (Jean-Philippe Luiggi)
Date: Fri, 09 Nov 2007 13:54:19 -0500
Subject: [Bro] HTTP Question
In-Reply-To: <473495C0.4030104@brturbo.com.br>
References: <mailman.1.1194465606.5773.bro@ICSI.Berkeley.EDU>
	<473495C0.4030104@brturbo.com.br>
Message-ID: <4734ACDB.90009@free.fr>

Diogo Corteletti de Oliveira a ?crit :
> Hello,
>
>             Can BRO alarm on non-http traffic over port 80?
> _______________________________________________
> Bro mailing list
> bro at bro-ids.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/bro
>   

Hello Diogo,

I think so if you use DPD (dynamic protocol detection).
Please note there's already a file "detect-protocols.bro" which
is able to find connections with protocols on non-standard ports.

Best regards,

Jean-philippe.



From jp.luiggi at free.fr  Fri Nov  9 10:55:58 2007
From: jp.luiggi at free.fr (Jean-Philippe Luiggi)
Date: Fri, 09 Nov 2007 13:55:58 -0500
Subject: [Bro] HTTP Question
In-Reply-To: <473495C0.4030104@brturbo.com.br>
References: <mailman.1.1194465606.5773.bro@ICSI.Berkeley.EDU>
	<473495C0.4030104@brturbo.com.br>
Message-ID: <4734AD3E.3020501@free.fr>

Diogo Corteletti de Oliveira a ?crit :
> Hello,
>
>             Can BRO alarm on non-http traffic over port 80?
> _______________________________________________
> Bro mailing list
> bro at bro-ids.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/bro
>
>
>
>
>
> !DSPAM:1,47349958153933285824817!
>   
Hello Diogo,
I think so if you use DPD (dynamic protocol detection).
Please note there's already a file "detect-protocols.bro" which
is able to find connections with protocols on non-standard ports.

Best regards,

Jean-philippe



From jp.luiggi at free.fr  Fri Nov  9 11:00:56 2007
From: jp.luiggi at free.fr (Jean-Philippe Luiggi)
Date: Fri, 09 Nov 2007 14:00:56 -0500
Subject: [Bro] HTTP Question
In-Reply-To: <473495C0.4030104@brturbo.com.br>
References: <mailman.1.1194465606.5773.bro@ICSI.Berkeley.EDU>
	<473495C0.4030104@brturbo.com.br>
Message-ID: <4734AE68.70402@free.fr>

Diogo Corteletti de Oliveira a ?crit :
> Hello,
>
>             Can BRO alarm on non-http traffic over port 80?
> _______________________________________________
> Bro mailing list
> bro at bro-ids.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/bro
>
>
>
>
>
> !DSPAM:1,47349958153933285824817!
>   
Hello Diogo,

I think so if you use DPD (dynamic protocol detection).
Please note there's already a file "detect-protocols.bro" which
is able to find connections with protocols on non-standard ports.

Best regards,

Jean-philippe.


From diogo_c at brturbo.com.br  Fri Nov  9 11:02:09 2007
From: diogo_c at brturbo.com.br (Diogo Corteletti de Oliveira)
Date: Fri, 09 Nov 2007 16:02:09 -0300
Subject: [Bro] HTTP Question
In-Reply-To: <4734AD3E.3020501@free.fr>
References: <mailman.1.1194465606.5773.bro@ICSI.Berkeley.EDU>
	<473495C0.4030104@brturbo.com.br> <4734AD3E.3020501@free.fr>
Message-ID: <4734AEB1.7050904@brturbo.com.br>

Yeah! You are right there's also "detect-protocols-http.bro"


Jean-Philippe Luiggi escreveu:
> Diogo Corteletti de Oliveira a ?crit :
>> Hello,
>>
>>             Can BRO alarm on non-http traffic over port 80?
>> _______________________________________________
>> Bro mailing list
>> bro at bro-ids.org
>> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/bro
>>
>>
>>
>>
>>
>> !DSPAM:1,47349958153933285824817!
>>   
> Hello Diogo,
> I think so if you use DPD (dynamic protocol detection).
> Please note there's already a file "detect-protocols.bro" which
> is able to find connections with protocols on non-standard ports.
>
> Best regards,
>
> Jean-philippe
>
>
>



From jp.luiggi at free.fr  Fri Nov  9 11:06:11 2007
From: jp.luiggi at free.fr (Jean-Philippe Luiggi)
Date: Fri, 09 Nov 2007 14:06:11 -0500
Subject: [Bro] HTTP Question
In-Reply-To: <473495C0.4030104@brturbo.com.br>
References: <mailman.1.1194465606.5773.bro@ICSI.Berkeley.EDU>
	<473495C0.4030104@brturbo.com.br>
Message-ID: <4734AFA3.9010007@free.fr>

Diogo Corteletti de Oliveira a ?crit :
> Hello,
>
>             Can BRO alarm on non-http traffic over port 80?
> _______________________________________________
> Bro mailing list
> bro at bro-ids.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/bro
>
>
>
>
>
> !DSPAM:1,47349958153933285824817!
>   
Hello Diogo,

I think so if you use DPD (dynamic protocol detection).
Please note there's already a file "detect-protocols.bro" which
is able to find connections with protocols on non-standard ports.

Best regards,

Jean-philippe.


From nweaver at ICSI.Berkeley.EDU  Fri Nov  9 11:06:11 2007
From: nweaver at ICSI.Berkeley.EDU (Nicholas Weaver)
Date: Fri, 9 Nov 2007 11:06:11 -0800
Subject: [Bro] HTTP Question
In-Reply-To: <4734ACDB.90009@free.fr>
References: <mailman.1.1194465606.5773.bro@ICSI.Berkeley.EDU>
	<473495C0.4030104@brturbo.com.br> <4734ACDB.90009@free.fr>
Message-ID: <20071109190611.GA27972@kona.ICSI.Berkeley.EDU>

On Fri, Nov 09, 2007 at 01:54:19PM -0500, Jean-Philippe Luiggi composed:
> Diogo Corteletti de Oliveira a ?crit :
> > Hello,
> >
> >             Can BRO alarm on non-http traffic over port 80?
> > _______________________________________________
> > Bro mailing list
> > bro at bro-ids.org
> > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/bro
> >   
> 
> Hello Diogo,
> 
> I think so if you use DPD (dynamic protocol detection).
> Please note there's already a file "detect-protocols.bro" which
> is able to find connections with protocols on non-standard ports.
> 
> Best regards,
> 
> Jean-philippe.


Note also to make this more reliable, you should set dpd_buffer_size
to a significantly longer size, otherwise larger POST requests may not
be recognized.

EG,

redef dpd_buffer_size = 4096; 
or
redef dpd_buffer_size = 10000; 

-- 
Nicholas C. Weaver                               nweaver at icsi.berkeley.edu
     This message has been ROT-13 encrypted twice for higher security.


From jp.luiggi at free.fr  Fri Nov  9 12:28:09 2007
From: jp.luiggi at free.fr (Jean-Philippe Luiggi)
Date: Fri, 09 Nov 2007 15:28:09 -0500
Subject: [Bro] HTTP Question
In-Reply-To: <20071109190611.GA27972@kona.ICSI.Berkeley.EDU>
References: <mailman.1.1194465606.5773.bro@ICSI.Berkeley.EDU>
	<473495C0.4030104@brturbo.com.br> <4734ACDB.90009@free.fr>
	<20071109190611.GA27972@kona.ICSI.Berkeley.EDU>
Message-ID: <4734C2D9.7070303@free.fr>

Nicholas Weaver a ?crit :
> On Fri, Nov 09, 2007 at 01:54:19PM -0500, Jean-Philippe Luiggi composed:
>   
>> Diogo Corteletti de Oliveira a ?crit :
>>     
>>> Hello,
>>>
>>>             Can BRO alarm on non-http traffic over port 80?
>>> _______________________________________________
>>> Bro mailing list
>>> bro at bro-ids.org
>>> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/bro
>>>   
>>>       
>> Hello Diogo,
>>
>> I think so if you use DPD (dynamic protocol detection).
>> Please note there's already a file "detect-protocols.bro" which
>> is able to find connections with protocols on non-standard ports.
>>
>> Best regards,
>>
>> Jean-philippe.
>>     
>
>
> Note also to make this more reliable, you should set dpd_buffer_size
> to a significantly longer size, otherwise larger POST requests may not
> be recognized.
>
> EG,
>
> redef dpd_buffer_size = 4096; 
> or
> redef dpd_buffer_size = 10000; 
>
>   
Hello,

Thank you for pointing out this information, i missed it (much more, i 
didn't think about this problem).

Best regards,

Jean-philippe.



From jp.luiggi at free.fr  Fri Nov  9 12:39:27 2007
From: jp.luiggi at free.fr (Jean-Philippe Luiggi)
Date: Fri, 09 Nov 2007 15:39:27 -0500
Subject: [Bro] HTTP Question
In-Reply-To: <4734AEB1.7050904@brturbo.com.br>
References: <mailman.1.1194465606.5773.bro@ICSI.Berkeley.EDU>
	<473495C0.4030104@brturbo.com.br> <4734AD3E.3020501@free.fr>
	<4734AEB1.7050904@brturbo.com.br>
Message-ID: <4734C57F.90300@free.fr>

Diogo Corteletti de Oliveira a ?crit :
> Yeah! You are right there's also "detect-protocols-http.bro"
>> Hello Diogo,
>> I think so if you use DPD (dynamic protocol detection).
>> Please note there's already a file "detect-protocols.bro" which
>> is able to find connections with protocols on non-standard ports.
>>
>> Best regards,
>>
>> Jean-philippe

Hello Diego,

Yes, that's right, this one loads "detect-protocols.bro"
In fact, i think specifying the use of "dpd" in "brolite.bro" will give 
all the things you want :

from brolite.bro :
====
## Dynamic Protocol Detection configuration
#
# This is off by default, as it requires a more powerful Bro host.
# Uncomment next line to activate.
const use_dpd = T;

@ifdef ( use_dpd )
        @load dpd
        @load irc-bot
        @load dyn-disable
        @load detect-protocols
        @load detect-protocols-http
        @load proxy
        @load ssh

        # By default, DPD looks at all traffic except port 80.
        # For lightly loaded networks, comment out the restrict_filters 
line.
        # For heavily loaded networks, try adding addition ports (e.g., 
25) to
        #   the restrict filters.
        redef capture_filters += [ ["tcp"] = "tcp" ];
        redef restrict_filters += [ ["not-http"] = "not (port 80)" ];
@endif
====

Best regards,

Jean-philippe.




From geek00l at gmail.com  Sat Nov 10 23:08:54 2007
From: geek00l at gmail.com (CS Lee)
Date: Sun, 11 Nov 2007 15:08:54 +0800
Subject: [Bro] Baselining: The foundation of Specification Based IDS
Message-ID: <1bb5dd90711102308j63a87b90we3406ceac76934f3@mail.gmail.com>

Hi all,

I like the idea of specification based IDS, and since Vern has mentioned
about it, I would like to gather the idea or suggestion of anyone who has
done network baselining for their network, what are the tools and
methodologies used by people around here to build the baseline of their
network, and what kind of data are important for that matter(for example I
myself prefer to use statistical and flow based tools to do that) however I
really like to hear from the bro community.

I know it should be different when applying on different networks but
getting the idea is great.

Thanks.

-- 
Best Regards,

CS Lee<geekooL[at]gmail.com>

http://geek00l.blogspot.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20071111/e6ce02ab/attachment.html 

From jean-philippe.luiggi at didconcept.com  Sun Nov 11 07:23:15 2007
From: jean-philippe.luiggi at didconcept.com (jean-philippe luiggi)
Date: Sun, 11 Nov 2007 10:23:15 -0500
Subject: [Bro] Baselining: The foundation of Specification Based IDS
In-Reply-To: <1bb5dd90711102308j63a87b90we3406ceac76934f3@mail.gmail.com>
References: <1bb5dd90711102308j63a87b90we3406ceac76934f3@mail.gmail.com>
Message-ID: <20071111102315.1fb5fa55@localhost>

On Sun, 11 Nov 2007 15:08:54 +0800
"CS Lee" <geek00l at gmail.com> wrote:

> Hi all,
> 
> I like the idea of specification based IDS, and since Vern has
> mentioned about it, I would like to gather the idea or suggestion of
> anyone who has done network baselining for their network, what are
> I know it should be different when applying on different networks but
> getting the idea is great.

Hello everybody,

As announced by Vern, to use specifications is a very good method and
the concepts used by Bro show their interest fully. 
For me the specifications go first of all by a phase of
recognition to the direction training of what exists.
The problem within the framework of campus or corporate networks is
that the environment should already be known because it may be that
needs (speaking of networks flows) exist and who seem us odd while
being legitimate. 
If in the case of a local area network, to obtain information is more
or less easy, in the case of distant sites, it is less obvious. 
In this case, i used Netflow technology which enabled me to check
what occurred and then allow me to act.

Please note that i used statisticals methods over the Netflow data in
order to get accurate results (i had more than 100 routers/switchs).

Best regards,

Jean-philippe.


From diogo_c at brturbo.com.br  Mon Nov 12 10:02:02 2007
From: diogo_c at brturbo.com.br (Diogo Corteletti de Oliveira)
Date: Mon, 12 Nov 2007 15:02:02 -0300
Subject: [Bro] Bro Alarms
In-Reply-To: <4734C57F.90300@free.fr>
References: <mailman.1.1194465606.5773.bro@ICSI.Berkeley.EDU>
	<473495C0.4030104@brturbo.com.br> <4734AD3E.3020501@free.fr>
	<4734AEB1.7050904@brturbo.com.br> <4734C57F.90300@free.fr>
Message-ID: <4738951A.6040605@brturbo.com.br>

Hello Guys,

                        One more question. After enabling the DPD and 
filtering it to only consider events on port 80 I am getting a lot of 
alarms for Google connections like the one bellow:

t=1194889271.174088 no=ProtocolViolation na=NOTICE_ALARM_ALWAYS 
sa=x.x.x.x sp=4421/tcp da=209.85.165.189 dp=80/tcp msg=x.x.x.x/4421\ >\ 
209.85.165.189/http\ analyzer\ HTTP\ disabled\ due\ to\ protocol\ 
violation sub=not\ a\ http\ reply\ line tag=@877

                         I am assuming that this is an alert that could 
inform that someone is using a different protocol (not-http) on port 80. 
My objective (as stated in a previous e-mail) is to detect such a thing. 
The strange thing is that I tried to do this before with SourceFire's 
RNA and it alerted with google connections also. Could this mean that 
Google does not follow the HTTP RFC? Any suggestions?


Tks


From vern at icir.org  Mon Nov 12 10:12:35 2007
From: vern at icir.org (Vern Paxson)
Date: Mon, 12 Nov 2007 10:12:35 -0800
Subject: [Bro] Bro Alarms
In-Reply-To: <4738951A.6040605@brturbo.com.br> (Mon,
	12 Nov 2007 15:02:02 -0300).
Message-ID: <200711121812.lACICe4j016029@pork.ICSI.Berkeley.EDU>

> Could this mean that 
> Google does not follow the HTTP RFC? Any suggestions?

As usual with puzzles like this, the next step is to capture a trace that
reproduces the problem, and, if possible, send it to us or the list.

		Vern


From diogo_c at brturbo.com.br  Mon Nov 12 11:39:48 2007
From: diogo_c at brturbo.com.br (Diogo Corteletti de Oliveira)
Date: Mon, 12 Nov 2007 16:39:48 -0300
Subject: [Bro] Bro Alarms
In-Reply-To: <200711121812.lACICe4j016029@pork.ICSI.Berkeley.EDU>
References: <200711121812.lACICe4j016029@pork.ICSI.Berkeley.EDU>
Message-ID: <4738AC04.2090408@brturbo.com.br>

Vern,

             I've noticed that the alarms are been triggered with a 
normal conection to gmail. Do you need the entire trace ? From the 
Handshake to the FIN?

Vern Paxson escreveu:
>> Could this mean that 
>> Google does not follow the HTTP RFC? Any suggestions?
>>     
>
> As usual with puzzles like this, the next step is to capture a trace that
> reproduces the problem, and, if possible, send it to us or the list.
>
> 		Vern
>
>
>   



From vern at icir.org  Mon Nov 12 12:36:27 2007
From: vern at icir.org (Vern Paxson)
Date: Mon, 12 Nov 2007 12:36:27 -0800
Subject: [Bro] Bro Alarms
In-Reply-To: <4738AC04.2090408@brturbo.com.br> (Mon,
	12 Nov 2007 16:39:48 -0300).
Message-ID: <200711122036.lACKaWDM018887@pork.ICSI.Berkeley.EDU>

>              I've noticed that the alarms are been triggered with a 
> normal conection to gmail. Do you need the entire trace ? From the 
> Handshake to the FIN?

In general, yes, otherwise Bro isn't going to process it when run
off-line.

		Vern


From kanthimyneni at gmail.com  Wed Nov 14 07:40:52 2007
From: kanthimyneni at gmail.com (kanthi myneni)
Date: Wed, 14 Nov 2007 10:40:52 -0500
Subject: [Bro] doubt regarding notice alarm always
Message-ID: <6db04b6c0711140740t45862ce6xd5896623b33146d6@mail.gmail.com>

Hi,

I Started a server on the machine(system 1) where bro is running. I
tried to access to that from other  system (system 2).

I observed that it is logged as notice alarm always like

t=1195051259.323269 no=HTTP_SensitiveURI na=NOTICE_ALARM_ALWAYS
sa=157.182.235.186 da=157.182.235.207 method=GET url=/icons/blank.gif
msg=157.182.235.186\ ->\ 157.182.235.207\ %232:\ <no\ reply>

t=1195051259.323269 no=HTTP_SensitiveURI na=NOTICE_ALARM_ALWAYS
sa=157.182.235.186 da=157.182.235.207 method=GET url=/icons/folder.gif
msg=157.182.235.186\ ->\ 157.182.235.207\ %232:\ <no\ reply>

Here system 1 is 157.182.235.207 and system 2 is 157.182.235.186

Few questions regarding the above data

1. On what based it is logged as notice alarm always.

2. I think t stand for time... can I know in what format it is logged.

3. msg=157.182.235.186\ ->\ 157.182.235.207\ %232: in this message
what is %232. Is that is session id.

4. I am getting as 2 different url like url=/icons/folder.gif and
url=/icons/blank.gif why is it logging so.

Sorry to take your valuable time.

Thanks & Regards,
Kanthi.


From kanthimyneni at gmail.com  Wed Nov 14 09:58:22 2007
From: kanthimyneni at gmail.com (kanthi myneni)
Date: Wed, 14 Nov 2007 12:58:22 -0500
Subject: [Bro] need help on bro
In-Reply-To: <20071109073405.58c0c7c7@localhost>
References: <20071108213859.35ee02e6@localhost>
	<200711090830.lA98UGl1025832@pork.ICSI.Berkeley.EDU>
	<20071109073405.58c0c7c7@localhost>
Message-ID: <6db04b6c0711140958l1f2efc40t83fa443f0bb32788@mail.gmail.com>

Hi,

Much more specific into specification based.  Like if there is one
specification "a
valid SMTP greeting is no longer than NN bytes long . We need to know
that NN bytes. Similiarly I believe that there are some specifications
built in bro. Is there any way to know more about those specifications
like how threshold is set... Can any one suggest me any reference
which will help me know more about this stuff...

Thanks&Regards,
KAnthi.

On Nov 9, 2007 7:34 AM, jean-philippe luiggi
<jean-philippe.luiggi at didconcept.com> wrote:
> On Fri, 09 Nov 2007 00:30:11 -0800
> Vern Paxson <vern at icir.org> wrote:
>
> > > Yes, it's the same drawback as of signature's NIDS i think
> > > (considering the rules as specifications).
> >
> > Pretty much.  Two differences are (1) signatures are easy to share,
> > since they describe attacks, while specifications aren't, since they
> > describe local environments, and (2) signatures are bad at detecting
> > unknown types of attack, while specifications can do this quite well.
>
> Sure, it's why i really like the approach used by Bro and specifically
> the use of policies. With them, i'm able to define my environment and
> to regulate the parameters of detection compared to this last.
>
> > > In all the cases with approachs likes this, we may have to make
> > > corrections as with neural networks for example (where we'll have to
> > > specify upon a result if it's correct or not).
> >
> > Well, then it starts drifting away from specification-based and
> > towards anomaly detection.  In true specification-based intrusion
> > detection, corrections are done manually, to ensure they correspond
> > with intended specification updates.
>
> I agree with you, i was not rather precise in my remarks and was
> speaking of anomaly-based detection using something likes ANN
> (artificial neural network). :-)
>
> I guess you may have some traffic at Berkeley so how do you manage
> defining "allowed" things ?
> At first a cartography of flows has being made, then you choose to
> "allow" a few of them  and build the specifications ?
>
> Best regards,
>
> Jean-philippe.
>


From kanthimyneni at gmail.com  Wed Nov 14 10:00:39 2007
From: kanthimyneni at gmail.com (kanthi myneni)
Date: Wed, 14 Nov 2007 13:00:39 -0500
Subject: [Bro] About Specification Based detection
Message-ID: <6db04b6c0711141000t3d370a93s25c879d1706bb2f5@mail.gmail.com>

Hi,

Much more specific into specification based.  Like if there is one
specification "a
valid SMTP greeting is no longer than NN bytes long . We need to know
that NN bytes. Similiarly I believe that there are some specifications
built in bro. Is there any way to know more about those specifications
like how threshold is set... Can any one suggest me any reference
which will help me know more about this stuff...

Thanks&Regards,
KAnthi.


From robin at icir.org  Wed Nov 14 17:09:51 2007
From: robin at icir.org (Robin Sommer)
Date: Wed, 14 Nov 2007 17:09:51 -0800
Subject: [Bro] doubt regarding notice alarm always
In-Reply-To: <6db04b6c0711140740t45862ce6xd5896623b33146d6@mail.gmail.com>
References: <6db04b6c0711140740t45862ce6xd5896623b33146d6@mail.gmail.com>
Message-ID: <20071115010950.GA6634@icir.org>


On Wed, Nov 14, 2007 at 10:40 -0500, kanthi myneni wrote:

> 1. On what based it is logged as notice alarm always.

NOTICE_ALARM_ALWAYS is the default if you don't define anything
else. You can change what an alert is mapped to by defining a
notice_policy; see notice-policy.bro for examples.

> 2. I think t stand for time... can I know in what format it is logged.

It's seconds since Jan 1 1970. Bro comes with a tool in aux/cf which
converts them into human-readable:

         > echo "1195051259.323269" |  ./cf
         Nov 14 06:40:59

> 3. msg=157.182.235.186\ ->\ 157.182.235.207\ %232: in this message
> what is %232. Is that is session id.

Correct.

> 4. I am getting as 2 different url like url=/icons/folder.gif and
> url=/icons/blank.gif why is it logging so.

Seems that both match HTTP::sensitive_URIs. Have you changed the
default for that?

Robin

-- 
Robin Sommer * Phone +1 (510) 931-5555 * robin at icir.org 
ICSI/LBNL    * Fax   +1 (510) 666-2956 *   www.icir.org


From irdeto at gmail.com  Mon Nov 19 03:45:15 2007
From: irdeto at gmail.com (Fabian Hensel)
Date: Mon, 19 Nov 2007 12:45:15 +0100
Subject: [Bro] Unable to debug policies
Message-ID: <a1bcc3160711190345p4f3145dbvbc66e194c1ccd320@mail.gmail.com>

Hi

I am trying to debug policy files with the -d parameter (version
1.3.2). When I try to enter any debug command ("b
connection_established" in the example), it gets misinterpreted and I
get output similar to this:

root at idsvmifi:/home/irdeto98/bro-1.3.2/out# bin/bro -i eth0 -d brolite
Policy file debugging ON.
listening on eth0
In bro_init() at policy/pcap.bro:99
99              update_default_pcap_filter();
(Bro [0]) b connection_established
Breakpoint 1 set at policy/pcap.bro:99
Ambiguous command; could be
        continue
        cond
No Matching command for 'nn'.
No Matching command for 'ec'.
No Matching command for 'ti'.
No Matching command for 'on'.
No Matching command for '_e'.
In update_default_pcap_filter() at policy/pcap.bro:86
86              default_pcap_filter = build_default_pcap_filter();
No Matching command for 'ab'.
82      global default_pcap_filter = "<not set>";
83
84      function update_default_pcap_filter()
85              {
86              default_pcap_filter = build_default_pcap_filter();
87
88              if ( ! precompile_pcap_filter(DefaultPcapFilter,
default_pcap_filter) )
89                       {
90                       print fmt("can't compile filter %s",
default_pcap_filter);
91                       exit();
No Matching command for 'sh'.
No Matching command for 'ed'.
Ambiguous command; could be
        help
        quit
        next
        s
        c
        finish
        b
        cond
        d
        clear
        dis
        enable
        ignore
        set
        where
        frame
        up
        down
        info
        l
        display
        undisplay
        trace
(Bro [1]) (Bro [2]) (Bro [3]) (Bro [4]) (Bro [5]) (Bro [6]) (Bro [7])
(Bro [8]) (Bro [9]) (Bro [10]) (Bro [11]) (Bro [12]) (Bro [13])

Running on Ubuntu 7.10. Anyone have an idea what is wrong? My
suspicion is something with termcap/ncurses...

Regards - Fabian


From vern at icir.org  Mon Nov 26 18:17:46 2007
From: vern at icir.org (Vern Paxson)
Date: Mon, 26 Nov 2007 18:17:46 -0800
Subject: [Bro] Unable to debug policies
In-Reply-To: <a1bcc3160711190345p4f3145dbvbc66e194c1ccd320@mail.gmail.com>
	(Mon, 19 Nov 2007 12:45:15 +0100).
Message-ID: <200711270217.lAR2Hpqe013868@pork.ICSI.Berkeley.EDU>

> (Bro [0]) b connection_established
> Breakpoint 1 set at policy/pcap.bro:99
> Ambiguous command; could be
>         continue
>         cond
> No Matching command for 'nn'.
> No Matching command for 'ec'.
> No Matching command for 'ti'.
> No Matching command for 'on'.

This indeed looks familiar (though doesn't reproduce for me running
on MacOS 10.4).

> Running on Ubuntu 7.10. Anyone have an idea what is wrong? My
> suspicion is something with termcap/ncurses...

I suspect you're right.  Can you send us your config.log as a starting
point?

		Vern


From christian at whoop.org  Wed Nov 28 11:39:08 2007
From: christian at whoop.org (Christian Kreibich)
Date: Wed, 28 Nov 2007 11:39:08 -0800
Subject: [Bro] The Bro wiki is currently down for maintenance.
Message-ID: <1196278748.2761.409.camel@strangepork>

We apologize for any inconvenience caused.

Cheers,
Christian
-- 
________________________________________________________________________
                                           http://www.icir.org/christian
                                                    http://www.whoop.org



From muscletot at gmail.com  Thu Nov 29 11:01:49 2007
From: muscletot at gmail.com (Mike Wood)
Date: Thu, 29 Nov 2007 11:01:49 -0800
Subject: [Bro] a tree structure with Bro records
Message-ID: <7f3e32390711291101h6ac48ec7ka65f73901b9e5d3f@mail.gmail.com>

Hello,

I would like to build a tree data structure to track flows at
different aggregate granularities. However, I cannot seem to construct
a recursive record structure.

The following...

type tree_node : record {
    data : count;
    parent : tree_node;
};

... will lead to...

$ bro tree.bro
./tree.bro, line 3 and ./tree.bro, line 5
   (tree_node): error, not a BRO type

... and changing the parent type to 'any' and doing anything w/ the record...

type tree_node : record {
    data : count;
    parent : any;
};

event bro_init () {
    local tn : tree_node;
    tn$data = 0;
    tn$parent = tn;
}

... will lead to...

$ bro tree.bro
./tree.bro, line 12 (tn$parent = tn): error, type clash in assignment

... because you cannot assign to 'any' type variables, I guess.


So... just wondering if there is some other scheme / mechanism to
build such a tree in Bro, or am I just out-of-luck.

Thanks,
Mike


From vern at icir.org  Fri Nov 30 09:52:01 2007
From: vern at icir.org (Vern Paxson)
Date: Fri, 30 Nov 2007 09:52:01 -0800
Subject: [Bro] a tree structure with Bro records
In-Reply-To: <7f3e32390711291101h6ac48ec7ka65f73901b9e5d3f@mail.gmail.com>
	(Thu, 29 Nov 2007 11:01:49 PST).
Message-ID: <200711301752.lAUHq6iQ006615@pork.ICSI.Berkeley.EDU>

> So... just wondering if there is some other scheme / mechanism to
> build such a tree in Bro, or am I just out-of-luck.

I'm afraid closer to just-out-of-luck.

You could fake it up using table[string] of XYZ, where XYZ records include
a string that point back into the table.  Not pretty, but seems it should
work.

		Vern


From vern at icir.org  Fri Nov 30 10:01:16 2007
From: vern at icir.org (Vern Paxson)
Date: Fri, 30 Nov 2007 10:01:16 -0800
Subject: [Bro] a tree structure with Bro records
In-Reply-To: (Fri, 30 Nov 2007 09:52:01 PST).
Message-ID: <200711301801.lAUI1LLA006772@pork.ICSI.Berkeley.EDU>

> You could fake it up using table[string] of XYZ, where XYZ records include
> a string that point back into the table.  Not pretty, but seems it should
> work.

(or, slightly easier, a table[count] of XYZ, along with a counter that you
just increment every time you add a new node, which becomes its identifier)


From kanthimyneni at gmail.com  Fri Nov 30 12:05:43 2007
From: kanthimyneni at gmail.com (kanthi myneni)
Date: Fri, 30 Nov 2007 15:05:43 -0500
Subject: [Bro] (no subject)
Message-ID: <6db04b6c0711301205u27aa4dd6rde0b5b9b3bdbc9a5@mail.gmail.com>

Hi,

I am unable to generate dialy reports in bro. it configured and installed
successfully. To which address it will send the reports.

Like in configuring bro

Email addresses for internal reports [bro at localhost]

what type of email address I can provide  here.

It went well in every aspect  except this.  Can you help me generating
reports.

Thanks&Regards,

Kanthi Myneni.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20071130/a5d2ff9b/attachment.html 

From kanthimyneni at gmail.com  Fri Nov 30 12:26:18 2007
From: kanthimyneni at gmail.com (kanthi myneni)
Date: Fri, 30 Nov 2007 15:26:18 -0500
Subject: [Bro] link is not working
Message-ID: <6db04b6c0711301226w48ed2345h43d0ae23aabd917e@mail.gmail.com>

Hi,

In bro-quick start

http://www.bro-ids.org/Bro-quick-start.pdf

In 5th page , the link to the tutorial view graph is not working. It might
be helpful for me in few apects to set up bro.

Thanks&Regards,
Kanthi Myneni.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20071130/43b0a570/attachment.html