Intrusion Detection Systems: Re: kernel implementations (Target based IDS comments and questions)

[Ron Gula <rgula () network-defense com>]

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

I've got a few comments & questions ;)

First off, I should point out that NSW and Hiverworld (and NFR, ISS, Axent,
.etc) are competitors and these comments could/should be taken with a grain
of salt. Second ... I have lots of respect for Marty and I am looking forward
to seeing the IDS he is working on for Hiverworld in action. 

The comments:

> network for signs of intrusion.  Once this picture of the network is built we
> can do a number of cool things including target based IP defragmentation &
> stream reassembly (so long, and thanks for all the fish Mr Ptacek & Mr
> Newsham), 
This is pretty cool, but it is not perfect. There are still limited resources
when reconstructing a session and an attack can exhaust those. We've seen 
this with Dragon when an attacker will start an attack (fragmented), start
1000's of other sessions and then finish the first attack. There is also
slow role attacks that trickle in a slow fragmented stream of packets. 

I think a lot of the answers here are to look for responses from your servers
which may indicate an attack (See the 'Bro' tool for anyone who wants to know
more about this stuff). 

> OS/application specific
> rules, rejection (or direct shunting to log) of traffic that's heading for
> hosts that are not alive on the network (and/or heightened analysis of that
> traffic like a network sniffing "honeypot").  
This is cool as well, but there are many switch manufactures who have this
feature in their switches. Most ASPs use them to detect when one of their
servers crash, but it can be used to detect remote scanning. 

> The design of this system is predicated upon the existence of a continuously
> running and highly accurate network vulnerability scanner.  Fortunately,
> Hiverworld just happens to make one of those.  You have to have this because
> the TIDS must be updated seamlessly and automatically every time the network
> changes and because if the scanner isn't accurate the TIDS won't be either.
If the scanner is your source of data for your TIDS, then I would imagine
that firewalls, routers with ACLs and NAT devices are pretty difficult to
deal with. I'd also guess that for attacks coming *from* a network, a TIDS
is just as good as a NIDS since it has little knowledge of the systems 
outside the network. 

> optimal rules loading and false alarm reduction. :)  The traditional method
> for false alarm "tuning" is to set the NIDS up for a day or two then analyze
> its output for intrusive data (i.e. attacks) and squelch out the noisy
rules. 
> This isn't exactly a great method for real world use.  
An the TIDS won't have this? The first time you install it on a network which
is managed via snmp and the community string of public - it won't report an
attack/probe? 

> The other big advantage of TIDS is speed.  The detection engine is much
faster
> because it can select the proper rules to test more rapidly and because fewer
> rules need to be checked for a given server/vulnerability.  Current IDSs
> (well, Snort at least, probably some others as well) need to *find* the right
> set of rules to be tested (based on protocol/IP/port information) before it
> can actually begin testing them.  A TIDS doesn't necessarily have to do this
> since it knows how large the network is before hand and which hosts are alive
> so it can set itself up appropriately to only lookup the servers that exist,
> arranging those servers into a rapid lookup data structure.  At the same
time,
> a given entry for a server in the detection engine only needs to contain
tests
> relevant to that particular OS/architecture and application (and we can
get as
> specific as versions and patch levels) that the packet is hitting.
Leveraging
> the information collected by the vulnerability scanner in this way reduces
the
> number of tests that need to be performed for a given packet dramatically,
> which means that the detection engine (and the rest of the program) is that
> much faster.
This would be faster, but I think I see a religious war brewing in that IDS
systems are built optimized for looking for valid attacks or valid probes. My 
personal feeling (and this is how Dragon is built) is to look for any attack
regardless if it is valid or not. This has much higher false positive rates, 
but is much more likely to log data. Another approach (which exists today in
Dragon on customer networks) is to look for compromise events. Example: the
/etc/passwd file was mailed out of the network. Example: someone typed '
telnet <IP address> 25' in a DNS sessions (possible buffer overflow). 

> Here's another example.  If your network is going to be running both IIS and
> Apache web servers, a NIDS would need to load and monitor all traffic for
both
> types of attacks, potentially traversing the complete set of IIS and Apache
> vulnerabilities for every web server access.  Since many NIDS do content
> checking for these services (which is an expensive operation) these rules are
> processed slowly.  In a TIDS we can select the proper server rules directly
> and only test the things that (for example) Apache 1.3.9 and the particular
> version of MiniVend (or whatever) are vulnerable to.  Non-attacks can be
> logged as anomalous data, while attacks can be recorded and reported with
high
> fidelity.  
How do you know that a particular probe is 'non-attack' without testing all
the
other rules? From an alerting point of view, this is very cool and I don't
think
there are many products approaching this type of correlation (yet). But from a
performance point of view, I don't see the advantage. The non-applicable rules
still need to be tested in order to log the anonymous attack.


Ron Gula
Network Security Wizards