Signatures play a very important role in Suricata.

Suricata Rules consists of the following format:

• Action: Determines what happens when the signature matches.
• Header: Defining the protocol, IP addresses, ports and direction of the rule.
• Options: Defines the specifics of the rule.

Classification

Custom Rules

alert ip any any -> any any (msg:"ICMP detected"; sid:2; rev:1;)
 
alert icmp any any -> \
      any any (msg:"PING detected"; \
      sid:2; rev:1;)
 
 
alert tcp 1.2.3.4 1024 - > 5.6.7.8 80
 
 
# Detect SSH protocol anomalies.
alert tcp any any -> any 22 (msg:"ALERT TCP port 22 but not SSH"; app-layer-protocol:!ssh; sid:2271009; rev:1;)
 
 
# Non-TLS traffic on TLS ports.
alert tcp any any -> any [443,465] (msg:"Detected non-TLS on TLS port"; flow:to_server; app-layer-protocol:!tls; threshold: type limit, track by_src, seconds 90, count 1; sid:210003; rev:1;)
 
 
alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:\".htpasswd access attempt\"; flow:to_server,established; content:\".htpasswd\"; nocase; sid:210503; rev:1;)

where:

• Action: drop.
• Header: tcp $HOME_NET any → $EXTERNAL_NET any.
• Options: (msg:“ALERT TCP port 22 but not SSH”; app-layer-protocol:!ssh; sid:2271009; rev:1;)

Action:

• pass: If the packet matches this rule it’ll be accepted through.
• drop: The packet doesn’t get processed any further down the chain and the sender isn’t notified.
• reject: This acts the same as drop but will also notify the sender that the packet has been removed from the stack.
• alert: Notifies you of any packets that have matched rules.

Protocol

• ip: Any packets on the network involving the adapter.
• tcp: TCP.
• udp: UDP.
• icm ICMP packets, such as ping.

Source and Destination IP and Port

• An exclamation mark specifies “not”, so “! 10.0.1.0/8” means any IP not in the 10.0.1.0 subnet.
• [] - t specify multiple IPs and ports. They go inside the brackets and are comma-separated.
  • You can also mix-and-match with the ! as well.
  • For example, if you wanted the rule to match IP 192.168.0.5 but not 192.168.1.0/24, you would do “[! 192.168.1.0/24, 192.168.0.5]”. The value will be matched in the order you pass it.
• You can also throw in variables as well, like so: [$EXTERNAL_NET, !$HOME_NET] or if you want to exclude only two IP blocks from the rule: ![192.168.1.0/24,192.168.0.0/24] (this will match everything but IPs in the 192.168.1.0/24 and 192.168.0.0/24 ranges.

Ports act similarly but they have one additional sign that you can use:

• : - Specifies a range of ports (i.e.: [80:82] will match ports 80-82).
  • If you want a non-specific range (i.e.: only a maximum or minimum port number), you can do this: [:1024] (matches everything from 0-1024) or [1024:] (matches from 1024 to the highest [typically 65535]).

Direction Specification

• Between the IP and ports is the direction of packet flow, in our case →. There’s two options for this:

• → - This is the most common and means only check if the source IP and port are coming in to the destination IP and port.
• <> - This will match packet flow in either direction.

Rule Options

• The 3 most basic options are:

• msg: - What will be prompted in an alert (unless you’re using pass as the action, set this regardless).
• sid: - This is a unique ID for the rule.
  • If multiple rules have the same sid Suricata will let you know, and not be nice about it.
  • Typically you should pick a really high number (> 100000) if you are going to write your own.
• rev: - Revision number/ID.
  • Incremented by 1 every time the rule is changed.

https://redmine.openinfosecfoundation.org/projects/suricata/wiki/Suricata_Rules

https://suricata.readthedocs.io/en/latest/rule-management/adding-your-own-rules.html

https://forum.netgate.com/topic/127428/suricata-custom-rules

https://www.admin-magazine.com/Articles/Detecting-intruders-with-Suricata/(offset)/3