----- Original Message -----
From: "Vandoorselaere Yoann" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, May 03, 2000 6:22 AM
Subject: [Cooker] Interesting paper.


>
> This paper talk about the future of IDS,
> notably the facts, that IDS will not longer monitor
> large network because of the fast evolution of technology
> ( network fasteness, packet content encryption ).

There are some fundamental problems with the paper.  First, "anomaly
detection" is not  used by any commercial intrusion detection system that I
am aware of(I am employed in this field) in other than very specific, well
defined areas.  The reason is that for general network traffic, it is nearly
impossible to define "normal".  If  you cannot define "normal", you cannot
define an "anomaly".  The problem with defining a general "normal" is
explained below.
In limited, well-defined cases,  you can indeed define "normal".  For
example, I can define "normal" as the absence of SYN-FIN flagged packets on
the network and thus define the "anomaly" as the presence of SYN-FIN
packets.  Using this, I can then write a NIDS signature to catch people
using nmap (or any other tool that does SYN-FIN scanning) to probe my
networks.  Thats pretty straight forward.  Now lets consider FIN scanning.
FIN-only packets actually do show up in "normal" traffic, so I can't use the
same logic as SYN-FIN.  I can, however, determine from large amounts of
traffic analysis that FIN-only is (generally) relatively rate.  So I could
write a signature that looks at the *rate of arrival* of FIN-only packets.
However, now I am keeping state about past network activity...which is
directly in contradiction of one of the paper's points:

[quote]Alternatively, an entirely stateless approach could be taken by
defining the
allowable variation in each field of the TCP header and in its
construction/format;  analysis could then be performed without reference to
previous or future network traffic.  Exceptions which occur would be
flagged.[end quote]

The " ...without reference to previous or future network traffic." just
won't work.  Many network protocols are stateful, and almost all network
applications are stateful (see sendmail for a good example)  You have to be
able to keep state to do good network intrusion detection.  I also cannot
fathom how, for instance, an RPC buffer overlow attack, which uses
completely legit TCP could be detected using this "stateless" approach.  Not
to mention, IGMP attacks, or ARP spoofing, which aren't even TCP based.
Which, brings me to:

[quote]Firstly, the TCP state-transition diagram could be modeled within an
IDS as a
set of rules;  these rules represent the valid use of TCP as per the TCP
specification.  Exceptions (i.e. "not use") which occur would be alerted
upon.  Some analysis has already been done on exceptions which occur to the
classical TCP state transition diagram, see [14].[end quote].

This looks to be a good idea on the surface, the real problem lies in the
"undefined" areas of the TCP spec.  For instance, SYN-FIN is a perfectly
valid use of the TCP spec...the spec doesn't disallow it, or NULL packets,
etc....  The TCP spec is only a partially specified protocol and the
undefined "wiggle room" makes it difficult (again) to define "normal".  The
Queso scanner (since incorporated into nmap) can do OS identifcation because
of the "undefined" areas of the spec and the TCP stack implementor's freedom
to respond to undefined situations in arbritrary ways.  Oh yah, you'd have
to do this for every L4 protocol too, and, again, it doesn't address attacks
that use legitimate TCP, IGMP, ARP, etc....


Ok, so after all that, is there anything good in the paper?  Not much, but
at least the authors recognize that "normal" is practially impossible:
"The difficulty in constructing an IDS which utilizes a strict anomaly
detection model, is in being able to define allowable "use".  It may be that
strict anomaly detection is best employed in an environment in which "use"
can
be (or is already) well defined, such as in the firewall example above, or
in
a 'trusted system' - such as Trusted Solaris [15] for example."

Commercial NIDS systems are already deployed as suggested in the "firewall
example".  It should also be noted that people who take network security
seriously generally don't rely on one system and/or one technology.  A well
protected network uses the "defense in depth" approach.  Firewalls backed up
by NIDS backed up by Host-based IDS were the assets being protected rate
that level of protection.
It is probably possible, hopefully not very likely, that a patient, skilled
hacker could get through/around a defense in depth scheme; but he would have
to be Very patient, Very skilled, and Very lucky!


Atacdad



Reply via email to