"Atacdad" <[EMAIL PROTECTED]> writes:
> ----- 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".
Agree,
even if you can describe the "normal" situation on only one network,
you can't do it in a generical way.
> 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:
It is clear that for a good number of network attack ( scanning is a good
exemple ), you *must* keep state of the past network activity.
Now, this is with such algorithm, where we keep, for exemple, connection
state, that we ( Francis ? :) ) crash our head on the wall.
For exemple : because in flooding situation, where the flooding host
is spoofing it's source adress on each packet, with > 2000 packets seconds.
Too memory used.
+ Too many cpu used
= Need to improve the algorithm.
I'm on the way to look at the new netfilters stack,
and see how kernel modules like ip_conntrack work in such situation.
> [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.
Agree again, in fact i don't really understand
what the author mean by :
"defining the allowable variation in each field of the TCP header and in its
construction/format"
> 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.
Have you tried prelude ?
because i've wrote a module that detect buffer overflow in a generic way
wo need of getting previous connections state.
Basically you can probe for buffer smashing attack by looking at the data
and counting the number of NOP they contains.
This can be done in a state less fashion.
> 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].
Yop, but you will have problem with host not completly respecting the
tcp ( in this exemple ) specifications.
> 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....
i think we should'nt rely on undefined things;
signature are, probably good for theses one.
> 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."
Yes, by defining what you agree on this network & what you do not.
Then issue security alert.
> 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.
This mean that all IDS have leak that other doesn't have :)
We should adress this also ;)
> 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!
There is always a way :)
--
-- Yoann, http://www.mandrakesoft.com/~yoann/
It is well known that M$ products don't call free() after a malloc().
The Unix community wish them good luck for their future developments.
