How to Install Suricata 8.0 as an Inline IPS on a Linux Dedicated Server

Updated on Oct 1, 2026
Mathew M
8 MINS READ
Table of Contents
Set Up Suricata 8 as a Real Inline IPS on Linux

Suricata is a free tool that inspects network traffic for attacks and malware. Most setups only use it to send alerts, but it can also sit inline and block bad traffic in real time. This guide shows a full Suricata 8 inline IPS Linux setup on a dedicated server.

Requirements for Suricata 8 as an inline IPS

For a correct Suricata 8 inline IPS Linux setup, you need:

  • A Linux dedicated server running Ubuntu 22.04 or newer.
  • Root or sudo access.
  • Two network interfaces if you want a true bridge-style inline setup.
  • At least 2 CPU cores and 4 GB RAM for light traffic.

If your dedicated server has only one NIC, you can still run Suricata inline using a routed design with nfqueue, as covered in this guide.

For real production traffic, you need a server with extra CPU power and a fast network card. This matters because Suricata checks every single packet as it passes through. This is where using a dedicated server built for security workloads makes a real difference, because Suricata competes with your other services for CPU and network I/O.

Step 1: Check Your Network Interfaces

First, you must list the interfaces and write down the names of the two interfaces you plan to use, for example, eth0 and eth1:

Bash
ip a

Note: If you only have one interface, you can create a routed setup instead, which is explained in Step 4.

Then, check that both interfaces are up with the commands below:

Bash
sudo ip link set eth0 upsudo ip link set eth1 up

Also, you should confirm both interfaces use the same MTU. Suricata's AF_PACKET IPS mode copies packets directly between interfaces, and a mismatched MTU causes silent packet drops. To verify this, run the commands below: 

Bash
ip link show eth0 | grep mtuip link show eth1 | grep mtu

Step 2: Install Suricata 8 on Ubuntu

At this point, you can add the official Suricata stable PPA repository and install it with the commands below:

Bash
sudo apt install software-properties-common -ysudo add-apt-repository ppa:oisf/suricata-stablesudo apt updatesudo apt install suricata -y

Verify the installation by checking the version:

Bash
suricata -V

You should see output like This is Suricata version 8.0.7 RELEASE.

Note: The Ubuntu package already includes IPS support (AF_PACKET and NFQUEUE), full JSON output, and the suricata-update tool, so you don't need to compile anything from source.

Step 3: Configure AF_PACKET for Inline Mode

To configure AF_PACKET for inline mode, open the main config file with your desired text editor:

Bash
sudo nano /etc/suricata/suricata.yaml

Find the af-packet: section and replace it with a two-interface inline block. This tells Suricata to send packets between eth0 and eth1, checking each packet as it passes through:

YAML
af-packet:  - interface: eth0    threads: auto    defrag: no    cluster-type: cluster_flow    cluster-id: 98    copy-mode: ips    copy-iface: eth1    buffer-size: 64535  - interface: eth1    threads: auto    defrag: no    cluster-type: cluster_flow    cluster-id: 97    copy-mode: ips    copy-iface: eth0    buffer-size: 64535

Three details matter here for a correct Suricata 8 inline IPS Linux setup:

  • The cluster-id must be different on each interface.
  • MTU must match on both interfaces.
  • NIC offloading features such as GRO, LRO, or TSO must be turned off, as they create oversized packets that are silently dropped.

To turn off offloading, you can use the commands below:

Bash
sudo ethtool -K eth0 gro off lro off tso off gso offsudo ethtool -K eth1 gro off lro off tso off gso off

Once you are done, scroll down to the stream: section in the file and set inline mode to auto so Suricata enforces drop rules instead of just logging them:

YAML
stream:  inline: auto

Step 4: Choose Bridge or Routed Design

With the AF_PACKET IPS configuration above, no iptables or nftables rules are needed. Suricata handles the packet copy itself as long as both interfaces are up. This is the simplest and most reliable design for a dedicated server acting as a bridge between two network segments.

If your server has only one physical interface and you need a routed design instead, you must use NFQUEUE mode with iptables to hand packets to Suricata:

Bash
sudo iptables -I FORWARD -j NFQUEUE --queue-num 0sudo sysctl -w net.ipv4.ip_forward=1

Then, set the nfq: section in suricata.yaml and start Suricata with --af-packet replaced by -q 0.

Note: For most dedicated servers, the two-NIC AF_PACKET bridge is simpler to manage and runs with less overhead.

Step 5: Enable ET Open Rules

Suricata ships with suricata-update, which pulls the free Emerging Threats Open ruleset. You can enable it with the command below:

Bash
sudo suricata-update enable-source et/opensudo suricata-update

This downloads and compiles the rules into /var/lib/suricata/rules/suricata.rules. You must confirm your suricata.yaml points to this file:

YAML
default-rule-path: /var/lib/suricata/rulesrule-files:  - suricata.rules

Once you confirm it, restart Suricata to load the new rules:

Bash
sudo systemctl restart suricata

ET Open is the biggest free ruleset available, and it's the standard starting point for any Suricata 8 inline IPS Linux setup before you add custom rules for your own environment.

Step 6: Start Suricata in Inline IPS Mode

Now you can enable Suricata to start automatically and launch it with AF_PACKET:

Bash
sudo systemctl enable suricatasudo systemctl start suricata

Check that it's running and using AF_PACKET with:

Bash
sudo systemctl status suricatasudo journalctl -u suricata -n 50 --no-pager

You should see log lines confirming both interfaces were opened and that stream inline mode is active. If Suricata fails to start, check /var/log/suricata/suricata.log for the exact error, which is usually an interface name typo or an MTU mismatch.

Step 7: Test and Validate Drop Actions

This is the step that separates a real inline IPS from a passive monitor. You must create a safe test rule that won't affect real traffic. To do this, open a new rules file with:

Bash
sudo nano /etc/suricata/rules/test.rules

Add a rule that drops any HTTP request containing a harmless test string:

Bash
drop http any any -> any any (msg:"TEST inline IPS block"; content:"suricata-ips-test"; nocase; sid:9000001; rev:1;)

Then, add this file to your suricata.yaml under rule-files, then restart Suricata:

YAML
rule-files:  - suricata.rules  - test.rules
Bash
sudo systemctl restart suricata

From a client machine on the other side of your bridge, send a request containing the test string:

Bash
curl "http://<target-ip>/?q=suricata-ips-test"

The request should time out or fail to connect, proving traffic was actually dropped, not just logged. Also, confirm the drop event appears in Suricata's alert log:

Bash
sudo tail -f /var/log/suricata/eve.json | grep drop

Seeing a "action":"blocked" entry in the JSON output is the clearest proof your Suricata 8 inline IPS Linux setup is enforcing rules, not just watching traffic pass by.

Step 8: Configure EVE JSON Logging

EVE JSON is Suricata's structured log format, and it is enabled by default. You can tune it to specify which event types you keep. To do this, edit the eve-log section in suricata.yaml:

YAML
outputs:  - eve-log:      enabled: yes      filetype: regular      filename: eve.json      types:        - alert        - http        - dns        - tls        - flow        - drop

Save the file, restart Suricata, and watch the live output to confirm events are being written:

Bash
sudo systemctl restart suricatasudo tail -f /var/log/suricata/eve.json

In this Suricata 8 inline IPS Linux setup, every alert, blocked connection, and flow record goes into one JSON file. This makes it easy to send to a SIEM later.

Step 9: Set Up Log Rotation

The eve.json file grows fast on a busy server, so you can set up logrotate to keep it under control. Create a new logrotate config:

Bash
sudo nano /etc/logrotate.d/suricata

Add the following content to the file. It rotates logs daily, keeps 14 days of history, and sends Suricata a signal so it reopens a fresh log file instead of writing to a deleted one:

Bash
/var/log/suricata/*.json /var/log/suricata/*.log {    daily    rotate 14    missingok    notifempty    compress    delaycompress    create    sharedscripts    postrotate        /bin/kill -HUP `cat /var/run/suricata.pid 2>/dev/null` 2>/dev/null || true    endscript}

Once you are done, save and close. Test the rule without actually waiting a day:

Bash
sudo logrotate --force /etc/logrotate.d/suricata

Step 10: Send Events to Wazuh

If you already run Wazuh as your SIEM, you can point the Wazuh agent at Suricata's eve.json file instead of building a separate log pipeline. On the server running the Wazuh agent, edit the agent config:

Bash
sudo nano /var/ossec/etc/ossec.conf

Add this block inside <ossec_config>:

HTML/XML
<ossec_config>  <localfile>    <log_format>json</log_format>    <location>/var/log/suricata/eve.json</location>  </localfile></ossec_config>

Restart the agent, and Wazuh reads the JSON fields on its own and shows an alert on its dashboard whenever Suricata logs a drop or an alert:

Bash
sudo systemctl restart wazuh-agent

Tips: If you're setting Wazuh up from scratch on a VPS, this Wazuh SIEM configuration tutorial covers the agent installation and manager setup in detail before you connect Suricata to it.

Conclusion

Now you have a working Suricata 8 inline IPS Linux setup that blocks traffic, not just watches it. You installed Suricata 8, set up AF_PACKET inline mode on two interfaces, loaded ET Open rules, tested that drops actually work, and connected the logs to Wazuh.

We hope you enjoy this guide.