Network Fields

network.application

A name given to an application level protocol. This can be arbitrarily assigned for things like microservices, but also apply to things like skype, icq, facebook, twitter. This would be used in situations where the vendor or service can be decoded such as from the source/dest IP owners, ports, or wire format.

The field value must be normalized to lowercase for querying. See the documentation section "Implementing ECS".

type: keyword

example: aim

extended

network.bytes

Total bytes transferred in both directions.

If source.bytes and destination.bytes are known, network.bytes is their sum.

type: long

example: 368

core

network.community_id

A hash of source and destination IPs and ports, as well as the protocol used in a communication. This is a tool-agnostic standard to identify flows.

Learn more at https://github.com/corelight/community-id-spec.

type: keyword

example: 1:hO+sN4H+MG5MY/8hIrXPqc4ZQz0=

extended

network.direction

Direction of the network traffic.

Recommended values are:

* ingress

* egress

* inbound

* outbound

* internal

* external

* unknown

When mapping events from a host-based monitoring context, populate this field from the host’s point of view, using the values "ingress" or "egress".

When mapping events from a network or perimeter-based monitoring context, populate this field from the point of view of the network perimeter, using the values "inbound", "outbound", "internal" or "external".

Note that "internal" is not crossing perimeter boundaries, and is meant to describe communication between two hosts within the perimeter. Note also that "external" is meant to describe traffic between two hosts that are external to the perimeter. This could for example be useful for ISPs or VPN service providers.

type: keyword

example: inbound

core

network.forwarded_ip

Host IP address when the source IP address is the proxy.

type: ip

example: 192.1.1.2

core

network.iana_number

IANA Protocol Number (https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml). Standardized list of protocols. This aligns well with NetFlow and sFlow related logs which use the IANA Protocol Number.

type: keyword

example: 6

extended

network.inner

Network.inner fields are added in addition to network.vlan fields to describe the innermost VLAN when q-in-q VLAN tagging is present. Allowed fields include vlan.id and vlan.name. Inner vlan fields are typically used when sending traffic with multiple 802.1q encapsulations to a network sensor (e.g. Zeek, Wireshark.)

type: object

extended

network.name

Name given by operators to sections of their network.

type: keyword

example: Guest Wifi

extended

network.packets

Total packets transferred in both directions.

If source.packets and destination.packets are known, network.packets is their sum.

type: long

example: 24

core

network.protocol

L7 Network protocol name. ex. http, lumberjack, transport protocol.

The field value must be normalized to lowercase for querying. See the documentation section "Implementing ECS".

type: keyword

example: http

core

network.transport

Same as network.iana_number, but instead using the Keyword name of the transport layer (udp, tcp, ipv6-icmp, etc.)

The field value must be normalized to lowercase for querying. See the documentation section "Implementing ECS".

type: keyword

example: tcp

core

network.type

In the OSI Model this would be the Network Layer. ipv4, ipv6, ipsec, pim, etc

The field value must be normalized to lowercase for querying. See the documentation section "Implementing ECS".

type: keyword

example: ipv4

core

vlan

network.inner.vlan.*

Fields to describe observed VLAN information.

vlan

network.vlan.*

Fields to describe observed VLAN information.