How to Install and Configure Suricata on Ubuntu

Install Suricata from the Open Information Security Foundation’s suricata-stable PPA, then configure the network interface, HOME_NET, and detection rules before starting the service. Installation by itself does not inspect useful traffic: Suricata must be attached to the correct interface and have signatures loaded.

Need a server to try this on? Antihost offers Linux VPS plans with NVMe storage, full root access and a 14-day free trial.

What you need before installing

Suricata is a network intrusion detection and prevention engine. In the Ubuntu setup described here, it captures packets from a live interface, evaluates them against signatures (also called rules), writes operational logs, and emits structured events in EVE JSON.

As an Amazon Associate I earn from qualifying purchases.

• An Ubuntu host with administrator access through sudo.
• The name of the interface whose traffic the sensor must inspect.
• The interface address and local network ranges, so HOME_NET can be set correctly.
• A decision about package channel: the stable PPA is the normal installation route; beta and daily packages are intended for testing and can be unstable.
• Permission to add a third-party apt repository. Canonical’s repository guidance says: “Only add software repositories from sources that you trust.”

The sensor must be positioned where the relevant packets are visible. A Suricata process on a host that cannot receive the traffic you care about will run normally but generate no useful detections. Before changing software, identify whether the host is intended to inspect its own interface traffic, traffic delivered to a monitoring interface, or a recorded PCAP. The installation commands are the same, but the capture path and validation method differ.

Choose an Ubuntu installation channel

Channel	Best use	Stability and maintenance
suricata-stable PPA	Normal production installation on Ubuntu	Supported OISF route; maintained with apt updates
suricata-beta	Testing upcoming changes	May be unstable; do not treat it as the default production channel
suricata-daily-allarch	Development or daily-package testing	May be unstable and requires more cautious change management
Source build	Cases requiring custom build choices or development work	Higher maintenance effort; the Ubuntu installation procedure here does not provide source-build commands
suricata-dbg	Debugging a package-level problem	Debug package rather than the ordinary runtime package

For a normal sensor, use the stable PPA. Before adding it, confirm that the PPA supports the Ubuntu release running on the host and that your organization permits third-party repositories. The beta and daily channels are useful when testing package changes, but their instability increases the amount of validation and rollback work required. A debug package addresses troubleshooting needs; it is not a replacement for the normal suricata runtime package.

Canonical’s Ubuntu guidance is explicit that only trusted software repositories should be added. A PPA is maintained outside Ubuntu’s standard archive and is not checked by Ubuntu members for security or reliability. Record who approved the repository and which channel was selected so later upgrades do not silently change the package source.

Install Suricata from the stable PPA

Run the following commands in order. The first installs the Ubuntu helper that provides add-apt-repository; the second adds the OISF stable channel; the third refreshes package metadata; and the fourth installs Suricata.

sudo apt-get install software-properties-common
sudo add-apt-repository ppa:oisf/suricata-stable
sudo apt-get update
sudo apt-get install suricata

During repository setup, review the apt prompt rather than accepting an unknown source automatically. The PPA is external to Ubuntu’s own archive, so repository trust is an administrative decision, not merely an installation detail. If apt reports that the release is unsupported, stop and verify the Ubuntu version and the PPA’s available distributions instead of switching immediately to a beta or daily package.

The package installation gives you the Suricata executable and its Ubuntu integration, but it does not finish sensor configuration. You still need to identify the interface, set HOME_NET, select the AF_PACKET device, obtain rules, test the configuration, and verify that logs show traffic.

Verify the package and service

Inspect the compiled capabilities

After installation, display the build information:

sudo suricata --build-info

This confirms that the executable is present and reports the capabilities compiled into that package. Keep the output with your deployment notes when comparing hosts, especially if one sensor behaves differently after an upgrade.

Check the systemd unit

sudo systemctl status suricata

The status output shows whether the unit is loaded, active, or failed. A service that is installed but not running is not yet inspecting traffic; configuration and rule preparation should be completed before restarting it for normal operation. If the unit is already active from package setup, do not assume it is monitoring the intended interface. Confirm the YAML and rule file first, then restart deliberately.

Find the interface Suricata should monitor

List the host’s interfaces and addresses:

ip addr

Record the actual device name, such as enp1s0, and the address or local network attached to it. Do not copy an interface name from an example blindly: predictable-interface names differ between Ubuntu installations, virtual machines, cloud instances, and physical hosts. The address and prefix shown by ip addr also provide the information needed to define the protected network in HOME_NET.

Make sure the sensor’s placement exposes the traffic you want to analyze. If the host sees only its own ordinary traffic, it cannot detect packets that never reach that host or its capture path. A correct interface name does not compensate for a host that is physically or virtually placed where the relevant traffic is invisible. When testing, generate traffic that actually traverses the selected device and use the statistics log to confirm that packets are being processed.

Configure suricata.yaml

Set HOME_NET

Open the main configuration file:

sudo nano /etc/suricata/suricata.yaml

Set HOME_NET so it includes the address on the monitored interface and the local networks that should be treated as protected. Use the CIDR values shown by ip addr and the network design for this sensor. A wrong value can classify internal traffic as external, or prevent rules that depend on protected-network context from matching as intended.

Do not treat HOME_NET as a description of every network reachable from the machine. It should represent the protected address space relevant to the sensor’s role. If the host has several interfaces, decide which local ranges belong in the protected set and make the choice explicit. After editing the value, run configuration-test mode so a malformed address or YAML entry is caught before the service is restarted.

Set the AF_PACKET capture interface

In the af-packet section, make the interface value exactly match the device name discovered earlier. The basic IDS capture settings are:

af-packet:
  - interface: enp1s0
    cluster-id: 99
    cluster-type: cluster_flow
    defrag: yes
    tpacket-v3: yes

Replace enp1s0 with your real interface. Keep the YAML indentation intact; a spelling or indentation error can prevent Suricata from loading the configuration. The cluster-id, cluster-type, defragmentation setting, and TPACKET v3 option shown above are the quickstart’s recommended basic IDS capture settings.

The key must be written as af-packet; do not insert a space into the name. Check the completed block against the interface output and preserve the surrounding YAML structure supplied by the package. If you later change the device name, update the configuration and repeat the validation command before restarting.

Validate the configuration before launching

Use Suricata’s configuration-test mode before restarting the service:

sudo suricata -T -c /etc/suricata/suricata.yaml

The -T option tests configuration without starting a normal capture run. Fix any reported YAML, interface, path, or rule errors first. This check is especially useful after changing HOME_NET or the af-packet block. A successful test means Suricata can parse and validate the configuration; it does not by itself prove that the host will receive the traffic you need.

The Ubuntu manpage also documents these operating modes:

Option	Purpose
-T	Test the configuration
-i <interface>	Capture live traffic from a named interface
--af-packet	Use Linux AF_PACKET capture
-r <path>	Replay an offline PCAP file

These options let you separate configuration validation, live capture, and recorded-traffic troubleshooting. A PCAP replay is useful when you need repeatable input without relying on a live network. Live capture through -i or the configured AF_PACKET block is appropriate when the sensor must process packets as they arrive. The mode should match the evidence you are trying to collect; replaying a file cannot prove that a production interface is receiving mirrored traffic.

Install and update detection rules

Suricata needs signatures to trigger alerts. The Open Information Security Foundation’s Suricata 8.0.0 quickstart notes that signatures are also called rules, hence the term rule files. Install or refresh the default rules with:

sudo suricata-update

In its default mode, suricata-update fetches the ET Open ruleset and writes the generated rules under /var/lib/suricata/rules, normally as suricata.rules. Running the command is therefore a required setup step, not an optional add-on after installation. The package can be present and the service can be active while no detection occurs if the rule file has not been obtained or loaded.

After the update, check that the expected directory and generated file exist, and then run the configuration test again if you changed any paths. Keep rule updates separate from package upgrades in your change notes: suricata-update refreshes signatures, while apt upgrades the Suricata package itself. If Suricata is already running, follow your service procedure for loading the refreshed file; restarting is the straightforward validation step used in this setup.

If Suricata starts but produces no alerts, first confirm that this rules file exists and that the configuration points to the rules directory being populated. A successful package install does not prove that rules were downloaded or loaded.

Start Suricata and inspect its logs

Restart after configuration and rules are ready

sudo systemctl restart suricata

Check the service again with sudo systemctl status suricata. If it enters a failed state, run the configuration test again and inspect the service’s error output before attempting repeated restarts. A clean restart confirms that the current YAML and rule paths can be used by the running service, but traffic counters and alerts still need to be observed.

Read the main and statistics logs

sudo tail /var/log/suricata/suricata.log
sudo tail -f /var/log/suricata/stats.log

The main log records startup and operational messages. The statistics log exposes packet-processing and decoded-traffic counters. The quickstart states that stats.log is updated every 8 seconds by default, so counters should change at that cadence when the process is active. Watch the counters while generating known traffic; a running process with unchanging packet counts points to a capture or placement issue rather than a missing signature.

Watch structured EVE alerts

EVE JSON is useful for shell filtering and later ingestion. To display only alert events as they arrive:

sudo tail -f /var/log/suricata/eve.json | jq 'select(.event_type=="alert")'

The quickstart uses jq for this filter. If the command reports that jq is missing, install it with apt before repeating the pipeline:

sudo apt-get install jq

Use the plain eve.json stream when you need fields such as signature identifiers, source and destination addresses, or event timestamps. Use fast.log for a compact text view during a quick detection check. Keeping suricata.log, stats.log, and the alert stream visible in separate terminals makes it easier to correlate startup, packet receipt, and rule matches.

Run the documented controlled detection test

The quickstart provides ET Open signature ID 2100498 for a controlled IDS test. Open a second terminal and watch the fast alert log:

sudo tail -f /var/log/suricata/fast.log

From the sensor host, request the test page:

curl http://testmynids.org/uid/index.html

The documented rule looks for the string uid=0(root). When the rule is loaded, the expected alert identifies SID 2100498. This procedure is a documentation test, not an independent performance measurement; treat it as confirmation that the configured capture path, rule loading, and alert logging work together.

Run the request only in an environment where this controlled test is permitted. The useful result is not merely that curl returns content. The packet must traverse the interface Suricata monitors, the ET Open rule must be loaded, and an alert must be written to fast.log or EVE JSON with the expected signature identifier.

If no alert appears, check the failure points in this order:

1. Confirm Suricata is active with systemctl status.
2. Confirm the configured af-packet interface matches the device shown by ip addr.
3. Run sudo suricata-update and verify the rules directory contains the generated rule file.
4. Watch stats.log to determine whether packets are being received and decoded.
5. Check suricata.log and eve.json for startup, rule-loading, or capture errors.
6. Ensure the test request traverses the interface Suricata is monitoring rather than another route or a local path outside that capture.

Common installation and configuration problems

The PPA cannot be added

Verify that software-properties-common is installed, that the host can reach the package service, and that your Ubuntu release is supported by the selected PPA. Do not replace the stable channel with a beta or daily channel merely to bypass an unresolved repository problem. Review the apt source carefully and confirm that a trusted administrator approved the external repository.

The service fails immediately

Run sudo suricata -T -c /etc/suricata/suricata.yaml and read the first reported error. Typical causes in this setup are invalid YAML indentation, an interface name that does not exist, an unavailable rules path, or a malformed HOME_NET value. Correct one issue at a time, rerun the test, and restart only after the test completes cleanly.

Statistics remain at zero

Zero counters generally indicate that the process is not seeing the traffic you expect, even if the service is technically running. Recheck the interface, host placement, and capture mode. The af-packet block must name the real device, and the traffic must actually reach that device. If a PCAP is available, use the documented -r <path> mode to distinguish a rule problem from a live-capture visibility problem.

Rules update but no alerts are produced

Confirm that suricata-update completed, that /var/lib/suricata/rules/suricata.rules exists, and that Suricata loaded it without errors. Then use the controlled test and inspect both fast.log and the EVE JSON alert stream. An empty alert stream with active packet counters usually calls for checking rule loading, the test traffic, and the protected-network context rather than reinstalling the package.

Logs are difficult to interpret

Start with suricata.log for startup and configuration messages, use stats.log for packet and decoder counters, and use EVE JSON when you need machine-readable alert fields. Keeping each view in a separate terminal makes it easier to correlate a test request with the resulting event. The eight-second statistics interval provides a predictable point at which to recheck counters after generating traffic.

The expected interface is missing

Run ip addr again and compare the current device names with the YAML. Interface names can differ across physical hosts, virtual machines, and cloud instances. Update the af-packet entry to the actual device, then validate with -T. Do not leave the example name in place simply because the service starts; an unused or nonexistent device cannot provide useful packet data.

Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Support on Ko-Fi

Keep a stable installation current

For upgrades from the stable package channel, refresh apt metadata and upgrade only the Suricata package:

sudo apt-get update
sudo apt-get upgrade suricata

After an upgrade, rerun the configuration test, check the service state, and review the logs before relying on the sensor. Package changes can affect defaults or compiled capabilities even when your YAML file is unchanged. Compare suricata --build-info before and after an upgrade when you need to confirm the executable’s capabilities.

Rules are maintained separately from the package. Run sudo suricata-update whenever you need the current default ET Open rules, then restart Suricata if your deployment requires a restart to load the refreshed rule file. A repeatable maintenance sequence is: update apt metadata, upgrade the package, run suricata-update, test the configuration, restart the service, and watch the logs and counters.

Remove Suricata

To remove the installed package:

sudo apt-get remove suricata

This command removes the package but is not a substitute for reviewing the repository configuration, saved logs, rules, and local changes. If the host will no longer be used as a sensor, also remove or disable the PPA according to your organization’s package-management policy. Preserve logs or rule files only when they are needed for operational records; otherwise, handle them according to the host’s normal retention policy.

Production checklist

• The stable PPA was approved and added deliberately.
• suricata --build-info runs successfully.
• HOME_NET includes the protected address space relevant to this sensor.
• The af-packet interface exactly matches the intended device.
• sudo suricata -T -c /etc/suricata/suricata.yaml completes without configuration errors.
• sudo suricata-update has populated /var/lib/suricata/rules.
• The systemd service is active after restart.
• stats.log shows packet-processing activity.
• EVE JSON and/or fast.log can be monitored for alerts.
• The controlled SID 2100498 test has been run where appropriate, and its result has been interpreted as a capture-and-rule validation rather than a benchmark.

Use the checklist in layers. First establish that the executable and systemd unit work. Next verify that YAML, HOME_NET, and AF_PACKET are valid. Then confirm the rule file exists and is loaded. Finally generate traffic and correlate packet counters with an alert event. This ordering prevents a missing interface feed from being mistaken for a rule failure.

Frequently asked questions

Which PPA should I use for a normal Ubuntu deployment?

Use the OISF suricata-stable PPA and install the regular suricata package. The beta and daily channels are intended for testing and may be unstable. Confirm that the selected PPA supports your Ubuntu release and that your organization trusts and permits the external repository.

Is installing the package enough to detect attacks?

No. Installation provides the executable, but Suricata also needs a correct HOME_NET, an AF_PACKET interface that can see the relevant traffic, and loaded signatures. Run suricata-update, validate the YAML, restart the service, and inspect counters and alert logs.

How do I know which interface to put in the YAML file?

Run ip addr and use the actual device name attached to the traffic you want to inspect. Names such as enp1s0 are examples only. The value in the af-packet block must match the current device exactly.

What does HOME_NET control?

It identifies the protected address space relevant to the sensor. Set it using the interface address and local network ranges shown by ip addr and your network design. An incorrect value can change how rules classify internal and external traffic.

Where does suricata-update put the rules?

The default ET Open update writes generated rules under /var/lib/suricata/rules, normally in suricata.rules. Confirm that the file exists and that Suricata loads it without errors.

How can I test the configuration without starting live capture?

Use sudo suricata -T -c /etc/suricata/suricata.yaml. The -T mode checks the configuration before a normal launch. For recorded traffic, the Ubuntu manpage documents -r <path> for offline PCAP replay.

What should I monitor after starting the service?

Use systemctl status suricata for service state, suricata.log for startup and operational messages, stats.log for packet and decoder counters, and EVE JSON or fast.log for alerts. The statistics log updates every 8 seconds by default.

What does SID 2100498 mean in the test?

It is the ET Open signature used by the documented controlled test. Requesting http://testmynids.org/uid/index.html should expose the string uid=0(root); when the rule, capture path, and logging are working, the alert identifies SID 2100498. This confirms operation; it is not a performance benchmark.

What a correct installation gives you

A working Ubuntu deployment has four verified layers: an installed executable, a valid capture configuration, a populated rule set, and observable service output. The stable PPA supplies the package, HOME_NET and af-packet define what Suricata can interpret, suricata-update supplies signatures, and systemd plus the Suricata logs show whether the sensor is actually processing traffic. Validate each layer independently before troubleshooting the next.

Frequently Asked Questions

Which PPA should I use for a normal Ubuntu deployment?

Use the OISF suricata-stable PPA with the regular suricata package. Beta and daily channels are for testing and may be unstable.

Why are there no alerts after installation?

Installation alone is insufficient. Verify HOME_NET, the AF_PACKET interface, the ET Open rules installed by suricata-update, packet counters, and the alert logs.

How do I validate Suricata before starting it?

Run sudo suricata -T -c /etc/suricata/suricata.yaml. Use -r <path> when you need to replay an offline PCAP.

Where are the updated rules stored?

The default ET Open update writes generated rules under /var/lib/suricata/rules, normally as suricata.rules.

How can I confirm live detection?

Watch fast.log or filtered EVE JSON, then run the documented test request and look for ET Open SID 2100498.

The Bottom Line

Install the stable OISF PPA package, identify the real capture interface, set HOME_NET, load ET Open rules with suricata-update, validate with -T, and verify packet counters and alerts through the service logs. Suricata is ready only when all four layers—package, capture configuration, rules, and observable output—have been checked.

Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.