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

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.

Patch.

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?

Yes this is part of Proofpoint.

I have installed Suricata from OISF provided RPMs on CentOS 7. When services starts the following warnings occurs:

[/usr/lib/systemd/system/suricata.service:17] Unknown lvalue ‘MemoryDenyWriteExecute’ in section ‘Service’
[/usr/lib/systemd/system/suricata.service:18] Unknown lvalue ‘LockPersonality’ in section ‘Service’
[/usr/lib/systemd/system/suricata.service:19] Unknown lvalue ‘ProtectControlGroups’ in section ‘Service’
[/usr/lib/systemd/system/suricata.service:20] Unknown lvalue ‘ProtectKernelModules’ in section ‘Service’

In the suricata.service these four parameters are set to “true”. If the value “yes” is used the warnings don’t occur. Theoretically based on man systemd.unit the boolean arguments can be written in various formats (1, yes, true and on are equivalent). It looks like it is not. The suricata.service in CentOS/RHEL rpms can be corrected.

How can you create RPMs from the downloaded Suricata 6 files?

The files to build RPMs that the OISF provides for Suricata can be found here: GitHub - jasonish/suricata-rpms: Suricata RPMs for CentOS/RHEL and Fedora

I’ve just done some fixups and updated the README to help with doing your own local builds. For our official RPMs we use COPR, a build service provided by the Fedora project. The README has examples for building RPMs for CentOS 7 and AlmaLinux 8.