Chapter 5. The programs sockserv and servsock
These two programs are very similar and work with two parallel threads. One thread receives the alerts and the other processes these data.
The first thread of the program sockserv[1] receives alerts from snort and stores them in a buffer in memory. The second thread takes these alerts and forwards them via TCP/IP to the servsock[2] program. This program consists of a master program waiting for connections from sockserv processes of remote sensors. For each connection one process is forked off. Each of these processes consist of two threads. One thread simply receives the incoming alerts, the second stores them to the database.
Starting with version 1.5.0 there is a third thread running, a control thread. This thread listens on a named pipe which can be used to change several options during runtime. See the file README.ctrl for further informations.
5.1. The details of sockserv
This program provides an unix domain socket for snort. One thread simply receives alerts via this socket and stores them in memory, see picture sockserv/servsock process.
Through the threading design and the use of a memory buffer the risk of loosing alerts is minimized. The output plugins from snort are reduced to a simple write statement on an unix domain socket. If more alerts are generated than sockserv can send to the central server these alerts are buffered in memory until the attack flood decreases.
To reduce the problem on memory shortage due to an high attack flood,
the maximum number of alerts in the buffer can be limited. This is done via
two parameters, the LowWater and HighWater
marks. If more alerts than the HighWater mark are buffered in memory
as many alerts are dropped until the LowWater mark is reached. All dropped
alerts are written to an unix domain socket. The program drop is able to provide such a
socket, receive these alerts and send them via email to a list of
recipients. Otherwise, if you do not use drop, the these informations
are written to stdout or syslog.
If either sockserv can not connect to servsock on startup or the connection is closed during runtime the program tries to reopen the connection after a short delay for several times.
Note: If the buffer of sockserv is empty at this point of time it tries a reconnect only if a new alert arrives.
All output can be redirected to syslog, using the
facility LOCAL0 and level
INFO. A daemon mode is also
supported. Finally statistics could be printed on a periodical basis
or once by using the named pipe of the sockserv
process.
5.1.1. Options
There are several options available:
sockserv [-bhlqv] [-Adelay] [-Ddropsocket] [-HHighWater] [-Iinterface] [-LLowWater] [-mmode] [-Mmaxtry] [-Nsensorname] [-pport] [-Ppidfile] [-ssnortsocket] [-Sserver] [-Varea,level] [-wdir] [-Wwaittime]
The sockserv options in detail
-AdelayPrint every
delayseconds statistics about received, sent and dropped alerts. The change of these values betweendelayseconds is printed in brackets. See also option-l.-bStart the process in the background: daemon mode. This automatically activates option
-l.-DdropsocketIf there are more than
HighWateralerts buffered then the newest alerts are dropped to dropsocket until theLowWatermark is reached.-hPrint a help message and exit.
-HHighWaterSets the
HighWatermark, see option-D. The default value is 10000.-IinterfaceInterface on which snort is sniffing. This parameter is optional but together with the sensorname, see Option
-N, it should be unique. By default this option is not used.-lLog statitiscs to syslog instead of
stdout. See also option-A.-qEnable quiet dropping, no dropped alerts were written to the dropsocket, see option
-D.-LLowWaterSets the
LowWatermark, see option-D. The default value is 9900.-mmodeSets the umask to
modefor the daemon mode. This affects the mode for the created unix socket and PID file. The mode can be either given in ascii, octal (with leading0) or hex (with leading0x) format.-MmaxtrySets the maximum number of tries to (re-) connect to the
server. See also option-W.-NsensornameSensorname which should be used in the database. By default this is the hostname of the machine running sockserv. It is now possible to use more than one instance of sockserv per sensor. Note: You have to change the unix socket for different instances, see Option
-s.-pportDefines on which
portto try to reach theserverrunning servsock. See also option-S.-PpidfileFilename to store the PID. Note: This file must be writeable by the user running sockserv!
-ssnortsocketDefines the name and directory where the unix domain socket is opened for snort. The default is /tmp/snort.
Maybe the default should be changed to something like /tmp/snort_sensorname if option
-Nis used.-SserverDefines the server running servsock. The name can be either a full qualified domain name or an IP address. The default is
127.0.0.1. See also option-p.Note: The default is only useful for testing. In real productive systems you should use a separate server for the database and servsock.
-Varea,valueSets the debug level of the program.
Areaspecifies the section of the code which should generate debug output.valueshould be between 0 (disabled) and 9 (maximum output). For further information read the file README.debug.-wdirSets the working directory in daemon mode to
dir. The default is to use the current working directory. It is useful to choose / to avoid blocking of mounted filesystems.-WwaittimeTime in seconds to wait between two tries to connect to the server. See also option
-M.
5.1.2. Signalhandling
Currently the following signals are used with sockserv:
Signals used with sockserv
SIGINTCancels the process, prints the final statistics and performs a clean exit. The
socketnameandpidfileare removed.SIGTERMThis signal results in the same behaviour as
SIGINT.SIGPIPEThis signal is ignored. If the servsock program is interrupted during the data is sended. In this case we simply try to open a new connection and therefore we have to ignore this signal.
SIGHUP[3]If this signal is received sockserv stops and restarts. First, if enabled, all buffered alerts are dropped via dropsocket and the final statistics are printed. Further
socketnameandpidfileare removed to enable a restart of the program. (Otherwise the program would fail since the id does not change!)
The actual version of sockserv uses a control thread to change some parameters during runtime. This thread is also used to print statistics on a periodically interval instead of using signals.
5.1.3. Some additional notes
The drop feature is not enabled by default and has to
be compiled in separately. If it is not compiled in then the
options -D, -L and -H are missing in the
output of the -h
option. It is highly advisable to choose a very large
HighWater mark to buffer as
many alerts as possible. This will reduce the possibility of
information loss. On the other hand the difference between
HighWater and LowWater should not be too large. To
minimize information loss the alerts are spooled via drop to a mail
server. Normally this server is either located on the
central server or is reached via this
server. If there are too many alerts spooled to drop the emails become
unreadable long.
Problems should only arise if the connection to the servsock program is lost for a longer period. But if there are network problems then it is alike that drop will fail too. If this happens then the alerts are written either to stdout or syslog.
Be cautious: With increasing buffer usage the memory consumption
raises with about 3 kB for each alert (actually 1048 bytes per alert on an
x86_32 System plus payload). But this memory is shared
with the snort process. So set the HighWater to a value where it is safe for the
snort process.
If a pid file exists then the program checks only for a running process with this PID. If one process is found the program exits. There is no check for which program is running, only if one with this PID exists!