In this tutorial, you will learn how to install and configure Suricata as an Intrusion Detection System (IDS) on an Ubuntu Linux machine, using the official community repository (PPA).
Suricata is a high-performance, open-source network security engine capable of operating on three main fronts:
- IDS (Intrusion Detection System): Passively monitors network traffic and generates detailed alerts if it identifies malicious packets or anomalies.
- IPS (Intrusion Prevention System): Acts inline with the network flow, being able to actively drop packets or block invading IP addresses in real-time.
- NSM (Network Security Monitoring): Logs network events and metadata (DNS, HTTP, TLS, traffic flows) in structured files (JSON).
Installing Suricata on Ubuntu
Although the standard Ubuntu repository has the Suricata package, it tends to be older. To ensure access to the latest features and fixes, we will add the official repository maintained by the OISF (Open Information Security Foundation).
Open the terminal and execute:
sudo add-apt-repository ppa:oisf/suricata-stable
Next, we will update our repositories, as we just added a new repository.
sudo apt updateNow, let’s install Suricata. For this we will use the command below.
sudo apt install suricata -y
To ensure that the service is started and configured to come up automatically whenever the computer is restarted, use the command:
sudo systemctl enable --now suricata
Alternative Suricata Installation
Suricata is multi-platform and can be installed on RHEL/CentOS/Fedora based distributions, Debian, FreeBSD, macOS, and even Windows. If you are not using Ubuntu, check the binary and source packages on the project’s official website:.
Configuring Suricata (Interface and HOME_NET)
The main configuration directory is in /etc/suricata/. Let’s go there to inspect the files:
cd /etc/suricata
lsWe can observe in the figure below that there are several files and a folder named rules.
The central file where almost everything is adjusted is called suricata.yaml. Before editing it, we need to find out which network interface we are going to inspect.
Identifying the Network Interface
In our VirtualBox lab, the machine has two interfaces:
- One interface in NAT mode (used for Internet access);
- One interface in Internal Network mode, through which the traffic of the clients we want to protect will pass.
Find out the names of the interfaces with the command:
ip a
Attention: Disregard the
lo(loopback) interface. In our case, the interface connected to the internal network that we wish to monitor isenp0s8. Identify yours before proceeding.
Editing the suricata.yaml file
Open the configuration file with the editor of your choice (e.g., nano):
sudo nano /etc/suricata/suricata.yamlA) Adjust the interface in af-packet
Locate the af-packet: section (usually around line 580) and change the default interface (eth0) to your network interface:
Inside the line “– interface: eth0″ we will remove “eth0” and include the name of our interface which is enp0s8.
Below is the already modified interface.
Define the HOME_NET variable
Scroll up to the beginning of the file, in the variables section (vars:). By default, HOME_NET comes with generic private ranges, but it’s good practice to define the exact subnet you are protecting (e.g., 192.168.11.0/24):
Suricata in Host IDS/IPS Mode
When Suricata is deployed as a Host IDS/IPS (meaning its purpose is strictly to defend the local machine where it is installed, rather than acting as a gateway for an entire network), the HOME_NET variable in suricata.yaml should be restricted to the host’s own IP address using a /32 CIDR mask (e.g., HOME_NET: "[192.168.24.20/32]").
This distinction is critical: by designating the protected host as the sole member of HOME_NET, any other machine on the local network, including an attacking virtual machine on the same subnet, will be evaluated by the engine as $EXTERNAL_NET. This ensures that default scan and exploit signatures targeting local endpoints properly trigger alerts and inline drop actions during lab evaluations.
Alternatively, to simplify testing in lab environments, you may uncomment and set EXTERNAL_NET: "any"
Technical tip for Ubuntu/Debian: In some installations via APT, Suricata reads a default interface in the
/etc/default/suricatafile. If the service experiences issues starting, open this file (sudo nano /etc/default/suricata) and confirm that theIFACE=...line matches your interface (IFACE=enp0s8).
Save the changes (in nano: Ctrl + O and then Enter) and close the editor (Ctrl + X).
Updating Rules with Suricata-Update
Suricata relies on signatures (rules) to recognize attacks, malware, and network scans. To keep the system secure, we must download the updated rule set from the community (ET Open – Emerging Threats).
Execute the official update tool:
sudo suricata-update
Where are the rules saved?
The suricata-update utility compiles all active rules into a single high-performance file located at /var/lib/suricata/rules/suricata.rules (and not in /etc/suricata/rules/, a folder reserved for local rules created by you).
Validating the Configuration (suricata -T)
Before restarting the service, it’s an excellent practice to test the syntax of the configuration file and the loaded rules with the test mode (-T):
sudo suricata -T
If you notice warning messages (Warning) for protocols like RDP or DNP3, it simply means that these protocol parsers are commented out in the YAML file.
If you use RDP (Remote Desktop) in your environment and wish to inspect it:
- Open
/etc/suricata/suricata.yamlagain; - Locate
app-layer:and uncomment the protocol line (remove the#character beforerdp: yes); - Save and test again with
sudo suricata -T.
Uncommented configuration line.
Once the configuration is valid, restart the service to apply the new rules and parameters:
sudo systemctl restart suricataUnderstanding the Logs: fast.log vs eve.json
All Suricata reports and detections are saved in the /var/log/suricata/ directory:
cd /var/log/suricata/
ls
The three most important files are:
suricata.log: Stores operational logs of the engine itself (startup errors, statistics, and module status).fast.log: Plain text file readable by humans. Each line represents a summary alert containing timestamp, rule ID (SID), alert message, and source/destination IPs.eve.json: The modern industry standard. Generates all events (alerts, flows, DNS/HTTP requests) in structured JSON format, perfect for integration with SIEMs like Wazuh, Splunk, Graylog, or Elastic Stack (ELK).
sudo tail /var/log/suricata/suricata.log
The other file, “fast.log”, displays the alerts generated by Suricata. In this way, you can check the alerts by inspecting the “fast.log” file. For this, we can use the command below.
sudo tail /var/log/suricata/fast.log
Initially, the “fast.log” file may not contain any alerts. Therefore, in the next section we will present a test to generate alerts in Suricata.
Testing Suricata as IDS
To put the engine to the test, we will use the following test scenario:
- Machine 1 (IDS): Our Suricata server listening on the internal network interface (
192.168.11.24). - Machine 2 (Attacker/Client): Another Ubuntu virtual machine connected to the same internal network.
The second virtual machine will be connected to the VirtualBox internal network and will be linked to the “enp0s8” interface of the Suricata machine.
Below we have the topology used.
Step 1: Leave monitoring open in Suricata
On the Suricata machine, let’s open the real-time alerts file using the -f (follow) parameter:
sudo tail -f /var/log/suricata/fast.logStep 2: Trigger the scan on the client machine
Go to the client machine (with Nmap installed) and execute a test directed at the Suricata IP:
sudo nmap -sO 192.168.11.24Why do we use
-sO?The
-sOoption executes an IP Protocol Scan (scanning of network layer protocol numbers, such as GRE, ICMP, IGMP, and OSPF), and not a common TCP port check. This type of probe sends non-standard packets that generate immediate alerts in the Emerging Threats rules.
If you wish to understand how NMAP works you can view the following posts:
NMAP: TCP and UDP port mapping
NMAP : Identify a service version
Step 3: Check the generated alerts
When looking back at the terminal of the machine with Suricata, you will see the alerts appearing right away.
If you wish to check the alerts file “/var/log/suricata/fast.log”, you can use the command below.
sudo tail /var/log/suricata/fast.log
Notice the provided details:
- Date and time of the intrusion attempt;
- The signature identifier (
SID: 2100498); - The event classification (Detection of a Network Scan);
- Priority level and the involved source and destination IPs.
Conclusion and Next Steps
Congratulations! You now have a high-performance IDS running on Ubuntu Linux, inspecting traffic in real time with updated rules and generating network scan alerts.
In the next tutorial of our series, we will take a step further: we will transform Suricata from a passive monitor (IDS) into an Active IPS, teaching how to configure the inline mode with iptables/nftables to block threats automatically.
In the alert description we can have an alert ID and the priority level of the alert. In the future we will present more information related to Suricata in upcoming tutorials. If you liked it, comment on our YouTube channel on the following video.
This tutorial is part of the Suricata Course on Linux.
Article 1: Install Suricata Linux
Article 2: Suricata in Host IPS
Article 3: Suricata in Network IPS
See more:
Snort PfSense: Detect DoS attack
NMAP: TCP and UDP port mapping
