dreamwvr <[EMAIL PROTECTED]> wrote:
> one issue that i foresee that
>most likely could be a problem further down the road if not now . is that
>someone will/is working on basically some sort of resource starvation
>attack..
This is already an issue. In testing early versions (3.X) of NFR some
people found (hi Mark!) that some DOS tools would overstress the
reassembly routines and cause the engine to consume all available
resources. Basically, we rewrote the garbage collection routines of
the reassembly stack to recognize large numbers of malformed or
partial streams and to clean them up, logging them as likely
attacks (by type) in progress. It turns out that in "normal" network
usage you just don't see that kind of traffic. An IDS that didn't
do any kind of reassembly at all would just cruise through the
test because it didn't have to garbage-collect all the broken
sessions.
I ran into interesting confusion early on in the IDS days
when customers would decide to "benchmark" IDS by using
a Shomiti to generate lots of random traffic, so they could
see at what point the IDS would begin to drop packets. Well,
the IDS that does reassembly has a clear problem, since
they're suddenly trying to track what appear to be millions
of broken TCP streams - a big CPU and memory hog - and the
IDS that doesn't reassemble is fat, dumb, and happy looking
for strings in all those random packets. It's even worse, since
random packets don't fit the profile of some of the "only
look at a few streams" IDS - basically those packets get
ignored unless they happen to fall on port 25, or port 80, or
whatever the IDS only knows to look at. ;) If you did that
kind of trick, you could process 150-200mb/s no problem
in a lab, but you'd die a bloody death if you were watching
a web site that did that kind of traffic to a single endpoint.
So dreamwvr's point is well taken - resource starvation
is always going to be an issue. I suspect that it's going
to be more often used as a trick for disreputable vendors
cooking benchmarks than for attackers working against IDS.
Any reasonably effective IDS today is going to detect
that kind of stuff and generate an alarm telling you
there's more broken stuff than usual on your network.
>since this is more ps intensive. therefore the IDS system needs
>to as well protect itself from itself actually on how the approach that is
>uses. hmmm.. the solution to this issue i certainly do not have the answer
>for:-{ obviously the IDS system needs to be hardened to prevent this
>sort of thing.
It's still an issue but I'd guess that most of the IDS that
actually do reassembly (how many is that, now, 3 out of
the whole lot?) will have addressed these issues in more or
less the same way. There are still issues with performance
between reassembling and non-reassembling IDS, since
it's always going to take a bit more work to track something
(for any "something") than not. Once we've gotten past
that, there's still issues about _how_ you do reassembly.
For example, in order to get around MTU-based reassembly
spoofing, NFRs look for ACK packets on a stream. That
way, we _know_ what the target machine thinks it saw.
Doing ACK-based stream reassembly means you have
to keep even more state, which is even more work, but
it's harder to fool. When a vendor claims they do "reassembly"
these days it's hard to know what they mean - they could
just be doing packet defragmentation. Or they could be
defragging and putting things into a ring buffer in sequence
and then searching the result for strings. Or they could be
running a TCP state machine for each and every stream
they see on the network, like we do. Your mileage is going
to vary as a result, and it's going to show on one hand in
performance and on the other in completeness of detection.
mjr.
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
