Packet Checker

Intrusion detection systems (IDSs) and intrusion prevention systems (IPSs) are some of the classic tools in the administrator's toolbox to counter sophisticated attacks. One popular Linux candidate is the highly functional Suricata [1] (Figure 1).

Figure 1: Suricata is a comprehensive tool for detecting digital attacks. © Linux Screenshots (USA)

Various databases house online attack signatures for Suricata, which the tool uses to examine the data traffic and detect attacks. Much like antivirus programs, however, Suricata can only detect attacks with identified signatures. With the progress made in machine learning over the past few years, efforts have been made to generate new signatures automatically with artificial intelligence (AI) and to enter them into Suricata.

In this article, I first look into Suricata in detail and then introduce the Dragonfly machine learning engine (MLE) [2] specifically designed for Suricata. Finally, I look at OPNids [3], a fork of the OPNsense firewall and routing software that integrates Suricata and Dragonfly.

IDS and IPS

First, however, I want to focus briefly on terminology. An IDS merely examines data traffic for known patterns as it passes by, whereas an IPS also can manipulate the traffic and, if necessary, flip a kill switch as soon as it detects an attack pattern. The Suricata presented here offers both functions (i.e., it can act both as an IDS and an IPS). For the sake of simplicity, I will be filing Suricata under IDS in this article, but this does not exclude the IPS part of the tool.

How IDS Systems Work

For an IDS system to check incoming traffic for known signatures, it must first see the traffic. The same is true for outbound traffic: A common misconception is that attacks are identified primarily by suspicious network traffic. Active malware such as unwanted Bitcoin miners, for example, can only be identified by a large volume of unwanted traffic suddenly trying to find its way into the outside world. One way or another, for an IDS to have its full effect, it must be able to see the packets passing in both directions.

One idea is to roll out Suricata on load balancers, because they see most of the traffic in an environment. The IDS would then be a simple loop, so to speak, that would be attached to the respective load-balancing software and examine the data traffic before it was forwarded to the target systems. However, load balancers and corresponding appliances usually do not have the resources for comprehensive analysis of network traffic, and having an IDS as a proxy between the inside and the outside of a setup would inevitably create a bottleneck that would become a problem over time.

IDSs therefore adopt a different approach. Virtually every switch operating system (e.g., Junos OS by Juniper or Nexus by Cisco) offers the ability to set up a mirror port, wherein you use rules to tell the switch what traffic to investigate. The devices then copy this traffic to a separate port declared up front as a mirror. Then, you attach an IDS system to this switch port, and the IDS sees the mirrored data traffic for the other nodes in the system. Of course, this functional principle rules out the possibility of using IPS functions – to do so, the IPS system would need to reconfigure the firewalls – but at least attacks can be reliably detected.

What Suricata Can Do

Suricata is justifiably considered a prime example of a comprehensive and well-functioning IDS. The open source software, licensed under the GPL, has a history and is considered stable and mature. Suricata's distribution matches its reputation: Packages are available for all relevant distributions, mostly from official repositories. If no suitable package can be found there, third-party providers maintain Suricata PPAs (e.g., for Ubuntu). In the steps that then follow, you simply build a configuration and adapt it to your local environment.

As already mentioned, Suricata has an internal engine that manages all rules for the IDS. With a separate tool, known as the Oinkmaster [4], you could even create a set of rules specific to a particular application. A number of authors have published their personal rules in online directories of templates.

However, you should not install all rules blindly; instead, make a meaningful selection up front. It would make no sense at all to let Suricata search for SMTP packets in the data traffic if you don't run an SMTP server yourself. Every rule that Suricata has to apply to packets costs system resources. At the end of the day, most admins build a subset that contains a set of Suricata rules that perfectly fits the respective usage scenario.