NEWS: Adapt for conn_id$ctx introduction

This commit is contained in:
Arne Welzel 2025-07-03 17:39:26 +02:00
parent 6eb0d4df32
commit a7bc144465

28
NEWS
View file

@ -90,15 +90,35 @@ New Functionality
@load frameworks/conn_key/vlan_fivetuple @load frameworks/conn_key/vlan_fivetuple
This results in two additional fields in the conn_id record, showing any VLAN By convention, additional fields used by alternative ConnKey implementations are
tags involved in the flow. (Accordingly, every log using conn_id reflects the added into the new ``ctx`` field of ``conn_id``. The type of ``ctx`` is ``conn_id_ctx``.
change as well as these fields have the ``&log`` attribute.)
The ``vlan_fivetuple`` script adds two additional fields to the ``conn_id_ctx``
record type, representing any VLAN tags involved. Accordingly, every log
using ``conn_id`` reflects the change as well as ``ctx`` and the VLAN fields have
the ``&log`` attribute. The columns used for logging will be named ``id.ctx.vlan``
and ``id.ctx.inner_vlan``.
This feature does not automatically provide a notion of endpoint that This feature does not automatically provide a notion of endpoint that
corresponds with the effective flow tuple. For example, applications tracking corresponds with the effective connection tuple. For example, applications tracking
endpoints by IP address do not somehow become VLAN-aware when enabling endpoints by IP address do not somehow become VLAN-aware when enabling
VLAN-aware tracking. VLAN-aware tracking.
Users may experiment with their own notion of endpoint by combining the ``orig_h``
or ``resp_h`` field of ``conn_id`` with the new ``ctx`` field. For example, tracking
the number of connections from a given host in a VLAN-aware fashion can be done
as follows:
global connection_counts: table[conn_id_ctx, addr] of count &default=0;
event new_connection(c: connection) {
++connection_counts[c$id$ctx, c$id$orig_h];
}
Note that this script snippet isn't VLAN-specific, yet it is VLAN-aware if the
``vlan_fivetuple`` script is loaded. In future Zeek versions, this pattern is
likely to be used to adapt base and policy scripts for more "context awareness".
Users may add their own plugins (for example via a zkg package) to provide Users may add their own plugins (for example via a zkg package) to provide
alternative implementations. This involves implementing a factory for alternative implementations. This involves implementing a factory for
connection "keys" that factor in additional flow information. See the VLAN connection "keys" that factor in additional flow information. See the VLAN