Cybersecurity has now become one of the key areas for improvement within organizations. Every day, we see numerous articles reporting on cyberattacks against companies, which is why investment in this area grew by 7.7% last year, according to data from the IDC (Market Research Report).
Companies are seeking various solutions to protect and safeguard data—their most valuable asset—and, at the same time, are looking for ways to mitigate attacks.
Have you heard of Suricata?
Among the solutions sought by organizations, the implementation of IDSs (intrusion detection systems) such as Suricata is gaining prominence. Suricata is a high-speed, resource-efficient threat detection engine that analyzes network traffic for malicious patterns and behaviors, capable of blocking unwanted traffic and thereby protecting the organization’s network and systems against potential threats. In addition, it features a graphical interface to assist and facilitate configuration in a simple and user-friendly way for the administrator.
This article discusses rule generation, explaining their structure and the various parameters used to define them.
Rule Structure in Suricata
Suricata rules are a set of directives used to specify which types of network traffic should be monitored and what actions should be taken when suspicious traffic is detected. Suricata rules consist of three main parts: the action, the header, and the options. The general structure of Suricata rules, referred to as “Signatures,” includes a series of fields that describe the characteristics of the rule itself.
These rules can be applied to each of the available interfaces based on the organization's needs.
The format of Suricata rules is defined as:
- Action: Specify the action that occurs when a match is found with the signature
- Header: The protocol, IP addresses, and source and destination ports for the rule are defined
- Options: Provides a number of additional options that can be used to refine the rule based on how you want it to behave. For example, if you want to perform a case-insensitive search, you can use the “nocase” parameter (case-insensitive).
The following section breaks down each of the parameters applicable to Suricata rules, describing and illustrating some of them:
Action:
- alert: An alert is generated in the event log, and traffic is allowed.
- drop: Traffic that matches the rule is discarded.
- reject: Traffic that matches the rule is rejected with an ICMP error message.
- pass: Traffic that meets the rule is allowed without triggering an alert in the event log.
- sdrop: Traffic that matches the rule is dropped without generating an alert in the event log.
- ignore: Traffic that meets the rule is ignored without generating an alert in the event log.
- replace: Content that matches the rule is replaced before being accepted or rejected.
- log: Traffic that matches the rule is logged in the event log without triggering an alert or blocking the traffic.
- user: Used to apply a custom action defined by the user in the settings.
Header:
- Protocol: Specifies the specific transport layer protocol to be analyzed. The following are some of the main protocols: TCP, UDP, ICMP, ICMPv6, IP, ARP
- Source or destination IP: Specifies the source and destination IP addresses of the traffic
- Port of origin or destination: Specify the port of origin and destination for the traffic
- Content: Refers to the content to be searched for in the traffic, such as text strings or a byte pattern.
- Content: Allows you to search for a text string in the package.
- Content:!"string": allows you to search for packages that do NOT contain a specific text string.
- Content:| hex |: allows you to search for a specific hexadecimal value in the packet.
- Content:!"| hex |": allows you to search for packets that do NOT contain a specific hexadecimal value.
- Content:"pattern1"; content:"pattern2": allows you to search for multiple patterns within the same package.
- Content:"pattern1"; within:X; content:"pattern2": allows you to search for patterns separated by X bytes.
Options:
- distance: is used in conjunction with within to specify a distance from the last content match. For example, if you had content:"ABC"; distance:10; content:"DEF";, you would be searching for a "DEF" that appears 10 bytes after the end of the preceding "ABC".
- offset: used to skip a specific number of bytes in a packet before attempting to match the content.
- depth: used to limit the search depth for a match in a packet.
- http_method, http_uri, http_header, etc.: These are HTTP-specific modifiers that allow you to search specific parts of an HTTP request or response.
Rule for detecting port scanning
Here's what a simple rule for detecting port scanning based on the sending of SYN packets would look like:
ACTION |HEADER |OPTIONS
alerttcp any any -> any any(msg:"SYN SCAN Detected"; flow:stateless; flags:S; reference:arachnids,198; classtype:attempted-recon; sid:2100624; priority:5; rev:8; threshold:type both, track by_src, count 9, seconds 1;)
- alert: Indicates that an alert will be generated if the specified condition is met.
- tcp: Indicates that the search will be performed on TCP packets.
- any any -> any any: Specify the source and destination IP addresses and ports for the packets to be searched. In this case, the search will include any source and destination IP address and port.
- msg:"SYN Scan Detected": Sets the alert message that will be displayed when the specified condition is met. In this case, the message is "SYN Scan Detected".
- flow:stateless: Indicates that the rule applies to stateless flows, that is, those in which TCP connection tracking is not expected.
- flags:S: Specifies that packages with the SYN (S) bit set to active will be searched for.
- reference:arachnids,198: Refers to the rule identifier in the Arachnids database.
- classtype:attempted-recon: Indicates the alert classification. In this case, "attempted-recon" means that a reconnaissance attempt has been detected.
- sid:2100624: Unique identifier for the rule.
- priority:5: Priority assigned to the rule, on a scale of 1 to 5.
- rev:8: Revision number of the rule.
- threshold:type both, track by_src, count 9, seconds 1: Sets a threshold to prevent false alerts. In this case, an alert will be generated when more than 9 port scan attempts per second are detected from the same source IP address.
Conclusion
In conclusion, Suricata rules are used to detect threats such as port scanning attempts, denial-of-service attacks, malware, and network intrusions, among others. Creating and managing rules within Suricata allows organizations to tailor their security system to their specific needs and the ever-changing threat landscape. At SCASSI, we are ready to help organizations improve their detection capabilities. This is the first step toward establishing efficient workflows for threat and alert management. Cybersecurity is a journey, not a destination. At SCASSI, we are committed to supporting our clients every step of the way, helping them stay secure and resilient in an increasingly threatened cyberspace.
