Configuration and HOME_NET

Choose the address boundary

Our isolated lab has client 10.10.10.20 and a cleartext HTTP service at 192.0.2.80:8080. The passive sensor sees both directions. HOME_NET is a rule variable describing protected addresses, not a routing command or a guarantee that those addresses are visible.

Edit the matching packaged configuration

Start from the complete Suricata 8.0.1 packaged YAML. Replace its existing vars, rule-file selection and relevant capture entry with the following settings; merge into existing sections rather than adding duplicate top-level keys. The excerpt is not a complete standalone configuration.

vars:
  address-groups:
    HOME_NET: "[10.10.10.0/24]"
    EXTERNAL_NET: "!$HOME_NET"

default-rule-path: /etc/suricata/rules
rule-files:
  - local.rules

af-packet:
  - interface: mon0
    cluster-id: 99
    cluster-type: cluster_flow
    defrag: yes
    tpacket-v3: yes

Understand membership before direction

With this definition, 10.10.10.20 is home and 192.0.2.80 is external. A different policy could define both as protected; then an EXTERNAL_NET-to-HOME_NET rule would not cover traffic between them. A rule header selects address direction, while flow direction describes client/server roles. Do not assume the words inbound and outbound mean the same thing at every sensor.

If HOME_NET is any, its negation is an empty external set. Use deliberate nonempty address groups. Include IPv6 networks when they are part of the actual protected scope. NAT placement may require translated addresses or correlation with translation logs.

Load the rule and validate

Create local.rules with the harmless test signature below. This first configuration intentionally selects only the local file; later ruleset lessons add managed signatures.

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;)

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

Check that the test reports zero failed rules as well as successful configuration loading. A misspelled rule path, invalid keyword or empty address expansion must be repaired before replay.

Prove classification with controlled evidence

Save the configuration with its rules as one reproducible policy. Recheck known positive and negative traffic whenever address groups change. A syntactically valid group can still express the wrong monitoring policy.