[Snort-devel] Re: Symantec IDS Experts????????????????????

Martin Roesch roesch at ...48...
Mon Oct 23 16:54:55 EDT 2000


I'm just going to reply to this thread to clear up a few misconceptions about
Snort.  You can draw your own conclusions about its usefulness.

Elliot Turner wrote:
> 
>  - writing new protocol decoding modules
> 
> Writing a protocol decoding module (implementing a RFC standard) is no easy
> task.  In addition, open source solutions such as Snort don't even allow 
> you to write protocol decoding modules.  

Snort allows you to write any protocol decoder you want, the source is open. 
It doesn't have a specific plug-in interface for it (this month) but adding a
new protocol decoder is a relatively straightforward procedure.  I invite you
to take a look at the source and see just how easy it is (hint: it's in
decode.c).

> These systems are based on network grep techniques (an old and unreliable
> form of attack detection) that most vendors have given up on.  Network grep
> is highly prone to evasion tactics and false positives.

Unless it isn't.  Snort has or will have with the release of version 1.7 even
more evasion resitant features than it has now (like IP defragmentation and
TCP stream reassembly).  "Network grep" is a derisive term that NIDS vendors
like to tag onto systems that allow easy network traffic inspection through
direct packet pattern matching.  The fact is that both network grep and
protocol modeling schemes have their limitations, but for the vast majority of
attacks network grep does an excellent job of catching hostile activity.

Additionally, it should be noted that Snort is not strictly a network grep
system.  It's true that its main detection engine relies on atomic operations
(e.g. test the TCP flags, test the IP ID field, etc) that are combined into
signatures, but the preprocessor interface allows literally endless detection
methods to be implemented in a relatively painless manner.  Take a look at the
new statistical anomaly detection engine (SPADE) from SiliconDefense for an
example of an implementation of a non-grep detection system in Snort.

> This goes back to my original statement regarding current open source
> solutions being based on out-dated technology.

Packets are on the wire, we can test them in a variety of ways, tell me again
how this is outdated?

>  - writing new attack signatures
> 
> While _some_ organizations _may_ have an individual on-site with the
> networking and attack knowledge to write an attack signature, this 
> is not some "occassional task".  New vulnerabilities are discovered
> every single day, and many discovered vulnerabilities are not released 
> with exploitation details.  This leads to two problems for open source
> developers:
>  1. Time - Monitoring security mailing lists, vulnerability archive sites
> and other resources for new vulnerability information is a full-time job.
> Most IDS vendors emply entire teams to do such activities.  So you could
> either employ a full-time engineer (an entire team, really) to write 
> signatures for your open source solution, paying each engineer $80,000/yr
> or more, or buy a commercial offering.

? 

You could also rely on thousands of pretty smart people out there to do it for
you for free, in effect utilizing the expertise of your entire user base to
help develop sigs.  With a few knowledgeable people to act as "gatekeepers" on
the approved vulnerability database, you can achieve impressive results
without paying anyone.

>  2. Information - Vulnerabilities are often published without exploitation
> details, depending on the publishing organization or vendor.  This requires
> reverse engineering work on the part of the attack signature writer, to 
> discover the method of attack and write a signature.  So the (Time, #1)
> factor is increased even further.

Yes, but how often do you update your sigs as a commercial vendor?  (This is a
rhetorical question.)  Many vendors only do it once per quarter or even
worse...

>  - preventing new IDS evasion tactics
> 
> IDS technology is an ongoing war, where attackers attempt to discover new
> methods to subvert the systems and the IDS software producers employ
> protective/detection measures.  Lots of evasion methods exist, beyond 
> simple fragmentation attacks.  For a starting point, refer to the 
> Ptacek/Newsham paper on IDS evasion (wonderful read).
> So add on some engineers to constantly stress-test and re-code your IDS to
> handle new evasion attacks, at a minimum of $80-100k/yr each.

Why?  I've got a group of great guys who do it for free and do an excellent
job.

> In regard to being cost effective, your open source solution has just
> escalated from being free to well over $300-400,000 per year in maintenance
> costs.

Through completely bogus "math" of what-if's and pie in the sky numbers.  I
really don't get where you're going with this stuff.  If it's free and it
stays free, how is it not *free*?!

> >Additionally, when you talk about management infrastructures, you
> >really need to explain which ones you mean.  I very easily set up
> 
> Integration into facilities such as CA Unicenter, HP OpenView, etc.  If
> you're managing an enterprise network with dozens or hundreds or remote 
> sites, you need to have your IDS integrate into the rest of your management
> infrastructure.

Anyone who wants flashing icons up on a screen can do that themselves, the
output plug-in interface for Snort is clearly defined.  

> >While I wouldn't put snort up against the full-fledged commercial
> >IDSes out there now, I may do it in a year.  All things being equal,
> 
> Snort is several years behind the top-tier commercial offerings.  If much
> effort was put into Snort over the next year, it would still be behind.  

I would dispute that.  That's also relatively insulting to the Snort
development team, considering we do this for free we've been pretty
successful.

> (IDS vendors don't simply create a product and start development; it's an
> on-going process).  I personally believe that IDS is far too much of a
> "niche" area in the open source community to attract sufficient developers
> to truly compete.  In addition, IDS knowledge is held by a very
> few individuals, and thus the available pool of developers is quite small.

Well, I've been told that I'm pretty good at it, and the rest of the team is
pretty good too....

> You won't look good to management when your network gets compromised because
> you're using 2-year old technology that isn't suitable for production 
> environments.

If your network gets compromised, it won't be due to Snort.  Snort isn't a
access control device, it's a NIDS.  Perhaps you're confusing it with a
firewall.

> Security is no laughing matter.  If someone isn't truly concerned about
> keeping out attackers, and is just "interested" in the occassional knowledge
> of who's doing what on your network, they should run snort.  It's
> an adequate solution in this case, because this type of person isn't looking
> for an IDS.  They're looking for a sniffer toy.

Please, get your facts straight.  Snort is no more or less powerful in the
hands of a user than any other product out there.  The fact that it's
extremely extensible and easy to use appeals to a lot of people.  Unless
you're doing something other than designing a flexible network traffic
analysis framework at Intrusion.com, I don't really see the difference from
what we're doing.  The particulars and the chrome (TurboPacket, GTK interface,
SSLeay crypto, etc) may be a little different, but the goal and capabilities
are relatively similar.

> Someone who is truly concerned about protecting their network wouldn't run a
> system that can be easily evaded
> with tactics that are years old, and is utterly unmaintenable from a
> resources/manpower standpoint (see my three points in the beginning of this
> message).

Or utterly unmaintainable if for some reason the company they bought the
product from was unable to maintain it to their liking.  Something of a double
edged sword, eh?

>  - Snort is based on simple network-grep IDS technology.  Network-grep can
> be easily fooled and is surpassed by today's more advanced state-based 
> protocol decoding techniques.  Network grep methods are also highly prone
> to false positives, and not suitable for detecting intrusions which involve
> multiple dis-jointed steps.

Snort's primary detection engine is has its basis in this concept, but you can
do far more with Snort than simple network grep.  The Snort signature
detection engine can literally be thought of as simply another preprocessor,
there's no reason why it can't perform more complex detection tasks.  It's
also easy to extend and modify.

>  - Snort is vulnerable to many evasion techniques that were described years
> ago.  Fragment reassembly (only recently added, though the fragment-based 
> evasion has been a well-known attack for years) was only recently added.  
> In addition, the fragment reassembly system doesn't allow one to specify 
> Windows/*NIX reassembly methods for individual hosts on a network.  This
> means that even with the new fragment reassembly code, it's still vulnerable 
> to fragment evasion attacks.

The development history of Snort is unknown to you, and there are many solid
reasons that I never added IP defragmentation until now.  

Multi-path IP fragmentation packet reconstruction isn't in the current
version.  It may be in version 1.7.

>  - The Snort site claims that it doesn't even do TCP stream reassembly. This
> is something that was available in even the first-generation commercial IDS
> offerings quite a number of years ago.  Streams reassembly is a basic feature
> that should be a part of any IDS.  It reduces the complexity of performing 
> attack evasion to the skill level of a BSD sockets programmer.  If this has
> recently changed, they should update their site to reflect the fact.

Docs will be updated with the new release of 1.7.  Once again, without knowing
the development history of Snort, you shouldn't throw stones.  I didn't add
defrag and reassembly not because I was unable to, but because I was asked not
to by several different people.  Version 1.7 will include TCP stream
reassembly.

> Exactly.  A team of specialists costs money, meaning that the open source
> solutions that you're updating are no longer "free".  In fact, they become 
> quite a bit more expensive to maintain than the currently available commercial
> offerings.

I beg to differ.  We provide pretty good service to user requests for new
features, probably better than most commercial vendors, and we do it for
free.  

> An organization that is truly concerned about security isn't going to sit
> around and hope that some open source developer gets around to writing 
> signatures for the latest attacks.  When the security of their network is 
> on the line, they don't have that luxury.  Open source is great for things
> like system utilities, graphics programs, and so forth.  But when you're 
> dealing with a rapid action/response environment (as with the security 
> world's "discover vulnerability", "respond to vulnerability" society), you
> can't be dependent on developers who are writing code as a hobby.

Here's a cheap alternative: Send the open source people an e-mail (maybe to a
public list like arachNIDS or Snort-sigs) asking for a new signature.  For the
really good/fast responders, maybe send them a piece of hardware (Sparc, PC,
etc) running your OS load and or apps and have them develop sigs for it. 
Cost: far less than a full time employee.

    -Marty

-- 
Martin Roesch
roesch at ...48...
http://www.snort.org



More information about the Snort-devel mailing list