A common discussion in the security industry is how to improve the effectiveness of detection and prevention systems. You can find tons of documentation and books about: The Defender's Dilemma, Blue Team vs Red Team, A Comprehensive Security Approach, among others. However, in any organization, it is very important to move beyond theory and implement specific solutions to detect security attacks and security threats.
In this post, I want to share some thoughts about one specific topic: Network Intrusion Detection Systems (NIDS), specifically a really good piece of software called Suricata.
Let's start with some background. Intrusion detection is a broad concept that refers to some type of mechanism or process to identify security threats. Organizations typically use solutions like Host Intrusion Detection Systems (HIDS) and Network Intrusion Detection Systems. In addition, response capabilities are also quite popular in Intrusion Detection Systems (IDS). In fact, several vendors offer Endpoint Detection and Response (EDR) and some vendors are using a new acronym: Network Detection and Response (NDR). I think the industry is trying to be more consistent by adding the word “response” in both endpoint detection and network detection.
In NIDS, there are two main approaches: signature-based detection and anomaly-based detection.
A signature-based intrusion detection system operates in real time capturing traffic and looking for signature matches. If a match is found, the system will generate an alarm.
An anomaly-based system is looking for abnormal behavior that represents threats. Instead of being concentrated on the packet, it looks for unusual behavior, anomalies and deviations from normal.
Having said that, let’s switch gears to the main topic of this post which is Suricata.
What is Suricata?
In the official documentation, you will find this:
“Suricata is a high-performance Network IDS, IPS, and Network Security Monitoring engine. It is open source and owned by a community-run non-profit foundation, the Open Information Security Foundation (OISF). Suricata is developed by the OISF” [1].
Besides the official definition, I think Suricata is a very powerful open source NIDS. It is a signature-based IDS and once it is properly configured, Suricata is capable of doing real-time traffic inspection in order to trigger alarms when suspicious activity is detected in your environment. Suricata also offers a very extensive list of features. The complete list can be found here:
https://suricata-ids.org/features/all-features/
From that list, I would like to highlight an important one: Threading [2].
Suricata threading
Suricata is capable of running multiple threads. If you have hardware with multiple CPUs/cores, the tool can be configured to distribute the workload on several processes at the same time. You can start running with a single thread and process packets one at a time. Nevertheless, from my experience, multi-threading is a much better configuration and the way to improve Suricata’s performance.
Suricata has four thread modules:
- Packet acquisition: responsible for reading packets from the network.
- Decode and stream application layer: decodes the packets and inspects the application.
- Detection: compares signatures and can be run in multiple threads.
- Outputs: in this module, all the alarms are processed.
Figure 1 shows a graphical example of how the thread module works.
Suricata runmodes
Suricata also offers runmodes. I recommend you familiarize yourself with that concept when learning Suricata. It’s a “Lego-style” approach with 3 pieces working together: threads, thread-modules, and queues.
As mentioned above, Suricata has the ability to run several threads at the same time. Thread-modules are specific thread functionalities, like decode or detect. A packet can be processed by more than one thread and queues are responsible for passing the packet from one thread to another.
When those three elements combined work together in packet processing, they become a runmode. Suricata uses the following names for its runmodes: single, workers and autofp.
If you have a Suricata CLI available, try the following command to show the runmodes.
USM# suricata --list-runmodes
You should obtain an output like this:
------------------------------------- Runmodes ------------------------------------------
| RunMode Type | Custom Mode | Description
|----------------------------------------------------------------------------------------
| PCAP_DEV | single | Single threaded pcap live mode
| ---------------------------------------------------------------------
| | autofp | Multi threaded pcap live mode. Packets
| from each flow are assigned to a single
| detect thread, unlike “pcap_live_auto”
| where packets from the same flow can be
| processed by any detect thread
| ---------------------------------------------------------------------
| | workers | Workers pcap live mode, each thread does
| all tasks from acquisition to logging
|----------------------------------------------------------------------------------------
| PCAP_FILE | single | Single threaded pcap file mode
| ---------------------------------------------------------------------
| | autofp | Multi threaded pcap file mode. Packets
| from each flow are assigned to a single
| detect thread, unlike “pcap-file-auto”
| where packets from the same flow can be
| processed by any detect thread
|----------------------------------------------------------------------------------------
| PFRING(DISABLED) | autofp | Multi threaded pfring mode. Packets
| from each flow are assigned to a single
| detect thread, unlike “pfring_auto”
| where packets from the same flow can be
| processed by any detect thread
| ---------------------------------------------------------------------
| | single | Single threaded pfring mode
| ---------------------------------------------------------------------
| | workers | Workers pfring mode, each thread does
| all tasks from acquisition to logging
|----------------------------------------------------------------------------------------
| NFQ | autofp | Multi threaded NFQ IPS mode with respect
| to flow
| ---------------------------------------------------------------------
| | workers | Multi queue NFQ IPS mode with one thread
| per queue
|----------------------------------------------------------------------------------------
| NFLOG | autofp | Multi threaded nflog mode
| ---------------------------------------------------------------------
| | single | Single threaded nflog mode
| ---------------------------------------------------------------------
| | workers | Workers nflog mode
|----------------------------------------------------------------------------------------
| IPFW | autofp | Multi threaded IPFW IPS mode with respect
| to flow
| ---------------------------------------------------------------------
| | workers | Multi queue IPFW IPS mode with one thread
| per queue
|----------------------------------------------------------------------------------------
| ERF_FILE | single | Single threaded ERF file mode
| ---------------------------------------------------------------------
| | autofp | Multi threaded ERF file mode. Packets
| from each flow are assigned to a single
| detect thread
|----------------------------------------------------------------------------------------
| ERF_DAG | autofp | Multi threaded DAG mode. Packets from each
| flow are assigned to a single detect thread,
| unlike “dag_auto”
| where packets from the same flow can be
| processed by any detect thread
| ---------------------------------------------------------------------
| | single | Singled threaded DAG mode
| ---------------------------------------------------------------------
| | workers | Workers DAG mode, each thread does all tasks
| from acquisition to logging
|----------------------------------------------------------------------------------------
| AF_PACKET_DEV | single | Single threaded af-packet mode
| ---------------------------------------------------------------------
| | workers | Workers af-packet mode, each thread does all
| tasks from acquisition to logging
| ---------------------------------------------------------------------
| | autofp | Multi socket AF_PACKET mode. Packets from
| each flow are assigned to a single detect
| thread.
|----------------------------------------------------------------------------------------
| NETMAP(DISABLED) | single | Single threaded netmap mode
| ---------------------------------------------------------------------
| | workers | Workers netmap mode, each thread does all
| tasks from acquisition to logging
| ---------------------------------------------------------------------
| | autofp | Multi threaded netmap mode. Packets from
| each flow are assigned to a single detect
| thread.
|----------------------------------------------------------------------------------------
| UNIX_SOCKET | single | Unix socket mode
|----------------------------------------------------------------------------------------
With those options, you would be able to configure which runmode you want to use. You can configure it using the CLI or the Suricata.yaml configuration file.
We won’t cover Suricata configuration in this post, so for now, let’s just mention that it uses YAML, which is the abbreviated form of “YAML Ain’t markup language.” It is a human-friendly format and easy to read. In addition, Suricata includes a YAML sample file.
Figures 2, 3 and 4, show runmode examples:
About hardware requirements
Suricata can run in Linux, FreeBSD, OpenBSD, Mac OS, and Windows. However, I would recommend verifying the amount of traffic that you will be processing per interface. There is no specific hardware configuration to run it.
You can install Suricata in an Ubuntu Server with 2 cores and 8 GB of RAM, which will be enough if you plan to test the tool in a lab environment and see how it works. On the other hand, if you plan to test several interfaces and send an important amount of traffic to them, you are going to need more CPUs and more memory in order to process packets and use multi-threading. Remember, if you don’t have enough hardware to process incoming traffic, Suricata will experience performance issues.
Three suggested installations that you can use during your learning process are:
- Ubuntu server: for this Linux distribution, the Open Information Security Foundation (OISF) have stable binary packages in their repository. You only need to check which are Suricata’s dependencies and then install it. I would recommend this option for your first installation.
- pfSense: pfSense is an open source firewall/router which offers a Suricata add-on package. This option could be your next step if you want to explore adding a network intrusion detection system to your firewall.
- Dedicated Hardware: a third and more robust option is to have a dedicated Linux server with 16 cores, 32GB of memory RAM and at least 2 NICs. This suggested configuration is going to provide good performance and you will be able to test Suricata’s runmodes without issues.
Conclusion
There are many types of intrusion detection systems available in the industry. In this article, we covered only one, a well-known NIDS, Suricata. I strongly recommend including a NIDS in your essential security tool-kit. Once you install a NIDS, you should enable multi-threading, if that option is available. Then, I recommend tuning your NIDS to avoid false positives. It is also a best practice to enable log auditing and send your logs to a Security Information and Event Management (SIEM) system, which is responsible for analyzing and correlating your logs. In AT&T Cybersecurity we have a product called USM Anywhere™ (USMA) which is a Unified Security Management Platform. USMA comes with a network IDS and the software that we use is open source Suricata. For more information please visit: https://www.alienvault.com/
References
Article Link: https://feeds.feedblitz.com/~/603517034/0/alienvault-blogs~Suricata-IDS-an-overview-of-threading-capabilities