Suricata

What would a ruleset look like with these hooks?

In HTTP1 the hooks follow the distinct stages of a transaction, that can happen over many packets: leading up to the request line (request_started), having the request line complete (request_line), headers, body, etc. AFAICS in SNMP we have single packet requests and responses, so there isn't per transaction state progression.

We tested in 8.0.4 and the built-in hooks actually work — snmp:request_started , snmp:request_complete , snmp:response_started , snmp:response_complete all load and fire correctly in firewall mode. We wrote a suricata-verify test confirming this.

As noted, SNMP is single-packet request/response — there's no multi-stage progression. The existing 4 hooks are sufficient. The proposed states in the ticket (GET, GETNEXT, SET, GETBULK, Trap, etc.) map to snmp.pdu_type values, not separate hook states.

A practical firewall ruleset would look like:

# Transport: accept UDP to SNMP agent
accept:hook udp:all any any -> any 161 (sid:100;)
accept:hook udp:all any 161 -> any any (sid:101;)

# App-layer: only allow read-only operations (GetRequest=0, GetNextRequest=1, GetBulkRequest=5)
# Block SetRequest (pdu_type 3) and other write operations
accept:tx snmp:request_complete any any -> any 161 (snmp.pdu_type:0; sid:200;)
accept:tx snmp:request_complete any any -> any 161 (snmp.pdu_type:1; sid:201;)
accept:tx snmp:request_complete any any -> any 161 (snmp.pdu_type:5; sid:202;)
accept:tx snmp:response_complete any 161 -> any any (snmp.pdu_type:2; sid:210;)

# Trap receiver (port 162): only accept traps from monitored hosts
accept:hook udp:all any any -> any 162 (sid:300;)
accept:hook udp:all any 162 -> any any (sid:301;)

# Restrict community string
accept:tx snmp:request_complete any any -> any 161 (snmp.community; content:"monitoring-ro"; sid:400;)

However, we found that accept:tx with snmp.community or snmp.pdu_type at snmp:request_complete currently fails with "engine progress value 0 doesn't match hook 1". The keywords are registered at progress 0 but request_complete is progress 1. This needs to be fixed for the keywords to be usable in firewall per-transaction rules.

Victor Julien wrote in #note-5:

by default SCDetectHelperBufferRegister registers at progress 0, which is not correct in this case. I wonder if we need another registration func to specify the progress value, or if we can just always register these to the completion status. The latter sounds a bit risky to me, so probably need the former.

So, the reason for this behavior (before firewall mode) is that SNMP (like other protocols) transactions are complete as soon as they are created.

We can easily add another registration function with additional argument to specify the progress value.
But I guess we can change SCDetectHelperBufferRegister behavior to use completion status instead of 0 and check which protocols use this SCDetectHelperBufferRegister to see if it is right...

https://github.com/OISF/suricata/pull/15210