Bug #8444
openfirewall: accept:flow at app-layer hook bypasses app:td (IDS/IPS) evaluation
Description
When a firewall rule uses accept:flow at an app-layer hook, the IDS/IPS threat detection table ( app:td ) is not evaluated for that flow. IDS rules that would otherwise match the accepted traffic are silently skipped.
Reproduction: A TLS firewall ruleset with accept:flow at tls:client_hello_done and a TD rule matching tls.cert_subject on the server certificate. The TD rule never fires.
Firewall rules:
accept:hook tcp:all $HOME_NET any <> $EXTERNAL_NET any (flow:not_established; sid:1000;) accept:hook tcp:all $HOME_NET any <> $EXTERNAL_NET any (flow:established; sid:1001;) accept:hook tls:client_in_progress $HOME_NET any -> $EXTERNAL_NET any (sid:1002;) accept:flow tls:client_hello_done $HOME_NET any -> $EXTERNAL_NET any (tls.sni; content:"www.google.com"; sid:1003;) accept:hook tls:client_cert_done $HOME_NET any -> $EXTERNAL_NET any (sid:1004;) accept:hook tls:client_handshake_done $HOME_NET any -> $EXTERNAL_NET any (sid:1005;) accept:hook tls:client_finished $HOME_NET any -> $EXTERNAL_NET any (sid:1006;) accept:hook tls:server_in_progress $EXTERNAL_NET any -> $HOME_NET any (sid:1007;) accept:hook tls:server_hello $EXTERNAL_NET any -> $HOME_NET any (sid:1008;) accept:hook tls:server_cert_done $EXTERNAL_NET any -> $HOME_NET any (sid:1009;) accept:hook tls:server_hello_done $EXTERNAL_NET any -> $HOME_NET any (sid:1010;) accept:hook tls:server_handshake_done $EXTERNAL_NET any -> $HOME_NET any (sid:1011;) accept:hook tls:server_finished $EXTERNAL_NET any -> $HOME_NET any (sid:1012;)
TD rule:
alert tls any any -> any any (tls.cert_subject; content:"CN=www.google.com"; msg:"TD: server cert seen"; sid:9001;)
Expected: sid:9001 fires (TD evaluates accepted traffic).
Actual: sid:9001 does not fire. Only sid:1003 (the firewall rule) fires.
The pipeline documentation states that after all app-layer states are accepted, the pipeline moves to app:td. With accept:hook at every state, TD rules fire correctly. But accept:flow at any app-layer hook causes the entire app:td evaluation to be skipped for that flow.
Note: accept:tx does not have this issue — TD rules evaluate correctly after accept:tx. The issue is specific to accept:flow (and likely accept:packet) at app-layer hooks.
Files
VJ Updated by Victor Julien 27 days ago
I think this works as designed. accept:packet is meant to immediately accept the packet. accept:flow is essentially accept:packet applied to the current and all future packets in this flow.
If it is needed to create something to address this specific case we can look into that, but at least for for TLS the whole session is a tx so accept:tx should work.
Docs should clearly reflect what the scope of the accept is, will look at improving that.
VJ Updated by Victor Julien 26 days ago
- Related to Feature #7697: firewall: allow request/response action scopes added
VJ Updated by Victor Julien 18 days ago
- File clipboard-202604101546-jnm2l.png clipboard-202604101546-jnm2l.png added
- File clipboard-202604101548-rdtrr.png clipboard-202604101548-rdtrr.png added
After some offline discussion, I think the consensus is that the current behavior isn't intuitive.
I've mapped the current behavior
The following suggests to change accept:packet and accept:flow, and introduce new options to still support the existing behavior under a new name
@yashda@amazon.com does this make sense to you?
AP Updated by Aneesh Patel 14 days ago
This makes sense and aligns with our vision - adding pass_packet and pass_flow as specific configs to completely bypass IPS while leaving packet/flow to still go to IPS was the behavior we were hoping for. The accept:request and accept:response are also aligned. Our intention is also to be able to use these additions as default actions in relation to this redmine - https://redmine.openinfosecfoundation.org/issues/7701
Thank you for the deep dive here!
AP Updated by Aneesh Patel 14 days ago
It also would be useful to add an alert action that would essentially be equivalent to an accept rule with an alert keyword - this would tie in well with the ask we have for the default configs in the redmine I linked above
JI Updated by Jason Ish 12 days ago
- Related to Feature #8480: firewall: allow specifying multiple actions added