1. Suricata is derived from the classic NIDS system. It is a network traffic-based threat detection engine that integrates IDS (Intrusion Detection), IPS (Intrusion Prevention), NSM (Network Security Monitoring), and PCAP functionalities.
2. IDS Function By monitoring network card traffic and matching rule engines, it performs real-time intrusion detection and alerting, similar to Wazuh. 3. IPS Function Unlike Wazuh’s active response feature, IPS does not need to call the firewall. Instead, it directly queues the passing traffic into iptables. If a threat is detected, the traffic is immediately dropped or rejected, preventing it from reaching the target server.
Note: IPS provides traffic blocking functionality compared to IDS.
The alert position is where we need to specify the action
Commonly used actions include:
drop — In IPS mode, if the signature matches the corresponding content, it will immediately stop, and the packet will not be sent. An alert will be generated.
reject — This is an active rejection of the packet. Both the receiver and sender receive the rejection packet. Two types of rejection packets will be automatically selected.
alert — If the signature matches the corresponding content, Suricata will generate an alert. Only the system administrator will notice this alert.
2. Protocol (http position)
http is the protocol we need to configure
Transport Layer:
TCP
UDP
ICMP
IP (represents all or any)
Application Layer:
http
ftp
tls (this includes ssl)
smb
dns
ssh
smtp
imap (etc.)
3. Source/Destination ($HOME_NET / $EXTERNAL_NET)
$HOME_NET # Source IP, configured in the suricata.yaml file, representing the visiting IP
$EXTERNAL_NET # Destination IP, the IP being accessed
4. Ports ($HTTP_PORTS)
$HTTP_PORTS # Can be configured in the suricata.yaml file, or written as 80 or 81, etc.
5. Direction (dirction)
<> This symbol can be understood as follows:
“-> ” : Matches request data
”<-“ : Matches response data
“<> ” : Matches both directions
Note: In Suricata, the ; symbol represents a separator. The ” symbol is used to enclose matching items and has special meaning.
IV. Rule Analysis Keywords
Keywords can be understood as the data inside the parentheses (msg:·····). They are used to match and filter traffic, set alert levels, and other parameters such as sid.
1. mgs (message)
Generally placed at the beginning, it can be used for alert prompts (SQL injection; XSS injection, etc.)
2. sid (signature ID)
Generally placed at the end of the signature rule, each rule is assigned a unique ID that cannot be duplicated (sid:561004;)
Note: The ending also needs to use ;
3. rev (revision)
This can also be written at the end. It is used to record the number of times a signature rule has been modified, making it convenient for maintenance personnel to track changes (rev:1;)
4. gid (group ID)
For example: The following is an alert message I triggered
03/23/2023-00:24:05.191941 [**] [1:565001:0] The server is suspected to be communicating with Ant Sword!! Please check it out as soon as possible!! [# Custom Category Configuration classification: [Attack Type], [Description], [Priority Level (1, 2, 3) – This level will be used when the rule does not define a specific level]
6. reference
Not commonly used. This keyword is intended for signature authors and analysts investigating the reason for signature matches. It serves as a note on what type of vulnerability the signature corresponds to.
reference: cve, CVE-2014-6666
7. priority
Priority usually carries a mandatory numeric value ranging from 1-255. Typically, levels 1-4 are used, with lower numbers indicating higher priority and thus higher threat levels. Example:
priority:1;
8. metadata
This keyword allows the addition of non-functional information to the signature, essentially serving as a tag.
metadata: key value, key value;
9. target
This allows rule writers to specify which side of the alert is the attack target (source IP or destination IP).
target: src_ip;
HTTP Keywords
1. http_method
This field includes GET, POST, PUT, HEAD, DELETE, TRACE, OPTIONS, CONNECT, and PATCH.
It is generally used in conjunction with the content field for matching and filtering.
http.method; content:”POST”;
Combining these can filter out POST/GET requests in data packets!
2. http_uri/http_raw_uri
These modifiers can specifically match the content following GET or POST requests.
3. http.request_body
Checks the entire content of the request or response, as shown in the example above.
http.request_body; pcre: “/union.+select/i”; # Used to check if the request or response content contains the “union select” field. pcre:”/【regex match】/i”
// # Fixed structure
i # Indicates case-insensitive matching
4. http.header
Matches all information in the HTTP header buffer, except those with specific text modifiers (e.g., http.cookie, http.method).
For example, it can retrieve the Host from the request header:
http.header; content:”www.google.com”;
5. http.user_agent
This is part of the request header, but it specifically matches the content following “User-Agent:”.
6. http.cookie
Matches only cookies.
7. http_referer
This is also part of the request header, but it can be used separately to match the Referer in the request header.
The above are some commonly used matching signatures.
