Protecting your network with the Suricata intrusion detection system
Suricata IPS
Setting up Suricata as an IPS [4] is actually relatively simple – honestly, 80 percent of the work is getting it installed and the rules configured. Depending on your network and how many systems you are protecting, I would recommend you place Suricata behind your firewall so that it has less traffic to filter and deal with. Ideally, you should also firewall your internal traffic before it hits Suricata.
You can also use Suricata with Linux iptables NFQUEUE (NetFilter queue). In a nutshell, NFQUEUE allows you to pass packets to a userspace program for processing and a decision on whether the packet is DROPed, ACCEPTed, REJECTed, and so on. You can thus selectively apply the IPS to traffic and allow other traffic to bypass Suricata easily. For example, to examine HTTP traffic requested by client systems on your network:
iptables -I INPUT -i [EXT_IF] -p tcp --sport 80 -j NFQUEUE
If you want to examine everything, simply send all forwarded packets to NFQUEUE:
iptables -I FORWARD -j NFQUEUE
You might also need to modify the nfq
section of suricata.yaml
. The main thing to consider is the default action (accept or drop) and whether or not to fail open or fail closed. The question to ask yourself is which is more important; blocking data (and running the risk of a service outage) or allowing data (and running the risk of a security incident).
Suricata Performance
Now that you have Suricata running, you will probably want to ensure that performance doesn't become an issue, especially if you are deploying Suricata on gigabit, 10Gb, and faster networks. So the three most obvious candidates for Suricata performance are CPU, RAM, and good network cards. Luckily, because Suricata is threaded, the more cores you add, the faster Suricata will run – ditto for RAM. Network cards are a bit more tricky; I suggest using well-known brands (Intel- or Broadcom-based NICs) because hardware capabilities can vary a lot, and driver quality is also a factor. Another feature to look for is "interrupt coalescing," which allows you to reduce the number of interrupts generated by the network card – a critical factor on high-speed networks that carry small packets.
Finally, if you are logging the data, use an SSD. No matter how many disks or how you tune and RAID them, even a cheap SSD can blow a disk array out of the water, especially if you need to read the data and process it later. SSDs also handle large volumes of concurrent writes and reads a lot more gracefully than a hard drive (hard drives only have one head per platter side at best, whereas an SSD is circuit based).
Barnyard
If using an SSD is not an option, or if you really need to eke out every last bit of performance, you'll want to look into barnyard (which is now replaced by Barnyard2). Barnyard2 [5] provides a highly efficient way to log the data to disk. Logging was originally a concern with Snort; because Suricata is multithreaded, logging is less of an issue. However, if you want to log data to a database directly (rather than logging to JSON, e.g., and importing it), you'll need to use Barnyard2. You can install from a package, although packages seem pretty rare, so a source install is probably best:
tar -xvf v2-1.13.tar.gz cd barnyard2-2-1.13/ ./autogen.sh ./configure --with-postgresql make sudo make install
Please note you will, of course, need libpcap-devel
and the devel
libraries for the database of your choice. You will then need to configure Barnyard2 via the barnyard2.conf
file. The main changes you'll need to make are the paths to the Snort config files; the files
config reference_file: /etc/snort/reference.config config classification_file: /etc/snort/classification.config config gen_file: /etc/snort/gen-msg.map config sid_file: /etc/snort/sid-msg.map
should instead be something like:
config reference_file: /etc/suricata/reference.config config classification_file: /etc/suricata/classification.config config gen_file: /etc/suricata/rules/gen-msg.map config sid_file: /etc/suricata/rules/sid-msg.map
Fortunately, the rest of the file is well commented, and although the configuration is tedious, it is not overly complicated.
One note to consider: If you are logging to remote systems (e.g., using Suricata syslog or Barnyard2 to a remote database server), I strongly recommend you ensure you are using a dedicated network. If you are logging over the same link used to send data to internal systems, a large volume of traffic, such as an attack, that generates a large volume of alerts might not be logged correctly if the network packets are dropped or time out.
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.