Feature #7674: source/tunnels: config option to distinguish tunnels - Suricata - Open Information Security Foundation

Actions

Copy link

Feature #7674

open

source/tunnels: config option to distinguish tunnels

Added by Philippe Antoine about 1 month ago. Updated 1 day ago.

Status:

In Review

Priority:

Normal

Assignee:

Philippe Antoine

Target version:

9.0.0-beta1

Effort:

Difficulty:

Label:

Description

The ebpf xdp_filter.c program does not handle encapsulated flows (with erspan, VXLAN, or some other tunnel)
But it could.

Even if it does, Suricata AFPXDPBypassCallback checks PacketIsTunnel and falls back to local bypass in this case

The feature request here is to

Have config options for which kinds of tunnels AFPXDPBypassCallback can handle
have the example xdp_filter.c handle these

Some other improvements to xdp_filter.c will be proposed : ARP bypass, and tunnel stripping ( related to https://github.com/OISF/suricata/pull/11472 )

Related issues 1 (1 open — 0 closed)

Actions

Copy link

Updated by Philippe Antoine 14 days ago

Subject changed from xdp: possibility to bypass encapsulated flows to source/tunnels: config option to distinguish tunnels

This means adding a tunnel identifier based on suricata.yaml configuration which will define these tunnels (packet sources)

The use case is when the network stream to be monitored is brought to Suricata using one or more tunnels (GRE, VXLAN, ...).

Suricata.yaml could look like

capture-tunnels:
  - id: 1
    type: erspan
    src: 192.168.1.1
    dst: 192.168.1.3
    session: 123
  - id: 2
    type: vxlan
    src: 192.168.1.2
    dst: 192.168.1.3
    session: 42

Then a ping from 192.168.5.6 -> 192.168.5.7 in tunnel 1, and one ping from 192.168.5.6 -> 192.168.5.7 in tunnel 2 will not be the same flow ! (and not the same as the same not encapsulated ping)

Adding this feature will lead to other possible implementable stuff :
- we will be able to bypass at XDP level the encapsulated flows while taking care that one encapsulated flow in tunnel 1 is not mistaken in another same-looking encapsulated flow in tunnel 2
- we could also use this tunnel identifier as a multi-tenant selector
- a config option could be used to skip the traffic that is not part of the defined tunnels

Actions

Copy link