Re: Snort + (OpenBSD or Linux)

From: Jeff Nathan (
Date: 07/31/01

Message-ID: <>
Date: Tue, 31 Jul 2001 01:03:47 -0700
From: Jeff Nathan <>
Subject: Re: Snort + (OpenBSD or Linux), "S.f." wrote:
> Hash: SHA1
> Disclaimer - I work for a NIDS vendor also.
That's ok, I work for a non-vendor and don't get paid (now that's love).


> Absolutely. We also are implementing "value-add" kernel and driver
> modifications to increase our rate of sniffability (is that a word?). We've
> found it to be absolutely necessary as BPF and even TurboPacket (or MMAP -
> whatever you want to call it today) are not sufficient for high-speed
> sniffing. Correspondingly, the application must be enhanced as well since
> you are now throwing much more traffic at it...

I had to respond to this post because it's a great foundation for
quashing this rediculous argument. Also, I think both you and Elliot
make some sense in your post so I know I won't be stepping on toes. :)

Now, every few weeks someone hops on this list and asks one of the
annoying questions that has already been addressed here in the past and
I guess this whole speed question is one of them, but some very
interesting things have been mentioned and I don't want them to be

There are many, many places for an IDS to have performance issues and
many of them begin way before the IDS application even receives a single
packet. Starting with your NIC card, you can have performance issues if
the card doesn't have enough buffers available or overall buffer space.
From there your NIC has to make interrupt requests to get more
information (both sending & receiving) and this is yet another place
systems break down - interrupt request handling within the OS. If your
system can keep up with the interrupt requests, there's the problem of
copying the buffer off the card into somewhere (like the IP stack of
your OS for example) and then your application having to copy the packet
out of BPF (or pcap in snort's case as of now). Stover mentioned some
of the more interesting techniques used today to minimize packet copies
such as MMAP sniffing using custom NIC drivers (as close to single copy
as it gets), turbopacket and even modifications to BPF. Ok, so now your
applciation (the IDS itself) can begin to read packets... not as quick
as you'd expected?

Only now can we finally start talking about data structures for storing
fragments, stream segments, pattern matching algorithms, alert queueing
and all those other ugly issues.

Dragos made a really well founded point, you want a system that is the
least likely to break down when doing all the work that occurs before
your IDS application even reads its first packet. This includes a good
NIC, an OS that has fast interrupt handling code, and a solid - high
speed IP stack. Given all these requirements OpenBSD is a natural
choice for me. Your mileage may vary.

If you want speed, try DOS. :)


PS, please read the focus-IDS archives before you post, your question
may have already been answered.

> - --
> SfStover
> Director of IDS QA
> Enterasys Networks/NSW
> GPG Key Fingerprint: 768E C80E 4AAD 63A3 DA0D B2F2 8529 52E3 3F91 2AA5
> Version: GnuPG v1.0.6 (FreeBSD)
> Comment: For info see
> iD8DBQE7Zdt0hSlS4z+RKqURAu+hAJ0TwnsUtmLHPbSydRW1jLj73woUOACfQuHU
> 11zzVJMSG7BmvUXl22S+9II=
> =cI3d

--            (pgp key available)
"Common sense is the collection of prejudices acquired by age eighteen."
- Albert Einstein