防火墙模式设计 ==================== .. note:: 在 Suricata 8 中防火墙模式属于实验性功能，后续可能变更。 Suricata 的防火墙模式允许使用与默认"威胁检测"规则集具有不同特性的规则集： 1. 默认策略为 ``drop``，意味着防火墙规则集需要明确指定允许的内容 2. 防火墙规则从独立文件加载 3. 防火墙规则使用新动作 ``accept`` 4. 防火墙规则必须使用显式的动作作用域和规则钩子（见下文） 5. 按协议状态严格遵循文件中的规则顺序进行评估 核心概念 -------- * ``table`` 具有不同属性的规则集合：``packet:filter``, ``packet:td``, ``app::``, ``app:td``。这些是内置表，不支持创建自定义表。 * ``state`` 控制规则评估的特定协议状态。例如 ``tcp.flow_start`` 或 ``tls.client_body_done``。 应用层表按应用层协议和协议状态划分。例如 ``app:http:request_line``。 动作与作用域 ------------------------- 防火墙规则要求显式指定动作作用域。 accept ~~~~~~ ``accept`` 用于对数据包、流或钩子做出允许裁决： * ``packet`` 允许当前数据包 * ``flow`` 允许该流的所有后续数据包 * ``hook`` 允许当前钩子/状态的规则，继续评估后续表 * ``tx`` 允许当前事务的规则，继续评估后续表 ``accept`` 动作仅适用于防火墙规则。 .. note:: 部分协议实现（如 ``dns``）每个方向使用独立事务。对于这些协议，``accept:tx`` 仅允许该方向的数据包。 drop ~~~~ ``drop`` 用于丢弃数据包或流： * ``packet`` 直接丢弃当前数据包，不再评估其他规则 * ``flow`` 丢弃当前数据包（同 ``packet``）并丢弃该流所有未来数据包 .. note:: 由于与威胁检测规则的现有语义存在歧义，防火墙规则中不可用 ``pass`` 动作。 显式规则钩子（状态） ~~~~~~~~~~~~~~~~~~~~~~~~~~~ 常规 IDS/IPS 规则中，引擎通过规则的匹配逻辑推断规则应"挂钩"到引擎的位置。虽然这对检测类规则有效，但会导致许多防火墙规则集不可接受的边缘情况。因此防火墙规则必须显式设置钩子。 这通过规则的协议字段实现。威胁检测规则可能形如:: alert http ... http.uri; ... 而防火墙规则则为:: accept:hook http1:request_line ... http.uri; ... 应用层状态/钩子按协议定义。每个钩子都有其默认-``drop`` 策略，因此规则集需要为每个状态提供 ``accept`` 规则以允许流量通过。 通用状态 ^^^^^^^ 每个协议至少包含以下默认状态： 请求端（``to_server``）： * ``request_started`` * ``request_complete`` 响应端（``to_client``）： * ``response_started`` * ``response_complete`` 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 协议 ^^^ 可用状态参见 :ref:`ssh-hooks`。 防火墙处理流程 ~~~~~~~~~~~~~~~~~ 防火墙流程在检测引擎中运行，在完成数据包解码、流更新、流追踪重组和应用层解析后触发。 每个数据包首先评估 ``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``。 .. image:: fw-pipeline.png 防火墙模式下的 Pass 规则 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 在 IDS/IPS 模式中，带有应用层匹配的 ``pass`` 规则会绕过该流的后续检测。在防火墙模式中，由于 ``pass`` 规则不影响防火墙规则，这种绕过不再以相同方式发生——此类流的数据包仍会调用检测引擎，但会跳过 ``packet_td`` 和 ``app_td`` 表。