26.1. 防火墙模式设计¶

Note

在 Suricata 8 中防火墙模式属于实验性功能，后续可能变更。

Suricata 的防火墙模式允许使用与默认"威胁检测"规则集具有不同特性的规则集：

默认策略为 drop，意味着防火墙规则集需要明确指定允许的内容
防火墙规则从独立文件加载
防火墙规则使用新动作 accept
防火墙规则必须使用显式的动作作用域和规则钩子（见下文）
按协议状态严格遵循文件中的规则顺序进行评估

26.1.1. 核心概念¶

table 具有不同属性的规则集合：packet:filter, packet:td, app:<proto>:<state>, app:td。这些是内置表，不支持创建自定义表。
state 控制规则评估的特定协议状态。例如 tcp.flow_start 或 tls.client_body_done。

应用层表按应用层协议和协议状态划分。例如 app:http:request_line。

26.1.2. 动作与作用域¶

防火墙规则要求显式指定动作作用域。

26.1.2.1. accept¶

accept 用于对数据包、流或钩子做出允许裁决：

packet 允许当前数据包
flow 允许该流的所有后续数据包
hook 允许当前钩子/状态的规则，继续评估后续表
tx 允许当前事务的规则，继续评估后续表

accept 动作仅适用于防火墙规则。

Note

部分协议实现（如 dns）每个方向使用独立事务。对于这些协议，accept:tx 仅允许该方向的数据包。

26.1.2.2. drop¶

drop 用于丢弃数据包或流：

packet 直接丢弃当前数据包，不再评估其他规则
flow 丢弃当前数据包（同 packet）并丢弃该流所有未来数据包

Note

由于与威胁检测规则的现有语义存在歧义，防火墙规则中不可用 pass 动作。

26.1.2.3. 显式规则钩子（状态）¶

常规 IDS/IPS 规则中，引擎通过规则的匹配逻辑推断规则应"挂钩"到引擎的位置。虽然这对检测类规则有效，但会导致许多防火墙规则集不可接受的边缘情况。因此防火墙规则必须显式设置钩子。

这通过规则的协议字段实现。威胁检测规则可能形如:

alert http ... http.uri; ...

而防火墙规则则为:

accept:hook http1:request_line ... http.uri; ...

应用层状态/钩子按协议定义。每个钩子都有其默认-drop 策略，因此规则集需要为每个状态提供 accept 规则以允许流量通过。

26.1.2.3.1. 通用状态¶

每个协议至少包含以下默认状态：

请求端（to_server）：

request_started
request_complete

响应端（to_client）：

response_started
response_complete

26.1.2.3.2. HTTP 协议¶

HTTP 协议提供多个可挂钩状态（适用于 HTTP 0.9/1.0/1.1，HTTP/2 使用独立状态机）：

请求端（to_server）：

request_started
request_line
request_headers
request_body
request_trailer
request_complete

响应端（to_client）：

response_started
response_line
response_headers
response_body
response_trailer
response_complete

TLS 协议 ^^^

可用状态：

请求端（to_server）：

client_in_progress
client_hello_done
client_cert_done
client_handshake_done
client_finished

响应端（to_client）：

server_in_progress
server_hello
server_cert_done
server_hello_done
server_handshake_done
server_finished

SSH 协议 ^^^

可用状态参见钩子函数。

26.1.2.4. 防火墙处理流程¶

防火墙流程在检测引擎中运行，在完成数据包解码、流更新、流追踪重组和应用层解析后触发。

每个数据包首先评估 packet:filter 钩子中的规则。若裁决为 accept:hook，则继续评估 ``packet:td``（数据包威胁检测）钩子。此处的规则动作不会立即执行，可能被告警后处理（如速率过滤、阈值等）修改。

packet:filter 表的默认 drop 是 drop:packet，仅作用于当前数据包。

若数据包被标记为包含应用层更新，则继续评估 app:*:* 表。

在 app:*:* 中，每个应用层状态至少评估一次。每个状态都需要 accept:hook 才能进入下一状态。所有状态接受后，流程进入最终表 app:td``（应用层威胁检测）。``app_filter 表中的 drop 会立即执行，而 accept 取决于 app:td 表的裁决。

app:*:* 表的默认 drop 是 drop:flow，将丢弃当前数据包及该流所有未来数据包。

在 app:td 表中评估应用层威胁检测规则，drop 动作会加入告警队列。

所有表评估完成后，告警终处理按 action-order 逻辑排序威胁检测告警，最终执行 drop 或默认 accept。

26.1.2.5. 防火墙模式下的 Pass 规则¶

在 IDS/IPS 模式中，带有应用层匹配的 pass 规则会绕过该流的后续检测。在防火墙模式中，由于 pass 规则不影响防火墙规则，这种绕过不再以相同方式发生——此类流的数据包仍会调用检测引擎，但会跳过 packet_td 和 app_td 表。