Examine alerts, logs, and rules with Suricata

In this activity, I examined rules and alerts on network traffic using Suricata. Also, I analyzed log outputs, such as a fast.log and eve.json file.

Suricata is an open-source-based intrusion detection system, intrusion prevention system, and network security monitoring engine. The Suricata tool monitors network interfaces and applies rules to the packets that pass through the interface. Suricata determines whether each packet should generate an alert and be dropped, rejected, or allowed to pass through the interface.

Configure Suricata

Before Suricata can begin monitoring systems and networks, its settings must be properly configured so that it knows what to do. A configuration file is a file used to configure the settings of Suricata. Suricata's configuration file is suricata.yaml, which uses the YAML file format for syntax and structure. Firstly, the interface(s) that Suricata should be inspecting network packets, and source and destination networks must be specified in the Suricata configuration.

sudo vim /etc/suricata/suricata.yaml

The HOME_NET variable should include the IP address of the monitored interface and all the local networks in use.

The interface(s) that Suricata should be inspecting network packets can be configured in the af-packet section.

Suricata uses signatures or rules to trigger alerts so it's necessary to install those and keep them updated.

Rules can be fetched and updated using the below command.

sudo suricata-update

Afterwards, the rules are installed at /var/lib/suricata/rules which is also the default at the config and uses the sole suricata.rules file.

These are the most recent recommended settings for the IDS run mode for a basic setup.

The below command can restart Suricata.

sudo systemctl restart suricata

Rules

Rules or signatures are used to identify specific patterns, behaviours, and conditions of network traffic that might indicate malicious activity. The terms rule and signature are often used interchangeably in Suricata. Signatures or patterns associated with malicious activity are used to detect and alert specific malicious activity. Rules can also be used to provide additional context and visibility into systems and networks, helping to identify potential security threats or vulnerabilities.

Suricata uses signature analysis, which is a detection method used to find events of interest. Signatures consist of three components:

Action: The first component of a signature. It describes the action to take if network or system activity matches the signature. Examples include alert, pass, drop, or reject.
Header: The header includes network traffic information like source and destination IP addresses, source and destination ports, protocol, and traffic direction.
Rule options: The rule options provide us with different options to customize signatures.

Please find below an example of a Suricata signature.

Rule options have a specific order and changing their order would change the meaning of the rule.

Rule order refers to the order in which rules are evaluated by Suricata. Rules are processed in the order in which they are defined in the configuration file. However, Suricata processes rules in a different default order: pass, drop, reject, and alert. Rule order affects the final verdict of a packet especially when conflicting actions such as a drop rule and an alert rule both match on the same packet.

Define a custom rule in Suricata

I wrote a custom rule and saved it in the custom.rules file. Please find below the custom rule.

In this example, the action is alert and the alert keyword instructs to alert on selected network traffic. The IDS will inspect the traffic packets and send out an alert in case it matches.

The header part of this signature defines the signature’s network traffic, which is any HTTP traffic leaving the home network and going to the external network.

Configuring rule options helps narrow down network traffic. Let's further examine the rule options in this custom rule.

The msg: option provides the alert text. In this case, the alert will print out the text “GET on wire”, which specifies why the alert was triggered.
The flow:established,to_server option determines that packets from the client to the server should be matched. (In this instance, a server is defined as the device responding to the initial SYN packet with a SYN-ACK packet.)
The content:"GET" option tells Suricata to look for the word GET in the content of the http.method portion of the packet.
The sid:12345 (signature ID) option is a unique numerical value that identifies the rule.
The rev:3 option indicates the signature's revision which is used to identify the signature's version. Here, the revision version is 3.

Test the custom rule in Suricata

Before running Suricata, there are no files in the /var/log/suricata directory.

The below command list the files in the /var/log/suricata folder.

I prepared a sample.pcap file (a packet capture file) that contains an example of network traffic data to test the custom Suricata rule. Below command starts the Suricata application and processes the sample.pcap file using the rules in the custom.rules file. It returns an output stating how many packets were processed by Suricata.

sudo suricata -r sample.pcap -S custom.rules -k none

Let's examine the options in the command:

The -r sample.pcap option specifies an input file to mimic network traffic. In this case, the sample.pcap file.
The -S custom.rules option instructs Suricata to use the rules defined in the custom.rules file.
The -k none option instructs Suricata to disable all checksum checks.

Please find below the output of the command.

Log files

Let's list the files in the /var/log/suricata folder again.

After running Suricata, there are now four files in the /var/log/suricata directory, including the fast.log and eve.json files.

The eve.json file is the standard Suricata log file. This file contains detailed information and metadata about the events and alerts generated by Suricata stored in JSON format. For example, events in this file contain a unique identifier called flow_id which is used to correlate related logs or alerts to a single network flow, making it easier to analyze network traffic. The eve.json file is used for more detailed analysis and is considered to be a better file format for log parsing and SIEM log ingestion.

The fast.log file is used to record minimal alert information including basic IP address and port details about the network traffic. The fast.log file is used for basic logging and alerting and is considered a legacy file format and is not suitable for incident response or threat-hunting tasks.

The main difference between the eve.json file and the fast.log file is the level of detail that is recorded in each. The fast.log file records basic information, whereas the eve.json file contains additional verbose information.

I used the cat command to display the fast.log file generated by Suricata.

Each line or entry in the fast.log file corresponds to an alert generated by Suricata when it processes a packet that meets the conditions of an alert generating rule. Each alert line includes the message that identifies the rule that triggered the alert, as well as the source, destination, and direction of the traffic.

I used the jq command to display the entries in the eve.json file in an improved format.

The jq command can be used to extract specific event data from the eve.json file as follows.

Also, the jq command can be used to display all event logs related to a specific flow_id from the eve.json file. The flow_id value is a 16-digit number and will vary for each of the log entries.

In conclusion, I demonstrated how to set up Suricata, create and test custom rules, and examine the fast.log and eve.json output in this activity.

Resources for more information

Suricata User Guide: https://docs.suricata.io/en/latest/index.html

Google Sites

Report abuse