Cybersecurity has become a top priority for organizations. Numerous articles detailing cyberattacks on businesses are published daily, which explains the 7.7% increase in cybersecurity spending last year, according to data from IDC (Quantity Data Report).
Companies are seeking various solutions to protect and secure their data—which is the most valuable asset of any business—and are also looking for ways to mitigate attacks.
Have you heard of Suricata?
Among the solutions organizations are seeking, the implementation of intrusion detection systems (IDS) such as Suricata is gaining prominence. Suricata is a fast, resource-efficient threat detection engine that analyzes network traffic for malicious patterns and behaviors, enabling it to block unwanted traffic and thus protect the organization’s network and systems from potential threats. Additionally, it features a user-friendly graphical interface that makes configuration simple and intuitive for administrators.
This article discusses rule generation, explaining its structure and the various parameters used to define rules.
Social Structure Among Meerkats
Suricata rules are a set of guidelines used to specify the types of network traffic to monitor and the actions to take in the event of suspicious traffic. They consist of three main parts: the action, the header, and the options. The overall structure of rules in Suricata, known as a "signature," 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 follows:
- Action: Specifies the action that occurs when a match is found with the signature.
- Header: Specifies the protocol, IP addresses, and source and destination ports for the rule.
- Options:Provides a range of additional options that allow you to fine-tune the rule to match your desired behavior. For example, to perform a case-insensitive search, use the "nocase" parameter (case-sensitive).
The following section details each of the parameters applicable to Suricata rules, describing and illustrating some of them:
Action:
- Alert: An alert has been generated in the event log, and traffic is allowed.
- Deletion: Traffic that matches the rule is discarded.
- Reject: Traffic that matches the rule is rejected with an ICMP error message.
- Passage: Traffic that complies with 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 matches this rule is ignored without generating an alert in the event log.
- replace: Content that meets the rule is replaced before being accepted or rejected.
- log: Traffic that complies with the rule is recorded 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 transport layer protocol to be analyzed. Here are some of the main protocols: TCP, UDP, ICMP, ICMPv6, IP, ARP
- Source or destination IP address: Specifies the source and destination IP addresses of the traffic
- Source or destination port: Specifies the source and destination ports 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 within 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"; in: X; content: "pattern2": allows you to search for patterns separated by X bytes.
Options:
- The `distance:` argument is used in conjunction with `within` to specify a distance from the last content match. For example, if you have `content:"ABC"; distance:10; content:"DEF";`, you will search for an "DEF" that appears 10 bytes after the end of the previous "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 within a packet.
- http_method, http_uri, http_header, etc.: These are HTTP-specific modifiers that allow you to search for specific parts of an HTTP request or response.
Rule for detecting port scans
Here is what a simple rule for detecting port scans based on sending SYN packets would look like:
ACTION | HEADER | OPTIONS
alert tcp 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 TCP packets will be searched for.
- any any -> any any: Specifies the IP addresses and source and destination ports of the packets to be scanned. In this case, all IP addresses and all source and destination ports will be scanned.
- 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, i.e., flows for which TCP connection tracking is not expected.
- flags:S: Indicates that packets with the SYN (S) bit set will be searched for.
- reference:arachnids,198: Refers to the rule's identifier in the Arachnids database.
- classtype:attempted-recon: Indicates the alert classification. In this case, "attempted-recon" means that an attempted reconnaissance operation has been detected.
- sid:2100624 : Unique rule ID.
- priority:5: The 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 enable the detection of threats such as port scanning attempts, denial-of-service attacks, malware, and network intrusions. Creating and managing rules within Suricata allows organizations to tailor their security systems to their specific needs and to the constantly evolving threat landscape. At SCASSI, we are ready to help organizations improve their detection capabilities. This is the first step toward establishing effective workflows for threat and alert management. Cybersecurity is an ongoing process. At SCASSI, we are committed to supporting our clients every step of the way, helping them stay protected and resilient in an increasingly threatened cyberspace.
