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.
How to Install Suricata 8.0 as an Inline IPS on a Linux Dedicated Server
Table of Contents
- Requirements for Suricata 8 as an inline IPS
- Step 1: Check Your Network Interfaces
- Step 2: Install Suricata 8 on Ubuntu
- Step 3: Configure AF_PACKET for Inline Mode
- Step 4: Choose Bridge or Routed Design
- Step 5: Enable ET Open Rules
- Step 6: Start Suricata in Inline IPS Mode
- Step 7: Test and Validate Drop Actions
- Step 8: Configure EVE JSON Logging
- Step 9: Set Up Log Rotation
- Step 10: Send Events to Wazuh
- Conclusion

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:
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:
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:
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:
Verify the installation by checking the version:
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:
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:
Three details matter here for a correct Suricata 8 inline IPS Linux setup:
- The
cluster-idmust 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:
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:
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:
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:
This downloads and compiles the rules into /var/lib/suricata/rules/suricata.rules. You must confirm your suricata.yaml points to this file:
Once you confirm it, restart Suricata to load the new rules:
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:
Check that it's running and using AF_PACKET with:
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:
Add a rule that drops any HTTP request containing a harmless test string:
Then, add this file to your suricata.yaml under rule-files, then restart Suricata:
From a client machine on the other side of your bridge, send a request containing the test string:
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:
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:
Save the file, restart Suricata, and watch the live output to confirm events are being written:
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:
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:
Once you are done, save and close. Test the rule without actually waiting a day:
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:
Add this block inside <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:
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.