Protecting your network with the Suricata intrusion detection system
Securing Suricata
To secure Suricata, the first thing you'll want to change is the user and group that Suricata runs as (which, by default, is root). Edit suricata.yaml
with the following:
user: suricata group: suricata
Of course, you'll also need to create a user and group, make sure you set the login shell as /sbin/nologin
and specify that you won't need a home directory. You should also ensure the account is not allowed to login. Unfortunately locking Suricata down with SELinux is non-trivial, so by default, it'll run unconfined; however, if you're feeling lucky, I suggest running the system in permissive mode and using audit2allow
to examine the logfiles and create a policy to confine it. (Suricata requires relatively minimal filesystem access – just lots of network access.)
I would also strongly advise firewalling the Suricata server itself. In general, the Suricata server should have a minimum of incoming connections and outgoing connections. However, if you are using Suricata in IPS mode (where it acts as a router and traffic flows through it), a skilled attacker should be able simply to spoof outgoing connections, as from an IP address for which Suricata is routing, and Suricata by design would be able to accept incoming connections for IP addresses other than the server itself.
Suricata Rules
As mentioned before, Suricata is Snort compatible for your basic IDS/IPS rules. If you are monitoring a general network (e.g., Windows workstations, mobile devices, server), I would strongly advise using the Snort rules. As with any signature database of attacks; it is best to keep your ruleset up to date.
Two options for automatically updating your ruleset are Oinkmaster and PulledPork [3]. Oinkmaster's last release was in 2006; PulledPork is more up to date with a release in 2013; however, it does have some issues with Suricata. PulledPork is a Perl script; basically, you'll need to install some requirements, like LWP-UserAgent
, SSLeay
, Archive::TAR
, SYS::Syslog
, and so on. PulledPork can simply download the rules tarball and replace your existing rules, then you can restart Suricata. You can also drop rules (e.g., if you have no Windows machines, you can probably drop all the Windows stuff) and modify rules, both simply and in arbitrary ways (e.g., you could change path names used in HTTP-related rules). Finally you'll want to run PulledPork on a regular basis using crontab at some time when you're around, so you can deal with problems in case it breaks (which should never happen, but who knows).
IDS vs. IPS
If Suricata can serve as an IPS (to block attacks), why would you ever use it in IDS mode (just detect and log attacks)? Several issues come into play; the first is contractual and legal. Many networks have contracts with customers that allow them to monitor traffic for administrative purposes (e.g., so you can do billing by usage) but does not allow modification or blocking of the traffic. IPS systems can inadvertently block legitimate traffic, depending on the rules and configuration in use, so tuning rules and monitoring blocked traffic to ensure no legitimate traffic is blocked can require some effort. Finally, IPS systems can introduce latency (depending on how the data is examined and blocked) and introduce points of failure. I suggest either engineering your system so you can disable Suricata and allow traffic to flow normally, or having at least two Suricata systems with routers configured to failover if one fails. If you plan to use Suricata as an IPS, I suggest using it in IDS mode initially to get an idea of how much traffic will be blocked and to ensure any blocked traffic is not critical.
Using Suricata as an IDS can also provide a great deal of insight into your network. For example, which filesharing protocols are being used? NFS? CIFS? Rsync? FTP? Using Suricata with detection rules or the packet profiling will provide information you cannot easily collect using other tools.
Buy this article as PDF
(incl. VAT)
Buy Linux Magazine
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters
Support Our Work
Linux Magazine content is made possible with support from readers like you. Please consider contributing when you've found an article to be beneficial.
News
-
Fedora 39 Beta is Now Available for Testing
For fans and users of Fedora Linux, the first beta of release 39 is now available, which is a minor upgrade but does include GNOME 45.
-
Fedora Linux 40 to Drop X11 for KDE Plasma
When Fedora 40 arrives in 2024, there will be a few big changes coming, especially for the KDE Plasma option.
-
Real-Time Ubuntu Available in AWS Marketplace
Anyone looking for a Linux distribution for real-time processing could do a whole lot worse than Real-Time Ubuntu.
-
KSMBD Finally Reaches a Stable State
For those who've been looking forward to the first release of KSMBD, after two years it's no longer considered experimental.
-
Nitrux 3.0.0 Has Been Released
The latest version of Nitrux brings plenty of innovation and fresh apps to the table.
-
Linux From Scratch 12.0 Now Available
If you're looking to roll your own Linux distribution, the latest version of Linux From Scratch is now available with plenty of updates.
-
Linux Kernel 6.5 Has Been Released
The newest Linux kernel, version 6.5, now includes initial support for two very exciting features.
-
UbuntuDDE 23.04 Now Available
A new version of the UbuntuDDE remix has finally arrived with all the updates from the Deepin desktop and everything that comes with the Ubuntu 23.04 base.
-
Star Labs Reveals a New Surface-Like Linux Tablet
If you've ever wanted a tablet that rivals the MS Surface, you're in luck as Star Labs has created such a device.
-
SUSE Going Private (Again)
The company behind SUSE Linux Enterprise, Rancher, and NeuVector recently announced that Marcel LUX III SARL (Marcel), its majority shareholder, intends to delist it from the Frankfurt Stock Exchange by way of a merger.