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: Wed Oct 18 2000 - 13:13:28 CDT

Hello Swen,

Thanks for the input! See below..

-----Original Message-----
>about we speak is a basic problem of NIDS, they have to capture packets and
>look for the content of this. I repeat every NIDS have to do that, even
>commercial do that. If the NIDS captured the package
>the NIDS engine want to know what the package will do. How they will do
that?
>They have to look inside, if it (the NIDS) is state based, it has to know
were
>the package belonging to. How it will figure out this information? Snort
only

I'm not sure what you're referring to when you say 'package'. Are you
speaking of
network services? If so, this information should be fairly readily
available. Most
services bind to standard ports, and a state-based IDS with decent content
analysis
capabilities should be able to perform basic heuristics on random port
connections
to determine what services they're associated with.

For example, I've written RPC (remote procedure call) monitoring code that
dynamically
builds listening-port tables based on portmapper responses, to determine the
RPC services
associated with particular dynamic ports.

>products and snort. But every NIDS capture package from the wire and look
>inside. If we use encryption no NIDS, even not commercial will now know
>something about the package. A NIDS will never reliable predict the impact
at
>the targetet system. That's the reason why NIDS are an out-dated
technology. It
>is only a small part in modern Intrusion Detection Systems. This statement
will
>cause trouble on this list, but in my opinion is it the truth.

NIDS isn't an "end-all" technology. This is something that is readily
admitted by most
vendors (the honest ones, anyway). A good security solution is made up of a
combination
or network and host-based IDS, packet filtering mechansisms, a solid
security policy, and
a dedicated and educated security team.

And in regard to the encryption issue: You can't just magically "encrypt"
any data that flows
to a network server. You can only make encrypted connections to the
specific services that
support encryption. IE: SSL, SSH, etc. Therefore it shouldn't be assumed
that someone can
simply bypass a network IDS by encrypting packets. The end-point host has
to support encryption
for the service that an attacker wishes to compromise.

>For this you should really use a HIDS, because the behaviour from your
System
>is the only reliable source to gather information of that what happens.

>>-- writing new protocol decoding modules
>
>If you start to do that, then you hav to employ a team of specialists that
will
>do that job. They want also earn money. I think if you use a commercial
NIDS
>then you won't do that, because the vendor have to supply the module.

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.

>>-- writing new signatures
>
>Have a look at www.whitehats.com, there is an hourly updated
>signature file. I think such service even commercial vendors don't supply.

I've seen the whitehats archive. It's a good resource. They may have a
script to update their
signature file hourly, but that doesn't mean that open source developers
around the world are
working around-the-clock to write new signatures on an hourly basis.

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.

And in regard to the commercial vendors statement, most vendors have already
moved to some sort of
attack signature update subscription service. Any vendor's who don't do
this will probably do so soon
if they wish to stay an active player in the market.

>At last I want to say, if implementing a state based NIDS you have to
implement
>every known protocol that every package can be inspected. Maybe the vendor
>will sell you these additionally to the NIDS. That's an horrible effort and
for
>what you do that? A NIDS will inspect the packages and see that there is
>something wrong (maybe a DoS), but what now, in the same time the target is
>death. You can't prevent such attacks with NIDS, and a lot of others too.

Integration or reactive response capabilities has become quite common in the
IDS field.
Such capabilities include: termination of attacker TCP connections, blocking
attackers at the
router, blocking attackers at the firewall, blocking attackers at the host
TCP/IP stack, etc.

I'm not going to get into a discussion regarding the merits or drawbacks of
each response technology,
as that's out of the scope of the original discussion regarding Open Source
vs. Commercial IDS. But my point is,
many IDS packages have progressed beyond simple burgler alarms into systems
that can take active responses
to the actions of an attacker. It's interesting stuff, however there is
much room for future improvements
and development in this area. IDS is still a fairly young field, and as
such is quite exciting to be involved
in as there is much room for innovation.
Thx,

Elliot