Re: P0F in Snort?

I am kind of surprised that no one from SourceFire has commented, but
that may be because of "quiet period" restrictions.

Snort is becoming more and more target based (see Frag3 and the
experimental Stream5). Right now, target information is only
updateable via a change to the snort.conf and a restart (HUP). I hate
to put words in Marty's mouth, but from what I understand, one of the
big additions to snort 3.0 will be an interactive "command line", that
will let other applications (think RNA) update target information on
the fly.  So, Matt, yeah I think others have definately thought about
what you are wondering, and I expect it's already being worked on (at
least to some degree).

I don't think it's a bad idea to do something yourselves though (I
think it's a great idea). I think there are a couple of reasons why
SourceFire isn't putting the OS (or application) detection inside
Snort like you've suggested. First is probably performance.  It's
pretty obvious that commercial products have to perform in the
multi-gig space and I don't think Marty wanted to stop at OS
detection. So, while OS detection in multi-gig with might be feasible,
I doubt application detection is.  A second reason is business. RNA is
a huge piece of SourceFire (one might say that it is THE piece that
makes SourceFire), so even if they could move RNA capabilities "into"
snort, there is no way it's going to happen (and understandably so).

Anyway, it'd be great to start seeing contributions to the snort
codebase from outside of SourceFire again.

Bammkkkk

On 1/27/07, Matt Jonkman 
<jonkman-WwB1pFISwSkm7effSn6vN9HuzzzSOjJt@xxxxxxxxxxxxxxxx> wrote:
> Stray thought: ANyone ever seen or thought about integrating p0f into
> snort? P0f is an OS detection tool that's uncannily accurate by tcp
> behavior, totally passive.
>
> What if we were to have p0f just feed it's thoughts about a client to a
> flowbit, we'd be able to query that flowbit to get the p0f reading on
> whether a source or dest is a certain OS? Like
>
> flowbits:isnotset,p0f.src.is.WinXPSP2;
>
> That'd allow us a lot of possibilities in eliminating false positives,
> or attacks to machines that are not relevant. Or blocking inbound email
> from XP boxes (likely bots)
>
> More I think about it, more possibilities come to mind.
>
> Any coders interested in looking into that?
>
> Matt
>
>
> --
> --------------------------------------------
> Matthew Jonkman
> Bleeding Edge Threats
> 765-429-0398
> 765-807-3060 fax
> http://www.bleedingthreats.net
> --------------------------------------------
>
> PGP: http://www.bleedingthreats.com/mattjonkman.asc
>
>
> _______________________________________________
> Bleeding-sigs mailing list
> Bleeding-sigs-WwB1pFISwSkm7effSn6vN9HuzzzSOjJt@xxxxxxxxxxxxxxxx
> http://lists.bleedingthreats.net/cgi-bin/mailman/listinfo/bleeding-sigs


--
sguil - The Analyst Console for NSM
http://sguil.sf.net