Re: NIPS solutions

[Mike Frantzen <frantzen () nfr com>]

> Especially I wonder if either single processor or multiple processor 
> machines are used?

Either one.  Locking is easy.  You just need to be careful about the
cache affects so multiple processor aren't constantly having to steal
each others cache lines; make sure your pool or slab allocator does
coloring and per cpu magazines.

> I just explain my point of view. I realized a simple NIPS that is 
> running on a linux machine. The intrusion prevention system is running 
> as a thread in kernel space. So, each packet that is arriving at the 
> network interface triggers an hardware interrupt that is instantly 
> processed by the Linux OS. Consequently the intrusion prevention thread 
> is interrupted and the higher the traffic load the more often an 
> interrupt occurs.

You *really* don't want to run any more than necessary in an interrupt
handler.  if you must handle it in kernel, queue the packet and process
it in a soft interrupt.  There are two significant problems of doing
things in a hard interrupt:
  1) you may not be able to service another packet from the NIC while
     you are still processing the previous.  Many NICs have very small
     fifos so you'll be dropping packets.
  2) you are typically *VERY* limited in what memory allocations you can
     do in a hard interrupt.  I don't know Linux's VM/PMAP
     implementation but in BSD land you are not allowed to wire memory
     (that means back it with a physical memory page).  So you are
     limited to only allocating from a very small map of pre-wired
     memory (kmem_map: typically only 64meg).  There may also be other
     side affects of violating the splimp().


It is a good idea to have some type of hardlimit and drop mechanism on
the soft interrupt packet queue.  This is more often seen on a streams
based OS like Solaris where you're queueing packets faster than you can
service them.  So you may have a few millions packets in the queue which
will takes a while to process.  TCP will start retransmitting after the
RTT is exceeded which grows your queue more...  All the while the
administrator can't connect to the IPS to diagnose and fix the problem.

> An IPS solution that is running on a dual or multiple processor machine 
> would not suffer under this limitation. But  it is a real hassle to get 
> useful  information from manufacturers.

Do it in userland.  You'll save yourself a major headache and you will
be able to contain the security implications of a vulnerability in your
IPS itself.  Latency isn't even measurable if you have a good mechanism
to transport packets to and fro userland.  Plus you get to make obscure
wisecracks in the code about walking to and fro in the earth and walking
up and down it.

.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

---------------------------------------------------------------------------

---------------------------------------------------------------------------