Rule anatomy and actions

Start with a harmless signature

alert http 10.10.10.20 any -> 192.0.2.80 8080 (msg:"LAB PacketLab marker"; flow:established,to_server; http.uri; content:"/routecraft-check"; startswith; sid:1000001; rev:1;)

This local signature observes an established HTTP request to the lab service. It is intentionally narrow and is not a malware detector. Save it in local.rules and use the offline fixture from the previous lesson.

Read the header left to right

Application protocol and port are separate conditions. HTTP can run on another port; this particular signature still requires destination port 8080. A response travels in the opposite header direction.

Read the condition and identity

flow:established,to_server requires established client-to-server traffic. http.uri selects the normalized URI buffer for following content. content matches the marker bytes; startswith anchors that content at the start of the selected buffer. The message is a label. sid identifies this local rule and rev tracks its revisions; neither value chooses which host to inspect.

Rule options are not arbitrary decoration: moving content before the intended sticky buffer changes the inspection target. A syntactically valid broad match can still be the wrong policy.

Choose an action deliberately

Action precedence and flow handling mean rule-file order is not a simple firewall list. Do not use a broad pass rule merely to quiet one noisy alert: it can hide other detections. Passive placement cannot enforce a drop against the original copy source.

Validate the intended boundary

suricata -T -c /etc/suricata/suricata.yaml -S ./local.rules --init-errors-fatal
Configuration provided was successfully loaded. Exiting.

Then replay the positive and negative fixtures. Change one condition at a time: URI, port or client address. Only matching traffic should produce this local SID; retain the previous rule revision so a bad change can be reversed.