Guide: Getting Started on RHEL, CentOS and rebuild Linux Distributions

This is a getting started guide for Suricata on RedHat Enterprise Linux and CentOS, including rebuilds likes AlmaLinux and RockyLinux. It should also be applicable to Fedora.


Install from OISF Provided RPMs

The OISF provides Suricata RPMs for RHEL 7 and newer. The main benefit of the OISF RPMs is that an RPM repository is provided for each supported version of Suricata allowing you to track the latest 6.0 or 7.0 patch releases.

yum install epel-release yum-plugin-copr
yum copr enable @oisf/suricata-7.0
yum install suricata

Please see Guide: Suricata RPMs for CentOS and Fedora for more information on the OISF provided RPMs as well as installing other supported versions of Suricata.

Installation from EPEL

Suricata can also be installed from EPEL, however these packages are not maintained or tested by the OISF, and may not be the latest version due to policies outside our control.

sudo yum -y install epel-release
sudo yum -y install suricata

A note on permissions: The Suricata RPM will create a group, suricata which Suricata will run-as after startup. By adding user accounts to this group, users can view the logs as well as run suricata-update without using sudo or becoming root.

After installation, it is recommended to add your user to the suricata group. You will need to logout and log back in again to become a member of this group. If you choose to not add yourself to the suricata group you will have to prefix the suricata-update commands with sudo.

Update The Rules

Suricata does not ship with any rules. To get the Emerging Threats Open ruleset simply run:


Set the Interface

The network interface that Suricata listens on when installed with the RPM package is set in the file /etc/sysconfig/suricata. The default version of this file specifies the eth0 interface but it is very likely you’ll need to change this. For example, if your interface is named enp4s0f0, then you will need to modify the OPTIONS line in /etc/sysconfig/suricata to look like:

OPTIONS="-i enp4s0f0 --user suricata "

If you are setting up Suricata to use a different capture method set us NFQUEUE, or PF_RING, this is where you would set that option by replace -i. For example, to use NFQUEUE you would use -q 0 instead of -i eth0.

Starting and Stopping Suricata

The Suricata RPM is setup to be started and stopped with systemd.

To start Suricata run:

systemctl start suricata

To stop Suricata:

systemctl stop suricata

To have Suricata automatically started on boot:

systemctl enable suricata

Configuration File Location

The configuration file is located at /etc/suricata/suricata.yaml.

Updating Rules

The Suricata RPM is bundled with Suricata-Update, which can be used to update your rules. By default the Emerging Threats Open ruleset will be used until another rule source is configured. To update your rules, run:


Note: If the above command fails with a permission error please consider adding your user to the suricata group. This will allow you run suricata-update as a non-root user which is recommended. Alternatively you could run suricata-update with sudo (not recommended).

Then if Suricata is currently running and rule reload can be triggered with the following command:

sudo systemctl reload suricata

Log Directory

The log directory is located at /var/log/suricata, with the Eve log file being found at /var/log/suricata/eve.json. If your user belongs to the suricata group you should have read access to these files. Otherwise you may have to become root to view the log files.

IPS Mode with NFQUEUE - Single Host

If you would like to use IPS mode for protecting the host that Suricata is running on, a few direct rules must be added to firewalld. These rules can be added with the following commands:

firewall-cmd --permanent --direct --add-rule \
    ipv4 filter INPUT 0 -j NFQUEUE
firewall-cmd --permanent --direct --add-rule \
    ipv4 filter OUTPUT 0 -j NFQUEUE

Note: To operate in a fail-open manner, where packets will still be passed if Suricata is not running, add --queue-bypass to the end of the following commands.

Then reload firewalld with firewall-cmd --reload.

IPS Mode with NFQUEUE - NAT/Router Mode

To protect machines behind the Suricata host in the case where its acting like a router, a single direct rule must be added to firewalld. This rule can be added with the following command:

firewall-cmd --permanent --direct --add-rule \
    ipv4 filter FORWARD 0 -j NFQUEUE

Thank you for it.
Please add it to Suricata-IDS manual. Nowadays, many administrators using “Firewalld”.

Excuse me, “-q 0” is correct or “-q0” ?

Doesn’t matter. Both are valid and mean the same thing.

1 Like

In some tutorial, I can see “Disable Packet Offloading”, why you never did it?

ethtool -K enp0s8 gro off lro off

Is it mandatory?

No. If you run Suricata with -vv you should see something like this:

11/9/2020 -- 11:57:47 - <Perf> - 4 cores, so using 4 threads
11/9/2020 -- 11:57:47 - <Perf> - Using 4 AF_PACKET threads for interface enp4s0f0
11/9/2020 -- 11:57:47 - <Perf> - enp4s0f0: disabling gro offloading
11/9/2020 -- 11:57:47 - <Perf> - enp4s0f0: disabling tso offloading
11/9/2020 -- 11:57:47 - <Perf> - enp4s0f0: disabling gso offloading
11/9/2020 -- 11:57:47 - <Perf> - enp4s0f0: disabling sg offloading

Suricata attempts to disable these offloads for you on Linux.

1 Like

If, I did it manually then can make any problem?

No, thats fine to have done it manually.

I added these firewalld rules and my web server take down:

# firewall-cmd --permanent --direct --add-rule \
    ipv4 filter INPUT 0 -j NFQUEUE
# firewall-cmd --permanent --direct --add-rule \
    ipv4 filter OUTPUT 0 -j NFQUEUE
# firewall-cmd --reload

I can’t SSH to my web server. What is the problem?
I have port 22, 80 and 443 open, but, now everything is lost :frowning:

@Hack3rcon: When you add these rules, the kernel sends the packets to the queue waiting for Suricata to OK or reject them, so Suricata must be running.

You can add the --queue-bypass flags to fail open and allow things to continue to work when Suricata is not running, as I described here: Suricata-IDS conflicts with other security applications

May I suggest you get used to working with Suricata in a passive mode first? Make sure it alerts on what you want to block, then maybe move into an inline mode.

Thus, I must edit that file and add " --queue-bypass" flags? Please add this note to your tutorial.
I can’t understand the usage of IDS! It just detect the attacks and not prevent them.

IPS mode can be more intrusive, and cause stuff to be blocked when it shouldn’t. It also requires more work. For example, nothing will be blocked by default. You’ll have analyze your alerts and decide for yourself which rules you want to to turn into drop rules.

I added --queue-bypass to direct.xml file and problem solved by now.
Excuse me, why Suricata-IDS couldn’t detect which attempts must be block?
To be honest, I can’t understand why IDS mode is useful! a company need an operator that checking log and do it manually? If it must be manually then why IDS?
How about a tool like Snort? Is it like Suricata-IDS?

You’ll have to go through the same process with Snort as well. Decide for yourself which rules you want to turn into block rules. It might help to understand this as working with the basic building blocks of a larger security system. Suricata is just an engine that looks for patterns provided in rules - it can optionally drop those packets that match those patterns. However, Suricata itself does not come with these rules. You get rules from other vendors like Emerging Threats. You as the end user will need to decide which of those pattern matches you want to block to add “protection”.

As to why run IDS? Its probably the most common way of running Suricata. It alerts you to activity that may require further investigation, which is what most people are after I think. There is no easy button to just “protect my server”.

Thank you, but when a tool doesn’t blocking a threat automatically then it is not so useful :frowning:
Consider an Antivirus that just show an alert and never clean the infection!!!
If Suricata-IDS alerting about an attack when you are not at the desk then? Attacker hack your server and you will just see Suricata-IDS alert after your server hacked.

That’s because there are several different use cases and scenarios. Sometimes it’s not feasible to run IPS mode due to your network. Also keep in mind that rules are written mostly for IDS mode and thus if you can convert those to drop for IPS mode you will end up with a lot of legit traffic being blocked due to false positive.

There are several different approaches to security, sometimes you want IDS, sometimes IPS, sometimes just NSM and combine this with other security controls.

IDS mode is very useful, take a look into a lot of enterprise environments where it helps the SOC team.

If you want to learn, feel free to look into literature about those different approaches.

Then, How can I protect my server?

Seek out resources/forums specific to your Linux distribution. Maybe others have protections in mind when running in a similar position to your. Or your hosting provider may have some resources as well - Digital Ocean publishes all sorts of articles for tips and hints around this, most would be applicable to self-hosting or other hosting providers as well. If a VPS, see what protections your hosting provider may offer.

When it comes to Suricata set your expectations accordingly and the learning/work you may need to do implement an IPS in your environment. I don’t think any other open source IPS solutions are going be that much different from us.

Seek out commercial options that may just work out of the box.


Can you share some of your Suricata-IDS rules?

I just using Emerging Threats Open - as is. This is already enabled by default if you use Suricata-Update. I don’t run inline.

The Emerging Threats Open is a separate company?