Re: Sourcefire VRT Certified Snort Rules Update 2010-03-17

[Seth Art <sethsec () gmail com>]

On Wed, Mar 24, 2010 at 1:18 AM, Will Metcalf <william.metcalf () gmail com> wrote:
> First off I know my opinion probably doesn't count for much, but I'm
> growing very tired of the anti-SF comments that tend to follow my
> posts, it doesn't add anything to the conversation and is quite
> annoying.  I have a lot of respect for the snort devels past and
> present. I mean names like Sturges, Novak, Norton, Roesch.  Do a
> little bit of goggling to see who's names are on the majority of
> substantial research done in the area of NIDS and I bet at one time or
> another they worked for SF.  Also the VRT blog should be required
> reading for anyone in this field. Matt Watchinski's presentation
> @dojosec this year (http://www.ustream.tv/recorded/2502995) is the
> best damn presentation I have seen on how to build an effective
> security program ever.  You have to admit SF employs a lot have a lot
> of very, very smart people. Agree with their decisions or not, things
> would be more pleasant if you would at least show some respect for a
> company that has invested millions of dollars into something that you
> are now using in your network and/or have built a business around that
> you have payed absolutely nothing for.

Will -- I certainly agree with you, and I hope that was not directed
at me.  I also have nothing but respect for Sourcefire, the Snort
team, the VRT, and the frequent contributors (including you, Frank,
and Joel among many others) to the snort-users and snort-sigs mailing
lists.   Put simply, I owe a good portion of the success I have had in
my professional career to the aforementioned parties.

My initial email had three purposes:

1) To make sure I am not missing anything obvious.  Just because you
have been doing something for a while, does not mean you are doing it
correctly... right? :)
2) To question the effectiveness of these particular signatures,
potentially causing the VRT or the community to reevaluate/modify them
3) If I am doing everything correctly and this is expected behavior,
to raise awareness of a limitation in snort, and any other IDS that I
know of, that is not often talked about openly

I think that lack of awareness regarding the third point became
apparent tonight.

> > My question to you: What IS the tool to do this.    Will it be the
> > next round of snort, or does anyone have a better way to DETECT client
> > side attacks.  I really think that since these are network based
> > attacks, the industry needs to be a lot more effort into detecting
> > these with NIDS.
>
> Some of these apply to client-side and some are more general, it is
> just my opinion so take it for what it's worth.
>
> 1. If your environment permits, don't allow normal users to download
> executable content from non-trusted sites (this is harder than it
> sounds, most proxies can block based on filename or mime-type very few
> actually implement things like mime-sniffing to determine file type)
> a lot of malware will use an exploit to gain access to a system only
> to turn around and grab the actual executable from the web somewhere.
>
> 2. Don't allow your users to have administrative access to their
> workstations.  I know all you check that box on your compliance form,
> but come on this isn't how it is in the real world is it? ;-)
>
> 3. Deploy some sort of HIPS product, sure these can be bypassed as
> well but it is a lot harder in most cases. For these to be of any use,
> you have to know what applications you want to protect and the normal
> behavior they are supposed to exhibit. For example I worked with a
> product from vendor X that did a great job of buffer overflow
> protection, but you had to tell it what applications you wanted it to
> protect as it only came with a very small default list.  Most people
> don't do this.
>
> 4. I know I said I wasn't going to put these in any particular order,
> but this is the most important.  Organizations should probably invest
> less in tools and more in people. You need to have a group of very,
> very talented people working for your organization that know your
> environment inside and out. These people also need to actually
> understand what is happening in the security space and what this means
> for your environment.  As Watchinski says in the talk above
> "Technology Won't Save You... People Will."
>
> 5. Listen to people like Richard Bejtlich, and implement technologies
> that will allow you to do retrospective analysis when your preventive
> measures fail (it will happen, I can almost guarantee it) and your
> detective measures give you just enough clues to let you know that
> something doesn't look quite right on your net. Tools that will allow
> you to do this might include things like full packet capture, flow
> logging, centralized logging, an environment to perform host based
> forensics, etc, etc.

I am 100% in agreement here especially with the Bejtlich mantra of
"Prevention will eventually fail".


> > Filtering egress traffic: Easily bypassed in most locations by having
> > the PDF connect outbound on port 443 or 25.
>
> Hmmm unless you are a college or a boingo hotspot or something you
> should not be allowing outbound port 25 access from anything other
> than your mail relays.

You are 100% correct here. I meant 21/tcp as most companies that do
egress filtering allow http, https, and ftp in my experience.  As you
mentioned earlier, proper protocol inspection would help a lot here.


> > ASLR/buffer overflow protection: I personally do not have any
> > experience with any of these types of products... You have any names?
>
> Some of these technologies are built into various Windows/Unix OS's
> and compilers but in most cases you have to use them for them to be
> effective ;-).  There are commercial products as well i.e. Mcafee
> HIPS, Cisco Security Agent, etc,  they fit into the HIPS category.
>
> > HIDS/HIPS -- Can certainly help detect certain things that a NIDS will
> > miss (encrypted traffic post decryption, right?), but can only detect
> > again

I was in a rush here.  The point I was trying to make was that I agree
that HIDS/HIPS are necessary and that currently, it seems that they
can provide additional insight itno client side attacks.

> Nope, preventive as well.
>
> Regards,
>
> Will

My main point is that unless Snort/Sourcefire takes the lead on some
of these issues, I can't imagine any of the other vendors doing it.
In my opinion, SF is the market leader in terms of innovation here, as
evidenced by the changes coming in 2.8.6.  As a member of the snort
community, I think it serves the greater good to talk about current
limitations in the open, rather than ignoring them.  As evidenced by
your inclusion in this thread, I know you agree.

I think these were some of the reasons for the formation of Suricata
as well, and I have a lot of respect for that endeavor as well.
Unfortunately I have not been able to play with it yet, but it is
definitely on the to-do list.

Respectfully,

Seth










> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Snort-sigs mailing list
> Snort-sigs () lists sourceforge net
> https://lists.sourceforge.net/lists/listinfo/snort-sigs

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Snort-sigs mailing list
Snort-sigs () lists sourceforge net
https://lists.sourceforge.net/lists/listinfo/snort-sigs