To rapidly install a sensor, these steps should do the trick, assuming all dependencies are satisfied.
# chdir /tmp# tar -zxvf sensor-1.0.tar.gz# cd ./sensor-1.0# ./install_sensorps -ef should report tcpdump is running. Other
operating system/hardware combinations need a different interface name in
sensor.conf. Have a look at /var/log/idabench/site0. It
should look like:
[root@sensorbox7 log]# ls -la /var/log/idabench/site0/
total 36
drwxrws--- 2 root idabench 4096 Mar 20 13:28 .
drwxrws--- 3 idabench idabench 4096 Mar 20 13:28 ..
-rw-rw---- 1 root idabench 14 Mar 20 13:28 sensor.date
-rw-rw---- 1 root idabench 6 Mar 20 13:28 site0.pid
-rw-rw---- 1 idabench idabench 16384 Mar 20 13:29 tcp.2003032013.gz
-rw-rw---- 1 root idabench 51 Mar 20 13:28 tcpdump.err
On the analyzer:
<this site>/site0.ph to <idabenchroot>/etc/sites/ if it doesn't exit yet.<this site> directory in <idabenchroot>/etc/sites/ and configure the site.ph and plugin filters appropriately.
For the best understanding of what goes into an IDABench sensor , we recommend reading the scripts and inline comments. Here is an overview of the scripts and what the installer does:
This file is read by both the install_sensor and sensor_driver scripts. It contains locations of preferred binaries, sensor-wide parameters, and definitions of each sensor "site". Jump to Sensor config for a field-by-field description.
Here's the meat and potatoes(sp?) of an IDABench sensor, the wrapper that starts
and stops the actual packet capture process and manages the resultant dumpfiles in
preparation for the analyzer(s)'s retreival. The .in version of sensor_driver
is a template used to create the .pl version during install. sensor_driver.pl
is called by the init.d script to start the sensor, and by crond(8) to restart it hourly.
Sensor_driver.pl requires two commandline parameters, stop/start/restart and
<sitename(s)>/ALL. For most installations, sensor_driver.pl start ALL is what
should be in the crontab. Start and restart are synonymous. In both cases, any
existing packet capture processes for the specified "site" is stopped and a new
one is started. In earlier versions of IDABench, sensor_driver.pl would call
stop_logger, then start_logger to accomplish this task. To remove the latencies
incurred during Perl's runtime compilation of start_logger, thus possible packet
loss, these have been incorporated into sensor_driver.pl as subroutines.
This is a template used to create the system startup script. The only change
made to it during install is the SENSOR_PATH line. On Linux and Solaris the
init.d script sensor is placed in the appropriate location for your system by
install_sensor and, a symbolic link is created in the rc.X directories. In
FreeBSD, the script is created as /usr/local/etc/rc.d/idabench.sh
See SITEx_FILTER in the Sensor config section.
The installation script. It has been tested on various Linux distributions, FreeBSD 5.0, and Solaris 8. Here's a summary of its actions:
Stopping the sensor is relatively simple, removing it is a bit more involved, as there are a fair number of moving pieces.
The startup script (possibly installed as /etc/init.d/sensor,
/usr/local/etc/rc.d/idabench.sh, /sbin/init.d/sensor, etc.) accepts a
commandline parameter "stop" which will kill site-specific tcpdump and gzip
processes, and merge any partial logs, if merging is available.
# <path to startup scripts>/sensor stopOn many Linux distributions, you can use the
/sbin/service script:
# service sensor stop
To keep the sensor from restarting, you can either remove that script, or
on systems that use symbolic links in rc.X directories (Linux, Solaris),
remove that link.
On most Linuxes, this is fairly straightforward with chkconfig(8):
# chkconfig --del sensorotherwise, you will need to:
# rm /etc/rc*.d/S99sensorBSD variants do not use these symlinks, and require the script be removed, or the execute permission on that script be removed:
# chmod -x /usr/local/etc/rc.d/idabench.sh
/usr/local/idabench/sensor/
/var/log/idabench
crontab -e), removing the lines inserted by the installer. They are commented to ease identification.
userdel -r should do the trick.