Comment(s)

Note

If there was ever a time when I was over-thinking a problem this was certainly one of those times! I've edited this post to summarize the original research and include the unbelievably simplistic solution.

I run a number of Sguil deployments, of which some are on hardware that is extremely under-utilized, so I set out to determine what it would take to run multiple Sguil deployments on the same server.

The required configuration changes were relatively simple for most of the processes (Sguil agents, Snort, DaemonLogger, PADS, Barnyard) until I got to SANCP. The FreeBSD package at the time of this writing (v1.6.1_4) doesn't utilize a PID file, nor does it have a configuration option for defining one. This makes it very difficult to run multiple instances since without a PID file the rc.subsystem defaults to checking for the process name in the process table; thus leading to sancp already running? errors.

The SANCP page on NSMWiki lists "cxtracker" as a replacement for SANCP, and it looked promising since it provides an option for defining a PID file:

USAGE:
   $ cxtracker [options]
   OPTIONS:
    -i : network device (default: eth0)
    -b : berkeley packet filter
    -d : directory to dump sessions files in
    -u : user
    -g : group
    -D : enables daemon mode
    -p : pidfile
    -P : path to pidfile
    -h : this help message
    -v : verbose

Unfortunately cxtracker doesn't compile under FreeBSD:

sensor# make
gcc -O3 -o cxtracker cxtracker.c -lpcap
cxtracker.c: In function 'got_packet':
cxtracker.c:98: error: 'struct in6_addr' has no member named 's6_addr32'
cxtracker.c:99: error: 'struct in6_addr' has no member named 's6_addr32'

I wasn't feeling motivated enough to research the proper #define for IPv6 support (since I don't have a need for it at this time anyways) so I searched for another quick solution.

Update

To summarize my original research, the Sancp v1.6.2BETA supports a PID file but unfortunately doesn't appear to work properly with Sguil. After sleeping on it, I've added my simplistic solution is below.

My final solution was to create uniquely named symbolic links to the standard snacp binary installed with "pkg_add -r sancp":

ln -s /usr/local/bin/sancp /usr/local/bin/sancp_snsr1
ln -s /usr/local/bin/sancp /usr/local/bin/sancp_snsr2

Then to configure the multiple sancp services we need to edit rc.conf:

File: /etc/rc.conf
    sancp_snsr1_enable="YES"
    sancp_snsr1_flags="-D -P -R -u nsm -g nsm -d /nsm_data/snsr1/sancp -c /usr/local/etc/nsm/sancp_snsr1.conf -i vlan2

    sancp_snsr2_enable="YES" |
    sancp_snsr2_flags="-D -P -R -u nsm -g nsm -d /nsm_data/snsr2/sancp -c /usr/local/etc/nsm/sancp_snsr2.conf -i vlan3

Finally, create the service files in /usr/local/etc/rc.d/, just adjust the "instance" and "interface" variables accordingly:

File: /usr/local/etc/rc.d/sancp_snsr1
#!/bin/sh

. /etc/rc.subr

instance=snsr1
interface=vlan2

name="sancp_${instance}"
rcvar=`set_rcvar`
command="/usr/local/bin/sancp_${instance}"
load_rc_config $name
run_rc_command "$1"

Enjoy. -Dave



Comments

comments powered by Disqus