servsock

NAME
SYNTAX
DESCRIPTION
OPTIONS
FILES
EXAMPLES
AUTHORS
NOTES
SEE ALSO

NAME

servsock − Threaded server for sockserv

SYNTAX

servsock [−bdfhlnqTuv] [−A delay] [−c <config>] [−D <dropsocket>] [−H highwater] [−L lowwater] [−m mode] [−M priority] [−p port] [−P pidfile] [−s socketname] [−S server] [−U alertsocket] [−w daemondir] [−V area,level] [−W swapdir] [−Z TimeZone]

DESCRIPTION

This is a threaded server to gather alerts from sockserv processes running on distributed snort sensors. These alerts are feeded via a unix domain socket to a database, either MySQL or PostgreSQL.

The main procress listens on a TCP port and waits for incoming connections from the sockserv program. For each established connection the main program forks so that for each sensor one sockservservsock pair exists.

Like sockserv one thread gathers the incoming alerts and buffers them whereas the second thread writes this alerts to a database.

To limit the buffer size used to store alerts there is an optional drop feature. To use it servsock has to be compiled with −DDROP. If this feature is enabled (option −D) and the number of buffered alerts reaches the highwater mark then the most recent alerts are dropped to the unix socket dropsocket until the lowwater mark is reached.

A program called drop is able to create such an unix socket and work with the alerts.

Additional there is an optional alert feature similar to the drop feature. But here the alerts with a higher priority are dumped to the alertsocket after they were inserted in the database. The intention is to send the high priority alerts via email to emphasize the importance.

In contrast to drop there is also an ID with each alert to identify this alert in the database.

A problem exists if the database has gone after a remote sockserv has connected. In this special case it is possible that there are already buffered alerts on the central server which needs to be stored in the database. These alerts (with payload) are stored now in a special file called servsock_swap_{senorname} in the given swap directory. After this the connection is closed.
If the sockserv process reconnects again and the database is now available these alerts are read in first. Then the normal process starts as described above. The user running servsock must have the access options ’rwx’ on this directory.

Starting with FLoP−1.5.0 a control thread is added. Some parameters can be set on runtime regarding a single connection between servsock and sockserv via a named pipe called {SwapDir}/servsock_pipe_{sensorname} or for the sockserv process /tmp/sockserv_{sensorname}.
The setting can be changed with redirecting an echo statement of the configuration option into the pipe, e.g:
echo DumpConfig: 1 > /var/tmp/servsock_pipe_sensor1
This would print the acutal configuration settings of the servsock process connected to the sockserv on sensor1.
Supported commands are: Statistics, AlarmDelay, LowWater (if DROP is enabled), HighWater (if DROP is enabled), Debug, DBTrust, TimeZone, DumpConfig and UnixSocketPriority (if ALERT is enabled).

OPTIONS

−A delay

Print every delay seconds statistics about received, sent and dropped alerts. The change of these values between delay seconds is printed in brackets. See also option −l.

−b

Start the process in the background: daemon mode. This automatically activates option −l.

−c <config>

Use the file config as configuration file. In this file additional options can be set especially the options regarding the database access. The default is servsock.conf. See servsock.conf(5) for more details.
NOTE: The command line options have precedence above the parameters in the config file!
NOTE: A configuration file is required!

−d

Dump the actual configuration to stdout.

−D <dropsocket>

If there are more than highwater alerts buffered then the newest alerts are dropped to <dropsocket> until the lowwater mark is reached.

−f

Store additional information in the database so that a pcap packet can be rebuild. Therefore you need the program getpacket(8) and an extended database scheme (see README.payload).

−r

If value is positive then it will be tried to store additional information in the database so that a pcap containing all related tagged packets file can be rebuild. Therefore you need an extended database scheme (see README.payload).

−H highwater

Sets the highwater mark, see option −D. The default value is 10000.

−h

Print a help message and exit.

−l

Log statitiscs to syslog instead of stdout. See also option −A.

−L lowwater

Sets the lowwater mark, see option −D. The minimum value is 100. The difference between highwater and lowwater must be 10.

−m mode

Sets the umask to mode for 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 leading 0) or hex (with leading 0x) format.

−M priority

Alerts with equal or higher priority than priority are dumped to a unix domain socket after they were inserted in the database. If this value is negative then the absolute value is taken and the order is reversed. Then the lowest number is interpreted as the highest priority. See also option −U.

−n

OBSOLETE, now the sensor provides its name. This option is now ignored. Old behaviour: Do not resolve the full qualified names of the sensors, use the IP addresses instead. This will avoid conflicts with the database if on a new connection the DNS resolution fails.

−p port

Defines on which port to listen for incoming connections from sockserv. See also option −S.

−P PIDfile

Filename to store the PID. Note: This file must be writeable by the user running servsock!

−q

Disables the writing of dropped alerts to the unix socket.

−s <socketname>

Defines the name and directory where the unix domain socket of the database listens. The default is NULL. If <socketnameR> contains a colon ’:’ then the first part is interpreted as a hostname, the second as port number. In this case a TCP connection to the database will be used.
NOTE: The word NULL
results in a NULL pointer which means that the database library will use its own configuration file.

−S server

Defines the interface servsock should bind on. The name can be either a full qualified domain name (not very useful) or an IP address. The default is 0.0.0.0, servsock listens on all interfaces. See also option −s.

−T

Enable trust modus for the database. If set, it is assumed that the alert description is already part of the database. If this is not the case, the alert is added. So it is safe to enable this feature unless the transfer of alert message is disabled in snort. But this is an optional feature and usually disabled. (But would safe 256 Bytes on the wire.)

−u

Disables the use of the alert unix socket. This is useful if the alert is activated in the configuration file but you want not use the alert program.

−U <alertsocket>

Specifies the socket where alerts with a high prioriy are written to. This additionally enables the alert feature. See also option −M.

−v

Output version information and exit.

−V area,level

Activate debug output for area (see README.debug) for informations up to level. A value of ALL activates all areas, level should be between 0 (disabled) and 9 (maximum output). This option can be used several times for different values.

−w daemondir

Sets the working directory in daemon mode to daemondir. The default is to use the current working directory. It is useful to choose "/" to avoid blocking of mounted filesystems.

−W spooldir

Sets the directory where alerts canb swapped out temporarily if the database is not available or gone. This directory must have ’rwx’ rights for the user running servsock. The default value is /var/tmp, the swap files are called sensor_swap_<senorname>.

−Z TimeZone

Specify which timezone we should use to calculate the time. TimeZone=0 means to use the local timezone, all other values will use UTC.

FILES

servsock.conf
/tmp/drop
(unix socket)
/tmp/alert
(unix socket)
/tmp/servsock.pid
/var/tmp/servsock_swap_{sensorname}
(swap file)
/var/mp/servsock_pipe_{sensorname}
(named control pipe)

EXAMPLES

To run this program the standard way type:

servsock

To run it on all interfaces and TCP port 1234 using servsock.conf as configuration file:

servsock −c servsock.conf −S 0.0.0.0 −p 1234

To print every 30 seconds statistics to stdout and print the actual configuration:

servsock −d −A 30

AUTHORS

Dirk Geschke <Dirk@geschke−online.de>

NOTES

The drop and alert features are optional and have to be compiled in separately.
If it is not compiled in then the options −D, −L and −H are missing for the drop and the options −M, −u and −U are missing for the alert feature in the output of the −h option.
In contrast to sockserv the lowwater and highwater marks have to be choosen with more caution.
First there are more processes running than servsock especially the database. Further the bottleneck is not the network, it is usually the database. So it is quite normal that here the number of buffered alerts increases rapidly on a heavy attack.

Since the sensor name is taken from the IP address of the computer running sockserv there is only one sockserv instance per IP address allowed. Otherwise there will be a lot of collisions of inserts related to the database. (Two different sensors with the same name try to insert two different alerts with the same database ID, for example.)

If the connection dies, sockserv opens a new connection and a new servsock process is forked off. But if the old servsock thread feading the database did not finished yet we have a problem like two times the same sensor are logging. Therefore servsock has a list of up to 25 running child processes whith the sensor IP they are working with.
So if there is still one thread running any new connection of a sockserv process with the same IP address is rejected!

If a pid file exists the program checks for a running process with this id. If one is found the program exits. There is no check for which program is running, only if one runs!

SEE ALSO

servsock.conf(5), sockserv(8), alert(8), drop(8), snort(8)