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 2 months 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 2 months ago
- Related to Feature #7697: firewall: allow request/response action scopes added
VJ Updated by Victor Julien 2 months 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 about 2 months 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 about 2 months 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 about 2 months ago
- Related to Feature #8480: firewall: allow specifying multiple actions added
VJ Updated by Victor Julien about 1 month ago
- Status changed from New to In Progress
- Assignee set to Victor Julien
- Target version changed from TBD to 9.0.0-beta1
VJ Updated by Victor Julien about 1 month ago
- Status changed from In Progress to In Review
VJ Updated by Victor Julien 26 days ago
- Status changed from In Review to Resolved
VJ Updated by Victor Julien 25 days ago
- Label Needs backport to 8.0 added
OT Updated by OISF Ticketbot 25 days ago
- Subtask #8573 added
OT Updated by OISF Ticketbot 25 days ago
- Label deleted (
Needs backport to 8.0)
JL Updated by Jamie Lavigne 8 days ago
Do these new pass:packet and pass:flow actions in firewall rules introduce the possibility of partially or asymmetrically forwarding connections to the TD stage? If so what happens there? Can TD quietly fail due to not observing enough of the connection, or can it then be subject to the midstream policy?