Project

General

Profile

Actions
Copy link

Feature #7704

open
VJ YD

firewall: allow single packet rule to accept tcp connection

Feature #7704: firewall: allow single packet rule to accept tcp connection

Added by Victor Julien about 1 year ago. Updated about 22 hours ago.

Status:
In Review
Priority:
Normal
Assignee:
Yash Datre
Target version:
9.0.0-beta1
Effort:
Difficulty:
Label:

Description

The idea here is to allow a single rule to express:
- accept:hook
- directionality of connection initiator
- tcp state (3whs, established, etc)
- match opposing side as well

Currently we can have

accept:hook tcp:all $HOME_NET any <> ... 22 (flow:not_established;)
accept:hook tcp:all $HOME_NET any <> ... 22 (flow:established;)
But this doesn't enforce the direction of the 3whs.

One can also create a more complex ruleset like

accept:hook tcp:all $HOME_NET any -> any 22 (flags:S;)
accept:hook tcp:all any 22 -> $HOME_NET any (flags:SA;)
accept:hook tcp:all $HOME_NET any -> any 22 (flags:A; flow:not_established;)
accept:hook tcp:all $HOME_NET any <> any 22 (flow:established;)

The idea is to allow proper TCP setup, directionality, bidirectionality, all in one rule. E.g. something like:

accept:hook tcp:all $HOME_NET any \
     => \ # <- similar to txdir
     any 22 \
     (tcp.session:setup,established;) # < allow 3whs, tfo, etc.

Related issues 2 (2 open — 0 closed)

Related to Suricata - Feature #7705: firewall: allow single rule to accept protocol detection in progress and the final protocolIn ReviewYash DatreActions
Blocks Suricata - Story #7583: 9.0.0: usecase: improve firewall usecaseAssignedVictor JulienActions

VJ Updated by Victor Julien about 1 year ago Actions
Copy link
 #1

  • Related to Feature #7705: firewall: allow single rule to accept protocol detection in progress and the final protocol added

JL Updated by Jamie Lavigne about 1 year ago Actions
Copy link
 #2

The idea behind this one is to statefully accept the flow at layer 3/4 with a single directional rule, but not quite accept:flow because the app-layer rules still need to be applied. I picture something similar to ip-only rules on the IDS side that statefully associate and allow connections to be initiated in one direction only and automatically apply to the response side of the connection too.

VJ Updated by Victor Julien 11 months ago Actions
Copy link
 #3

  • Blocks Story #7583: 9.0.0: usecase: improve firewall usecase added

VJ Updated by Victor Julien about 1 month ago Actions
Copy link
 #4

  • Target version changed from TBD to 9.0.0-beta1

I think the main check here would actually just be that we rely on the stream engine to properly track the TCP session setup and the whole state progression. So I suppose we'd want something quite simple, like

accept:hook tcp:all $HOME_NET any => any 22 (tcp.stream:!error;)
accept:hook tcp:all $HOME_NET any => any 22 (tcp.stream:accepted;)

If we look at something like iptables, we see most ruleset accept NEW,ESTABLISHED and drop INVALID in ctstate. If we'd mimic that, it look like this:

accept:hook tcp:all $HOME_NET any => any 22 (tcp.stream-state:new,established;)
drop:packet tcp:all $HOME_NET any => any 22 (tcp.stream-state:invalid;)

More detailed matching would then still happen with actual flags checks and detailed TCP state as well, but for most cases this will likely be enough.

YD Updated by Yash Datre 11 days ago Actions
Copy link
 #6

Created a new PR as I accidentally closed the old one: https://github.com/OISF/suricata/pull/15714

LS Updated by Lukas Sismis about 23 hours ago Actions
Copy link
 #7

  • Status changed from Feedback to In Review

LS Updated by Lukas Sismis about 22 hours ago Actions
Copy link
 #8

  • Assignee changed from Victor Julien to Yash Datre
Actions
Copy link

Also available in: PDF Atom