On a network running at 10kfps a loaded sensor probably does
interesting memory management (or runs in the kernel) just to deal with
the memory latency from maintaining connection state --- not packet
contents, just connection stats --- for all those connections. Keeping
contents incurs a memory copy. Does your existing system copy raw
packets manually into DRAM after they've been DMA'd into a receive
buffer?
As a result of your paper on IDS evasions, we as IDS vendors had to
start keeping the data contents around until the ack. I'm not sure about
the other vendors but we at NFR just insert the packet into a tree
per-connection until the ACK arrives and we'll push the reassembled
(and hopefully evasion free) data through to the signature system.
Packet capture was really easy for the IDS/IPS vendors that have been
around for awhile since we're already forced to keep packets around for
a duration.
At least on our end, the biggest two hurdles have been dealing with the
packet copies and dealing with running out of memory. I think ISS beat
us to true zero copy by a release. We have about a gig of packet
buffers that the NICs DMA directly into and which are shared without
copy throughout the system. Jason Wright (jason@{nfr.com,openbsd.org})
did a great job such that the network cards are the only thing in the
system copying packets unless they get logged. It wouldn't surprise me
if Aaron Cambell or Eric Jackson over at Arbor had something similar.
Dealing with memory exhaustion because we're holding onto too many
packets was the other pain; either the IDS/IPS is underspec or an
attacker is trying to screw with us. We have to expunge some of the
packets in a random/non-determinstic manor so an attacker cannot predict
which connections will no longer have packet capture history.
A system like Lancope's (statistical anomalies) doesn't generate alerts
based on individual packets or even individual connections. It's
detecting rate shifts based on time. This is detection based on context
(useful for some things, don't get me wrong). What's the likelihood
that the forensic information you're actually looking for is contained
in the 15kB of data associated with the connection that happened to
trip a threshold?
I'd probably have to concede that the feature is more useful in
signature systems, where detection is atomic with respect to
connections.
I'm definately gonna have to agree with you there. Us signature and
protocol processing IDS/IPS engineers have a much easier time providing
forensics information since we have discrete events to point at. The
heuristics the anomaly guys would have to use just make my head hurt.
But then I'd have to ask:
How hard do you think a system like this would be to attack?
Packet capture took us less than a day of coding. Making it resistant
to attack took a *whole lot* longer and was a ton of fun to write.
I await my smackdown from Rob Graham or Mike Frantzen or Mike
Stolarchuk or whoever...
Throw down a gauntlet like that and I'm gonna have to take an apron out
of my kitchen and flip it around to use as a cape ;-)
.mike
frantzen@(nfr.com | cvs.openbsd.org | w4g.org)
PGP: CC A4 E2 E8 0C F8 42 F0 BC 26 85 5B 6F 9E ED 28
--------------------------------------------------------------------------
Test Your IDS
Is your IDS deployed correctly?
Find out quickly and easily by testing it with real-world attacks from
CORE IMPACT.
Go to http://www.securityfocus.com/sponsor/CoreSecurity_focus-ids_040708
to learn more.
--------------------------------------------------------------------------
