Within this configuration guide, you will find instructions for modifying Suricata's helm chart. All changes should be made in the values.yaml file. Please share any bugs or features requests via GitHub issues.
By default, images are pulled from official EDCOP's official repositorie, and the respective tool's official repository. If you're changing this value, make sure you use the full repository name.
images:
suricata: gcr.io/edcop-public/suricata:<version>
logstash: docker.elastic.co/logstash/logstash:<version>
redis: redis:<version>
runner: gcr.io/edcop-public/runner:<version>
Suricata uses 2 or 3 interfaces depending on whether it is in passive or inline mode. If you choose passive mode, net2 will be ignored and net1 will be the name of the passive interface. By default, these interfaces are named calico, passive, inline-1, and inline-2. When useHostNetworking is set to true these interfaces are named calico, and the names of the interfaces you used in EDCOP-CONFIGURESENSORS.
useHostNetworking is used in situations where container networking is insufficient (such as the lack of SR-IOV). This allows the container to see all physical interfaces of the nodes. This has some security concerns due to the fact that Suricata now have access to all physical networking. When useHostNetworking is set, the interface names will be pulled from the secrets created by the CONFIGURESENSORS repository. If using passive mode only the passive interface will be used. If using inline, then both inline-interface1 and inline-interface2 will be used. When useHostNetworking is specified, the container will still be joined to the Calico network, but will ignore passive, inline-1, and inline-2 SR-IOV networks.
networks:
overlay: calico
net1: passive
net2:
suricataConfig:
useHostNetworking: false
inline: false
networks:
overlay: calico
net1: inline-1
net2: inline-2
suricataConfig:
useHostNetworking: false
inline: true
networks:
overlay: calico
suricataConfig:
useHostNetworking: true
To find the names of your networks, use the following command:
# kubectl get networks
NAME AGE
calico 1d
inline-1 1d
inline-2 1d
This value tells Kubernetes which hosts the daemonset should be deployed to by using labels given to the hosts. Hosts without the defined label will not receive pods. Suricata will only deploy to nodes that have been labeled 'sensor=true'
nodeSelector:
label: sensor
To find out what labels your hosts have, please use the following:
# kubectl get nodes --show-labels
NAME STATUS ROLES AGE VERSION LABELS
master Ready master 1d v1.9.1 ...,infrastructure=true
minion-1 Ready <none> 1d v1.9.1 ...,sensor=true
minion-2 Ready <none> 1d v1.9.1 ...,sensor=true
For a detailed explanation on how the deployment modes work, please click here. External options will only be used if you're in external mode and Redis is located on another host.
deploymentOptions:
deployment: standalone
externalOptions:
externalHost: 192.168.0.1
nodePort: 30029
alertsOnly when set to true in the values.yaml will disable logs for http,dns,tls,smtp. This is common when using another tool that may already be recording this such as Bro. It will still provide alerts.
Suricata can be deployed in either inline or passive mode depending on how your cluster is setup. Inline mode will route traffic through the box for active threat detection and mitigation, while passive mode simply alerts you to potential threats. For an inline mode setup, the following is required:
- An external traffic loadbalancer passing traffic through 2 interfaces on the host.
- An SR-IOV capable NIC with a sufficient number of VFs created for each interface being used.
- A total of 3 Kubernetes networks:
- An overlay network to pass container traffic (Calico by default).
- One SR-IOV network to accept network traffic and output to the second network.
- A second SR-IOV network to accept network traffic from the first interface and output it back to the loadbalancer.
As mentioned before, if inline is set to true, Suricata will be deployed in inline mode and will require 2 networks for passing traffic. Setting to false will enable passive mode. The home and external net settings tell suricata what you consider your internal and external network spaces. You can customize these as needed, but the external net is usually !$HOME_NET for simplicity.
suricataConfig:
inline: true
homeNet: '[192.168.0.0/16,10.0.0.0/8,172.16.0.0/12]'
externalNet: '!$HOME_NET'
If Suricata is set to inline mode, you will need to specify threads for both net0 and net1. The more threads you have, the more CPU space is required for packet processing.
suricataConfig:
...
net0Threads: 1
net1Threads: 1
Similarly, CPU affinity will utilize specific cores for packet processing. This setting will significantly increase performance, but should be used with cpu isolation to maximize individual core potential. For the cpusets, enter either a single core or range of cpus as shown below:
suricataConfig:
...
setCpuAffinity: yes
recieveCpuSet: 0-2
workerCpuSet: 3-7
workerThreads: 1
verdictCpuSet: 8-10
For worker CPU sets, please refer to your NUMA node configuration to prevent cache thrashing.
The first time Suricata is deployed, a container will be created that will pull the latest version of the rules from the sources defined by rulesSources. If enableRulesUpdates is set to true, a cron job will be created that will update all the rules across all the suricata instances as defined by rulesUpdateSchedule. Updating rules has been seen to double memory usage, and therefore care should be taken to increase the limit to at least 8G in the memory limit. EnableConf, disableConf, dropConf and modifyConf are all used to modify rules from the defaults after the rules are download so that these changes persist after each update. The format for these is basically the same as Suricata-updates but with a dash (-) symbol before each line. See here for more details of how to modify rules. https://suricata-update.readthedocs.io/en/latest/update.html#example-configuration-files
enableRulesUpdates: false
rulesUpdateSchedule: "* */12 * * *"
# List of all resources that will be pulled, can list multiple options
rulesSources:
- https://rules.emergingthreats.net/open/suricata-4.0/emerging.rules.tar.gz
ruleModifications:
enableConf:
- #2019401 < Example rule number to enable
... More rules ...
disableConf:
- #2019401 < Example rule number to disable
dropConf:
- #2019401 < Example rule number drop
modifyConf:
- #modifysid * "^drop(.*)noalert(.*)" | "alert${1}noalert${2}" < Exmaple rule to modify
You can set limits on Suricata to ensure it doesn't use more CPU/memory space than necessary. Finding the right balance can be tricky, so some testing may be required.
suricataConfig:
limits:
cpu: 2
memory: 4G
Logstash is only included in the Daemonset if you're using standalone mode and is used to streamline the rules required for the data it ingests. Having one Logstash instance per node would clutter rules and cause congestion with log filtering, which would harm our events/second speed. This instance will only deal with Suricata's logs and doesn't need complicated filters to figure out which tool the logs came from. Please make sure to read the Logstash Performance Tuning Guide for a better understanding of managing Logstash's resources.
logstashConfig:
threads: 2
batchCount: 250
initialJvmHeap: 4g
maxJvmHeap: 4g
pipelineOutputWorkers: 2
pipelineBatchSize: 150
limits:
cpu: 2
memory: 8G
Redis is also included in the Daemonset (except for external mode) for the same reasons Logstash is. Currently, you can only limit the resources of Redis in this section, but in the future we would like to add configmaps for tuning purposes.
redisConfig:
limits:
cpu: 2
memory: 8G