Intrusion Detection Systems: Re: kernel implementations

[mht () clark net (mht () clark 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
UNSUBSCRIBE: email "unsubscribe ids" to majordomo () uow edu au

At 07:22 AM 7/22/00 -0400, Dug Song wrote:

> oh please. no IDS in the world, network-based or otherwise, will perform
> the kind of alert compression needed to handle a sustained flood of
> attacks, much less the receiver lock in processing them. that isn't what
> the hiverworld folks were talking about at all, or what the NFR guys
> implemented - they're just looking to reduce memory copies internally,
> nothing more. using a NIC with working DMA will also help in this regard.
Actually a couple of products have indeed been proven to withstand a 
constant flood of attacks versus the other IDS systems that are available.
If one aims a 1,000,000 jolt2 attacks at a Axent NetProwler Agent, 
according to the packet counter, it capture about 3% of the traffic and 
drops the rest.

> > NFR still needs a lot of improvement in the number of signatures
> > compared to the other products in IDS Enterprise segment.
> you've been brainwashed by vendors playing the IDS-by-numbers game.
If the management console and central stations are on the same network as 
that is being monitored, erroneous alerts may be generated due to the 
communication that is being sent between the management console, the IDA 
Network and Engine and the Central Stations.
The packet counter did not accurately count the number of packets that were 
being received to by the IDA Network Engine
There is no mechanism readily available to reset the packet counters.

NFR 4.0 must be removed from the system iIn order to reset the packet 
counters on the IDANetwork Engine  appliance, one must de-install NFR 4.0 
from the appliance.

The description of the Malicious HTML Request attack signature 
vulnerability description incorrectly describes the attack signatureis 
incorrect.  The applicable operating system support list does not list the 
various versions of the web-servers that are vulnerable to this type of 
attack are not listed.
The Finger Monitor attack signature watches for finger attempts and reports 
the user (or all users if the attempt was aimed at the whole machine)(s) 
that at which the finger was aimed at.  Multiple finger requests in a short 
time period could suggest brute force user-name or password guessing.  More 
than 6 in a minute are indicative of a username or password guessing attack 
from the source.
NFR 4.0 does not have the capability to correlate the Finger Monitor attack 
signature event to other events that could be sources or other signs of 
malicious intent.
The description of the RPCinfo Monitor attack signature description 
incorrectly describes the attack signatureis incorrect.  The attack 
signature does not list the operating systems that are vulnerable to this 
type of attack signature.
The HP Remote Watch attack signature is only applicable to the HP-UX 
Operating system platform.  This attack signature cannot be disabled if 
when no HP-UX platforms are not present.  This signature generates 
erroneous alerts to be generated.
RIP v1 Monitor, RIP v2 Monitor and RIP Trace File Monitor attack signatures 
should be combined. since it is possible that for all three attacks 
signatures to be triggered by the same initial event. The attack and thus 
would cause the NT Console to slow down as events would flood the alertd 
window.
The telnet backdoor attack module attack signature that is shipped with NFR 
4.0 only checks for telnetd daemons that support RFC 1408 or RFC 1572., The 
are both titled "Telnet Environment Option."
The description of the Ascend Kill attack signature description incorrectly 
describes the attack signatureis incorrect.  The applicable operating 
system support list should list Only the version of Ascend operating 
systems that are vulnerable to this type of signature, and not any other 
platforms should be listed.  This signature generates erroneous alerts to 
be generated if Ascend routers are not present.
The Bad Addresses denial of service signature may generate erroneous errors 
if DHCP is active on the network that is being monitored.  In a highly 
active networked environment, the configuration threshold values should be 
set very high to avoid false positives from being generated.
The Big Packet Monitor denial of service signature does not list the 
operating systems that may be vulnerable to this attack.  If configuration 
threshold values are not set correctly, this attack signature may cause 
generate erroneous data to be generated.
The Pingflood Monitor and Ping Reply Flood Monitor should be combined to 
one attack signature.
The Hostscan detector attack signature does not include a list of the 
various host based host-based scanners that are detected by this 
signature.  Commonly used Host Based scanners are ISS Internet Scanner, 
Cybercop, and various freely available shareware  scanners available  from 
the Internet but does not detect the properly.
The SYNFlood attack signature seems to generate more alerts than other 
signatures.  During various the SYNFlood attack signature seemed to cause 
Console flooding.  Configurable thresholds should be incorporated into this 
signatureare necessary to prevent continous Console flooding.

> > The point is unclear here, one does need to go to a "kernel" based IDS
> > system, one just needs to learn how to design an IDS system properly
> > from existing technology.
> NFR published a decent paper on the subject at USENIX LISA 1997 - do you
> have something better? please explain your insistence on a "kernel-based"
> IDS, and its salient difference from existing systems - i don't get it.
>
> > In its true form, an IDS system is a traffic data collector.
> at CITI, we're working on a updated version of our "packet vault" - what
> i'd always imagined the NFR to be, a black box that simply records ALL
> traffic on the network for later analysis. the cryptographic organization
> of the saved data enforces our local policy on the disclosure of evidence:
>
> http://www.citi.umich.edu/techreports/reports/citi-tr-98-5-usenix.ps.gz
>
> this kind of application definitely requires the kind of optimizations
> discussed earlier (zero-copy packet handling), as well as some that
> haven't (kernel support for hardware crypto acceleration, as in OpenBSD,
> etc.). but i don't really consider this to be IDS per se, just raw data
> collection for post-mortem forensics...
Current IDS systems have not been proven to capture traffic at 100 megabit 
speeds, and most of the current versions fail to detect events at the 10 
megabit level.

/m

> -d.
>
> ---
> http://www.monkey.org/~dugsong/