Project

General

Profile

Actions

Feature #6063

open

exception-policy: stream async policy

Added by Victor Julien over 1 year ago. Updated 20 days ago.

Status:
Assigned
Priority:
Normal
Assignee:
Target version:
Effort:
Difficulty:
Label:

Description

For streams that are using async routing, allow applying a separate exception policy.

Async detection would match the logic the async-oneside option uses today:

Client -> Server: SYN followed by ACK matching the 3whs. SEQ of this packet would be ISN+1. If no SYN/ACK has been seen we’d be in async mode.
Server -> Client: SYN/ACK as first packet.

In both cases we'd apply a new exception policy.

Suggested defaults:
- IDS: ignore
- IPS, async-oneside disabled: drop-packet (not drop flow as otherwise an injected packet might trigger a flow drop?)
- IPS, async-oneside enabled: ignore


Subtasks 2 (1 open1 closed)

Feature #6083: exception-policy: stream async policy (6.0.x backport)RejectedActions
Feature #7443: exception-policy: stream async policy (7.0.x backport)AssignedOISF DevActions
Actions #1

Updated by Victor Julien over 1 year ago

  • Label Needs backport to 6.0 added
Actions #2

Updated by OISF Ticketbot over 1 year ago

  • Subtask #6083 added
Actions #3

Updated by OISF Ticketbot over 1 year ago

  • Label deleted (Needs backport to 6.0)
Actions #4

Updated by Victor Julien over 1 year ago

  • Target version changed from 7.0.0-rc2 to 7.0.1
Actions #5

Updated by Jamie Lavigne over 1 year ago

I am curious about this one, could you provide some additional context on how this feature works?

I assume this is related to asymmetrically routed connections (not asynchronous) but I'm interested in how suricata would distinguish those and whether this would support matching connections where the client-to-server side of the connection is seen by suricata but the server-to-client side is not (i.e. what load balancers call "DSR", direct server return).

Today the existing midstream-policy matches on connections that are asymmetrically routed in the opposite way (where suricata doesn't see the SYN) but not this one, so I'm curious if this feature is related to adding support for both directions or if it's something different.

Actions #6

Updated by Juliana Fajardini Reichow over 1 year ago

  • Target version changed from 7.0.1 to 7.0.2
Actions #7

Updated by Victor Julien over 1 year ago

  • Description updated (diff)
Actions #8

Updated by Jason Ish about 1 year ago

  • Target version changed from 7.0.2 to 7.0.3
Actions #9

Updated by Victor Julien about 1 year ago

  • Target version changed from 7.0.3 to 7.0.4
Actions #10

Updated by Victor Julien 10 months ago

  • Target version changed from 7.0.4 to 7.0.5
Actions #11

Updated by Victor Julien 9 months ago

  • Target version changed from 7.0.5 to 7.0.6
Actions #12

Updated by Victor Julien 7 months ago

  • Target version changed from 7.0.6 to 7.0.7
Actions #13

Updated by Jamie Lavigne 7 months ago

It's important for this feature to include flow logs (or similar) visibility so that users can use the source & dest IPs to track down asymmetric routes in their network when this policy is triggered. Without that visibility it will be a difficult experience to find and fix the routes.

Actions #14

Updated by Victor Julien 6 months ago

  • Assignee changed from Juliana Fajardini Reichow to OISF Dev
Actions #15

Updated by Victor Julien 5 months ago

  • Target version changed from 7.0.7 to 7.0.8
Actions #16

Updated by Victor Julien 2 months ago

  • Target version changed from 7.0.8 to 7.0.9
Actions #17

Updated by Juliana Fajardini Reichow 20 days ago

  • Target version changed from 7.0.9 to 8.0.0-beta1
  • Label Needs backport to 7.0 added

As we were lacking a ticket for master, adjusting target and label.

Was mentioned in: https://github.com/OISF/suricata/pull/12167

Actions #18

Updated by OISF Ticketbot 20 days ago

  • Subtask #7443 added
Actions #19

Updated by OISF Ticketbot 20 days ago

  • Label deleted (Needs backport to 7.0)
Actions

Also available in: Atom PDF