Introduction to the
Suricata is a network security monitoring (NSM) tool that uses community-created and user-defined signature sets, also known as rules, to examine and process network traffic. When Suricata detects suspicious packets or requests from any number of different services running on the server, it can generate logging events, trigger alerts, and abandon traffic.
By default, Suricata works as a passive intrusion detection system (IDS), scanning servers or networks for suspicious traffic. It will generate and record alerts for further investigation. It can also be configured as an active Intrusion Prevention system (IPS) to record, warn, and completely block network traffic that conforms to certain rules.
You can deploy Suricata on gateway hosts in your network to scan all incoming and outgoing network traffic from other systems, or you can run it locally on individual machines in both modes.
In this tutorial, you will learn how to install Suricata and how to customize some of the default Settings on Ubuntu 20.04 to suit your needs. You’ll also learn how to download Suricata’s existing signature set (often referred to as rule set) for scanning network traffic. Finally, you’ll learn how to test if Suricata is working properly when it detects data in suspicious requests and responses.
The premise condition
Depending on your network configuration and how you plan to use Suricata, your server may need more or less CPU and memory. In general, the more traffic you plan to check, the more resources you should allocate to Suricata. In a production environment, plan to start with at least 2 cpus and 4 or 8GB of memory. From there, you can add resources based on Suricata’s performance and the amount of traffic you need to handle.
If you plan to use Suricata to protect the server on which it runs, you will need to.
- An Ubuntu 20.04 server with 2 or more cpus, a sudo non-root user, and firewall enabled. To set this up, you can follow our Initial server setup tutorial for Ubuntu 20.04.
Otherwise, if you plan to use Suricata on a gateway host to monitor and protect multiple servers, you will need to ensure that the host’s network is configured correctly.
If you use DigitalOcean, you can follow this guide on how to configure a Droplet as a VPC gateway. These instructions should also apply to most Ubuntu servers.
Step 1 – Install Suricata
To start installing Suricata, you need to add the Open Information Security Foundation (OISF) software library information to your Ubuntu system. You can do this using the add-apt-repository command.
Run the following commands to add the software libraries to your system and update the list of available packages.
sudo add-apt-repository ppa:oisf/suricata-stable
Copy the codeWhen you are prompted to confirm that you want to add the library, press ENTER. This command will update the list of available packages for you after adding new software libraries.
You can now install the Suricata package using the apt command.
sudo apt install suricata
Copy the codeNow that the package is installed, enable suricata.service so that it will run when your system restarts. Use the systemctl command to enable it.
sudo systemctl enable suricata.service
Copy the codeYou should receive output like the following indicating that the service is enabled.
Outputsuricata.service is not a native service, redirecting to systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install enable suricata
Copy the codeBefore moving on to the next section of the tutorial, which explains how to configure Suricata, stop the service using Systemctl.
sudo systemctl stop suricata.service
Copy the codeStopping Suricata ensures that when you edit and test the configuration file, any changes you make will be validated and loaded when Suricata starts again.
Step 2 – Configure Suricata for the first time
The Suricata package from the OISF repository contains a configuration file that covers a variety of usage scenarios. Suricata’s default mode is IDS mode, so no traffic is discarded, only records. It’s a good idea to set this mode to default when you learn Suricata. Once you have configured Suricata and integrated it into your environment, and have a good idea of the type of traffic it will alert you to, you can choose to turn on IPS mode.
However, the default configuration still has some Settings that you may need to change depending on your environment and needs.
(Optional) Enable the community traffic ID
Suricata can include a community ID field in its JSON output to make it easier to match individual event records with records in datasets generated by other tools.
If you plan to use Suricata with other tools, such as Zeek or Elasticsearch, it’s a good idea to add a community ID now.
To enable this option, please use the nano or your favorite editor to open/etc/suricata/suricata yaml.
sudo nano /etc/suricata/suricata.yaml
Copy the codeFind line 120 and read # Community Flow ID. If you are using nano, when prompted for the line number, type CTRL+_, then 120. Below this line is the community-id key. Set it to true to enable this setting.
/etc/suricata/suricata.yaml
.# Community Flow ID
# Adds a 'community_id' field to EVE records. These are meant to give
# records a predictable flow ID that can be used to match records to
# output of other tools such as Zeek (Bro).
#
# Takes a 'seed' that needs to be same across sensors and tools
# to make the id less predictable.
# enable/disable the community id feature.
community-id: true.Copy the codeNow when you check events, they will have an ID like 1:S+3BA2UmrHK0Pk+u3XH78GAFTtQ=, which you can use to correlate records in different NMS tools.
Save and close the/etc/suricata/suricata yaml files. If you are using nano, you can press CTRL+X, then Y and ENTER to confirm.
Determine the network interface to use
You may need to override the default network interface or interface that you want Suricata to check for traffic. The configuration file shipped with the OISF Suricata package defaults to checking traffic on a device called eth0. If your system uses a different default network interface, or if you want to check traffic on more than one interface, you will need to change this value.
To determine the device name for your default network interface, you can use the IP command, as shown below.
ip -p -j route show default
Copy the codeThe -p flag formats the output to make it more readable, and the -j flag prints the output as JSON.
You should receive output like the following.
The Output [{" DST ":" default ", "gateway" : "203.0.113.254", "dev" : "eth0," "protocol" : "static", "flags" : []}]Copy the codeThe dev line represents the default device. In the output of this example, the device is the eth0 interface highlighted. Your output might display a device name, such as ens… Or eno… . Whatever the name is, write it down.
Now you can edit Suricata’s configuration and validate or change the interface name. Using nano or your favorite editor to open/etc/suricata/suricata yaml configuration file.
sudo nano /etc/suricata/suricata.yaml
Copy the codeScroll through the file until you get to line 580 or so and read af-packet:. If you are using nano, you can also go directly to the line, type CTRL+_, and enter the line number. Below this line is the default interface Suricata uses to check traffic. Edit the line to match your interface, as highlighted in the example below.
/etc/suriata/suricata.yaml
# Linux high speed capture support
af-packet:
- interface: eth0
# Number of receive threads. "auto" uses the number of cores
#threads: auto
# Default clusterid. AF_PACKET will load balance packets based on flow.
cluster-id: 99
. . .
Copy the codeIf you want to check the traffic of other interfaces, you can add more – interface: eth… YAML object. For example, to add a device named ENP0S1, scroll down to the bottom of the AF-Packet section, to about 650 lines. To add a new interface, insert it before the -interface: default section, as highlighted in the example below.
/ec/suricata/suricata.yaml
# For eBPF and XDP setup including bypass, filter and load balancing, please
# see doc/userguide/capture-hardware/ebpf-xdp.rst for more info.
- interface: enp0s1
cluster-id: 98
- interface: default
#threads: auto
#use-mmap: no
#tpacket-v3: yes
Copy the codeMake sure to select a unique cluster-ID value for each -interface object.
Keep your editor open and continue to the next section where you will configure live rule reloading. If you don’t want to enable this setting, you can save and close the/etc/suricata/suricata yaml files. If you are using nano, you can press CTRL+X, then Y, ENTER to confirm.
Configure real-time rule reloading
Suricata supports real-time rule reloading, which means you can add, delete, and edit rules without restarting the running Suricata process. To enable the live reload option, scroll to the bottom of the configuration file and add the following lines.
/etc/suricata/suricata.yaml
. . .
detect-engine:
- rule-reload: true
Copy the codeWith this setting, you can send SIGUSR2 system signals to the running process, and Suricata will reload any changed rules into memory.
A command like the one below will tell the Suricata process to reload its rule set without restarting the process.
sudo kill -usr2 $(pidof suricata)
Copy the codeThe $(pidof Suricata) portion of the command invokes a child shell and finds the ID of the running Suricata daemon. The sudo kill -usr2 part of the command begins by sending SIGUSR2 signals to the process ID reported by the child shell using the kill tool.
You can run suricata-update at any time, or use this command when adding or editing your own custom rules.
Save and close the/etc/suricata/suricata yaml files. If you are using nano, you can press CTRL+X, then Y and ENTER to confirm.
Step 3 – Update the Suricata rule set
At this point in the tutorial, if you want to start Suricata, you will receive a warning in the log like the following, that there are no load rules.
Output<Warning> - [ERRCODE: SC_ERR_NO_RULES(42)] - No rule files match the pattern /var/lib/suricata/rules/suricata.rules
Copy the codeBy default, the Suricata package includes a limited set of detection rules (in the /etc/suricata/rules directory), so opening Suricata at this point will only detect limited bad traffic.
Suricata includes a tool called Suricata-Update to get rule sets from external vendors. Run it as follows to download the latest rule set for your Suricata server.
sudo suricata-update
Copy the codeYou should receive the following output.
Output19/10/2021 -- 19:31:03 - <Info> -- Using data-directory /var/lib/suricata. 19/10/2021 -- 19:31:03 - <Info> -- Using Suricata configuration /etc/suricata/suricata.yaml 19/10/2021 -- 19:31:03 - <Info> -- Using /etc/suricata/rules for Suricata provided rules. . . . 19/10/2021 -- 19:31:03 - <Info> -- No sources configured, will use Emerging Threats Open 19/10/2021 -- 19:31:03 - <Info> -- Fetching https://rules.emergingthreats.net/open/suricata-6.0.3/emerging.rules.tar.gz. - 3044855/3044855. 100%.. 19/10/2021 - 19:31:06 - <Info> -- Writing rules to /var/lib/suricata/rules/suricata.rules: total: 31011; enabled: 23649; added: 31011; removed 0; modified: 0 19/10/2021 -- 19:31:07 - <Info> -- Writing /var/lib/suricata/rules/classification.config 19/10/2021 -- 19:31:07 - <Info> -- Testing with suricata -T. 19/10/2021 -- 19:31:32 - <Info> -- Done.Copy the codeHighlighted a few lines of said suricata – update already obtained free Emerging ThreatsET Open Rules, and save it to the suricata/var/lib/suricata/Rules/suricata Rules file. It also shows the number of rules that were processed, and in this example, 31,011 were added, of which 23,649 were enabled.
Add a rule set vendor
The Suricata-Update tool can obtain rules from a variety of free and commercial rule set vendors. Some rule sets, such as the ET Open set you’ve added, are available for free, while others require a paid subscription.
You can use the list-sources flag to suricata-update like this to list the default set of rule providers.
sudo suricata-update list-sources
Copy the codeYou will receive a list of sources like the one below.
Output. . .
19/10/2021 -- 19:27:34 - <Info> -- Adding all sources
19/10/2021 -- 19:27:34 - <Info> -- Saved /var/lib/suricata/update/cache/index.yaml
Name: et/open
Vendor: Proofpoint
Summary: Emerging Threats Open Ruleset
License: MIT
. . .
Copy the codeFor example, if you want to include the tgreen/hunting rule set, you can enable it using the following command.
sudo suricata-update enable-source tgreen/hunting
Copy the codeThen run Suricata-Update again and the new rule set will be added to the existing ET Open rules and any other rules you have downloaded.
Step 4 – Verify Suricata configuration
Now that you have edited the Suricata configuration file to include the optional community ID, specify the default network interface, and enable live rule reloading, it is a good idea to test the configuration.
Suricata has a built-in test mode that checks whether the configuration file and any contained rules are valid. Run Suricata in test mode with the -t flag to verify the changes you made in the previous section. The -v flag prints some additional information, while the -c flag tells Suricata where to find its configuration file.
sudo suricata -T -c /etc/suricata/suricata.yaml
Copy the codeTesting can take some time, depending on how many cpus you allocate to Suricata and how many rules you add, so be prepared to wait a minute or two to complete.
Using the default ET Open rule set, you should receive the following output.
Output21/10/2021 -- 15:00:40 - <Info> - Running suricata under test mode
21/10/2021 -- 15:00:40 - <Notice> - This is Suricata version 6.0.3 RELEASE running in SYSTEM mode
21/10/2021 -- 15:00:40 - <Info> - CPUs/cores online: 2
21/10/2021 -- 15:00:40 - <Info> - fast output device (regular) initialized: fast.log
21/10/2021 -- 15:00:40 - <Info> - eve-log output device (regular) initialized: eve.json
21/10/2021 -- 15:00:40 - <Info> - stats output device (regular) initialized: stats.log
21/10/2021 -- 15:00:46 - <Info> - 1 rule files processed. 23879 rules successfully loaded, 0 rules failed
21/10/2021 -- 15:00:46 - <Info> - Threshold config parsed: 0 rule(s) found
21/10/2021 -- 15:00:47 - <Info> - 23882 signatures processed. 1183 are IP-only rules, 4043 are inspecting packet payload, 18453 inspect application layer, 107 are decoder event only
21/10/2021 -- 15:01:13 - <Notice> - Configuration provided was successfully loaded. Exiting.
21/10/2021 -- 15:01:13 - <Info> - cleaning up signature grouping structure... complete
Copy the codeIf there is an error in your configuration file, then test mode will generate a specific error code and information that you can use to help troubleshoot the fault. For example, including a nonexistent rules file named test.rules produces the following error.
Output21/10/2021 -- 15:10:15 - <Info> - Running suricata under test mode
21/10/2021 -- 15:10:15 - <Notice> - This is Suricata version 6.0.3 RELEASE running in SYSTEM mode
21/10/2021 -- 15:10:15 - <Info> - CPUs/cores online: 2
21/10/2021 -- 15:10:15 - <Info> - eve-log output device (regular) initialized: eve.json
21/10/2021 -- 15:10:15 - <Info> - stats output device (regular) initialized: stats.log
21/10/2021 -- 15:10:21 - <Warning> - [ERRCODE: SC_ERR_NO_RULES(42)] - No rule files match the pattern /var/lib/suricata/rules/test.rules
Copy the codeWith this error, you can edit your configuration file to include the correct path, or fix invalid variables and configuration options.
Once your Suricata test mode runs successfully, you can proceed to the next step, which is to start Suricata in daemon mode.
Step 5 – Run Suricata
Now that you have a valid Suricata configuration and rule set, you can start the Suricata server. Run the systemctl command.
sudo systemctl start suricata.service
Copy the codeYou can run the systemctl status command to check the status of the service.
sudo systemctl status suricata.service
Copy the codeYou should receive output similar to the following.
Service -lsb: Next Generation IDS/IPS Loaded: Loaded (/etc/init.d/suricata; generated) Active: active (running) since Thu 2021-10-21 18:22:56 UTC; 1min 57s ago Docs: man:systemd-sysv-generator(8) Process: 22636 ExecStart=/etc/init.d/suricata start (code=exited, status=0/SUCCESS) Tasks: 8 (limit: 2344) Memory: 359.2 M CGroup: / system. Slice/suricata service └ ─ 22656 / usr/bin/suricata - c/etc/suricata/suricata yaml -- pidfile/var/run/suricata. Pid --af-packet -D -vvv Oct 21 18:22:56 suricata systemd[1]: Starting LSB: Next Generation IDS/IPS... Oct 21 18:22:56 suricata suricata[22636]: Starting suricata in IDS (af-packet) mode... done. Oct 21 18:22:56 suricata systemd[1]: Started LSB: Next Generation IDS/IPS.Copy the codeAs with the commands in test mode, Suricata takes a minute or two to load and parse all the rules. You can use the tail command to see if there is any specific information in Suricata’s logs indicating that it has started.
sudo tail -f /var/log/suricata/suricata.log
Copy the codeYou will receive several lines of output, and the terminal may get stuck when Suricata loads. Continue to wait for the output until you receive a line like the one below.
Output19/10/2021 -- 19:22:39 - <Info> - All AFP capture threads are running.
Copy the codeThis line indicates that Suricata is running and ready to check traffic. You can exit the tail command by pressing CTRL+C.
Now that you have verified that Suricata is running, the next step in this tutorial is to check if Suricata has detected a request for the test URL that is intended to generate an alert.
Step 6 – Test the Suricata rule
The ET Open rule set you downloaded contains more than 30,000 rules. A full explanation of how Suricata rules work and how to build them is beyond the scope of this introductory tutorial. Subsequent tutorials in this series will explain how rules work and how to build your own rules.
For the purposes of this tutorial, it is sufficient to test whether Suricata detects suspicious traffic using the configuration you generate. Suricata Quick Start recommends using the curl command to test the ET Open rule, number 2100498.
Run the following command to generate an HTTP request that will return a response matching Suricata’s alert rules.
curl http://testmynids.org/uid/index.html
Copy the codeThe curl command will output a response similar to the following.
Outputuid=0(root) gid=0(root) groups=0(root)
Copy the codeThe response data for this example is to trigger an alert by pretending to return the output of a command like id that might be running on the remote system being attacked through the Web shell.
Now you can check Suricata’s logs to see if there are any alerts. In the default configuration of Suricata, two logs are enabled. The first is in the/var/log/suricata/fast. The log, the second is in the/var/log/suricata/eve. The log of machine-readable log.
check/var/log/suricata/fast.log
To check/var/log/suricata/fast. Log in with you if there is a curl request corresponding log entry, please use the grep command. Using the 2100498 rule identifier in the Quickstart document, search for entries that match it using the following command.
grep 2100498 /var/log/suricata/fast.log
Copy the codeIf your request uses IPv6, you should receive the following output, where 2001:DB8::1 is the public IPv6 address of your system.
[secondary_label] Output 10/21/2021-18:35:54.950106 [**] [1:21000498:7] GPL ATTACK_RESPONSE ID Check Returned root [**] [Classification: Potentially Bad Traffic] [Priority: 2] {TCP} 2600:9000:2000:4400:0018:30b3:e400:93a1:80 -> 2001:DB8::1:34628Copy the codeIf your request uses IPv4, your log should have information that 203.0.113.1 is your system’s public IPv4 address.
[secondary_label] Output 10/21/2021-18:35:57.247239 [**] [1:21000498:7] GPL ATTACK_RESPONSE ID Check Returned root [**] [Classification: Potentially Bad Traffic] [Priority: 2] {TCP} 204.246.178.81:80 -> 203.0.113.1:36364Copy the codeNotice the value 2100498 highlighted in the output, which is the signature ID (SID) that Suricata uses to identify the rule.
check/var/log/suricata/eve.log
Suricata also USES the JSON format entry to the event log to/var/log/Suricata/eve. The log (nicknamed eve logs).
The Suricata documentation recommends using the JQ tool to read and filter entries in this file. If you don’t have JQ on your system, install it using apt.
sudo apt install jq
Copy the codeOnce you have jQ installed, you can filter events in EVE logs by searching for the 2100498 signature using the following command.
jq 'select(.alert .signature_id==2100498)' /var/log/suricata/eve.json
Copy the codeThis command examines each JSON entry and prints any entry with an Alert object in which the Signature_ID key matches the 2100498 value you are searching for. The output will look something like the following.
Output{"timestamp": "2021-10-21T19:42:47.368856+0000", "flow_id": 775889108832281, "in_iface": "eth0", "event_type": "Alert", "src_ip" : "203.0.113.1", "src_port:" 80, "dest_ip" : "147.182.148.159", "dest_port:" 38920, "proto" : "TCP", "community_id": "1:XLNse90QNVTgyXCWN9JDovC0XF4=", "alert": { "action": "allowed", "gid": 1, "signature_id": 2100498, "rev": 7, "signature": "GPL ATTACK_RESPONSE id check returned root", "category": "Potentially Bad Traffic", . . . }Copy the codeNote the highlighted “Signature_ID “: 2100498, line, which is the key JQ is searching for. Also please note that the highlighted “community_id” : “1: XLNse90QNVTgyXCWN9JDovC0XF4 =”, this line is highlighted in the JSON output. This key is the generated community traffic identifier that you enable in Suricata’s configuration file.
Each alert will generate a unique community traffic identifier. Other NMS tools can also generate the same identifier so that Suricata alerts can be cross-referenced with the output of other tools.
Matching log entries in any of the log files means that Suricata has successfully checked for network traffic, matching it to detection rules and generating alerts for subsequent analysis or logging. Future tutorials in this series will explore how to send Suricata alerts to a security Event Management (SIEM) system for further processing.
Step 7 – Handle Suricata alerts
Once you have set up and tested the alerts, you can choose what to do with them. For some use cases, logging alerts for audit purposes may be sufficient; Or you might prefer to take a more aggressive approach to blocking traffic from a system that generates duplicate alerts.
If you want to block traffic based on the alerts generated by Suricata, one way is to use the entries in the EVE logs and then add firewall rules to restrict access to your system or systems. You can use JQ to extract specific fields from the alert and then add UFW or IPtables rules to block requests.
Again, this example is a hypothetical scenario that uses request and response data that is deliberately crafted. In order to determine which traffic is legitimate and which can be blocked, it is crucial that you understand the systems and protocols your environment should be able to access.
conclusion
In this tutorial, you have installed Suricata from OISF’s software library. Installing Suricata in this way ensures that you will receive updates whenever a new version of Suricata is released. After installing Suricata, you edited the default configuration to add a community traffic ID for use with other security tools. You also enable live rule reloading and download an initial set of rules.
Once you’ve verified Suricata’s configuration, you’ve started the process and generated some test HTTP traffic. You verify that Suricata can detect suspicious traffic by checking the two default logs to make sure they contain alerts that correspond to the rules you are testing.
For more information about Suricata, please visit the official Suricata website. For more details on any configuration options you configure in this tutorial, refer to the Suricata User Guide.
Now that you have Installed and configured Suricata, you can move on to the next tutorial in this series (coming soon), where you will explore how to write your own custom Suricata rules. You’ll learn about different ways to create alerts and even how to completely discard traffic based on criteria such as invalid TCP/IP packets, the content of DNS queries, HTTP requests and responses, and even TLS handshakes.