From mcholste at gmail.com  Sat Jan  3 19:53:49 2009
From: mcholste at gmail.com (Martin Holste)
Date: Sat, 3 Jan 2009 18:53:49 -0600
Subject: [Discussion] Rules Syntax
In-Reply-To: <494E86B6.8030509@jonkmans.com>
References: <494ABC49.2040504@jonkmans.com>
	<200812201225.19575.c.criscione@securenetwork.it>
	<494E86B6.8030509@jonkmans.com>
Message-ID: <df9074860901031653mc38f6acqb5066e6853bfc25a@mail.gmail.com>

I think that Claudio's English signatures are good examples to start with.
Even a repository of paragraphs like that would be valuable to me.

A port-tracking database wouldn't be that big (as in, only a few gigs) to
store last remote port on a per-local-IP basis.  With decent indexing, it
would be extremely fast.

Regarding statistical analysis, I highly encourage the group to check out
the NFSen project (nfsen.sourceforge.net) for inspiration.  They have an
entire framework for statistical alerting on Netflow contained in a small
amount of very pluggable/extensible Perl packages. I'm extremely impressed
with its efficiency and the overall software architecture.  I've recently
implemented it in my org and it took almost zero effort.  In particular,
they have a plugin which applies a Holt-Winters exponential smoothing
algorithm to flows and alerts based on those statisical anomalies.  Email
alerts are standard, but there is a plugin for MySQL alert logging as well.
The quality of code is exceptional (I was very impressed to see so much
effort being spent on input validation!) and I plan on bolting it onto my
existing SIM.  I would think the Holt-Winters plugin code could be modified
to analyze a lot of input types.

I also want to point out that Netflow (or equivalent) is a great way to
disambiguate the inside IP addresses of a NAT point without having to
install a separate sensor.

As for rotating tcpdumps, I recommend checking out the methods both Time
Machine (http://www.net.t-labs.tu-berlin.de/research/tm/) and SANCP use to
decided whether to record traffic or not.  Setting it to ignore RTSP and
other types of bulky but useless network traffic can save a ton of disk
space.  By default, Time Machine will store only the first N bytes of
traffic per connection, so you can get a really great profile of a ton of
connections with a reasonable amount of disk.  For those of you with any
kind of budget at all, I would point out that you can build a 24 TB RAID
enclosure for under $4K (complete with hardware RAID5).  Disk is cheap!

That said, you can often get 80-90% of the intel you need with today's
malware by simply recording URL's via a web proxy or something like tshark,
and getting that into a database.  I am finding that more and more, sifting
through pcap's just ends up with me extracting the trail of URL's which
tells the whole story.  This trail is especially helpful when you use Anubis
from iseclab.org to sandbox-analyze a given URL.

--Martin

On Sun, Dec 21, 2008 at 10:11 AM, Matt Jonkman <jonkman at jonkmans.com> wrote:

>
> Claudio Criscione wrote:
> >
> > Well, what about:
> >
> > "if someone in my organization has never started any ftp traffic in the
> last
> > three months starts an ftp connection, notify me and start watching more
> > carefully that person. "
>
> I like this too. How do we store that kind of data for long term? Even
> if we were to just store last timestamp we saw that port in use on this
> IP that'd be a significant amount of data on the average net to go back
> months, no?
>
> How do we go after that then? (Call to the db experts out there)
>
> Use a sliding scale so as the user-defined storage space allocated fills
> up older data drops out?
>
> Use a limited range of ports, and/or group together high port ranges?
>
>
> >
> >  - Someone vs some machine
> > Using the IP address is still the only way to go in most cases, but we
> need
> > more sophisticate means to identify who's who as networks evolve (think
> about
> > whole cities behind a NAT)
>
> I think we should think more inside the firewall for these issues, no?
>
> There are ways, and several commercial products that track a user to an
> IP in realtime. Cisco I believe does, and others surely. LDAP
> integration/AD, netbios login monitoring, etc. It's possible, but it's a
> big thing to tackle. And likely we'd have patent conflicts. We can
> explore that though if there's a large enough driver to get it. Thoughts?
>
>
> > - in the last three monts can actually be translated to "is not used to"
> > or "does not usually"
> > The issue with statistical approaches is that you really have to develope
> > custom models. What about "signature based statistical models"?
>
> Yes, statistical approaches are tough. I'd like to see what is available
> out there in this area these days as far as open research. As I
> mentioned, I think it'll be a good use of some of our grant money to
> contract or grant fund a real statistician or group of such. Maybe we
> could get it made into a class project at a university somewhere under
> the guidance of an experienced statistician.
>
> >
> > - "watching more carefully"
> > I'm not sure we always want the same "resolution" on network traffic, and
> I
> > feel it would be great to be able to zoom on suspicious activity
> > automatically without having to carry the burden of logging everything
> > everytime
> >
>
> Another good point. Most folks these days do that with rotating
> tcpdumps, but you're time limited there. If you don't get to that alert
> before the pcap rotates out you've lost it. Are there better approaches
> out 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
>
>
> _______________________________________________
> 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/20090103/e4ffc63d/attachment.html

From jonkman at jonkmans.com  Tue Jan  6 19:56:03 2009
From: jonkman at jonkmans.com (Matt Jonkman)
Date: Tue, 06 Jan 2009 19:56:03 -0500
Subject: [Discussion] Features - Designing for Scaleability
In-Reply-To: <bea0bdd30811181047x6caff439v9c5546e9c2e5cf0b@mail.gmail.com>
References: <bea0bdd30811181047x6caff439v9c5546e9c2e5cf0b@mail.gmail.com>
Message-ID: <4963FDA3.2030301@jonkmans.com>

John Pritchard wrote:
> 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).

Agreed, absolutely. I'm really envisioning a framework where we do away
with the idea of individual sensors. Get rid of the idea of a bunch of
independent points and more toward a meshed look. Where all sensors are
aware of each other and the data in each, maybe even the state of each.
How to do that I dunno. Maybe using the database as a communication medium?

> 
> 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

Ya, that's what I was going for above. I like the parent
child/department idea. Have a central db of course, and maybe
sub-sensors and sub parents. Then state and information can be shared
more readily among related senors, like by location, or by perimeter vs
internal, user nets vs servers, etc.


> --> 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...)

I want a db based config for all sensors. The whole config file approach
to it is a pain. It might be easier to run a db loaded config and
provide a basic web page or config tool to load these into the db. Then
it'd be pretty easy to maintain change tracking and give permissions for
changes, 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
> 

Very interesting, anyone have experience with it?

> 
> 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)...
> 

Absolutely, great idea! I think that could even be db based as well.
insert stats every x seconds. Makes the sensors more disposable as well
as all data is in the db. Just plug in a new box and tell it where to
get/store it's stuff via db.


> 
> 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

Definitely on both. We know we'll need to support postgress, mysql and
oracle. Anything else?

I believe all three have an ssl or otherwise based encryption option.
Should be look to make our own vpn or rely on these?

Matt

> 
> 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

-- 
--------------------------------------------
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 Jan  6 20:00:52 2009
From: jonkman at jonkmans.com (Matt Jonkman)
Date: Tue, 06 Jan 2009 20:00:52 -0500
Subject: [Discussion] Features
In-Reply-To: <ac597e6e0811111656i5ea4ff86ta7c63dfae55ee285@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>
	<ac597e6e0811111656i5ea4ff86ta7c63dfae55ee285@mail.gmail.com>
Message-ID: <4963FEC4.8000207@jonkmans.com>

David Glosser wrote:
> 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...

On the note of centralized state, maybe the dns lookups could be
centrally stored but cached on each sensor. So in theory a central
process could do any lookups, or do refresh lookups, and propagate to
sensors?

Matt

> 
> 
> 
> 
>>>> 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....
>>>>

-- 
--------------------------------------------
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 Jan  6 20:02:13 2009
From: jonkman at jonkmans.com (Matt Jonkman)
Date: Tue, 06 Jan 2009 20:02:13 -0500
Subject: [Discussion] Rules Syntax
In-Reply-To: <df9074860901031653mc38f6acqb5066e6853bfc25a@mail.gmail.com>
References: <494ABC49.2040504@jonkmans.com>	
	<200812201225.19575.c.criscione@securenetwork.it>	
	<494E86B6.8030509@jonkmans.com>
	<df9074860901031653mc38f6acqb5066e6853bfc25a@mail.gmail.com>
Message-ID: <4963FF15.5010801@jonkmans.com>


Martin Holste wrote:
> I think that Claudio's English signatures are good examples to start
> with.  Even a repository of paragraphs like that would be valuable to me.
> 
> A port-tracking database wouldn't be that big (as in, only a few gigs)
> to store last remote port on a per-local-IP basis.  With decent
> indexing, it would be extremely fast.

Maybe some kind of hash lookup, or bloom filter kinda thing?

> 
> Regarding statistical analysis, I highly encourage the group to check
> out the NFSen project (nfsen.sourceforge.net
> <http://nfsen.sourceforge.net>) for inspiration.  They have an entire
> framework for statistical alerting on Netflow contained in a small
> amount of very pluggable/extensible Perl packages. I'm extremely
> impressed with its efficiency and the overall software architecture. 
> I've recently implemented it in my org and it took almost zero effort. 
> In particular, they have a plugin which applies a Holt-Winters
> exponential smoothing algorithm to flows and alerts based on those
> statisical anomalies.  Email alerts are standard, but there is a plugin
> for MySQL alert logging as well.  The quality of code is exceptional (I
> was very impressed to see so much effort being spent on input
> validation!) and I plan on bolting it onto my existing SIM.  I would
> think the Holt-Winters plugin code could be modified to analyze a lot of
> input types.

This also looks promising. Anyone used it? Thoughts?

Matt
> 
> On Sun, Dec 21, 2008 at 10:11 AM, Matt Jonkman <jonkman at jonkmans.com
> <mailto:jonkman at jonkmans.com>> wrote:
> 
> 
>     Claudio Criscione wrote:
>     >
>     > Well, what about:
>     >
>     > "if someone in my organization has never started any ftp traffic
>     in the last
>     > three months starts an ftp connection, notify me and start
>     watching more
>     > carefully that person. "
> 
>     I like this too. How do we store that kind of data for long term? Even
>     if we were to just store last timestamp we saw that port in use on this
>     IP that'd be a significant amount of data on the average net to go back
>     months, no?
> 
>     How do we go after that then? (Call to the db experts out there)
> 
>     Use a sliding scale so as the user-defined storage space allocated fills
>     up older data drops out?
> 
>     Use a limited range of ports, and/or group together high port ranges?
> 
> 
>     >
>     >  - Someone vs some machine
>     > Using the IP address is still the only way to go in most cases,
>     but we need
>     > more sophisticate means to identify who's who as networks evolve
>     (think about
>     > whole cities behind a NAT)
> 
>     I think we should think more inside the firewall for these issues, no?
> 
>     There are ways, and several commercial products that track a user to an
>     IP in realtime. Cisco I believe does, and others surely. LDAP
>     integration/AD, netbios login monitoring, etc. It's possible, but it's a
>     big thing to tackle. And likely we'd have patent conflicts. We can
>     explore that though if there's a large enough driver to get it.
>     Thoughts?
> 
> 
>     > - in the last three monts can actually be translated to "is not
>     used to"
>     > or "does not usually"
>     > The issue with statistical approaches is that you really have to
>     develope
>     > custom models. What about "signature based statistical models"?
> 
>     Yes, statistical approaches are tough. I'd like to see what is available
>     out there in this area these days as far as open research. As I
>     mentioned, I think it'll be a good use of some of our grant money to
>     contract or grant fund a real statistician or group of such. Maybe we
>     could get it made into a class project at a university somewhere under
>     the guidance of an experienced statistician.
> 
>     >
>     > - "watching more carefully"
>     > I'm not sure we always want the same "resolution" on network
>     traffic, and I
>     > feel it would be great to be able to zoom on suspicious activity
>     > automatically without having to carry the burden of logging everything
>     > everytime
>     >
> 
>     Another good point. Most folks these days do that with rotating
>     tcpdumps, but you're time limited there. If you don't get to that alert
>     before the pcap rotates out you've lost it. Are there better approaches
>     out 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
> 
> 
>     _______________________________________________
>     Discussion mailing list
>     Discussion at openinfosecfoundation.org
>     <mailto: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 c.criscione at securenetwork.it  Wed Jan  7 03:27:07 2009
From: c.criscione at securenetwork.it (Claudio Criscione)
Date: Wed, 7 Jan 2009 09:27:07 +0100
Subject: [Discussion] Rules Syntax
In-Reply-To: <df9074860901031653mc38f6acqb5066e6853bfc25a@mail.gmail.com>
References: <494ABC49.2040504@jonkmans.com> <494E86B6.8030509@jonkmans.com>
	<df9074860901031653mc38f6acqb5066e6853bfc25a@mail.gmail.com>
Message-ID: <200901070927.07509.c.criscione@securenetwork.it>

Happy new year ;-)

On Sunday 04 January 2009 01:53:49 Martin Holste wrote:
> I think that Claudio's English signatures are good examples to start with.
> Even a repository of paragraphs like that would be valuable to me.

I'm not sure a repository would really be useful - apart from inspiration. I 
feel we need some sort of engine able to parse user-provided rules like that 
one. Maybe something "a-la Peakflow", but far more flexible: this kind of alerts 
are more about what's normal in your network than what's anomalous (i.e. 
related to an attack). So it's really important to be able to let each user 
build their own rulebase, or even better to be able to infer rules from actual 
network flows...

> Regarding statistical analysis, I highly encourage the group to check out
> the NFSen project (nfsen.sourceforge.net) for inspiration.  They have an
[...]
> existing SIM.  I would think the Holt-Winters plugin code could be modified
> to analyze a lot of input types.

Seems an interesting project, if a bit outdated. As of today, which kind of 
attacks can you detect in your organization with this tool?

> space.  By default, Time Machine will store only the first N bytes of
> traffic per connection, so you can get a really great profile of a ton of
> connections with a reasonable amount of disk.  For those of you with any

Which brings us to the "size of the window" issue... but that's another story.

Matt wrote:
> > How do we go after that then? (Call to the db experts out there)
> > Use a sliding scale so as the user-defined storage space allocated fills
> > up older data drops out?

I would definitly thing of some aggregation scheme... I can't remember the 
proper name but I'm sure any warehousing expert could enlighten me. We could 
have a greater resolution of data on, say, a week. Then we start to aggregate, 
for instance instead of saving the data we only record the protocol and the 
ports for up to one month, and we compress tcpdump data for a week. After one 
month, we only record IP endpoints and delete everything else.
In such a way, we somehow mitigate "rotation" issues...

> > integration/AD, netbios login monitoring, etc. It's possible, but it's a
> > big thing to tackle. And likely we'd have patent conflicts. We can
> > explore that though if there's a large enough driver to get it. Thoughts?

I think that we should build as many "plugin hooks" as possible. Let those who 
have the patents do the work, if they care... but an integration with AD 
(which is one of the most widely used "IM solutions") would be useful and 
interesting.

> > contract or grant fund a real statistician or group of such. Maybe we
> > could get it made into a class project at a university somewhere under
> > the guidance of an experienced statistician.

I'm sure many universities would be interested but, in order to have useful 
results, very very very detailed requirements should be provided :)

-- 
Claudio Criscione

Secure Network S.r.l
Via Venezia, 23 - 20099 Sesto San Giovanni (MI) - Italia
Tel: +39 02.24126788 Mob: +39 392 3389178
email: c.criscione at securenetwork.it
web: www.securenetwork.it

From lists at inliniac.net  Sun Jan 11 13:30:35 2009
From: lists at inliniac.net (Victor Julien)
Date: Sun, 11 Jan 2009 19:30:35 +0100
Subject: [Discussion] blog about oisf
Message-ID: <496A3ACB.2000803@inliniac.net>

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

Hi everyone,

I assume not everyone will know my network security blog at
http://www.inliniac.net/blog/ Among other things I'm writing about the
Open Infosec Foundation, including about the prototype code I'm
developing for the engine... if you're interested in reading about it,
have a look! If you just care about OISF stuff, use
http://www.inliniac.net/blog/category/oisf

Cheers,
Victor

- --
- ---------------------------------------------
Victor Julien
http://www.inliniac.net/
PGP: http://www.inliniac.net/victorjulien.asc
- ---------------------------------------------

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAklqOsgACgkQiSMBBAuniMcaygCfeO+SyycFsjqszZFVEwW6nMgO
Di8An2Xx7kKXuN6WDR55w5lz4wWok8a7
=gTFP
-----END PGP SIGNATURE-----

From mcholste at gmail.com  Thu Jan 15 13:17:58 2009
From: mcholste at gmail.com (Martin Holste)
Date: Thu, 15 Jan 2009 12:17:58 -0600
Subject: [Discussion] Rules Syntax
In-Reply-To: <200901070927.07509.c.criscione@securenetwork.it>
References: <494ABC49.2040504@jonkmans.com> <494E86B6.8030509@jonkmans.com>
	<df9074860901031653mc38f6acqb5066e6853bfc25a@mail.gmail.com>
	<200901070927.07509.c.criscione@securenetwork.it>
Message-ID: <df9074860901151017i50e28534x2a18dd819a880607@mail.gmail.com>

I agree with Claudio regarding the plugin hooks.  That's what's so
inspirational to me in the Nfsen project: they made the plugins really quite
simple to integrate, yet very powerful.  A good example is the Botnet
plugin, which is what we've had the most success with thus far.  It works by
grabbing a blacklist (I am using the Emerging Threats Bot CC list), parsing
it out of Snort rule format and putting it into Nfsen filter format, then
checking the traffic every five minutes to see if there are any hits.  I've
customized it slightly to exclude port 25 and 53 traffic (since that ends up
being way too chatty) and I've tweaked the configuration to only bother me
when there are more than a few packets.  It then logs an alert to the alert
database and sends me an email.  My SIM can query the database to grab the
latest alerts and do any follow-up incident creation, etc.

This setup has proven to be very useful, and has saved our butts a couple of
times with extra-careful malware.  (As in unpacked, sandbox-defeating
malware).  The project itself is getting on in years, but the code
architecture is really effective and well-suited to its purpose.  Namely, it
doesn't try to do everything, it's clear and concise, and it has a simple
way to extend it: create a package which exports functions from the short
and predefined list of plugin functions (e.g. alert_condition,
lookup_address, etc.), drop your package in the plugins dir, and boom, it's
now part of the system and can be implemented from the web GUI.  I'm looking
to create a meta-blacklist plugin in the near future that would implement
some basic scoring across many different blacklists.

My point is that though the Nfsen project's default install was reasonably
useful, it's true helpfulness has been the ease with which it can be
extended and integrated with our environment.

--Martin

On Wed, Jan 7, 2009 at 2:27 AM, Claudio Criscione <
c.criscione at securenetwork.it> wrote:

> Happy new year ;-)
>
> On Sunday 04 January 2009 01:53:49 Martin Holste wrote:
> > I think that Claudio's English signatures are good examples to start
> with.
> > Even a repository of paragraphs like that would be valuable to me.
>
> I'm not sure a repository would really be useful - apart from inspiration.
> I
> feel we need some sort of engine able to parse user-provided rules like
> that
> one. Maybe something "a-la Peakflow", but far more flexible: this kind of
> alerts
> are more about what's normal in your network than what's anomalous (i.e.
> related to an attack). So it's really important to be able to let each user
> build their own rulebase, or even better to be able to infer rules from
> actual
> network flows...
>
> > Regarding statistical analysis, I highly encourage the group to check out
> > the NFSen project (nfsen.sourceforge.net) for inspiration.  They have an
> [...]
> > existing SIM.  I would think the Holt-Winters plugin code could be
> modified
> > to analyze a lot of input types.
>
> Seems an interesting project, if a bit outdated. As of today, which kind of
> attacks can you detect in your organization with this tool?
>
> > space.  By default, Time Machine will store only the first N bytes of
> > traffic per connection, so you can get a really great profile of a ton of
> > connections with a reasonable amount of disk.  For those of you with any
>
> Which brings us to the "size of the window" issue... but that's another
> story.
>
> Matt wrote:
> > > How do we go after that then? (Call to the db experts out there)
> > > Use a sliding scale so as the user-defined storage space allocated
> fills
> > > up older data drops out?
>
> I would definitly thing of some aggregation scheme... I can't remember the
> proper name but I'm sure any warehousing expert could enlighten me. We
> could
> have a greater resolution of data on, say, a week. Then we start to
> aggregate,
> for instance instead of saving the data we only record the protocol and the
> ports for up to one month, and we compress tcpdump data for a week. After
> one
> month, we only record IP endpoints and delete everything else.
> In such a way, we somehow mitigate "rotation" issues...
>
> > > integration/AD, netbios login monitoring, etc. It's possible, but it's
> a
> > > big thing to tackle. And likely we'd have patent conflicts. We can
> > > explore that though if there's a large enough driver to get it.
> Thoughts?
>
> I think that we should build as many "plugin hooks" as possible. Let those
> who
> have the patents do the work, if they care... but an integration with AD
> (which is one of the most widely used "IM solutions") would be useful and
> interesting.
>
> > > contract or grant fund a real statistician or group of such. Maybe we
> > > could get it made into a class project at a university somewhere under
> > > the guidance of an experienced statistician.
>
> I'm sure many universities would be interested but, in order to have useful
> results, very very very detailed requirements should be provided :)
>
> --
> Claudio Criscione
>
> Secure Network S.r.l
> Via Venezia, 23 - 20099 Sesto San Giovanni (MI) - Italia
> Tel: +39 02.24126788 Mob: +39 392 3389178
> email: c.criscione at securenetwork.it
> web: www.securenetwork.it
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openinfosecfoundation.org/pipermail/discussion/attachments/20090115/f6f1d0a6/attachment.html

From mcholste at gmail.com  Thu Jan 15 13:35:14 2009
From: mcholste at gmail.com (Martin Holste)
Date: Thu, 15 Jan 2009 12:35:14 -0600
Subject: [Discussion] Features - Designing for Scaleability
In-Reply-To: <4963FDA3.2030301@jonkmans.com>
References: <bea0bdd30811181047x6caff439v9c5546e9c2e5cf0b@mail.gmail.com>
	<4963FDA3.2030301@jonkmans.com>
Message-ID: <df9074860901151035r2f83230fw77fd7c16192c33db@mail.gmail.com>

Regarding sensor-sensor communcation, I recommend using OpenVPN for all
communication since it's free, cross-platform, provides built-in
compression, has easy configuration, it's PKI infrastructure based, and
makes debugging much easier since you can sniff your tun0 socket.  It also
makes your host firewall rules much more simple.

--Martin

On Tue, Jan 6, 2009 at 6:56 PM, Matt Jonkman <jonkman at jonkmans.com> wrote:

> John Pritchard wrote:
> > 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).
>
> Agreed, absolutely. I'm really envisioning a framework where we do away
> with the idea of individual sensors. Get rid of the idea of a bunch of
> independent points and more toward a meshed look. Where all sensors are
> aware of each other and the data in each, maybe even the state of each.
> How to do that I dunno. Maybe using the database as a communication medium?
>
> >
> > 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
>
> Ya, that's what I was going for above. I like the parent
> child/department idea. Have a central db of course, and maybe
> sub-sensors and sub parents. Then state and information can be shared
> more readily among related senors, like by location, or by perimeter vs
> internal, user nets vs servers, etc.
>
>
> > --> 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...)
>
> I want a db based config for all sensors. The whole config file approach
> to it is a pain. It might be easier to run a db loaded config and
> provide a basic web page or config tool to load these into the db. Then
> it'd be pretty easy to maintain change tracking and give permissions for
> changes, 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
> >
>
> Very interesting, anyone have experience with it?
>
> >
> > 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)...
> >
>
> Absolutely, great idea! I think that could even be db based as well.
> insert stats every x seconds. Makes the sensors more disposable as well
> as all data is in the db. Just plug in a new box and tell it where to
> get/store it's stuff via db.
>
>
> >
> > 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
>
> Definitely on both. We know we'll need to support postgress, mysql and
> oracle. Anything else?
>
> I believe all three have an ssl or otherwise based encryption option.
> Should be look to make our own vpn or rely on these?
>
> Matt
>
> >
> > 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
>
> --
> --------------------------------------------
> 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/20090115/de313e42/attachment-0001.html

From frank at knobbe.us  Thu Jan 15 18:57:05 2009
From: frank at knobbe.us (Frank Knobbe)
Date: Thu, 15 Jan 2009 17:57:05 -0600
Subject: [Discussion] Features - Designing for Scaleability
In-Reply-To: <df9074860901151035r2f83230fw77fd7c16192c33db@mail.gmail.com>
References: <bea0bdd30811181047x6caff439v9c5546e9c2e5cf0b@mail.gmail.com>
	<4963FDA3.2030301@jonkmans.com>
	<df9074860901151035r2f83230fw77fd7c16192c33db@mail.gmail.com>
Message-ID: <1232063825.17526.7.camel@localhost>

On Thu, 2009-01-15 at 12:35 -0600, Martin Holste wrote:
> Regarding sensor-sensor communcation, I recommend using OpenVPN for
> all communication since it's free, cross-platform, provides built-in
> compression, has easy configuration, it's PKI infrastructure based,
> and makes debugging much easier since you can sniff your tun0 socket.
> It also makes your host firewall rules much more simple.

But then you have administration overhead, right? (Sorry, I don't use
OpenVPN. All my VPN's are SSH-based).

Wouldn't it make more sense to use some sort of cloud/P2P-based
sensor-to-sensor communication that is able to "find" other sensors to
reduce admin tasks? Give it a name and let it join the sensor cloud.  :)
I think that may be what Matt was eluding to in regards to sensors being
aware of each other.

Cheers,
Frank




From scheidell at secnap.net  Thu Jan 15 19:07:18 2009
From: scheidell at secnap.net (Michael Scheidell)
Date: Thu, 15 Jan 2009 19:07:18 -0500
Subject: [Discussion] Features - Designing for Scaleability
Message-ID: <048701c9776e$666e6c9c$0d01460a@secnap.com>

Openvpn does have a lot of overhead,and you need to decide if sensor-sensor communications is top or udp (then use the other for openvpn ). Using scripts ic you star config you can identify all the sensors real easy. We use it here.

-----Original Message-----
From: Frank Knobbe <frank at knobbe.us>
Sent: Thursday, January 15, 2009 6:57 PM
To: Martin Holste <mcholste at gmail.com>
Cc: discussion at openinfosecfoundation.org <discussion at openinfosecfoundation.org>
Subject: Re: [Discussion] Features - Designing for Scaleability

On Thu, 2009-01-15 at 12:35 -0600, Martin Holste wrote:
> Regarding sensor-sensor communcation, I recommend using OpenVPN for
> all communication since it's free, cross-platform, provides built-in
> compression, has easy configuration, it's PKI infrastructure based,
> and makes debugging much easier since you can sniff your tun0 socket.
> It also makes your host firewall rules much more simple.

But then you have administration overhead, right? (Sorry, I don't use
OpenVPN. All my VPN's are SSH-based).

Wouldn't it make more sense to use some sort of cloud/P2P-based
sensor-to-sensor communication that is able to "find" other sensors to
reduce admin tasks? Give it a name and let it join the sensor cloud.  :)
I think that may be what Matt was eluding to in regards to sensors being
aware of each other.

Cheers,
Frank



_______________________________________________
Discussion mailing list
Discussion at openinfosecfoundation.org
http://lists.openinfosecfoundation.org/mailman/listinfo/discussion

_________________________________________________________________________
This email has been scanned and certified safe by SpammerTrap(r). 
For Information please see http://www.secnap.com/products/spammertrap/
_________________________________________________________________________

From jonkman at jonkmans.com  Thu Jan 15 23:41:06 2009
From: jonkman at jonkmans.com (Matt Jonkman)
Date: Thu, 15 Jan 2009 23:41:06 -0500
Subject: [Discussion] Features - Designing for Scaleability
In-Reply-To: <1232063825.17526.7.camel@localhost>
References: <bea0bdd30811181047x6caff439v9c5546e9c2e5cf0b@mail.gmail.com>	
	<4963FDA3.2030301@jonkmans.com>	
	<df9074860901151035r2f83230fw77fd7c16192c33db@mail.gmail.com>
	<1232063825.17526.7.camel@localhost>
Message-ID: <49700FE2.4060409@jonkmans.com>

I was kind of thinking something along the lines of the sensors being
aware, but assuming they could all communicate with eachother may be too
much in many places. I think a hub and spoke architecture would probably
be best. But the communication method would probably be quite efficient
if we just used udp and internal encryption. i.e. udp with the payload
encrypted to preshared keys.

Matt

Frank Knobbe wrote:
> On Thu, 2009-01-15 at 12:35 -0600, Martin Holste wrote:
>> Regarding sensor-sensor communcation, I recommend using OpenVPN for
>> all communication since it's free, cross-platform, provides built-in
>> compression, has easy configuration, it's PKI infrastructure based,
>> and makes debugging much easier since you can sniff your tun0 socket.
>> It also makes your host firewall rules much more simple.
> 
> But then you have administration overhead, right? (Sorry, I don't use
> OpenVPN. All my VPN's are SSH-based).
> 
> Wouldn't it make more sense to use some sort of cloud/P2P-based
> sensor-to-sensor communication that is able to "find" other sensors to
> reduce admin tasks? Give it a name and let it join the sensor cloud.  :)
> I think that may be what Matt was eluding to in regards to sensors being
> aware of each other.
> 
> Cheers,
> Frank
> 
> 
> 

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

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



From ish at unx.ca  Thu Jan 15 23:38:59 2009
From: ish at unx.ca (Jason Ish)
Date: Thu, 15 Jan 2009 22:38:59 -0600
Subject: [Discussion] Features - Designing for Scaleability
In-Reply-To: <49700FE2.4060409@jonkmans.com>
References: <bea0bdd30811181047x6caff439v9c5546e9c2e5cf0b@mail.gmail.com>
	<4963FDA3.2030301@jonkmans.com>
	<df9074860901151035r2f83230fw77fd7c16192c33db@mail.gmail.com>
	<1232063825.17526.7.camel@localhost> <49700FE2.4060409@jonkmans.com>
Message-ID: <36e1a6ca0901152038q79d2a04cq4622d8556fc8912f@mail.gmail.com>

I know that some large companies and government agencies aren't to
keen when they've found out you are using your own encryption scheme.
They'd much rather see something along the lines of TLS.  I think TCP
can be quite efficient, its also much easier to keep track of state if
you need to.  Lately I've been looking at Google protocol buffers, and
it is quite efficient at encoding data over the wire.

Hub and spoke sounds about right I think.  I could imagine something
where a company has their sensors talking to their server.  Their
server could then optionally hook into the global network where
information such as IP reputation could be distributed, or even
notification of new rules.  Sensors wouldn't talk directly to each
other in this scenario but would send a message to their server which
would then broadcast to its connected agents, and perhaps upstream
into the bigger network.

Jason

On Thu, Jan 15, 2009 at 10:41 PM, Matt Jonkman <jonkman at jonkmans.com> wrote:
> I was kind of thinking something along the lines of the sensors being
> aware, but assuming they could all communicate with eachother may be too
> much in many places. I think a hub and spoke architecture would probably
> be best. But the communication method would probably be quite efficient
> if we just used udp and internal encryption. i.e. udp with the payload
> encrypted to preshared keys.
>
> Matt
>
> Frank Knobbe wrote:
>> On Thu, 2009-01-15 at 12:35 -0600, Martin Holste wrote:
>>> Regarding sensor-sensor communcation, I recommend using OpenVPN for
>>> all communication since it's free, cross-platform, provides built-in
>>> compression, has easy configuration, it's PKI infrastructure based,
>>> and makes debugging much easier since you can sniff your tun0 socket.
>>> It also makes your host firewall rules much more simple.
>>
>> But then you have administration overhead, right? (Sorry, I don't use
>> OpenVPN. All my VPN's are SSH-based).
>>
>> Wouldn't it make more sense to use some sort of cloud/P2P-based
>> sensor-to-sensor communication that is able to "find" other sensors to
>> reduce admin tasks? Give it a name and let it join the sensor cloud.  :)
>> I think that may be what Matt was eluding to in regards to sensors being
>> aware of each other.
>>
>> Cheers,
>> Frank
>>
>>
>>
>
> --
> --------------------------------------------
> 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
>
>

From ddpbsd at gmail.com  Fri Jan 16 09:25:43 2009
From: ddpbsd at gmail.com (ddp)
Date: Fri, 16 Jan 2009 09:25:43 -0500
Subject: [Discussion] Features - Designing for Scaleability
In-Reply-To: <49700FE2.4060409@jonkmans.com>
References: <bea0bdd30811181047x6caff439v9c5546e9c2e5cf0b@mail.gmail.com>
	<4963FDA3.2030301@jonkmans.com>
	<df9074860901151035r2f83230fw77fd7c16192c33db@mail.gmail.com>
	<1232063825.17526.7.camel@localhost> <49700FE2.4060409@jonkmans.com>
Message-ID: <ad3aaa740901160625g17d7a781x815e8d81087fb20a@mail.gmail.com>

XMPP (http://xmpp.org/tech/core.shtml) has some interesting features
that might make
it worth a look. I've been considering it for a couple of projects in
my head for a little
while now.

dan

On Thu, Jan 15, 2009 at 11:41 PM, Matt Jonkman <jonkman at jonkmans.com> wrote:
> I was kind of thinking something along the lines of the sensors being
> aware, but assuming they could all communicate with eachother may be too
> much in many places. I think a hub and spoke architecture would probably
> be best. But the communication method would probably be quite efficient
> if we just used udp and internal encryption. i.e. udp with the payload
> encrypted to preshared keys.
>
> Matt

From mcholste at gmail.com  Fri Jan 16 10:23:06 2009
From: mcholste at gmail.com (Martin Holste)
Date: Fri, 16 Jan 2009 09:23:06 -0600
Subject: [Discussion] Features - Designing for Scaleability
In-Reply-To: <36e1a6ca0901152038q79d2a04cq4622d8556fc8912f@mail.gmail.com>
References: <bea0bdd30811181047x6caff439v9c5546e9c2e5cf0b@mail.gmail.com>
	<4963FDA3.2030301@jonkmans.com>
	<df9074860901151035r2f83230fw77fd7c16192c33db@mail.gmail.com>
	<1232063825.17526.7.camel@localhost> <49700FE2.4060409@jonkmans.com>
	<36e1a6ca0901152038q79d2a04cq4622d8556fc8912f@mail.gmail.com>
Message-ID: <df9074860901160723n3837d0f2k265b77bb61042561@mail.gmail.com>

Since all of the OpenVPN nodes use identical config files, there really is
very little admin overhead.  You just put a different private key on each
one which is generated in one simple command with the shell script included
in the OpenVPN tarball.  (Actually, you can use the same private key if you
don't care about being able to revoke a specific one).  So, it takes about
60 seconds to add a node and they all "discover" each other rather easily.
>From there, all the communication is over standard IP as far as the apps are
concerned, which really really helps in troubleshooting.

However, Jason's point regarding allowed protocols in certain environments
is a valid one, so I can definitely see TLS as an advantage there.  My
concern is to keep whatever we use a socket or tunnel and not something
baked into the application.  That's because it's a huge headache to make
sure that every component of the system is capable of encrypting its
communication as opposed to the comfort of knowing that anything routed to
specific addresses will absolutely be encrypted.  If you know you've got an
encrypted tunnel from point A to point B, you can always resort to
wget-style hackery if you need to, you can implement any module you want
without worrying about encryption, and best of all, you are guaranteed to
only have to setup the certificates (or keys) once for each node, instead of
once per node per add-on application.  There's also the whole controlled
export of strong encryption pitfall for some of our international
colleagues.

--Martin

On Thu, Jan 15, 2009 at 10:38 PM, Jason Ish <ish at unx.ca> wrote:

> I know that some large companies and government agencies aren't to
> keen when they've found out you are using your own encryption scheme.
> They'd much rather see something along the lines of TLS.  I think TCP
> can be quite efficient, its also much easier to keep track of state if
> you need to.  Lately I've been looking at Google protocol buffers, and
> it is quite efficient at encoding data over the wire.
>
> Hub and spoke sounds about right I think.  I could imagine something
> where a company has their sensors talking to their server.  Their
> server could then optionally hook into the global network where
> information such as IP reputation could be distributed, or even
> notification of new rules.  Sensors wouldn't talk directly to each
> other in this scenario but would send a message to their server which
> would then broadcast to its connected agents, and perhaps upstream
> into the bigger network.
>
> Jason
>
> On Thu, Jan 15, 2009 at 10:41 PM, Matt Jonkman <jonkman at jonkmans.com>
> wrote:
> > I was kind of thinking something along the lines of the sensors being
> > aware, but assuming they could all communicate with eachother may be too
> > much in many places. I think a hub and spoke architecture would probably
> > be best. But the communication method would probably be quite efficient
> > if we just used udp and internal encryption. i.e. udp with the payload
> > encrypted to preshared keys.
> >
> > Matt
> >
> > Frank Knobbe wrote:
> >> On Thu, 2009-01-15 at 12:35 -0600, Martin Holste wrote:
> >>> Regarding sensor-sensor communcation, I recommend using OpenVPN for
> >>> all communication since it's free, cross-platform, provides built-in
> >>> compression, has easy configuration, it's PKI infrastructure based,
> >>> and makes debugging much easier since you can sniff your tun0 socket.
> >>> It also makes your host firewall rules much more simple.
> >>
> >> But then you have administration overhead, right? (Sorry, I don't use
> >> OpenVPN. All my VPN's are SSH-based).
> >>
> >> Wouldn't it make more sense to use some sort of cloud/P2P-based
> >> sensor-to-sensor communication that is able to "find" other sensors to
> >> reduce admin tasks? Give it a name and let it join the sensor cloud.  :)
> >> I think that may be what Matt was eluding to in regards to sensors being
> >> aware of each other.
> >>
> >> Cheers,
> >> Frank
> >>
> >>
> >>
> >
> > --
> > --------------------------------------------
> > 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
> >
> >
> _______________________________________________
> 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/20090116/0cd02230/attachment-0001.html

From c.criscione at securenetwork.it  Sun Jan 18 13:18:24 2009
From: c.criscione at securenetwork.it (Claudio Criscione)
Date: Sun, 18 Jan 2009 19:18:24 +0100
Subject: [Discussion] Hooks for Other than Blocking
In-Reply-To: <494E8733.4040801@jonkmans.com>
References: <494C0140.2010606@jonkmans.com>
	<200812201216.53429.c.criscione@securenetwork.it>
	<494E8733.4040801@jonkmans.com>
Message-ID: <200901181918.24833.c.criscione@securenetwork.it>

On Sunday 21 December 2008 19:13:07 Matt Jonkman wrote:
> Claudio Criscione wrote:
> >  Redirection could also be used to escalate to more CPU intensive checks
> > (antiviruses?),
> I like that idea. Use circumstances to help decide if a binary needs to
> be quarantined/av scanned. Maybe source, have we seen god/bad binaries
> from this source before, size of the binary (haven't seen many 50meg
> viruses of late), etc. What other factors might we consider?

For instance cross checks leveraging big databases (like comparisons on log 
files) or in memory checks on potentially compromised machines.
I think what really matters at this stage is to define a logical element in the 
architecture, the details of what can be done could be sorted out later maybe, 
or not?


> >  Think about blocking some "high confidence" attacks and introducing some
> > human interaction on more uncertain results in order to improve detection
> > with time.
> What kind of human interaction do you mean here? Human approval?

For instance, or human confirmation. Even a signature based system could benefit 
from such an engine. think about "proposed" signature: if you are not sure 
that the signature is false-positive prone you assign it to a specific group 
and every time an alert is generated you require the user to say "true or 
false", thus either "improving" the signature (automatically or via a human, 
p2p signature review network) or assigning a minor or major weight to it in 
your system in order to have less false positives and eventually promote or 
remove the signature.

If we think of any anomaly based system, instead, the benefits are quite 
obvious.

Sorry for the late answer ;)

-- 
Claudio Criscione

Secure Network S.r.l
Via Venezia, 23 - 20099 Sesto San Giovanni (MI) - Italia
Tel: +39 02.24126788 Mob: +39 392 3389178
email: c.criscione at securenetwork.it
web: www.securenetwork.it

From famousjs at gmail.com  Sun Jan 25 11:38:50 2009
From: famousjs at gmail.com (Josh Smith)
Date: Sun, 25 Jan 2009 11:38:50 -0500
Subject: [Discussion] Binary Signature Detection
Message-ID: <e7646750901250838l1c546b6ej1cec7e79ff17aaaf@mail.gmail.com>

I have been working on converting the PEiD database of binary packer
signatures straight to snort signatures.  I've been refining my
signatures with other members from Emerging Threats, and have over
10,000 snort signatures for packers.  I was told this may be a good
topic to bring up (binary packer detection) for OISF.

-Josh

From david.glosser at gmail.com  Sun Jan 25 11:58:22 2009
From: david.glosser at gmail.com (David Glosser)
Date: Sun, 25 Jan 2009 11:58:22 -0500
Subject: [Discussion] Binary Signature Detection
In-Reply-To: <e7646750901250838l1c546b6ej1cec7e79ff17aaaf@mail.gmail.com>
References: <e7646750901250838l1c546b6ej1cec7e79ff17aaaf@mail.gmail.com>
Message-ID: <ac597e6e0901250858g9a31b02ued47e569a3365df6@mail.gmail.com>

wow! is there any way to have a smaller list of "active" sigs? (or would
that "smaller" list still be too large for most snort installations)?



On Sun, Jan 25, 2009 at 11:38 AM, Josh Smith <famousjs at gmail.com> wrote:

> I have been working on converting the PEiD database of binary packer
> signatures straight to snort signatures.  I've been refining my
> signatures with other members from Emerging Threats, and have over
> 10,000 snort signatures for packers.  I was told this may be a good
> topic to bring up (binary packer detection) for OISF.
>
> -Josh
> _______________________________________________
> 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/20090125/562874bd/attachment.html

From famousjs at gmail.com  Sun Jan 25 12:03:02 2009
From: famousjs at gmail.com (Josh Smith)
Date: Sun, 25 Jan 2009 12:03:02 -0500
Subject: [Discussion] Binary Signature Detection
In-Reply-To: <ac597e6e0901250858g9a31b02ued47e569a3365df6@mail.gmail.com>
References: <e7646750901250838l1c546b6ej1cec7e79ff17aaaf@mail.gmail.com>
	<ac597e6e0901250858g9a31b02ued47e569a3365df6@mail.gmail.com>
Message-ID: <e7646750901250903p3a63cd18y11ca837b52327473@mail.gmail.com>

David,

Well I originally converted the database file they offer on the PEiD
website, and that was about 1500 signatures.  Now I've just been
collecting database files from around the internet.  The one I
originally did may be dated, but still applies to quite a few binary
signatures.

-Josh

On Sun, Jan 25, 2009 at 11:58 AM, David Glosser <david.glosser at gmail.com> wrote:
> wow! is there any way to have a smaller list of "active" sigs? (or would
> that "smaller" list still be too large for most snort installations)?
>
>
>
> On Sun, Jan 25, 2009 at 11:38 AM, Josh Smith <famousjs at gmail.com> wrote:
>>
>> I have been working on converting the PEiD database of binary packer
>> signatures straight to snort signatures.  I've been refining my
>> signatures with other members from Emerging Threats, and have over
>> 10,000 snort signatures for packers.  I was told this may be a good
>> topic to bring up (binary packer detection) for OISF.
>>
>> -Josh
>> _______________________________________________
>> Discussion mailing list
>> Discussion at openinfosecfoundation.org
>> http://lists.openinfosecfoundation.org/mailman/listinfo/discussion
>
>

From mcholste at gmail.com  Sun Jan 25 14:56:09 2009
From: mcholste at gmail.com (Martin Holste)
Date: Sun, 25 Jan 2009 13:56:09 -0600
Subject: [Discussion] Binary Signature Detection
In-Reply-To: <e7646750901250903p3a63cd18y11ca837b52327473@mail.gmail.com>
References: <e7646750901250838l1c546b6ej1cec7e79ff17aaaf@mail.gmail.com>
	<ac597e6e0901250858g9a31b02ued47e569a3365df6@mail.gmail.com>
	<e7646750901250903p3a63cd18y11ca837b52327473@mail.gmail.com>
Message-ID: <df9074860901251156n7c8a1c27wd45642e7244b37be@mail.gmail.com>

I want to take a second to really commend Josh on these signatures because I
really think that this was a worthwhile endeavor and has really defined the
scope of what needs to be detected.  That said, I think that now that we
know how many signatures it would take, we need to find a different way of
doing it.  Does a standard MZ executable signature miss on any of these PEiD
signatures?  I would think that by definition, all packed exe's must also
have at least part of the standard MZ PE headers.  If that is confirmed,
then I would posit the following:

   - There are too many ways to pack an exe to fit into an efficient rule
   set.
   - Polymorphic packers can easily evade existing PEiD's (see
   ShadowServer.org's packer stats).
   - I've not had reliable results with the PEiD Snort sigs because of
   signature overlap and false positives.

Therefore, using the standard (and existing) exe signature which canonically
identifes all exe's downloaded and feeds these exe's into an
application-layer exe analysis framework is preferable to attempting to make
Snort detect this on the wire.  This can easily be accomplished (and to some
degree already is) with the Bro framework, (insofar that it can auto-extract
exe's and test them against things like known malware hashes).  If it's not
already done, it would be trivial to run an extracted exe through PEiD.
This would be far easier to maintain than an entire ruleset of Snort sigs.
In fact, Snort could do this as well with the "session" rule modifier and
Jason Brevenik's SnortUnified Perl module tailing the unified output.  This
would also be the perfect spot to hook into a sandbox queue.  Imagine a
framework where a rule like this could be written: "alert if a binary is
extracted which when executed contacts a domain not on this whitelist."  If
the binary hashes are cached and submitted to a central repository, over
time, a larger existing library can be created which would save a lot of
back-end work.

There's a big hole in this, though, and that is a relatively new phenemenon
I've been coming across lately which consists of executable scripts encoded
in Javascript payloads, where the Javascript, after being unobfuscated, will
save a compressed .js file and run it using wscript.exe.  This is used to
replace the standard phase one downloader Trojan.  Occasionally, I've seen
it do phase two activities as well, like registry modification.  So, while
exe headers are easy to identify in a network stream, very application-level
Javascript implementations like this are nearly impossible to identify.  I
think Javascript behavior profiling and a signature language that describes
it is the next frontier for analysis, and I would love to see someone with
Josh's abilities and ambition try to attempt something in that problem
space.

To whet your appetites, check out the simply amazing work UC Santa Barbara
has done with wepawet (wepawet.iseclab.org).  It profiles Javascript and
Flash in a sandbox and shows the deobfuscated and run-time output.  Check
out the samples there for a look at how detailed it gets.

--Martin

On Sun, Jan 25, 2009 at 11:03 AM, Josh Smith <famousjs at gmail.com> wrote:

> David,
>
> Well I originally converted the database file they offer on the PEiD
> website, and that was about 1500 signatures.  Now I've just been
> collecting database files from around the internet.  The one I
> originally did may be dated, but still applies to quite a few binary
> signatures.
>
> -Josh
>
> On Sun, Jan 25, 2009 at 11:58 AM, David Glosser <david.glosser at gmail.com>
> wrote:
> > wow! is there any way to have a smaller list of "active" sigs? (or would
> > that "smaller" list still be too large for most snort installations)?
> >
> >
> >
> > On Sun, Jan 25, 2009 at 11:38 AM, Josh Smith <famousjs at gmail.com> wrote:
> >>
> >> I have been working on converting the PEiD database of binary packer
> >> signatures straight to snort signatures.  I've been refining my
> >> signatures with other members from Emerging Threats, and have over
> >> 10,000 snort signatures for packers.  I was told this may be a good
> >> topic to bring up (binary packer detection) for OISF.
> >>
> >> -Josh
> >> _______________________________________________
> >> 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/20090125/a63b11be/attachment.html

From famousjs at gmail.com  Sun Jan 25 15:19:29 2009
From: famousjs at gmail.com (Josh Smith)
Date: Sun, 25 Jan 2009 15:19:29 -0500
Subject: [Discussion] Binary Signature Detection
In-Reply-To: <df9074860901251156n7c8a1c27wd45642e7244b37be@mail.gmail.com>
References: <e7646750901250838l1c546b6ej1cec7e79ff17aaaf@mail.gmail.com>
	<ac597e6e0901250858g9a31b02ued47e569a3365df6@mail.gmail.com>
	<e7646750901250903p3a63cd18y11ca837b52327473@mail.gmail.com>
	<df9074860901251156n7c8a1c27wd45642e7244b37be@mail.gmail.com>
Message-ID: <e7646750901251219w33deff99occf2087a720986cf@mail.gmail.com>

Martin,

Thank you for the praise.  It's taken me longer than I would have
wanted to work on this subject, as I'm still an undergrad at RIT.  I
do work for iDefense as an Intern, and Blake (who I believe is on this
mailing list as well) is presenting at Shmoocon on his Javascript
de-obfuscation website and engine (http://jsunpack.jeek.org/dec/go).
We have actually been discussing automatically making rules based upon
user submissions to his site.

-Josh

On Sun, Jan 25, 2009 at 2:56 PM, Martin Holste <mcholste at gmail.com> wrote:
> I want to take a second to really commend Josh on these signatures because I
> really think that this was a worthwhile endeavor and has really defined the
> scope of what needs to be detected.  That said, I think that now that we
> know how many signatures it would take, we need to find a different way of
> doing it.  Does a standard MZ executable signature miss on any of these PEiD
> signatures?  I would think that by definition, all packed exe's must also
> have at least part of the standard MZ PE headers.  If that is confirmed,
> then I would posit the following:
>
> There are too many ways to pack an exe to fit into an efficient rule set.
> Polymorphic packers can easily evade existing PEiD's (see ShadowServer.org's
> packer stats).
> I've not had reliable results with the PEiD Snort sigs because of signature
> overlap and false positives.
>
> Therefore, using the standard (and existing) exe signature which canonically
> identifes all exe's downloaded and feeds these exe's into an
> application-layer exe analysis framework is preferable to attempting to make
> Snort detect this on the wire.  This can easily be accomplished (and to some
> degree already is) with the Bro framework, (insofar that it can auto-extract
> exe's and test them against things like known malware hashes).  If it's not
> already done, it would be trivial to run an extracted exe through PEiD.
> This would be far easier to maintain than an entire ruleset of Snort sigs.
> In fact, Snort could do this as well with the "session" rule modifier and
> Jason Brevenik's SnortUnified Perl module tailing the unified output.  This
> would also be the perfect spot to hook into a sandbox queue.  Imagine a
> framework where a rule like this could be written: "alert if a binary is
> extracted which when executed contacts a domain not on this whitelist."  If
> the binary hashes are cached and submitted to a central repository, over
> time, a larger existing library can be created which would save a lot of
> back-end work.
>
> There's a big hole in this, though, and that is a relatively new phenemenon
> I've been coming across lately which consists of executable scripts encoded
> in Javascript payloads, where the Javascript, after being unobfuscated, will
> save a compressed .js file and run it using wscript.exe.  This is used to
> replace the standard phase one downloader Trojan.  Occasionally, I've seen
> it do phase two activities as well, like registry modification.  So, while
> exe headers are easy to identify in a network stream, very application-level
> Javascript implementations like this are nearly impossible to identify.  I
> think Javascript behavior profiling and a signature language that describes
> it is the next frontier for analysis, and I would love to see someone with
> Josh's abilities and ambition try to attempt something in that problem
> space.
>
> To whet your appetites, check out the simply amazing work UC Santa Barbara
> has done with wepawet (wepawet.iseclab.org).  It profiles Javascript and
> Flash in a sandbox and shows the deobfuscated and run-time output.  Check
> out the samples there for a look at how detailed it gets.
>
> --Martin
>
> On Sun, Jan 25, 2009 at 11:03 AM, Josh Smith <famousjs at gmail.com> wrote:
>>
>> David,
>>
>> Well I originally converted the database file they offer on the PEiD
>> website, and that was about 1500 signatures.  Now I've just been
>> collecting database files from around the internet.  The one I
>> originally did may be dated, but still applies to quite a few binary
>> signatures.
>>
>> -Josh
>>
>> On Sun, Jan 25, 2009 at 11:58 AM, David Glosser <david.glosser at gmail.com>
>> wrote:
>> > wow! is there any way to have a smaller list of "active" sigs? (or would
>> > that "smaller" list still be too large for most snort installations)?
>> >
>> >
>> >
>> > On Sun, Jan 25, 2009 at 11:38 AM, Josh Smith <famousjs at gmail.com> wrote:
>> >>
>> >> I have been working on converting the PEiD database of binary packer
>> >> signatures straight to snort signatures.  I've been refining my
>> >> signatures with other members from Emerging Threats, and have over
>> >> 10,000 snort signatures for packers.  I was told this may be a good
>> >> topic to bring up (binary packer detection) for OISF.
>> >>
>> >> -Josh
>> >> _______________________________________________
>> >> 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
>
>

From urule99 at gmail.com  Sun Jan 25 17:48:53 2009
From: urule99 at gmail.com (Blake Hartstein)
Date: Sun, 25 Jan 2009 17:48:53 -0500
Subject: [Discussion] Binary Signature Detection
In-Reply-To: <e7646750901251219w33deff99occf2087a720986cf@mail.gmail.com>
References: <e7646750901250838l1c546b6ej1cec7e79ff17aaaf@mail.gmail.com>	<ac597e6e0901250858g9a31b02ued47e569a3365df6@mail.gmail.com>	<e7646750901250903p3a63cd18y11ca837b52327473@mail.gmail.com>	<df9074860901251156n7c8a1c27wd45642e7244b37be@mail.gmail.com>
	<e7646750901251219w33deff99occf2087a720986cf@mail.gmail.com>
Message-ID: <497CEC55.9030203@gmail.com>

My long term goals for jsunpack are to make a Snort preprocessor, but
there are obvious performance problems. I am trying to find shorter term
solutions for now and I hope to link jsunpack with detection by IDS
engines - If anyone is interested in helping achieve this goal or
volunteering JavaScript URLs or Snort hits, please contact me off list.

Blake

Josh Smith wrote:
> Martin,
>
> Thank you for the praise.  It's taken me longer than I would have
> wanted to work on this subject, as I'm still an undergrad at RIT.  I
> do work for iDefense as an Intern, and Blake (who I believe is on this
> mailing list as well) is presenting at Shmoocon on his Javascript
> de-obfuscation website and engine (http://jsunpack.jeek.org/dec/go).
> We have actually been discussing automatically making rules based upon
> user submissions to his site.
>
> -Josh
>
> On Sun, Jan 25, 2009 at 2:56 PM, Martin Holste <mcholste at gmail.com> wrote:
>   
>> I want to take a second to really commend Josh on these signatures because I
>> really think that this was a worthwhile endeavor and has really defined the
>> scope of what needs to be detected.  That said, I think that now that we
>> know how many signatures it would take, we need to find a different way of
>> doing it.  Does a standard MZ executable signature miss on any of these PEiD
>> signatures?  I would think that by definition, all packed exe's must also
>> have at least part of the standard MZ PE headers.  If that is confirmed,
>> then I would posit the following:
>>
>> There are too many ways to pack an exe to fit into an efficient rule set.
>> Polymorphic packers can easily evade existing PEiD's (see ShadowServer.org's
>> packer stats).
>> I've not had reliable results with the PEiD Snort sigs because of signature
>> overlap and false positives.
>>
>> Therefore, using the standard (and existing) exe signature which canonically
>> identifes all exe's downloaded and feeds these exe's into an
>> application-layer exe analysis framework is preferable to attempting to make
>> Snort detect this on the wire.  This can easily be accomplished (and to some
>> degree already is) with the Bro framework, (insofar that it can auto-extract
>> exe's and test them against things like known malware hashes).  If it's not
>> already done, it would be trivial to run an extracted exe through PEiD.
>> This would be far easier to maintain than an entire ruleset of Snort sigs.
>> In fact, Snort could do this as well with the "session" rule modifier and
>> Jason Brevenik's SnortUnified Perl module tailing the unified output.  This
>> would also be the perfect spot to hook into a sandbox queue.  Imagine a
>> framework where a rule like this could be written: "alert if a binary is
>> extracted which when executed contacts a domain not on this whitelist."  If
>> the binary hashes are cached and submitted to a central repository, over
>> time, a larger existing library can be created which would save a lot of
>> back-end work.
>>
>> There's a big hole in this, though, and that is a relatively new phenemenon
>> I've been coming across lately which consists of executable scripts encoded
>> in Javascript payloads, where the Javascript, after being unobfuscated, will
>> save a compressed .js file and run it using wscript.exe.  This is used to
>> replace the standard phase one downloader Trojan.  Occasionally, I've seen
>> it do phase two activities as well, like registry modification.  So, while
>> exe headers are easy to identify in a network stream, very application-level
>> Javascript implementations like this are nearly impossible to identify.  I
>> think Javascript behavior profiling and a signature language that describes
>> it is the next frontier for analysis, and I would love to see someone with
>> Josh's abilities and ambition try to attempt something in that problem
>> space.
>>
>> To whet your appetites, check out the simply amazing work UC Santa Barbara
>> has done with wepawet (wepawet.iseclab.org).  It profiles Javascript and
>> Flash in a sandbox and shows the deobfuscated and run-time output.  Check
>> out the samples there for a look at how detailed it gets.
>>
>> --Martin
>>
>> On Sun, Jan 25, 2009 at 11:03 AM, Josh Smith <famousjs at gmail.com> wrote:
>>     
>>> David,
>>>
>>> Well I originally converted the database file they offer on the PEiD
>>> website, and that was about 1500 signatures.  Now I've just been
>>> collecting database files from around the internet.  The one I
>>> originally did may be dated, but still applies to quite a few binary
>>> signatures.
>>>
>>> -Josh
>>>
>>> On Sun, Jan 25, 2009 at 11:58 AM, David Glosser <david.glosser at gmail.com>
>>> wrote:
>>>       
>>>> wow! is there any way to have a smaller list of "active" sigs? (or would
>>>> that "smaller" list still be too large for most snort installations)?
>>>>
>>>>
>>>>
>>>> On Sun, Jan 25, 2009 at 11:38 AM, Josh Smith <famousjs at gmail.com> wrote:
>>>>         
>>>>> I have been working on converting the PEiD database of binary packer
>>>>> signatures straight to snort signatures.  I've been refining my
>>>>> signatures with other members from Emerging Threats, and have over
>>>>> 10,000 snort signatures for packers.  I was told this may be a good
>>>>> topic to bring up (binary packer detection) for OISF.
>>>>>
>>>>> -Josh
>>>>> _______________________________________________
>>>>> 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
>>>       
>>     
> _______________________________________________
> Discussion mailing list
> Discussion at openinfosecfoundation.org
> http://lists.openinfosecfoundation.org/mailman/listinfo/discussion
>   


From lists at inliniac.net  Mon Jan 26 06:44:58 2009
From: lists at inliniac.net (Victor Julien)
Date: Mon, 26 Jan 2009 12:44:58 +0100
Subject: [Discussion] Binary Signature Detection
In-Reply-To: <e7646750901250838l1c546b6ej1cec7e79ff17aaaf@mail.gmail.com>
References: <e7646750901250838l1c546b6ej1cec7e79ff17aaaf@mail.gmail.com>
Message-ID: <497DA23A.3030001@inliniac.net>

Hi Josh, thanks for bringing this up!

Josh Smith wrote:
> I have been working on converting the PEiD database of binary packer
> signatures straight to snort signatures.  I've been refining my
> signatures with other members from Emerging Threats, and have over
> 10,000 snort signatures for packers.  I was told this may be a good
> topic to bring up (binary packer detection) for OISF.

10k sigs is quite a lot :) Can you tell something about the nature of
these sigs? Are they complex, or do they just use one content match for
example?

Should they be matches against full packets and streams or would we be
able to match them against a small part of it?

Cheers,
Victor

-- 
---------------------------------------------
Victor Julien
http://www.inliniac.net/
PGP: http://www.inliniac.net/victorjulien.asc
---------------------------------------------


From famousjs at gmail.com  Mon Jan 26 09:08:41 2009
From: famousjs at gmail.com (Josh Smith)
Date: Mon, 26 Jan 2009 09:08:41 -0500
Subject: [Discussion] Binary Signature Detection
In-Reply-To: <497DA23A.3030001@inliniac.net>
References: <e7646750901250838l1c546b6ej1cec7e79ff17aaaf@mail.gmail.com>
	<497DA23A.3030001@inliniac.net>
Message-ID: <e7646750901260608j76309805s1521ad0fa3ee6dbe@mail.gmail.com>

Victor,

Some are simple, others have more than 5 content matches using within
and depth statements.  I also use a flowbit to detect only binary
files.  Also, they should match against a small part of a packet
because the signature of the packet is small compared to the size of
the binary file.  (At least I think it shouldn't have to match against
the entire packet haha).

You can look at the signatures here:

http://malforge.com/snort/output_all_uniq.zip

-Josh

On Mon, Jan 26, 2009 at 6:44 AM, Victor Julien <lists at inliniac.net> wrote:
> Hi Josh, thanks for bringing this up!
>
> Josh Smith wrote:
>> I have been working on converting the PEiD database of binary packer
>> signatures straight to snort signatures.  I've been refining my
>> signatures with other members from Emerging Threats, and have over
>> 10,000 snort signatures for packers.  I was told this may be a good
>> topic to bring up (binary packer detection) for OISF.
>
> 10k sigs is quite a lot :) Can you tell something about the nature of
> these sigs? Are they complex, or do they just use one content match for
> example?
>
> Should they be matches against full packets and streams or would we be
> able to match them against a small part of it?
>
> Cheers,
> Victor
>
> --
> ---------------------------------------------
> Victor Julien
> http://www.inliniac.net/
> PGP: http://www.inliniac.net/victorjulien.asc
> ---------------------------------------------
>
> _______________________________________________
> Discussion mailing list
> Discussion at openinfosecfoundation.org
> http://lists.openinfosecfoundation.org/mailman/listinfo/discussion
>