Feature #8395
openTask #8388: firewall: support protocol hooks for all app-layer protocols
firewall: support SNMP hook states for firewall rule evaluation
Description
SNMP is a common network management protocol that firewalls frequently need to control. In Suricata 8.0.4, SNMP app-layer hook states are not registered for firewall mode. Attempting to use any snmp:* hook in a firewall rule fails with the error: "protocol snmp does not support hook".
Without SNMP hooks, SNMP traffic on UDP port 161/162 can only be controlled at the packet layer. While packet-layer rules can accept SNMP packets, the app-layer parser still engages and the flow may be subject to default_app_policy behavior. Registering SNMP hooks would allow the firewall engine to make explicit accept/drop decisions at the application layer.
Based on the SNMP protocol structure, the following potential states are recommended:- GET request sent
- GETNEXT request sent
- SET request sent
- GETBULK request sent
- Response received
- Trap received (v1)
- InformRequest sent
- InformRequest acknowledged
- SNMPv3 authentication/encryption negotiation
- Report received
At minimum, a request/response hook pair would enable basic firewall control. A trap hook would allow policy enforcement on unsolicited notifications (port 162).
VJ Updated by Victor Julien 25 days ago
- Tracker changed from Bug to Feature
- Subject changed from Firewall mode: Register SNMP hook states for firewall rule evaluation to firewall: support SNMP hook states for firewall rule evaluation
- Assignee set to OISF Dev
- Priority changed from Normal to High
- Target version changed from TBD to 9.0.0-beta1
- Affected Versions deleted (
8.0.4)
VJ Updated by Victor Julien 25 days ago
- Parent task set to #8388
VJ Updated by Victor Julien 24 days ago
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.
YD Updated by Yash Datre 18 days ago
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.
VJ Updated by Victor Julien 17 days ago
- Status changed from New to Assigned
- Assignee changed from OISF Dev to Philippe Antoine
- Label Needs backport to 8.0 added
catenacyber 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.
OT Updated by OISF Ticketbot 17 days ago
- Subtask #8432 added
OT Updated by OISF Ticketbot 17 days ago
- Label deleted (
Needs backport to 8.0)
PA Updated by Philippe Antoine 16 days ago
Victor Julien wrote in #note-5:
by default
SCDetectHelperBufferRegisterregisters 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...
PA Updated by Philippe Antoine 13 days ago
- Status changed from Assigned to In Progress