Awesome
🔃 slinkwatch ![CircleCI](https://circleci.com/gh/DCSO/slinkwatch.svg?style=svg)
slinkwatch is the Suricata Link Watcher, a tool to dynamically maintain interface
entries in Suricata's configuration file, depending on what network interfaces are connected. It is meant to ease deployment of identical sensor installations at many heterogenous sites, allowing to make full use of the sensor resources in the light of varying monitoring volume.
Interaction with Suricata
In order to propagate changed interface configuration to Suricata, one would need to configure Suricata in such a way that the section of the configuration YAML created by the slinkwatch template is included from a separate file, e.g. via
...
include: interfaces.yaml
...
in, for example, /etc/suricata/suricata.yaml
and then specifying /etc/suricata/interfaces.yaml
as the --target-file
in the slinkwatch call. Note that it must be writable by the slinkwatch process!
After modifying this file whenever a status change occurs, slinkwatch will attempt to restart Suricata. For systems that run systemd, slinkwatch will always try to restart the service given by the --service-name
option (default is suricata.service
). On non-systemd systems, it will run a simple command to restart Suricata (default is /etc/init.d/suricata restart
). Whether systemd is available will be checked at runtime.
Resource assignment
Support for interfaces going online and offline at runtime obviously raises the question of how to assign computing resources (i.e. detection threads) to the individual interfaces. Unless all interfaces on a sensor are completely identical in terms of supported bandwidth and traffic, it is not sufficient to simply assign equal amounts of threads to all interfaces that are connected at a given point in time. For example, one might have a 10Gbit interface eth1
and a 1Gbit interface eth2
on such a machine, and most certainly one would want more threads assigned to the former than to the latter. Even more importantly, how would an existing assignment be changed to be most efficient when another 10Gbit interface, say eth3
gets a link?
We address this issue using thread weights. That is, each interface i is assigned a integer value w<sub>i</sub> to denote its resource allocation importance. For example, in the case above we could assign w<sub>eth1</sub> = w<sub>eth3</sub> = 10 and w<sub>eth2</sub> = 2. We also consider the active set of interfaces A as the set of all interfaces that have an active link. On a machine with n threads available for detection, we can then assign to each interface i the value
as the number of threads allocated to detection for traffic on interface i. For example, for n = 40 we would then set
and
We aim for slight overcommitment of CPU hyperthreads to avoid idling CPUs as much as possible.
Installing dependencies via dep
The component of slinkwatch talking to systemd requires a specific godbus version. Please make sure to run
$ dep ensure
before building to make sure the correct version constraints apply.
Usage
Define the interfaces that are available to assign in a YAML file, together with their weights:
# Interfaces available for Suricata
---
ifaces:
eth1:
clusterid: 98
threadweight: 10
eth2:
clusterid: 97
threadweight: 2
eth3:
clusterid: 96
threadweight: 10
Adjust the template to fit the desired configuration format:
%YAML 1.1
---
af-packet:{{ range $iface, $vals := . }}
- interface: {{ $iface }}
threads: {{ $vals.Threads }}
cluster-id: {{ $vals.ClusterID }}
cluster-type: cluster_flow
defrag: yes
rollover: yes
use-mmap: yes
tpacket-v3: yes
use-emergency-flush: yes
buffer-size: 128000
{{ else }}
- interface: default
threads: auto
use-mmap: yes
rollover: yes
tpacket-v3: yes
{{ end }}
Finally, run slinkwatch, preferably in the background (there's also a systemd service unit file in the repo).
$ slinkwatch run
It is possible to specify the locations of the template and config file using the command line parameters:
$ slinkwatch run --help
Run the slinkwatch service
Usage:
slinkwatch run [flags]
Flags:
-c, --config string Configuration file (default "config.yaml")
-d, --delta-bytes uint threshold of bytes to be exceeded on interface to be marked as up (default 100)
-h, --help help for run
-i, --interfaces string Template file for interfaces (default "interfaces.tmpl")
-p, --poll-interval duration poll time for interface changes (default 5s)
-r, --restart-command string Suricata restart command (default "/etc/init.d/suricata restart")
-s, --service-name string systemd service name for Suricata service (default "suricata.service")
-t, --target-file string Target YAML file with interface information (default "/etc/suricata/interfaces.yaml")
Other commands
slinkwatch make-config
creates an initial YAML file with skeleton config entries for local interfaces (or a subset defined by a regular expression)slinkwatch makeman
creates a set of man pages for the toolslinkwatch show-active
lists the currently active set of interfaces (useful for debugging)
Dependencies/requirements
Needs ifplugo for network change notifications. This introduces a runtime dependency on libdaemon. It is also highly recommended to use systemd.
Authors
Sascha Steinbiss
License
GPL2 (due to ifplugo being GPL2).