OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
Subject: Re: Symantec IDS Experts????????????????????
From: Elliot Turner (eturnerINTRUSION.COM)
Date: Tue Oct 24 2000 - 11:17:13 CDT

Hello Martin!

-----Original Message-----
From: Martin Roesch [mailto:roeschMD.PRESTIGE.NET]
Sent: Monday, October 23, 2000 3:55 PM
To: FOCUS-IDSSECURITYFOCUS.COM
Subject: Re: Symantec IDS Experts????????????????????

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

It's good to hear that you're adding a plug-in interface to Snort. However,
that
doesn't make the process of writing protocol decoding modules "magical" or
"easy".

My point was not whether or not your package had programmer hooks for
plugging in
new decoding modules, but the inherent complexity of protocol decoding
modules
themselves.

As I originally stated, writing a proper protocol decoding module requires
one to
fully implement a RFC standard. A plug-in interface simply passes you
packets (or
TCP streams, depending on the system). You then have to completely
implement both
the client and server portions of a networking protocol.

The complexity of these modules is even further increased when you take into
account
that you're a passive listener analyzing both ends of a connection. You
have to take
provisions to deal with issues such as command pipelining (which requires
you to cache
requests until you catch a server response, to properly manage state),
recovering from
potential packet loss, etc.

The HTTP RFC standard is over 160 pages long. That's just one protocol.
Now take into
account NNTP, FTP, TFTP, RPC, Rlogin, Telnet, and so on. Then take into
account protocols
that contain semi-proprietary/undocumented features (ie: Windows SMB, etc).

Now you're talking about implementing literally thousands of pages of
standards. Not a
straightforward procedure. This involves a deep understanding of every
major networking
protocol, and the ability to reverse engineer proprietary protocols.

I'm not saying that implementing a protocol decoder is "impossible". I'm
saying that it
isn't as trivial as you're making it out to be.

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

It's good to hear that you guys have been working on the IP fragmentation
and stream
reassembly issues. But this isin't really relevant to my comments on
"network grep"
systems. Network grep occurs on a higher level than stream reassembly and
IP defrag,
normally at the application layer. (you could grep lower levels, but the
application layer
is most common for most NIDS packages).

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

Network grep is a refers to simple pattern matching capabilities. Yes,
network grep can
detect some attacks when they are sent across the network in a text-book,
"download a script and
run it" fashion. But these systems fall over when even simple
application-layer obfuscation
techniques are used. Just look at the Whisker tool. It tears most network
grep systems apart.

The problem at hand is that networking protocols are fairly complex. They
allow a large degree
of ambiguity in how data is sent, and processed. HTTP allows for
specification of URIs in a number
of different fashions, transfer of data in various modes (normal, chunked
transfers, partial transfers),
persistant connections, and so on. I'm merely using HTTP as an example in
this situation; other protocols
contain similar complexities.

On top of all this you have to deal with application-layer client/server
differences, where certain
applications deviate from the RFC standard.

Network grep just can't handle these ambiguities, and this is fairly simple
to evade by an attacker.

I've written both network grep and protocol decoding IDS engines, so I feel
fairly confident that I can
comment on the benefits/drawbacks of each. However any comments on your
side would be greatly appreciated.
I love technical discussions on IDS technology; It's just so interesting.

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

Yes, I've heard about the SPADE engine. Sounds pretty cool. However the
point is,
someone still has to write new analysis engines. One can't simply say "oh,
well the
source code is open, so someone can extend it to match the XXX product.
Therefore the
open source solution is better". If that were true, we'd see open source
solutions matching
or exceeding every commercial offering in existance. This hasn't happened.
Just because
something is open doesn't mean that it's better. Someone still has to write
the code.

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

You could try. But there aren't thousands of people out there who are
writing attack
signatures. There aren't thousands of people writing exploits either. Most
people don't
have the knowledge.

Anyways, an organization that is truly concerned about security can't just
hope that
someone who writes attack signatures in their spare time as a hobby will
respond to the
latest attack. That's putting their network on the line just to save a few
bucks.

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

Many vendors utilize hard-coded IDS solutions which require binary changes
and full
re-testing of their entire feature-set to root out possible bugs.
Hard-coded logic
can lead to program errors (buffer overflows, memory leaks, endless loops,
etc) which
slow the update cycle.

The coming trend is toward sand-boxed environments which allow for
separation of detection
logic from actual hard code. This protects against such problems, and
speeds the update
cycle. Some vendors havn't gone this route yet, but most probably will if
they wish to
stay competitive.

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

If they're truly committed and are willing to spend their entire working day
to testing, re-testing
and re-coding to prevent attacks and problems, I commend them. I think it's
great that Snort is
attracting interest from the community. However that doesn't mean that it's
magically better than
everything else out there. Systems should be judged on technical
capabilities, ease of maintenance,
reliability of support and upgrades, and so on. Not whether or not they are
free/open source.

>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*?!

Downloading the source is free. Maintaining it to keep up with industrial
offerings is not.

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

Not all IDS administrators are experiences programmers who have knowledge of
integration
with management infrastructures. And I wouldn't really consider integration
with
management systems "flashing icons up on a screen".

Large organizations need the ability to manage their entire network
(security is but one
aspect) in a simple cohesive manner, allowing data from different sources to
be combined,
correlated, analyzed, and so on. These systems aren't toys with icons.
They have a purpose.

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

I'm not trying to insult the Snort team. I think it's great that you all
have created this
program. My comment on Snort being behind is in relation to the current
state of technological
advancement of the Snort system.

You've just now added IP defragmentation and TCP stream reassembly. Quite a
few commercial
offerings have had these capabilities for years (I wrote TCP stream
reassembly back in '96,
and IP defrag in '98. Several other vendors followed similar time scales).
You're not doing
any sort of application-layer protocol decoding, etc.

Please don't take my comments as insulting. I'm merely commenting on the
technical comparison
of existing open-source NIDS solutions to their commercial counterparts.

>> (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've written Snort, so you're obviously good at it. My point is that the
available pool of
people like you, who have the knowledge, interest and time to develop these
solutions, is
quite small.

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

I wasn't referring to a network being compromised _using_ Snort. NIDS
systems serve as
burgler alarms, detecting attacks. If they don't detect attacks (due to
evasion, or whatever)
an attacker can compromise a network without being seen. If someone relies
completely on
their detection solution and it fails, they have a false sense of security.

However, you're comments on being compromised do raise an interesting point.
Since NIDS
solutions are located in "key locations", IE: network borders or mirror
ports on a switch,
the compromise of a NIDS host can seriously impact the security of a
network. It is the
perfect vantage point for sniffing and hijacking attacks.

>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

I disagree. Snort doesn't do things that other packages do. It certainly
serves a definate purpose, but doesn't match the capabilities of every other
product
out there.

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

A product is more than just "chrome". I've already stated the technical
differences.

>SSLeay crypto, etc) may be a little different, but the goal and
capabilities
>are relatively similar.

I agree in regard to goals. We're all actively involved in the IDS
community, and want
to further advance detection technology.

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

Someone still has to write the code. Having the ability to plug-in new
functionality
doesn't make that functionality magically appear.

>to by several different people. Version 1.7 will include TCP stream
>reassembly.

Wonderful!

Thanks for your response Martin.

Elliot