Re: Important Comments re: INtrusion Detection

[marc () sniff ct-net de]

Hello!

I disagree.

> But why would it need to?  Overlapping fragments are "never" produced
> by accident or misconfiguration, and can therefore always be taken as
> an attack signature.

In some special cases, when you have strong control over the
environment, you might be right and these fragments mean an
inside hacker is at work.

An _inside_. Out in the Internet you will find a countless
number of bugs in TCP/IP stacks producing "garbage".

> What's being missed here, imho, is that the great majority of attacks
> use packets/streams that lie far outside the boundaries of legitimate
> use, despite perhaps being legal IP or TCP.

It should be accepted even if it's not totally correct wrt
the RFC. Be gracious in what you accept. I know this sounds
a little bit funny when talking about security, but you can't
cut off potential customers from a web store in a secured
network because you don't like packets "far outside the boundary".
"Get your stack fixed or I won't sell you anything!" ;-)

"far outside the boundary" will produce a twilight zone where
you are still open to attacks. But even worse it will produce a
LOT of trouble. An example: There is actually one system which
likes to talk to my server with fragments of 182 bytes. I have no
idea why and it is definitly far outside a boundary all the other
systems are inside. But cutting of the connection would be a bad
idea: it's a german listserv system providing me with mail from
... bugtraq!    :)

All right, this is a very simple example, of course. But you get
the idea.

> As with firewalls, it can be useful to think about IDS as "deny what I
> don't recognize as permitted" rather than "permit what I don't recognize
> as denied".

My example means you have to deal with overlapping fragments or
any other kind of "network garbage". Thomas Ptacek explained that
one doesn't know what to do (NT? FreeBSD?). Your rule will drop a
possibly legitimate access because no one knows? 

> Products that trade off the false alarm rate vs the missed attack rate
> in different ways can compete in the marketplace, without being in any
> universal sense fatally flawed.

I look upon IDS as some kind of "network radar" connected to a tape
recorder, not the patriot missile control. So when alarmed I expect
to have a look into some detailed logs. If I need a firewall I will
buy a firewall. But the paper of Ptacek/Newsham shows that you 
cannot trust in what you see in the IDS logs. So the real attack 
may be hidden behind. I guess this may happen to a firewall, too.
(although a "rebuilding" firewall, e.g. a proxy, has this
normalizing effect, so it is at least harder to confuse the
firewall with a fake attack while doing the real bad job).
But you will spend much time doing your analytic work on the
logs and _waste_ much time if the log data is a fake.
Or you point with your finger on an innocent person because
it was a more sophisticated fake.
That's what I wouldn't call a "bug" anymore ... .


Regards, Marc
-- 
Marc Binderberger                                 97076 Wuerzburg, Germany
marc () sniff ct-net de                              Powered by FreeBSD ;-)