From mcholste at gmail.com  Mon Nov  3 20:14:39 2008
From: mcholste at gmail.com (Martin Holste)
Date: Mon, 3 Nov 2008 19:14:39 -0600
Subject: [Discussion] David's Bro Script
Message-ID: <df9074860811031714p617e48der22dfc7a1a9a014d7@mail.gmail.com>

David had a fine post again today <
http://blog.vorant.com/2008/11/detecting-outgoing-connections-from.html>
showing how to make a Bro script from scratch which identified
non-whitelisted traffic.  Could one of the Bro experts show how to take that
and make it able to be dynamically updated at run-time?

Thanks,

Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openinfosecfoundation.org/pipermail/discussion/attachments/20081103/80e523b0/attachment.html

From hall.692 at osu.edu  Mon Nov  3 23:46:49 2008
From: hall.692 at osu.edu (Seth Hall)
Date: Mon, 3 Nov 2008 23:46:49 -0500
Subject: [Discussion] David's Bro Script
In-Reply-To: <df9074860811031714p617e48der22dfc7a1a9a014d7@mail.gmail.com>
References: <df9074860811031714p617e48der22dfc7a1a9a014d7@mail.gmail.com>
Message-ID: <33C24C7A-2865-4DC2-AE51-375620604CA1@osu.edu>


On Nov 3, 2008, at 8:14 PM, Martin Holste wrote:

> David had a fine post again today <http://blog.vorant.com/2008/11/detecting-outgoing-connections-from.html 
> > showing how to make a Bro script from scratch which identified non- 
> whitelisted traffic.  Could one of the Bro experts show how to take  
> that and make it able to be dynamically updated at run-time?


It's update-able through the Bro communications protocol.  If you are  
using the cluster shell, there is an update command that does this for  
you.  You just need to make the changes to your global/const variables  
in your policy scripts and then do the following procedure...

# cluster<return>

   > check
   (check for all to be ok)
   > install
   > update

That *should* then put any updates to global/const variables in  
place.  It's certainly possible to write other scripts that would do  
the same procedure without as well since ultimately all the shell does  
to cause the update process is throw an event through the  
communications protocol.

   .Seth

---
Seth Hall
Network Security - Office of the CIO
The Ohio State University
Phone: 614-292-9721


From david at vorant.com  Tue Nov  4 08:36:24 2008
From: david at vorant.com (David J. Bianco)
Date: Tue, 04 Nov 2008 08:36:24 -0500
Subject: [Discussion] David's Bro Script
In-Reply-To: <33C24C7A-2865-4DC2-AE51-375620604CA1@osu.edu>
References: <df9074860811031714p617e48der22dfc7a1a9a014d7@mail.gmail.com>
	<33C24C7A-2865-4DC2-AE51-375620604CA1@osu.edu>
Message-ID: <49104FD8.5080201@vorant.com>

Wow, I had no idea this was possible.  Clearly, I still have much to learn
about Bro.  I dig it, though, and will definitely be relying on it as part
of my suite of detection tools in the near future.

	David

Seth Hall wrote:
> On Nov 3, 2008, at 8:14 PM, Martin Holste wrote:
> 
>> David had a fine post again today <http://blog.vorant.com/2008/11/detecting-outgoing-connections-from.html 
>>> showing how to make a Bro script from scratch which identified non- 
>> whitelisted traffic.  Could one of the Bro experts show how to take  
>> that and make it able to be dynamically updated at run-time?
> 
> 
> It's update-able through the Bro communications protocol.  If you are  
> using the cluster shell, there is an update command that does this for  
> you.  You just need to make the changes to your global/const variables  
> in your policy scripts and then do the following procedure...
> 
> # cluster<return>
> 
>    > check
>    (check for all to be ok)
>    > install
>    > update
> 
> That *should* then put any updates to global/const variables in  
> place.  It's certainly possible to write other scripts that would do  
> the same procedure without as well since ultimately all the shell does  
> to cause the update process is throw an event through the  
> communications protocol.
> 
>    .Seth
> 
> ---
> Seth Hall
> Network Security - Office of the CIO
> The Ohio State University
> Phone: 614-292-9721
> 
> _______________________________________________
> Discussion mailing list
> Discussion at openinfosecfoundation.org
> http://lists.openinfosecfoundation.org/mailman/listinfo/discussion


From mcholste at gmail.com  Tue Nov  4 09:42:17 2008
From: mcholste at gmail.com (Martin Holste)
Date: Tue, 4 Nov 2008 08:42:17 -0600
Subject: [Discussion] David's Bro Script
In-Reply-To: <49104FD8.5080201@vorant.com>
References: <df9074860811031714p617e48der22dfc7a1a9a014d7@mail.gmail.com>
	<33C24C7A-2865-4DC2-AE51-375620604CA1@osu.edu>
	<49104FD8.5080201@vorant.com>
Message-ID: <df9074860811040642o62f5ce54i1c09b6c35905afbc@mail.gmail.com>

Thanks, Seth.  Any idea how this would go using the Python-Broccoli
interface?  The idea being that there would be a database somewhere with the
ever-changing list of hosts, and at some regular interval, the data would be
dumped from the DB via Python-Broccoli to a running Bro instance.

--Martin

On Tue, Nov 4, 2008 at 7:36 AM, David J. Bianco <david at vorant.com> wrote:

> Wow, I had no idea this was possible.  Clearly, I still have much to learn
> about Bro.  I dig it, though, and will definitely be relying on it as part
> of my suite of detection tools in the near future.
>
>        David
>
> Seth Hall wrote:
> > On Nov 3, 2008, at 8:14 PM, Martin Holste wrote:
> >
> >> David had a fine post again today <
> http://blog.vorant.com/2008/11/detecting-outgoing-connections-from.html
> >>> showing how to make a Bro script from scratch which identified non-
> >> whitelisted traffic.  Could one of the Bro experts show how to take
> >> that and make it able to be dynamically updated at run-time?
> >
> >
> > It's update-able through the Bro communications protocol.  If you are
> > using the cluster shell, there is an update command that does this for
> > you.  You just need to make the changes to your global/const variables
> > in your policy scripts and then do the following procedure...
> >
> > # cluster<return>
> >
> >    > check
> >    (check for all to be ok)
> >    > install
> >    > update
> >
> > That *should* then put any updates to global/const variables in
> > place.  It's certainly possible to write other scripts that would do
> > the same procedure without as well since ultimately all the shell does
> > to cause the update process is throw an event through the
> > communications protocol.
> >
> >    .Seth
> >
> > ---
> > Seth Hall
> > Network Security - Office of the CIO
> > The Ohio State University
> > Phone: 614-292-9721
> >
> > _______________________________________________
> > Discussion mailing list
> > Discussion at openinfosecfoundation.org
> > http://lists.openinfosecfoundation.org/mailman/listinfo/discussion
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openinfosecfoundation.org/pipermail/discussion/attachments/20081104/32994fbb/attachment.html

From jonkman at jonkmans.com  Tue Nov  4 10:13:26 2008
From: jonkman at jonkmans.com (Matt Jonkman)
Date: Tue, 04 Nov 2008 10:13:26 -0500
Subject: [Discussion] David's Bro Script
In-Reply-To: <df9074860811040642o62f5ce54i1c09b6c35905afbc@mail.gmail.com>
References: <df9074860811031714p617e48der22dfc7a1a9a014d7@mail.gmail.com>	<33C24C7A-2865-4DC2-AE51-375620604CA1@osu.edu>	<49104FD8.5080201@vorant.com>
	<df9074860811040642o62f5ce54i1c09b6c35905afbc@mail.gmail.com>
Message-ID: <49106696.8070302@jonkmans.com>

I agree, starting to play with bro and am duly impressed.

Still not convinced we can do all we want to using it as a framework,
but keeping an open mind...

Matt

Martin Holste wrote:
> Thanks, Seth.  Any idea how this would go using the Python-Broccoli
> interface?  The idea being that there would be a database somewhere with
> the ever-changing list of hosts, and at some regular interval, the data
> would be dumped from the DB via Python-Broccoli to a running Bro instance.
> 
> --Martin
> 
> On Tue, Nov 4, 2008 at 7:36 AM, David J. Bianco <david at vorant.com
> <mailto:david at vorant.com>> wrote:
> 
>     Wow, I had no idea this was possible.  Clearly, I still have much to
>     learn
>     about Bro.  I dig it, though, and will definitely be relying on it
>     as part
>     of my suite of detection tools in the near future.
> 
>            David
> 
>     Seth Hall wrote:
>     > On Nov 3, 2008, at 8:14 PM, Martin Holste wrote:
>     >
>     >> David had a fine post again today
>     <http://blog.vorant.com/2008/11/detecting-outgoing-connections-from.html
>     >>> showing how to make a Bro script from scratch which identified non-
>     >> whitelisted traffic.  Could one of the Bro experts show how to take
>     >> that and make it able to be dynamically updated at run-time?
>     >
>     >
>     > It's update-able through the Bro communications protocol.  If you are
>     > using the cluster shell, there is an update command that does this for
>     > you.  You just need to make the changes to your global/const variables
>     > in your policy scripts and then do the following procedure...
>     >
>     > # cluster<return>
>     >
>     >    > check
>     >    (check for all to be ok)
>     >    > install
>     >    > update
>     >
>     > That *should* then put any updates to global/const variables in
>     > place.  It's certainly possible to write other scripts that would do
>     > the same procedure without as well since ultimately all the shell does
>     > to cause the update process is throw an event through the
>     > communications protocol.
>     >
>     >    .Seth
>     >
>     > ---
>     > Seth Hall
>     > Network Security - Office of the CIO
>     > The Ohio State University
>     > Phone: 614-292-9721
>     >
>     > _______________________________________________
>     > Discussion mailing list
>     > Discussion at openinfosecfoundation.org
>     <mailto:Discussion at openinfosecfoundation.org>
>     > http://lists.openinfosecfoundation.org/mailman/listinfo/discussion
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Discussion mailing list
> Discussion at openinfosecfoundation.org
> http://lists.openinfosecfoundation.org/mailman/listinfo/discussion

-- 
--------------------------------------------
Matthew Jonkman
Emerging Threats
Phone 765-429-0398
Fax 312-264-0205
http://www.emergingthreats.net
--------------------------------------------

PGP: http://www.jonkmans.com/mattjonkman.asc



From mcholste at gmail.com  Tue Nov  4 15:19:34 2008
From: mcholste at gmail.com (Martin Holste)
Date: Tue, 4 Nov 2008 14:19:34 -0600
Subject: [Discussion] David's Bro Script
In-Reply-To: <49106696.8070302@jonkmans.com>
References: <df9074860811031714p617e48der22dfc7a1a9a014d7@mail.gmail.com>
	<33C24C7A-2865-4DC2-AE51-375620604CA1@osu.edu>
	<49104FD8.5080201@vorant.com>
	<df9074860811040642o62f5ce54i1c09b6c35905afbc@mail.gmail.com>
	<49106696.8070302@jonkmans.com>
Message-ID: <df9074860811041219g7db31bd3ia71b48da38edb0df@mail.gmail.com>

I am also skeptical that it can be used as a complete framework, that's why
I'm inquiring about the Python-Broccoli interface, because it would be a
proof of concept for showing how Bro hooks into a larger, arbitrary
framework.

--Martin

On Tue, Nov 4, 2008 at 9:13 AM, Matt Jonkman <jonkman at jonkmans.com> wrote:

> I agree, starting to play with bro and am duly impressed.
>
> Still not convinced we can do all we want to using it as a framework,
> but keeping an open mind...
>
> Matt
>
> Martin Holste wrote:
> > Thanks, Seth.  Any idea how this would go using the Python-Broccoli
> > interface?  The idea being that there would be a database somewhere with
> > the ever-changing list of hosts, and at some regular interval, the data
> > would be dumped from the DB via Python-Broccoli to a running Bro
> instance.
> >
> > --Martin
> >
> > On Tue, Nov 4, 2008 at 7:36 AM, David J. Bianco <david at vorant.com
> > <mailto:david at vorant.com>> wrote:
> >
> >     Wow, I had no idea this was possible.  Clearly, I still have much to
> >     learn
> >     about Bro.  I dig it, though, and will definitely be relying on it
> >     as part
> >     of my suite of detection tools in the near future.
> >
> >            David
> >
> >     Seth Hall wrote:
> >     > On Nov 3, 2008, at 8:14 PM, Martin Holste wrote:
> >     >
> >     >> David had a fine post again today
> >     <
> http://blog.vorant.com/2008/11/detecting-outgoing-connections-from.html
> >     >>> showing how to make a Bro script from scratch which identified
> non-
> >     >> whitelisted traffic.  Could one of the Bro experts show how to
> take
> >     >> that and make it able to be dynamically updated at run-time?
> >     >
> >     >
> >     > It's update-able through the Bro communications protocol.  If you
> are
> >     > using the cluster shell, there is an update command that does this
> for
> >     > you.  You just need to make the changes to your global/const
> variables
> >     > in your policy scripts and then do the following procedure...
> >     >
> >     > # cluster<return>
> >     >
> >     >    > check
> >     >    (check for all to be ok)
> >     >    > install
> >     >    > update
> >     >
> >     > That *should* then put any updates to global/const variables in
> >     > place.  It's certainly possible to write other scripts that would
> do
> >     > the same procedure without as well since ultimately all the shell
> does
> >     > to cause the update process is throw an event through the
> >     > communications protocol.
> >     >
> >     >    .Seth
> >     >
> >     > ---
> >     > Seth Hall
> >     > Network Security - Office of the CIO
> >     > The Ohio State University
> >     > Phone: 614-292-9721
> >     >
> >     > _______________________________________________
> >     > Discussion mailing list
> >     > Discussion at openinfosecfoundation.org
> >     <mailto:Discussion at openinfosecfoundation.org>
> >     > http://lists.openinfosecfoundation.org/mailman/listinfo/discussion
> >
> >
> >
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > Discussion mailing list
> > Discussion at openinfosecfoundation.org
> > http://lists.openinfosecfoundation.org/mailman/listinfo/discussion
>
> --
> --------------------------------------------
> Matthew Jonkman
> Emerging Threats
> Phone 765-429-0398
> Fax 312-264-0205
> http://www.emergingthreats.net
> --------------------------------------------
>
> PGP: http://www.jonkmans.com/mattjonkman.asc
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openinfosecfoundation.org/pipermail/discussion/attachments/20081104/ea2599fe/attachment.html

From christian at icir.org  Tue Nov  4 17:58:17 2008
From: christian at icir.org (Christian Kreibich)
Date: Tue, 04 Nov 2008 14:58:17 -0800
Subject: [Discussion] David's Bro Script
In-Reply-To: <df9074860811040642o62f5ce54i1c09b6c35905afbc@mail.gmail.com>
References: <df9074860811031714p617e48der22dfc7a1a9a014d7@mail.gmail.com>
	<33C24C7A-2865-4DC2-AE51-375620604CA1@osu.edu>
	<49104FD8.5080201@vorant.com>
	<df9074860811040642o62f5ce54i1c09b6c35905afbc@mail.gmail.com>
Message-ID: <1225839497.30165.54.camel@strangepork>

On Tue, 2008-11-04 at 08:42 -0600, Martin Holste wrote:
> Thanks, Seth.  Any idea how this would go using the Python-Broccoli
> interface?  The idea being that there would be a database somewhere
> with the ever-changing list of hosts, and at some regular interval,
> the data would be dumped from the DB via Python-Broccoli to a running
> Bro instance.

Hi Martin -- Without going too much into the details (which are better
discussed on the Bro list), the idea would basically be to define event
types that would signal addition/removal to/from the main table(s)
driving Bro's operation. The Bro instance would request those event
types and upon their arrival add/drop the specified hosts to/from the
table. In David's code (which is about connections, not hosts), this
might look as follows:

event add_conn(c: connection) {
	detected_restricted_connections[c$id$orig_h, c$id$resp_h,
					c$id$resp_p] = network_time();
}

event drop_conn(c: connection) {
	if ([c$id$orig_h, c$id$resp_h, c$id$resp_p] in detected_restricted_connections)
		delete detected_restricted_connections[c$id$orig_h, c$id$resp_h,
						       c$id$resp_p]);
}

How to send such events in Python is described on the pybroccoli
page[1]; more detail on Broccoli's event API can be found in the
Broccoli manual[2]. I/O specifics such as update granularity & frequency
would have to be determined by the developer.

[1] http://www.icir.org/robin/bro/pybroccoli.html
[2] http://www.icir.org/christian/broccoli/manual/

-- 
Cheers,
Christian


From jh at dok.org  Thu Nov  6 14:03:24 2008
From: jh at dok.org (Jeremy Hewlett)
Date: Thu, 6 Nov 2008 14:03:24 -0500
Subject: [Discussion] Features suggestion
Message-ID: <20081106190324.GA3355@dok.org>

Greets all,

After having an impromptu conversation with Jonkman about IDS features, we
decided I should post some of my thoughts here and see what you guys think.

One of my long-standing irritations with IDS is a lack of ability to know
what else occurred after an alert was tripped. So, to that end, I've listed
out my thoughts in order from easy implementation to harder to implement.

Currently within Snort we can enable tagging on a rule so that we may
follow streams/packets after an event. This is often useful to me, in the
very least, to ascertain if an attack succeeded. Unfortunately, the act of
enabling tagged packets is tedious (but scriptable) task if I have more
than a handful of rules I want to modify. A method of globally setting a
tag definition that would apply to (groups of? all?) rules would be the
preferable way to accomplish this.

The second, but related thing I'd like to see is a method of recording IP
flows. I find this type of thing useful for statistical analysis, the IDS
already has this information available to it, and it mostly solves the
issue of not knowing what traffic (if any) occurred after an attack. It's
actually better because it doesn't necessarily require a rule being tripped
first... which leads me to my third point.

Anomaly detection / ability to learn normal network behavior. I'm sort of
disillusioned with rule-based IDS, especially now that targetted attacks
are becoming more prominent. An ability for an IDS to learn a network and
recognize bad/unusual/odd traffic patterns and payloads would be a huge
boon. This also fits in well with PassiveAppOSIdentification that I saw
already listed on the OpenInfosec feature list.

Anyway, those are my thoughts. I tried to keep it brief, so let me know
if I need to expand on anything.


From mcholste at gmail.com  Thu Nov  6 20:56:06 2008
From: mcholste at gmail.com (Martin Holste)
Date: Thu, 6 Nov 2008 19:56:06 -0600
Subject: [Discussion] Features suggestion
In-Reply-To: <20081106190324.GA3355@dok.org>
References: <20081106190324.GA3355@dok.org>
Message-ID: <df9074860811061756h3c5ba0f1r84ca229830bfcbed@mail.gmail.com>

Good points, Jeremy.  I agree that having a specification for follow-up
traffic would be a great feature.  I also strongly agree that flows are an
integral part of any NSM setup.

As an example, running a list of known-bad IP's against last week's flows
can be really great way of finding infected hosts that have evaded IDS.  It
follows then that the infected machines I find that way are usually the most
sophisticated and novel hacks.  Studying those incidents leads to the
creation of new signatures, which feeds back into the IDS net.  Supporting
that process as much as possible is a worthwhile goal for this project.

I feel I must give a word of caution regarding the pursuit of network
behavior anomaly detection.  I would instead suggest that this group focuses
on providing ways to define things which are absolute, and not subjective in
any way.  A system which can spew out info like "these 4 hosts downloaded
files which have an average .src entropy higher than 7" would be more
valuable than a system which tried to guess at which 4 hosts were not acting
like the other hosts on the network.  Obviously, if your system can pinpoint
interesting things, you are close to identifying odd traffic patterns.  The
key difference I am trying to point out is that I think it's less useful to
spend time identifying how many or what percentage entropy is "odd" than it
is in creating new ways of measuring something like file entropy.

--Martin

On Thu, Nov 6, 2008 at 1:03 PM, Jeremy Hewlett <jh at dok.org> wrote:

> Greets all,
>
> After having an impromptu conversation with Jonkman about IDS features, we
> decided I should post some of my thoughts here and see what you guys think.
>
> One of my long-standing irritations with IDS is a lack of ability to know
> what else occurred after an alert was tripped. So, to that end, I've listed
> out my thoughts in order from easy implementation to harder to implement.
>
> Currently within Snort we can enable tagging on a rule so that we may
> follow streams/packets after an event. This is often useful to me, in the
> very least, to ascertain if an attack succeeded. Unfortunately, the act of
> enabling tagged packets is tedious (but scriptable) task if I have more
> than a handful of rules I want to modify. A method of globally setting a
> tag definition that would apply to (groups of? all?) rules would be the
> preferable way to accomplish this.
>
> The second, but related thing I'd like to see is a method of recording IP
> flows. I find this type of thing useful for statistical analysis, the IDS
> already has this information available to it, and it mostly solves the
> issue of not knowing what traffic (if any) occurred after an attack. It's
> actually better because it doesn't necessarily require a rule being tripped
> first... which leads me to my third point.
>
> Anomaly detection / ability to learn normal network behavior. I'm sort of
> disillusioned with rule-based IDS, especially now that targetted attacks
> are becoming more prominent. An ability for an IDS to learn a network and
> recognize bad/unusual/odd traffic patterns and payloads would be a huge
> boon. This also fits in well with PassiveAppOSIdentification that I saw
> already listed on the OpenInfosec feature list.
>
> Anyway, those are my thoughts. I tried to keep it brief, so let me know
> if I need to expand on anything.
>
> _______________________________________________
> Discussion mailing list
> Discussion at openinfosecfoundation.org
> http://lists.openinfosecfoundation.org/mailman/listinfo/discussion
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openinfosecfoundation.org/pipermail/discussion/attachments/20081106/c51d253a/attachment.html

From jh at dok.org  Fri Nov  7 00:29:36 2008
From: jh at dok.org (Jeremy Hewlett)
Date: Fri, 7 Nov 2008 00:29:36 -0500
Subject: [Discussion] Features suggestion
In-Reply-To: <df9074860811061756h3c5ba0f1r84ca229830bfcbed@mail.gmail.com>
References: <20081106190324.GA3355@dok.org>
	<df9074860811061756h3c5ba0f1r84ca229830bfcbed@mail.gmail.com>
Message-ID: <20081107052936.GD20068@dok.org>

Thanks for your response - comments inline.

On Thu, Nov 06, 2008 at 19:56:06 -0600, Martin Holste wrote:
>    not subjective in any way.  A system which can spew out info like
>    "these 4 hosts downloaded files which have an average .src entropy
>    higher than 7" would be more valuable than a system which tried to
>    guess at which 4 hosts were not acting like the other hosts on the
>    network.  Obviously, if your system can pinpoint interesting things,
>    you are close to identifying odd traffic patterns.  The key
>    difference I am trying to point out is that I think it's less useful
>    to spend time identifying how many or what percentage entropy is

I'm not sure I can agree completely on this point. I still believe having
an accurate model of how your network behaves is the best way to detect
novel and modified attacks, as well as abnormal traffic patterns. It's not
so much of "guessing what 4 hosts aren't acting like the other hosts" as
much as comparing a host to itself over time and observing deviations from
the norm. 

In your example, you're not always guaranteed that after an attack the
victim will download a packed (high entropy) binary - or even download
anything at all. With an anomaly-based system, that wouldn't matter. The
very basis that the host is receiving abnormal attack traffic (perhaps say,
outside of observed protocol spec, a large packet, whatever) is enough to
raise an alert. In either case, if that particular victim has never talked
to .cn hosts, and is now doing so, that would also be another deviation
worth investigating.

Anyway, I digress; I understand the point you are conveying here. So, on
to the reason i replied in the first place... :)

Picking out traffic (files) with high entropy is a great idea. Have you
looked at http://code.google.com/p/pefile/ at all? I've been using that
from time to time to pinpoint files of interest on compromised boxes.
Something similar to pefile would be easy enough to implement in an IDS.


From jlewis at packetnexus.com  Fri Nov  7 13:22:11 2008
From: jlewis at packetnexus.com (Jason Lewis)
Date: Fri, 07 Nov 2008 13:22:11 -0500
Subject: [Discussion] Features suggestion
In-Reply-To: <20081106190324.GA3355@dok.org>
References: <20081106190324.GA3355@dok.org>
Message-ID: <49148753.3060303@packetnexus.com>

First, I like where the conversations have gone in regards to solving
issues that network operators have. 

Can anyone point to a tool/app that attempts to do everything and does
all those things well?  The idea of tagging streams and packets is a
good one and the idea of including flows is also valuable, but at what
point do we say "this is trying to do too much"?  Wouldn't time be
better spent building a system that can manage the tasking of other
devices for the end goal of preventing network attacks?  Instead of
building a tool that stores netflow, how about a tool that can control
devices that already collect netflow and use that data in a smarter way?

jas

Jeremy Hewlett wrote:
> Greets all,
>
> After having an impromptu conversation with Jonkman about IDS features, we
> decided I should post some of my thoughts here and see what you guys think.
>
> One of my long-standing irritations with IDS is a lack of ability to know
> what else occurred after an alert was tripped. So, to that end, I've listed
> out my thoughts in order from easy implementation to harder to implement.
>
> Currently within Snort we can enable tagging on a rule so that we may
> follow streams/packets after an event. This is often useful to me, in the
> very least, to ascertain if an attack succeeded. Unfortunately, the act of
> enabling tagged packets is tedious (but scriptable) task if I have more
> than a handful of rules I want to modify. A method of globally setting a
> tag definition that would apply to (groups of? all?) rules would be the
> preferable way to accomplish this.
>
> The second, but related thing I'd like to see is a method of recording IP
> flows. I find this type of thing useful for statistical analysis, the IDS
> already has this information available to it, and it mostly solves the
> issue of not knowing what traffic (if any) occurred after an attack. It's
> actually better because it doesn't necessarily require a rule being tripped
> first... which leads me to my third point.
>
> Anomaly detection / ability to learn normal network behavior. I'm sort of
> disillusioned with rule-based IDS, especially now that targetted attacks
> are becoming more prominent. An ability for an IDS to learn a network and
> recognize bad/unusual/odd traffic patterns and payloads would be a huge
> boon. This also fits in well with PassiveAppOSIdentification that I saw
> already listed on the OpenInfosec feature list.
>
> Anyway, those are my thoughts. I tried to keep it brief, so let me know
> if I need to expand on anything.
>
> _______________________________________________
> Discussion mailing list
> Discussion at openinfosecfoundation.org
> http://lists.openinfosecfoundation.org/mailman/listinfo/discussion
>
>   


From mcholste at gmail.com  Fri Nov  7 16:06:26 2008
From: mcholste at gmail.com (Martin Holste)
Date: Fri, 7 Nov 2008 15:06:26 -0600
Subject: [Discussion] Features suggestion
In-Reply-To: <49148753.3060303@packetnexus.com>
References: <20081106190324.GA3355@dok.org> <49148753.3060303@packetnexus.com>
Message-ID: <df9074860811071306q74d8e827vf6acc8fa26dceedf@mail.gmail.com>

Jeremy: Yes, I've used pefile from time to time, and I think that
integrating it with live traffic sniffing as some sort of plugin would be
awesome (similar to the pehunter Snort plugin).

Jason: Dead on.  Almost every feature discussed on this list is found in at
least one existing program.  Designing a robust, extensible command and
management "glue" for these tools seems like the most bang for our buck.

--Martin

On Fri, Nov 7, 2008 at 12:22 PM, Jason Lewis <jlewis at packetnexus.com> wrote:

> First, I like where the conversations have gone in regards to solving
> issues that network operators have.
>
> Can anyone point to a tool/app that attempts to do everything and does
> all those things well?  The idea of tagging streams and packets is a
> good one and the idea of including flows is also valuable, but at what
> point do we say "this is trying to do too much"?  Wouldn't time be
> better spent building a system that can manage the tasking of other
> devices for the end goal of preventing network attacks?  Instead of
> building a tool that stores netflow, how about a tool that can control
> devices that already collect netflow and use that data in a smarter way?
>
> jas
>
> Jeremy Hewlett wrote:
> > Greets all,
> >
> > After having an impromptu conversation with Jonkman about IDS features,
> we
> > decided I should post some of my thoughts here and see what you guys
> think.
> >
> > One of my long-standing irritations with IDS is a lack of ability to know
> > what else occurred after an alert was tripped. So, to that end, I've
> listed
> > out my thoughts in order from easy implementation to harder to implement.
> >
> > Currently within Snort we can enable tagging on a rule so that we may
> > follow streams/packets after an event. This is often useful to me, in the
> > very least, to ascertain if an attack succeeded. Unfortunately, the act
> of
> > enabling tagged packets is tedious (but scriptable) task if I have more
> > than a handful of rules I want to modify. A method of globally setting a
> > tag definition that would apply to (groups of? all?) rules would be the
> > preferable way to accomplish this.
> >
> > The second, but related thing I'd like to see is a method of recording IP
> > flows. I find this type of thing useful for statistical analysis, the IDS
> > already has this information available to it, and it mostly solves the
> > issue of not knowing what traffic (if any) occurred after an attack. It's
> > actually better because it doesn't necessarily require a rule being
> tripped
> > first... which leads me to my third point.
> >
> > Anomaly detection / ability to learn normal network behavior. I'm sort of
> > disillusioned with rule-based IDS, especially now that targetted attacks
> > are becoming more prominent. An ability for an IDS to learn a network and
> > recognize bad/unusual/odd traffic patterns and payloads would be a huge
> > boon. This also fits in well with PassiveAppOSIdentification that I saw
> > already listed on the OpenInfosec feature list.
> >
> > Anyway, those are my thoughts. I tried to keep it brief, so let me know
> > if I need to expand on anything.
> >
> > _______________________________________________
> > Discussion mailing list
> > Discussion at openinfosecfoundation.org
> > http://lists.openinfosecfoundation.org/mailman/listinfo/discussion
> >
> >
>
> _______________________________________________
> Discussion mailing list
> Discussion at openinfosecfoundation.org
> http://lists.openinfosecfoundation.org/mailman/listinfo/discussion
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openinfosecfoundation.org/pipermail/discussion/attachments/20081107/d3da013d/attachment.html

From jh at dok.org  Fri Nov  7 16:31:41 2008
From: jh at dok.org (Jeremy Hewlett)
Date: Fri, 7 Nov 2008 16:31:41 -0500
Subject: [Discussion] Features suggestion
In-Reply-To: <49148753.3060303@packetnexus.com>
References: <20081106190324.GA3355@dok.org> <49148753.3060303@packetnexus.com>
Message-ID: <20081107213141.GE20068@dok.org>


On Fri, Nov 07, 2008 at 13:22:11 -0500, Jason Lewis wrote:
> devices for the end goal of preventing network attacks?  Instead of
> building a tool that stores netflow, how about a tool that can control
> devices that already collect netflow and use that data in a smarter way?

I've been using IDS with IPaudit/IPaudit-web* with reasonable success in
tracking (potentially) compromised hosts. The graphs also give a quick
overview of host and traffic conditions (caught quite a few p2p users and
worm outbreaks with the graphs alone).

*http://ipaudit.sourceforge.net/ipaudit-web/

From jonkman at jonkmans.com  Tue Nov 11 05:39:47 2008
From: jonkman at jonkmans.com (Matt Jonkman)
Date: Tue, 11 Nov 2008 05:39:47 -0500
Subject: [Discussion] Wireless
Message-ID: <491960F3.5010405@jonkmans.com>

What are everyone's thoughts on how to address wireless issues within
this new tool?

Matt


-- 
--------------------------------------------
Matthew Jonkman
Emerging Threats
Phone 765-429-0398
Fax 312-264-0205
http://www.emergingthreats.net
--------------------------------------------

PGP: http://www.jonkmans.com/mattjonkman.asc



From mcholste at gmail.com  Tue Nov 11 09:25:00 2008
From: mcholste at gmail.com (Martin Holste)
Date: Tue, 11 Nov 2008 08:25:00 -0600
Subject: [Discussion] Wireless
In-Reply-To: <491960F3.5010405@jonkmans.com>
References: <491960F3.5010405@jonkmans.com>
Message-ID: <df9074860811110625o7b7f1cn1d6bd71253af2dfe@mail.gmail.com>

Wireless seems out of scope to me, but a generic SNMP trap receiver that
could process external events from networking gear might work for receiving
interesting wireless information from the access points.

--Martin

On Tue, Nov 11, 2008 at 4:39 AM, Matt Jonkman <jonkman at jonkmans.com> wrote:

> What are everyone's thoughts on how to address wireless issues within
> this new tool?
>
> Matt
>
>
> --
> --------------------------------------------
> Matthew Jonkman
> Emerging Threats
> Phone 765-429-0398
> Fax 312-264-0205
> http://www.emergingthreats.net
> --------------------------------------------
>
> PGP: http://www.jonkmans.com/mattjonkman.asc
>
>
> _______________________________________________
> Discussion mailing list
> Discussion at openinfosecfoundation.org
> http://lists.openinfosecfoundation.org/mailman/listinfo/discussion
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openinfosecfoundation.org/pipermail/discussion/attachments/20081111/c29991e9/attachment.html

From david.glosser at gmail.com  Tue Nov 11 19:56:20 2008
From: david.glosser at gmail.com (David Glosser)
Date: Tue, 11 Nov 2008 19:56:20 -0500
Subject: [Discussion] Features
In-Reply-To: <ac597e6e0810221829j77d1ff7fgc788964e01c0171c@mail.gmail.com>
References: <48F7E3B0.20002@jonkmans.com>
	<C4AEE0C0-7C4F-486D-BCE8-208865B87A17@informatik.uni-mannheim.de>
	<bb6f9ad60810181428g588b68f1t9b9fcc6106f09576@mail.gmail.com>
	<1224367303.13106.17.camel@localhost>
	<bb6f9ad60810181917g12f574e1id04cff39bcdd5052@mail.gmail.com>
	<1a0f92ae0810191746h5ed6b5e6yeb2109f89e173884@mail.gmail.com>
	<48FCC484.9080308@jonkmans.com>
	<ac597e6e0810221704q56ac4724lfede2b82b2231c7c@mail.gmail.com>
	<df9074860810221719o6d34157fr5ea3e6442c075083@mail.gmail.com>
	<ac597e6e0810221829j77d1ff7fgc788964e01c0171c@mail.gmail.com>
Message-ID: <ac597e6e0811111656i5ea4ff86ta7c63dfae55ee285@mail.gmail.com>

Going back to reputation scoring,  I think domains could be scored as well..

 Say reputation is from 0-100 (with 100 being bad enough to block:)

If a domain is on the same IP address as a bad site, it gets a score of 50.
If a domain is an adjacent IP address as a bad site, it gets a score of 30.
If a domain is on the same IP netblock as a bad site, it gets a score of 20.
If a domain is fast-flux, it gets a score of 30
If a domain has been registered within 30 days, it gets a score of 10.
If a domain has been used for malspam, it gets a score of 100.
etc.

This may be computationally intensive due to the reverse-ip lookups,
so it may have to refreshed  every night or so...




>>> Adjacent IPs are given a reputation score of 30.
>>> All of the IPs in "Btrivo's" netblock are given a reputation score of 10.
>>>
>>> Two adjacent IP addresses each hosting malware each will get a score of
>>> 90 (50+30+10).
>>>
>>> If malware goes away, score decreases each day. For each day host is
>>> still up, score increases....


>
>
> On Wed, Oct 22, 2008 at 8:19 PM, Martin Holste <mcholste at gmail.com> wrote:
>>
>> I really like that idea.  It won't directly lead to blocking innocent
>> IP's, but will still give the good guys a simple and reliable predictive
>> capability.
>>
>> On Wed, Oct 22, 2008 at 7:04 PM, David Glosser <david.glosser at gmail.com>
>> wrote:
>>>
>>> Back to the idea of Spam-assassin scoring:
>>>
>>> Once a bad host is identified, then I'm wondering if IP reputation could
>>> maybe using a "halo effect" whereby other IPs by the same provider are given
>>> lower scores.
>>>
>>> Say reputation is from 0-100 (with 100 being bad)
>>>
>>> So if an IP on hosting provider "Btrivo" contains malware, that IP gets a
>>> reputation score of 50.
>>> Adjacent IPs are given a reputation score of 30.
>>> All of the IPs in "Btrivo's" netblock are given a reputation score of 10.
>>>
>>> Two adjacent IP addresses each hosting malware each will get a score of
>>> 90 (50+30+10).
>>>
>>> If malware goes away, score decreases each day. For each day host is
>>> still up, score increases....
>>>

From srichman at viewpointsecurity.com  Thu Nov 13 09:40:39 2008
From: srichman at viewpointsecurity.com (SteveR)
Date: Thu, 13 Nov 2008 09:40:39 -0500
Subject: [Discussion] Discussion Digest, Vol 2, Issue 6
Message-ID: <200811131440.mADEeeNt027383@omr4.networksolutionsemail.com>


 
-----Original Message-----
From: discussion-request at openinfosecfoundation.org
To: discussion at openinfosecfoundation.org
Sent: 11/12/08 12:00 PM
Subject: Discussion Digest, Vol 2, Issue 6

Send Discussion mailing list submissions to
	discussion at openinfosecfoundation.org

To subscribe or unsubscribe via the World Wide Web, visit
	http://lists.openinfosecfoundation.org/mailman/listinfo/discussion
or, via email, send a message with subject or body 'help' to
	discussion-request at openinfosecfoundation.org

You can reach the person managing the list at
	discussion-owner at openinfosecfoundation.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Discussion digest..."


Today's Topics:

   1. Re: Features (David Glosser)


----------------------------------------------------------------------

Message: 1
Date: Tue, 11 Nov 2008 19:56:20 -0500
From: "David Glosser" <david.glosser at gmail.com>
Subject: Re: [Discussion] Features



From srichman at viewpointsecurity.com  Thu Nov 13 09:40:39 2008
From: srichman at viewpointsecurity.com (SteveR)
Date: Thu, 13 Nov 2008 09:40:39 -0500
Subject: [Discussion] Discussion Digest, Vol 2, Issue 6
Message-ID: <200811131440.mADEee7V027384@omr4.networksolutionsemail.com>


 
-----Original Message-----
From: discussion-request at openinfosecfoundation.org
To: discussion at openinfosecfoundation.org
Sent: 11/12/08 12:00 PM
Subject: Discussion Digest, Vol 2, Issue 6

Send Discussion mailing list submissions to
	discussion at openinfosecfoundation.org

To subscribe or unsubscribe via the World Wide Web, visit
	http://lists.openinfosecfoundation.org/mailman/listinfo/discussion
or, via email, send a message with subject or body 'help' to
	discussion-request at openinfosecfoundation.org

You can reach the person managing the list at
	discussion-owner at openinfosecfoundation.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Discussion digest..."


Today's Topics:

   1. Re: Features (David Glosser)


----------------------------------------------------------------------

Message: 1
Date: Tue, 11 Nov 2008 19:56:20 -0500
From: "David Glosser" <david.glosser at gmail.com>
Subject: Re: [Discussion] Features



From swineherd007 at gmail.com  Fri Nov 14 10:41:16 2008
From: swineherd007 at gmail.com (Christian T)
Date: Sat, 15 Nov 2008 02:41:16 +1100
Subject: [Discussion] Features suggestion
Message-ID: <1972345d0811140741r25ba6a9dmddb7f76b57f6832d@mail.gmail.com>

Hi all,

Following on from what Jeremy raised regarding knowing what happened after
an alert fired - given that we need to see the subsequent packets in a
stream (after the triggering one(s)) to determine if an exploit was
successful, in some situations couldn't that be automated by the IDS? Like
extending the flowbits function of snort to not just detect an attempted
exploit, but evaluate the victim response to determine if the attack was
successful or not. Or perhaps at least confirming that it failed, and thus
issuing a lower severity alert.

For example, a web attack is detected, the equivalent of a flowbit for
'web-attack' is set, and the ids checks for a 404 (or similar) response - if
so, it suggests the attack was unsuccesful. If it sees a 200 OK server
response, the alert has higher severity.

Or watching for succesful brute force attacks - easy for a signature to
detect many attempts to login in a short space of time, perhaps detect many
failed attempts in a short space of time - of more interest is many failed
and then successful  -okay, perhaps this belongs in the realm of a
correlation SIEM app, but a thought.

Mainly, I'm thinking why not offload some of the analyst work of
investigating network traffic associated with an ids signature match onto
the ids itself. At least as far as server response goes - most signatures
are built to answer the question - 'is this traffic malicious or not?' Why
not build them so they also try to answer - 'and was it successful or not?'

Cheers,
Christian
<discussion%40openinfosecfoundation.org?Subject=%5BDiscussion%5D%20Features%20suggestion&In-Reply-To=>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openinfosecfoundation.org/pipermail/discussion/attachments/20081115/28d496da/attachment.html

From david.glosser at gmail.com  Mon Nov 17 06:48:31 2008
From: david.glosser at gmail.com (David Glosser)
Date: Mon, 17 Nov 2008 06:48:31 -0500
Subject: [Discussion] features (mainly dns)
Message-ID: <ac597e6e0811170348t144947b7occ463bcbc027bccf@mail.gmail.com>

See http://isc.sans.org/diary.html?storyid=5345, I think there are some
interesting possible features, especially in the field of DNS and anomaly
detection:

   - DNS responses which had a low to very low TTL (time to live) value,
   which is somewhat unusual;
   - DNS responses which contained a domain that belonged to one of a long
   list of dynamic DNS providers;
   - DNS queries which were issued more frequently by the client than would
   be expected given the TTL for that hostname;
   - DNS requests for a hostname outside of the local namespace which were
   responded to with a resource record pointing to an IP address within either
   127.0.0.0/8, 0.0.0.0/32, RFC1918 IP space, or anywhere inside the public
   or private IP space of the organization;
   - Consecutive DNS responses for a single unique hostname which contained
   only a single resource record, but which changed more than twice every 24
   hours.
   - Persistent connections to HTTP servers on the internet, even outside
   regular office hours, can be normal: just think of software update
   mechanisms.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openinfosecfoundation.org/pipermail/discussion/attachments/20081117/0eb98508/attachment.html

From jonkman at jonkmans.com  Mon Nov 17 10:59:32 2008
From: jonkman at jonkmans.com (Matt Jonkman)
Date: Mon, 17 Nov 2008 10:59:32 -0500
Subject: [Discussion] Brainstorming Session Notes
Message-ID: <492194E4.3020605@jonkmans.com>

As most of you know we had our first brainstorming session in Vienna at
Deepsec last friday. The conference was a great success. Highly
recommend catching it next year.

We had a great turnout for the session. We unfortunately ran long by
choice into lunch and still kept most of the crowd. That was an
encouraging sign! (Sorry to those that ate lunch late :) )

Discussion was very positive. We learned a few things about how to
present this next time, the primary being to get right to the discussion
as there will be a lot of it!

We had a lot of discussion about IP Reputation. That is a very high
priority for most attendees, but a number of pitfalls (statistical
issues) were pointed out. While this is a simple concept overall, the
implementation will have to be studied well. Stefano from U of Milan
made the astute point that a continuous negative feedback is
counterproductive. For example if an IP is blocked by one site, then
that info relayed to another site where the same IP is blocked only by
reputation, we have to make sure that second block isn't reported into
the IPs reputation thus reducing the reputation of the IP without it
actually doing something bad. The reputation info fed back should be
based ONLY on attacks and not replicated blocks.

A lot of discussion went toward getting away from 100% signature based
detection. We definitely need to focus research there. IP Reputation can
feed into this, but we need to get some significant statistical
minds/research on board to look deeper into anomaly detection. Basic
signature detection + ip reputation + statistical anomaly detection I
think will go a very long way here. Does anyone know of some good
statistical modeling papers or researchers? DSpam was mentioned as a
model to consider.

Also brought up was considering preprocessors or some other process that
can do decoding. Mime, gzip, zlib, PE unpacking, etc. That'd definitely
be too slow to do inline, but if it were handed off to a spare thread
and that result used for IP reputation or stream reputation it could be
of great use.

Data flow collection was mentioned. I guess the best way to summarize
would be to be able to output netflow style data. Not too detailed, but
something that other tools could use.

And finally, we were reminded we should keep virtualization in mind.
Specifically making sure we test under load in common virtual
environments as it's likely in the next few years that sensors
themselves may be vmware virtual boxes. So capture support and full
utilization of cpu's will be critical.

In summary, it was a great session. We're working on getting the next
scheduled, hope to see you there!!

Matt

-- 
--------------------------------------------
Matthew Jonkman
Emerging Threats
Phone 765-429-0398
Fax 312-264-0205
http://www.emergingthreats.net
--------------------------------------------

PGP: http://www.jonkmans.com/mattjonkman.asc



From hall.692 at osu.edu  Mon Nov 17 11:08:44 2008
From: hall.692 at osu.edu (Seth Hall)
Date: Mon, 17 Nov 2008 11:08:44 -0500
Subject: [Discussion] Brainstorming Session Notes
In-Reply-To: <492194E4.3020605@jonkmans.com>
References: <492194E4.3020605@jonkmans.com>
Message-ID: <54357CEC-5CD2-4FEA-986B-8969E7AD8386@osu.edu>


On Nov 17, 2008, at 10:59 AM, Matt Jonkman wrote:

> Also brought up was considering preprocessors or some other process  
> that
> can do decoding. Mime, gzip, zlib, PE unpacking, etc. That'd  
> definitely
> be too slow to do inline, but if it were handed off to a spare thread
> and that result used for IP reputation or stream reputation it could  
> be
> of great use.

I think that *definitely* might be a somewhat overly finite  
statement.  Right now with Bro I'm doing gzip decoding of web traffic  
on 1.1Gbps of total network traffic (we typically see about 60% on  
port 80/tcp) and not dropping packets.

> Data flow collection was mentioned. I guess the best way to summarize
> would be to be able to output netflow style data. Not too detailed,  
> but
> something that other tools could use.

Bro's conn.bro script does this, but it's slightly nicer in the same  
sense that Argus is nicer than netflow.  It actually shows you the  
direction of the connection.  If you have the capacity on your  
machine(s), it can also tell you what protocol it detected during the  
connection.

   .Seth

---
Seth Hall
Network Security - Office of the CIO
The Ohio State University
Phone: 614-292-9721


From cunningpike at gmail.com  Mon Nov 17 17:04:58 2008
From: cunningpike at gmail.com (CunningPike)
Date: Mon, 17 Nov 2008 14:04:58 -0800
Subject: [Discussion] features (mainly dns)
In-Reply-To: <ac597e6e0811170348t144947b7occ463bcbc027bccf@mail.gmail.com>
References: <ac597e6e0811170348t144947b7occ463bcbc027bccf@mail.gmail.com>
Message-ID: <1226959498.27961.3.camel@arodgers-panasonic>

On Mon, 2008-11-17 at 06:48 -0500, David Glosser wrote:
> See http://isc.sans.org/diary.html?storyid=5345, I think there are
> some interesting possible features, especially in the field of DNS and
> anomaly detection:
>       * DNS responses which had a low to very low TTL (time to live)
>         value, which is somewhat unusual;
>       * DNS responses which contained a domain that belonged to one of
>         a long list of dynamic DNS providers;
>       * DNS queries which were issued more frequently by the client
>         than would be expected given the TTL for that hostname;
>       * DNS requests for a hostname outside of the local namespace
>         which were responded to with a resource record pointing to an
>         IP address within either 127.0.0.0/8, 0.0.0.0/32, RFC1918 IP
>         space, or anywhere inside the public or private IP space of
>         the organization;

dnswall (http://code.google.com/p/google-dnswall/) deals with RFC1918
replies.

>       * Consecutive DNS responses for a single unique hostname which
>         contained only a single resource record, but which changed
>         more than twice every 24 hours.
>       * Persistent connections to HTTP servers on the internet, even
>         outside regular office hours, can be normal: just think of
>         software update mechanisms.
> 
> _______________________________________________
> Discussion mailing list
> Discussion at openinfosecfoundation.org
> http://lists.openinfosecfoundation.org/mailman/listinfo/discussion


From thorsten.holz at informatik.uni-mannheim.de  Mon Nov 17 17:41:28 2008
From: thorsten.holz at informatik.uni-mannheim.de (Thorsten Holz)
Date: Mon, 17 Nov 2008 23:41:28 +0100
Subject: [Discussion] Brainstorming Session Notes
In-Reply-To: <54357CEC-5CD2-4FEA-986B-8969E7AD8386@osu.edu>
References: <492194E4.3020605@jonkmans.com>
	<54357CEC-5CD2-4FEA-986B-8969E7AD8386@osu.edu>
Message-ID: <3F0E4FA0-8E16-4862-A6D1-A1902981A8E0@informatik.uni-mannheim.de>

On 17.11.2008, at 17:08, Seth Hall wrote:

> I think that *definitely* might be a somewhat overly finite
> statement.  Right now with Bro I'm doing gzip decoding of web traffic
> on 1.1Gbps of total network traffic (we typically see about 60% on
> port 80/tcp) and not dropping packets.

But you are running a whole cluster of machines, don't you? :-)
Can you share some details on what kind of machines you use for Bro?

Cheers,
   Thorsten

From hall.692 at osu.edu  Mon Nov 17 23:07:02 2008
From: hall.692 at osu.edu (Seth Hall)
Date: Mon, 17 Nov 2008 23:07:02 -0500
Subject: [Discussion] Brainstorming Session Notes
In-Reply-To: <3F0E4FA0-8E16-4862-A6D1-A1902981A8E0@informatik.uni-mannheim.de>
References: <492194E4.3020605@jonkmans.com>
	<54357CEC-5CD2-4FEA-986B-8969E7AD8386@osu.edu>
	<3F0E4FA0-8E16-4862-A6D1-A1902981A8E0@informatik.uni-mannheim.de>
Message-ID: <5A7C4AA0-6B3D-4C7D-B50D-AB724208BE63@osu.edu>


On Nov 17, 2008, at 5:41 PM, Thorsten Holz wrote:
> But you are running a whole cluster of machines, don't you? :-)
> Can you share some details on what kind of machines you use for Bro?


Sure, anything you want to know :)

Right now I have 21 Dell SX260's with 1 gig of memory (they have  
horribly narrow memory bandwidth and are *very* slow) and 2 core2-quad  
processor hosts with 4 gigs of memory.  I'm going to be adding 4 more  
quad core hosts in the next couple of days too because I want to get  
rid of the SX260's.  My manager host is a Dell 2950 with 2 gigs of  
memory.

The quad core hosts I have been building are only costing ~$650, so  
it's fairly affordable to just keep adding new ones until we don't  
drop packets.

   .Seth

---
Seth Hall
Network Security - Office of the CIO
The Ohio State University
Phone: 614-292-9721


From jonkman at jonkmans.com  Tue Nov 18 10:28:40 2008
From: jonkman at jonkmans.com (Matt Jonkman)
Date: Tue, 18 Nov 2008 10:28:40 -0500
Subject: [Discussion] Brainstorming Session Notes
In-Reply-To: <5A7C4AA0-6B3D-4C7D-B50D-AB724208BE63@osu.edu>
References: <492194E4.3020605@jonkmans.com>	<54357CEC-5CD2-4FEA-986B-8969E7AD8386@osu.edu>	<3F0E4FA0-8E16-4862-A6D1-A1902981A8E0@informatik.uni-mannheim.de>
	<5A7C4AA0-6B3D-4C7D-B50D-AB724208BE63@osu.edu>
Message-ID: <4922DF28.2050502@jonkmans.com>

So what kind of overhead do you see on the clustering?

Is your setup near the upper or lower end of where the overhead makes
things feasible?

Matt

Seth Hall wrote:
> On Nov 17, 2008, at 5:41 PM, Thorsten Holz wrote:
>> But you are running a whole cluster of machines, don't you? :-)
>> Can you share some details on what kind of machines you use for Bro?
> 
> 
> Sure, anything you want to know :)
> 
> Right now I have 21 Dell SX260's with 1 gig of memory (they have  
> horribly narrow memory bandwidth and are *very* slow) and 2 core2-quad  
> processor hosts with 4 gigs of memory.  I'm going to be adding 4 more  
> quad core hosts in the next couple of days too because I want to get  
> rid of the SX260's.  My manager host is a Dell 2950 with 2 gigs of  
> memory.
> 
> The quad core hosts I have been building are only costing ~$650, so  
> it's fairly affordable to just keep adding new ones until we don't  
> drop packets.
> 
>    .Seth
> 
> ---
> Seth Hall
> Network Security - Office of the CIO
> The Ohio State University
> Phone: 614-292-9721
> 
> _______________________________________________
> Discussion mailing list
> Discussion at openinfosecfoundation.org
> http://lists.openinfosecfoundation.org/mailman/listinfo/discussion

-- 
--------------------------------------------
Matthew Jonkman
Emerging Threats
Phone 765-429-0398
Fax 312-264-0205
http://www.emergingthreats.net
--------------------------------------------

PGP: http://www.jonkmans.com/mattjonkman.asc



From jonkman at jonkmans.com  Tue Nov 18 10:35:34 2008
From: jonkman at jonkmans.com (Matt Jonkman)
Date: Tue, 18 Nov 2008 10:35:34 -0500
Subject: [Discussion] features (mainly dns)
In-Reply-To: <1226959498.27961.3.camel@arodgers-panasonic>
References: <ac597e6e0811170348t144947b7occ463bcbc027bccf@mail.gmail.com>
	<1226959498.27961.3.camel@arodgers-panasonic>
Message-ID: <4922E0C6.1090204@jonkmans.com>

Dnswall is interesting.

More inline:

CunningPike wrote:
>>       * DNS responses which had a low to very low TTL (time to live)
>>         value, which is somewhat unusual;

We tried sigs for this a while ago and found that there are as many
legit low ttl responses as there were hostile. The sigs were reliable
and relatively low load, but the information wasn't actionable
unfortunately. Pretty everyone with akami hit on it, etc.

>>       * DNS responses which contained a domain that belonged to one of
>>         a long list of dynamic DNS providers;

That's an interesting one. A good way for us to use DNS reputation adata
that we'd surely collect alongside IP reputation data.

>>       * DNS queries which were issued more frequently by the client
>>         than would be expected given the TTL for that hostname;

How do you mean? Loke looking for a client that's making repeated dns
queries within the TTL? Maybe poorly coded bots?

>>       * DNS requests for a hostname outside of the local namespace
>>         which were responded to with a resource record pointing to an
>>         IP address within either 127.0.0.0/8, 0.0.0.0/32, RFC1918 IP
>>         space, or anywhere inside the public or private IP space of
>>         the organization;

Absolutely here. But would require a good deal of local ocnfig, but
worthwhile I think.

Great Ideas!!

Matt


> 
> dnswall (http://code.google.com/p/google-dnswall/) deals with RFC1918
> replies.
> 
>>       * Consecutive DNS responses for a single unique hostname which
>>         contained only a single resource record, but which changed
>>         more than twice every 24 hours.
>>       * Persistent connections to HTTP servers on the internet, even
>>         outside regular office hours, can be normal: just think of
>>         software update mechanisms.
>>
>> _______________________________________________
>> Discussion mailing list
>> Discussion at openinfosecfoundation.org
>> http://lists.openinfosecfoundation.org/mailman/listinfo/discussion
> 
> _______________________________________________
> Discussion mailing list
> Discussion at openinfosecfoundation.org
> http://lists.openinfosecfoundation.org/mailman/listinfo/discussion

-- 
--------------------------------------------
Matthew Jonkman
Emerging Threats
Phone 765-429-0398
Fax 312-264-0205
http://www.emergingthreats.net
--------------------------------------------

PGP: http://www.jonkmans.com/mattjonkman.asc



From hall.692 at osu.edu  Tue Nov 18 09:46:41 2008
From: hall.692 at osu.edu (Seth Hall)
Date: Tue, 18 Nov 2008 09:46:41 -0500
Subject: [Discussion] Brainstorming Session Notes
In-Reply-To: <4922DF28.2050502@jonkmans.com>
References: <492194E4.3020605@jonkmans.com>
	<54357CEC-5CD2-4FEA-986B-8969E7AD8386@osu.edu>
	<3F0E4FA0-8E16-4862-A6D1-A1902981A8E0@informatik.uni-mannheim.de>
	<5A7C4AA0-6B3D-4C7D-B50D-AB724208BE63@osu.edu>
	<4922DF28.2050502@jonkmans.com>
Message-ID: <34C39807-0BAC-43EC-AFAD-7778043EAA46@osu.edu>


On Nov 18, 2008, at 10:28 AM, Matt Jonkman wrote:

> So what kind of overhead do you see on the clustering?

I'm probably not the best person to respond to this question, but I've  
never have a feeling that the clustering adds too much overhead.  It  
forces me to write some of my scripts a little differently if they  
need to watch for multiple actions between multiple hosts due to the  
fact that I'm splitting the traffic across the worker nodes by src-dst  
IP address pairs.

My canonical example of this is detecting hosts successfully  
compromised by remote file inclusion vulnerabilities because one of my  
workers might see the HTTP request with the attack and another worker  
might see the web server go out and request a PHP script or  
something.  I need to keep a variable for a short time with the attack  
HTTP request and synchronize it around to all of the cluster hosts so  
that I can compare with any PHP scripts that might be requested by the  
attacked host after that.

> Is your setup near the upper or lower end of where the overhead makes
> things feasible?

I've heard from the Bro developers that they've seen near linear  
scaling of the cluster deployment up to 24 nodes.  My cluster is a  
really bad example though because of all of those Dells that are so  
slow.  The new quad core hosts seem to each be able to handle about  
250Mbps in the way I currently have them configured (they're each  
running two Bro processes).  Once the multicore code in Bro is  
functional though, I believe that I'll see significantly better  
performance from them.  Anyway, the cluster deployment is definitely  
feasible and works quite well.

   .Seth


---
Seth Hall
Network Security - Office of the CIO
The Ohio State University
Phone: 614-292-9721


From david.glosser at gmail.com  Tue Nov 18 11:05:11 2008
From: david.glosser at gmail.com (David Glosser)
Date: Tue, 18 Nov 2008 11:05:11 -0500
Subject: [Discussion] features (mainly dns)
In-Reply-To: <4922E0C6.1090204@jonkmans.com>
References: <ac597e6e0811170348t144947b7occ463bcbc027bccf@mail.gmail.com>
	<1226959498.27961.3.camel@arodgers-panasonic>
	<4922E0C6.1090204@jonkmans.com>
Message-ID: <ac597e6e0811180805g60008e27j36185b14574c71d0@mail.gmail.com>

> >>       * DNS responses which had a low to very low TTL (time to live)
> >>         value, which is somewhat unusual;
>
> We tried sigs for this a while ago and found that there are as many
> legit low ttl responses as there were hostile. The sigs were reliable
> and relatively low load, but the information wasn't actionable
> unfortunately. Pretty everyone with akami hit on it, etc.
>

Maybe have a whitelist?
or Just include this parameter within a DNS/IP reputation score?


>
>
> >>       * DNS queries which were issued more frequently by the client
> >>         than would be expected given the TTL for that hostname;
>
> How do you mean? Loke looking for a client that's making repeated dns
> queries within the TTL? Maybe poorly coded bots?


Not sure, this was directly quoted from the SANs post :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openinfosecfoundation.org/pipermail/discussion/attachments/20081118/af72371b/attachment.html

From frank at knobbe.us  Tue Nov 18 12:39:28 2008
From: frank at knobbe.us (Frank Knobbe)
Date: Tue, 18 Nov 2008 11:39:28 -0600
Subject: [Discussion] features (mainly dns)
In-Reply-To: <1226959498.27961.3.camel@arodgers-panasonic>
References: <ac597e6e0811170348t144947b7occ463bcbc027bccf@mail.gmail.com>
	<1226959498.27961.3.camel@arodgers-panasonic>
Message-ID: <1227029968.27060.10.camel@localhost>

On Mon, 2008-11-17 at 14:04 -0800, CunningPike wrote:

> dnswall (http://code.google.com/p/google-dnswall/) deals with RFC1918
> replies.

Just make sure your mail servers don't use it, or you break the RBLs :)

-Frank


-- 
It is said that the Internet is a public utility. As such, it is best
compared to a sewer. A big, fat pipe with a bunch of crap sloshing
against your ports.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: This is a digitally signed message part
Url : http://lists.openinfosecfoundation.org/pipermail/discussion/attachments/20081118/14bae16b/attachment.bin

From john.r.pritchard at gmail.com  Tue Nov 18 13:47:19 2008
From: john.r.pritchard at gmail.com (John Pritchard)
Date: Tue, 18 Nov 2008 10:47:19 -0800
Subject: [Discussion] Features - Designing for Scaleability
Message-ID: <bea0bdd30811181047x6caff439v9c5546e9c2e5cf0b@mail.gmail.com>

Team,

My apologies if I've missed this being covered previously. Or, if the
Bro framework already takes some of these things into consideration.

I'd like to suggest that we take very large deployments into
consideration when designing our solution. The kind of problems you
encounter when managing an infrastructure with a handful or even a
dozen different IDS sensors is very different than trying to
efficiently and consistently manage infrastructures with larger
footprints (e.g. > 100+ sensors).

A couple of suggestions to help our design address these potential
deployment and management scenarios:

1) Centralized sensor and policy management platform (or framework)
--> Such a solution may be restricted to a single centralized server
or multiple servers.
--> Might be a parent -> child relationship among configuration
servers to segregate business units, or simply replication among
servers for disaster recovery / business continuity purposes
--> efficient, repeatable, and audit-able methodology for making
changes to both individual sensors as well as pre-defined groups of
sensors (e.g. dmz sensors, dns sensors, development lab sensors,
etc...)
--> My experience to date has been performing these kind of tasks with
home-grown scripts, ssh, scp, audit logs, etc... However, it would be
nice to find something a little more mature for this project.

I have not used it, but there is a project called "Puppet" that looks
like it might be a good candidate for trying to develop a framework
along these lines:
http://reductivelabs.com/trac/puppet/wiki/PuppetIntroduction


2) Centralized sensor and policy monitoring platform (or framework)
--> This is similar to the "management framework" concept, but the
focus is more on device health monitoring... and possibly policy
integrity monitoring...
--> For this piece, I'm thinking of something that provides functions
such as looking at memory utilization, cpu utilization, hard-drive
space, network interface stats... and other "bits" such as dates and
checksums for critical configuration files changed (e.g. detection
policies, tuning policies, variable definitions, etc)...

There are a number of open-source enterprise monitoring utilities out
there. Here's one I've been playing with recently:
http://www.zabbix.com/


3) Distributed Data Repositories
I know we briefly touched on the database stuff when talking about
schema design. I just wanted to add a plug for a couple of things
here:
--> encrypted communication channels (sensor -> DB or sensor -> sensor)
--> ability to simultaneously log to 2 or more data repositories

I strongly agree with the concept of designing modular solutions. So,
these kind of features can be "bolted on" if they were required.

Look forward to everyone's thoughts on how we can most effectively
tackle problems of scale for large deployments.

Cheers, John

From mcholste at gmail.com  Fri Nov 28 19:56:24 2008
From: mcholste at gmail.com (Martin Holste)
Date: Fri, 28 Nov 2008 18:56:24 -0600
Subject: [Discussion] Features - Designing for Scaleability
In-Reply-To: <bea0bdd30811181047x6caff439v9c5546e9c2e5cf0b@mail.gmail.com>
References: <bea0bdd30811181047x6caff439v9c5546e9c2e5cf0b@mail.gmail.com>
Message-ID: <df9074860811281656k516f172k6efaf6f287061148@mail.gmail.com>

John,

I think you've hit on some key points here.  I manage about a dozen sensors,
and there is a definite line that is crossed somewhere around a half-dozen
servers where managing the configuration and health of the boxes requires
some power tools.  I prefer Nagios for general system health monitoring, so
that has never been an issue.  Conversely, it has been an incredible
challenge to manage rules and granular Snort performance on many boxes with
multiple Snort instances.  I've taken the route you have with many
home-grown scripts, etc., but there's always something new that comes out
with Snort making the management difficult.  Specifically, dealing with SO
rules throws a huge wrench in the works when dealing with mixed
architectures.

My strategy thus far has been to have my sensors completely self contained
and manage them centrally using a home-grown system written in Perl to make
generic queries and issue commands.  The databases which Snort writes to are
on the box (performance really isn't impacted at all by doing this).  The
Perl agent receives queries like "get all alerts in last X minutes," or "add
this rule to the running configuration," or "calculate stats for Mbps and
alerts per second for last 1000 ticks."  The key is that since all the data
is on the sensor, it scales very well.  The central Perl client can then
parallelize queries so all sensors can search at the same time much faster
than if all the alerts were located in one central database.  Since
everything goes through the central management client, it can easily log all
the actions (and even queries) which are run for audit/change management
purposes.

For encryption, I run everything through OpenVPN.  This works really well,
especially for debugging, since it is much easier to tcpdump a tunnel
interface than get a hook into a TLS socket.

I'm working on a 2.0 version of this architecture which will be entirely
asynchronous, so that the sensors can alert the central management hub on
predetermined criteria.

For truly large deployments, I think you're right that a parent-child setup
might be necessary.  An exploration of peer-to-peer techniques might be an
interesting, but I think that for simplicity, a tree hierarchy would make
the most sense.  That is, a "hub" may have X number of servers assigned to
it, and a hub higher up the tree would be able to ask hubs to delegate
queries down the hierarchy.  It would be interesting to see if there would
be performance gains versus attempting parallelized queries over thousands
of sensors from just one hub.  My thinking is that some of the sensors could
also function as hubs.

I think that we need to remember that the vast majority of users do not
deploy more than a few sensors, so we need to guard against spending too
much devel time on features that will only serve a small percentage of the
community.  That said, audit, change management, archiving, and other
management features are things that benefit everyone.  As long as we keep it
all modular, users can mix and match to get the features they require.

--Martin

On Tue, Nov 18, 2008 at 12:47 PM, John Pritchard <john.r.pritchard at gmail.com
> wrote:

> Team,
>
> My apologies if I've missed this being covered previously. Or, if the
> Bro framework already takes some of these things into consideration.
>
> I'd like to suggest that we take very large deployments into
> consideration when designing our solution. The kind of problems you
> encounter when managing an infrastructure with a handful or even a
> dozen different IDS sensors is very different than trying to
> efficiently and consistently manage infrastructures with larger
> footprints (e.g. > 100+ sensors).
>
> A couple of suggestions to help our design address these potential
> deployment and management scenarios:
>
> 1) Centralized sensor and policy management platform (or framework)
> --> Such a solution may be restricted to a single centralized server
> or multiple servers.
> --> Might be a parent -> child relationship among configuration
> servers to segregate business units, or simply replication among
> servers for disaster recovery / business continuity purposes
> --> efficient, repeatable, and audit-able methodology for making
> changes to both individual sensors as well as pre-defined groups of
> sensors (e.g. dmz sensors, dns sensors, development lab sensors,
> etc...)
> --> My experience to date has been performing these kind of tasks with
> home-grown scripts, ssh, scp, audit logs, etc... However, it would be
> nice to find something a little more mature for this project.
>
> I have not used it, but there is a project called "Puppet" that looks
> like it might be a good candidate for trying to develop a framework
> along these lines:
> http://reductivelabs.com/trac/puppet/wiki/PuppetIntroduction
>
>
> 2) Centralized sensor and policy monitoring platform (or framework)
> --> This is similar to the "management framework" concept, but the
> focus is more on device health monitoring... and possibly policy
> integrity monitoring...
> --> For this piece, I'm thinking of something that provides functions
> such as looking at memory utilization, cpu utilization, hard-drive
> space, network interface stats... and other "bits" such as dates and
> checksums for critical configuration files changed (e.g. detection
> policies, tuning policies, variable definitions, etc)...
>
> There are a number of open-source enterprise monitoring utilities out
> there. Here's one I've been playing with recently:
> http://www.zabbix.com/
>
>
> 3) Distributed Data Repositories
> I know we briefly touched on the database stuff when talking about
> schema design. I just wanted to add a plug for a couple of things
> here:
> --> encrypted communication channels (sensor -> DB or sensor -> sensor)
> --> ability to simultaneously log to 2 or more data repositories
>
> I strongly agree with the concept of designing modular solutions. So,
> these kind of features can be "bolted on" if they were required.
>
> Look forward to everyone's thoughts on how we can most effectively
> tackle problems of scale for large deployments.
>
> Cheers, John
> _______________________________________________
> Discussion mailing list
> Discussion at openinfosecfoundation.org
> http://lists.openinfosecfoundation.org/mailman/listinfo/discussion
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openinfosecfoundation.org/pipermail/discussion/attachments/20081128/70fc7fa7/attachment.html