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.