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).
Updated by Victor Julien 3 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)
Updated by Victor Julien 2 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.