Re: Mod FWD

["Marcus J. Ranum" <mjr () nfr net>]

Archive: http://msgs.securepoint.com/ids
FAQ: http://www.ticm.com/kb/faq/idsfaq.html
IDS: http://www-rnks.informatik.tu-cottbus.de/~sobirey/ids.html
HELP: Having problems... email questions to ids-owner () uow edu au
NOTE: Remove this section from reply msgs otherwise the msg will bounce.
SPAM: DO NOT send unsolicted mail to this list.
UNSUBSCRIBE: email "unsubscribe ids" to majordomo () uow edu au
-----------------------------------------------------------------------------
"ascii 246" <ascii246 () postmaster co uk> wrote:
> 1. why is packet reassembly important in IDS systems?

It's not merely important, it's essential (at least for network IDS).
Suppose you've got an IDS that doesn't reassemble packet fragments
or correctly model a TCP stream - an attacker can simply split their
attack across multiple packets, reorder them, and send it right
past your IDS unseen. If the premise of your IDS is that it's going
to detect attacks (hence the "detection" in 'IDS') ;) then it's got
to be able to deal with packet rearrangement, packet overlap,
fragmentation, out-of-sequence packets, etc.

>  isnt this excessively CPU
> intensive, also i have a firewall that does Reassembly, am i still going 
> to need
> reassembly functionality on the IDS aswell.

It depends on the firewall; a proxy firewall (a classic proxy, not
one of your newer ones) would certainly get you around the issue
of packet ordering and fragmenting.


> 2. We have bespoke apps developed in house, which are unlikely to appear 
> in the
> "wild", however, we still would like to have attack recognition in place, 
> is it possible
> to tailor bespoke signatures for inhouse apps, i know i can look for text 
> or strings in
> signatures, but there are certain actions we would like to prevent, which 
> are likely to
> occur from a series of connections, Eg . if this happens + then that 
> happens  + then
> this happens = then this is would be defined as suspicious. can i do this 
> with current
> IDS technology.

Well, to do this kind of thing, you'd need a programmable IDS.
There aren't very many that support adequately poweful description
languages that would let you tailor signatures to your application.

I'm obviously biassed, here, since I'm the CTO of a company that
makes the industry's first (and most flexible) fully-programmable IDS,
the Network Flight Recorder. We've implemented a language called
N-code, which looks like of like a cross between C and a few other
things, which allows full semantics and state for connections - you
can do stuff like have a filter rule fire whenever a connection
occurs from one port to another, then monitor traffic within
that connection, pick values out of it, and then see if other
connections occur based on the contents of those values. Our
language is really powerful. For more information on the programming
language, Email me and I can send you some info on the language
specification and some of the builtin functions it supports. It's
pretty exhaustive stuff!!

> 3. Host based.IDS will host based work unconnected from the network, if 
> someone
> got physical access to the box, unplugged it from the network, and then 
> downloaded
> the database, could the IDS prevent the download, or even shutdown the box ?

Depends on the IDS. Generally, computers aren't secure against
console attacks, however. I can't think of a way that a piece
of software is going to protect reliably against someone booting
the system off an alternate disk pack or whatever. My belief
has always been that if you're interested in protecting your
systems from physical attack, you're operating in "the big leagues"
and most Internet-oriented security tools will be less useful
for you.

> 4. What happens when my Network IDS gets overloaded, does it tell me?, and
> what can i do to share the load.

It depends on the network IDS. Some products, believe it or not,
don't _TELL_ you if they are dropping packets!! Obviously,
you've got to ask yourself why a vendor wouldn't tell you
something that important. :) Usually it's because they're
dropping loads of packets. Just correlate the "packets seen"
count (if the IDS gives you that) with the number of packets
your router has sent out that interface, and subtract. Then
you can tell who's got something to hide. ;)

Dropping packets _really_ hurts IDS that do reassembly, since
they then have to "heal" their understanding of the traffic
they've seen, which means buffering data and spending more time
matching streams. So, one thing you may observe is that when
an network IDS starts to hurt, the pain will quickly grow worse.
There's a kind of "cliff effect" in which the IDS can keep up
until it falls off the cliff and loses a whole chunk of traffic.
One concern is that an attacker could deliberately cause this
kind of event; so a well-constructed network IDS will notify
you of packet storms that push it over the cliff.

You can make good headway on load-spreading traffic to a
network IDS. There are lots of tricks, many of which should
appear in the list archives (so I won't repeat them) such
as using a shomiti tap to a load-spreader switch. Be careful
when choosing a load-spreader, since you want one that sends
all traffic associated with a given stream out the same port: if
your IDS does reassembly (and who'd want one that doesn't?) then
you need to make sure that the traffic doesn't get chopped apart
by the load-spreader. Arrowpoint switches, Toplayer switches,
etc, do it "right" enough for IDS.

> 5. how should i budget the total cost of ownership for IDS, how much of it 
> is capital
> cost, and how much is ongoing management.

There are a number of things you should look at:
1) Cost to buy the IDS
1a) Cost of the IDS' underlying hardware
2) Cost of underlying operating system (if any) - i.e.: does it
        require a copy of Windows NT or some other licensed operating
        system?
3) Cost (staffing) to install the IDS - i.e.: if it takes 5 hours of
        a senior technician to install, you've just spent an extra
        $400 in fully-loaded staff time.
4) Cost (staffing) to maintain the IDS - how often/how much time does
        it take to keep the thing working?
5) Cost (staffing) to maintain underlying O/S (if any) - how often
        do you have to install NT patches to keep the IDS from being
        trashed by the latest NT denial-of-service attack?
6) Vendor maintenance costs (typically a %-age of the product cost)

When we built our product, we recognized that installation time
costs and upgrade costs (installing patches and operating system
patches) can actually bury the initial cost of the IDS pretty
quickly. So we built our system around a self-booting self-installing
CDROM operating system: no NT, no UNIX, no shell, no NT security
holes, no system management. It takes only basic skills to install
(i.e.: knowing what an IP address means) To upgrade, you just eject a
CDROM and put a new one in, then restart the system, etc, etc.

mjr.
-----
Marcus J. Ranum
Chief Technology Officer, Network Flight Recorder, Inc.
Work:                  http://www.nfr.net
Personal:              http://www.ranum.com