Enhance Network Threat Detection with Suricata: A Comprehensive Guide for Industrial Control Systems

Suricata is a free open-source network threat detection tool. It is primarily used for real-time intrusion detection (IDS), embedded intrusion prevention (IPS), and network security monitoring (NSM), etc. Due to work requirements, I am preparing to deploy it to inspect industrial control system traffic and add some industrial control rules to enhance detection efficiency.

Introduction to Suricata:

Although Suricata is a free open-source security tool, it has gained recognition from many enterprises and is widely deployed and utilized. This indicates that Suricata is a mature, feature-complete, and highly practical security tool. Suricata is a high-performance network intrusion detection and prevention engine. It is based on multithreading, fully leveraging the advantages of multicore processing. It supports multiple protocols such as IPv4, IPv6, TCP, UDP, HTTP, SMTP, POP3, IMAP, FTP, etc. It allows dynamic loading of preset rules and supports the output of statistical data in various formats such as pcap, JSON, unified2, etc., which makes it very convenient for integration with tools like Barnyard2.

All versions of Suricata: https://openinfosecfoundation.org/download/

>

Suricata Architecture:

There are three operating modes: single, workers, autofp. The officially recommended mode for optimal performance is the workers mode.single mode: There is only one packet processing thread, typically used in development mode.

workers mode: Multiple packet processing threads, each containing complete processing logic.

autofp mode: Multiple packet capture threads and multiple packet processing threads. It is generally suitable for nfqueue scenarios, consuming traffic from multiple queues for processing.

The packet detection system usually consists of four parts: packet acquisition, packet decoding, packet detection, and log recording. Suricata segments different functions into modules, where the output of one module serves as the input for another. Suricata links these modules with threads, as shown in the diagram below:

>

Suricata Deployment**:**

Installation steps, using Ubuntu1804 as an example, can be done using the official PPA:

sudo add-apt-repository ppa:oisf/suricata-stable    sudo apt update    sudo apt install suricata jq

1. Update rules:

suricata-update

2. Test if Suricata is operating normally:

suricata -T

3. Start running:

suricata -i ens33 -c /etc/suricata/suricata.yaml

Configuration Interpretation:

Navigate to the Suricata configuration file directory: cd /etc/suricata/, where you will see the following four configuration files: classification.config/reference.config/suricata.yaml/threshold.config and a rules folder.

suricata.yaml: This is the default configuration file for Suricata, with hardcoded configurations in the source code. It defines almost all operational content for Suricata, including operational modes, packet capture quantity and size, signatures, rules attributes, and log alert outputs, among others.

classification.config: Defines various traffic attack types and priorities, such as denial-of-service attacks and web application attacks, as depicted in the image below:

reference.config: Records URLs of security websites, vulnerability platforms, or custom URLs, serving as references for linking to external malicious attack detection sites concerning similar attack pages.

threshold.config: The threshold keyword is used to control the alert frequency of a rule, allowing setting a minimum threshold before alerts are generated.

rules folder: Stores different types of rules, which are used to determine traffic attack types and define attack types and alert categories. It can store built-in rules or new ones can be written according to rule syntax, as shown in the image below:

Detailed Explanation of Rules**:**

Next, we’ll focus on the rules of Suricata, which are the soul of the detection tool. Similar products that work well, with high interception and accuracy rates and low false positives, owe their success to well-written rules. Suricata’s rules refer to snort rules (Suricata is fully compatible with snort rules). I will briefly introduce each segment’s meaning, focusing primarily on industrial control rules by taking an industrial control rule as an example, as follows:

alert modbus any any -> any any (msg:"SURICATA Modbus Request flood detected"; flow:to_server;app-layer-event:modbus.flooded; classtype:protocol-command-decode; sid:2250009; rev:2;)

alert: The default order is: pass, drop, reject, alert—the four types of actions for skipping, discarding, rejecting, and alerting

Modbus: Signifies the type of protocol, such as UDP/ICMP, etc.

Any: Source/destination address (IP)

Any: Source/destination port

->: Direction, unidirectional flow; <> bidirectional flow

Any: Source/destination address (IP)

Any: Source/destination port

msg:”SURICATA Modbus Request flood detected”: The message keyword provides text information related to the signature/rule triggering the alert

flow:to_server: From client to server

app-layer-event:modbus.flooded: Specific attack content

classtype:protocol-command-decode: Provides information for rule and alert classification as defined by the classification.config file.

sid:2250009: A unique identifier for the rule; sid must not be duplicated

rev:2: The rule’s version number, which increments by 1 after each modification

Writing Industrial Control Rules:

Suricata now primarily uses et/open rules, which are the built-in rules of the system. The currently open-source free rules include et/open, pt rules, and sslbl rules; others require an authorization code to update. I recommend a link to additional rules: https://github.com/ptresearch/AttackDetection, which contains open-source rules covering common CVE vulnerabilities detected in recent years. You can use them at your discretion.

Actually, writing your rules is not difficult. As discussed above, it’s best to write rules containing content. For example, if we know the stop and start function codes of Modbus are 40, 41, we can write content: “|00 00 00 00 33 41 ff 00|” in the rule to match it; if it is an application layer traffic attack, you can write app-layer-event:dnp3.flooded/app-layer-event:modbus.invalid_length, etc. In industrial control rules, the most common are application layer detection and function code detection, capturing key function codes with offset and depth positions to match, as shown in the image below:

I referenced previously written Suricata (Snort) rules for industrial control, as shown in the image below. These rules are designed to detect Nmap scanning for open port 102 to locate PLC traffic:

Additional existing Modbus, enip, and dnp3 rules are supplemented. Interested friends can take a look:

Link provided: https://github.com/digitalbond/Quickdraw-Snort

Simulating Traffic Attacks**:**

After analyzing and writing Suricata rules, we’ll proceed with a real traffic test. However, before testing, we need to make small modifications to the suricata.yaml configuration file, as I captured packets when attacking the Modbus PLC device, then saved and replayed them in Suricata. Therefore, we need to change the pcap-file setting to yes in the diagram below:

Even though Modbus rules are included, they are not enabled by default. Thus, we need to find the Modbus section in the suricata.yaml file and set it to yes:

Then, I modified the session id captured in the communication between Modbus PLCs, altered the length and illegal strings in the packet with the session id, and sent it to the PLC using a Python script while capturing the traffic with Wireshark to obtain the necessary packet data. After uploading the packet to the server, I executed suricata -r modbus.pcap to replay the packets and exported the logs in JSON format for review, as depicted in the diagram below. It shows an alert with a unique SID number that corresponds to the rule hit:

Below are some Suricata command operations for those in need:

Summary:

Suricata encompasses an extensive range of functions. Due to space limitations, I only explained its use in the industrial control field. Suricata supports embedded Lua scripts for custom detection and script outputs, common packet decoding, common application layer protocol decoding, analyzing offline pcap files, and storing traffic data in pcap file formats. These useful features require gradual exploration and expanded use.

The rules of Suricata are an area requiring accumulation and improvement. By gathering threat intelligence regularly, combining it with your system’s production environment, and staying updated on newly disclosed security vulnerabilities, you can progressively enrich rules to fortify our security landscape!