# High Performance BSD Snort Box



## nanooc (Apr 6, 2010)

I'm having an issue that may be my fault due to lack of experience but I'm hoping to have some like shed on. I am trying to set up a snort IDS server. Linux has a cool ring buffer version of libpcap that can dramatically decrease packet drops with snort during high load times. (http://public.lanl.gov/cpw/) I want the same features for snort in a FreeBSD package. Daemonlogger from the makers of Snort seems to be a good answer for this (http://www.snort.org/users/roesch/Site/Daemonlogger/Daemonlogger.html). Daemonlogger can log to a rolling file but I don't want that as disk write/reads will slow performance. It also has the ability to send output to a network interface in a "soft tap" mode. That being said, here is what I have tried. 



```
ifconfig tap0 create
ifconfig tap0 up
daemonlogger -d -r -i eth0 -o tap0
snort -dev -i tap0
<<This produces nothing on a ping test>>
tail -f /dev/tap0
<<packets now appear on snort terminal which is dumping just like tcpdump for testing>>
```

Works but data is being spooled out of the ring buffer and into the tail command at a rate controlled by tail. Snort is sniffing the virtual interface in a "T" fashion where the ring buffer is not really beneficial and snort may still drop packets if the load gets high and tail is reading faster than snort can analyze. 

I also tried this:

```
ifconfig tap0 create
ifconfig tap1 create
ifconfig bridge create
ifconfig bridge0 addm tap0 addm tap1 up
ifconfig tap0 up
ifconfig tap1 up
daemonlogger -d -r -i etho -o tap0
snort -dev -i tap1
<<No traffic seen on ping test>>
tail -f /dev/tap0 >> /dev/null &
tail -f /dev/tap1 >> /dev/null &
<<traffic is now seen in snort>>
```
This seems to have something wrong with it. I want the bridge up at all times, not when i attach a tail to the device. Is there a way around this and have the bridge active full time?
I do have net.link.tap.user_open=1 & net.link.tap.up_on_open=1
I tried net.link.tap.up_on_open=0 to perhaps persuade it to be up all the time? But it did not seem to have an effect. Documentation is clear what =1 is on this setting but not what =0 does for you. I was hoping for a net.link.tap.up_perpetually=1. No such luck.

Lastly as a solution to the above I tried:

```
ifconfig tapo create && ifconfig tap0 up
ifconfig tap1 create && ifconfig tap1 up
dd bs=1500 if=/dev/tap0 of=/dev/tap1
daemonlogger -d -r -i etho -o tap0
snort -dev -i tap1
```
This produces results that seem mangled. dd is doing something to the packets between devices. I could try dropping the bs=1500 (MTU size) but I'm not sure I trust this method either. It does solve, however, the problem of leaving tail /dev/tapX >> /dev/null out of the picture. But, again, it does not seem quite right. I'm trying to bridge two virtual tap devices using dd. I don't expect dd to perform well taking in a 1gb link at high load times. It wasn't designed for that. Also I don't want to have to unbuild and rebuild a messy setup of tails and dd's every time a box hiccups.

I guess my question is. Why can't I just create a tap/bridge setup without hooking processes to the devices. Is there a way to keep the bridge alive 24hrs whether there is zero traffic or 100%? I do not want to entertain a VPN or writing daemonlogger to disk and using snort in batch file read mode. Both will be detrimental to performance. 

Lastly has anyone successfully compiled Phil Wood's ring buffer libpcap on FreeBSD successfully? There is a line on his readme's that worry's me below.

http://public.lanl.gov/cpw/ 

"Will the MMAP libpcap package compile on Solaris 8 or freeBSD?

By golly, it will, and it will generated a shared library too. But, you would need to install flex and bison along with all the other gnu programming environment stuff like autoconf, etc. Also, solaris and BSD is not linux, so mmap stuff is not relevant. "
               ^                 ^                 ^                     ^
Not relevant. I suspect compiling this on BSD will result in a standard libcap without ring buffering benefits. 

I feel like I'm just overlooking something obvious here. TIA for any advice or help.


----------



## DutchDaemon (Apr 6, 2010)

> Daemonlogger can log to a rolling file but I don't want that as disk write/reads will slow performance.



Then use a memory file, e.g. mdmfs(8) (see tmpmfs in /etc/defaults/rc.conf).


----------



## SirDice (Apr 6, 2010)

You could also try to add this to your kernel config:


```
# Zero copy sockets support.  This enables "zero copy" for sending and
# receiving data via a socket.  The send side works for any type of NIC,
# the receive side only works for NICs that support MTUs greater than the
# page size of your architecture and that support header splitting.  See
# zero_copy(9) for more details.
options         ZERO_COPY_SOCKETS
```

See zero_copy(9)


----------



## nanooc (Apr 6, 2010)

I thought of a tmpfs as well. Loss of data due to power outage or software hiccup is not an option. Also the complication of scripting out the file rolling and batch jobs over many boxes in a enterprise distributed environment would be problematic. I want to respond to threats not manage boxes. I need a smoother solution.
Thanks though, Good idea.


----------



## nanooc (Apr 6, 2010)

I'm hoping to get a ring buffer working due to the fact that I want to mitigate packets dropped by snort. The ring buffer will queue the traffic up as snort catches up. Zero_copy may definately improve performance and may even negate the need for a ring buffer in 99% of cases. However I don't think it solves the problem at hand. Never heard of it thou. Good stuff. TY.


----------

