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
-
Canonical Releases Ubuntu 24.04
After a brief pause because of the XZ vulnerability, Ubuntu 24.04 is now available for install.
-
Linux Servers Targeted by Akira Ransomware
A group of bad actors who have already extorted $42 million have their sights set on the Linux platform.
-
TUXEDO Computers Unveils Linux Laptop Featuring AMD Ryzen CPU
This latest release is the first laptop to include the new CPU from Ryzen and Linux preinstalled.
-
XZ Gets the All-Clear
The back door xz vulnerability has been officially reverted for Fedora 40 and versions 38 and 39 were never affected.
-
Canonical Collaborates with Qualcomm on New Venture
This new joint effort is geared toward bringing Ubuntu and Ubuntu Core to Qualcomm-powered devices.
-
Kodi 21.0 Open-Source Entertainment Hub Released
After a year of development, the award-winning Kodi cross-platform, media center software is now available with many new additions and improvements.
-
Linux Usage Increases in Two Key Areas
If market share is your thing, you'll be happy to know that Linux is on the rise in two areas that, if they keep climbing, could have serious meaning for Linux's future.
-
Vulnerability Discovered in xz Libraries
An urgent alert for Fedora 40 has been posted and users should pay attention.
-
Canonical Bumps LTS Support to 12 years
If you're worried that your Ubuntu LTS release won't be supported long enough to last, Canonical has a surprise for you in the form of 12 years of security coverage.
-
Fedora 40 Beta Released Soon
With the official release of Fedora 40 coming in April, it's almost time to download the beta and see what's new.