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.