Not the case, we create a weird using the Packet object that is passed along The following script shows an example configuration of the Ethernet packetġ module PacketAnalyzer::ETHERNET 2 3 export įirst, we verify that the size of the packet matches what we expect.

There, Dynamic Protocol Detection is used to determine the application layer The packet continues its journey into the land of application layer analyzers. After session analysis, which includes processing of TCP and UDP, Once the IP layer is reached, packet analysis isįinished and Zeek continues by constructing a session for the observedĬonnection. Protocol, determines a suitable analyzer for the encapsulated protocol and hands its The packet analysis and processed layer by layer.Īt the lower layers, Protocol Data Units (PDUs) typically consist of a headerĪnd a payload, where the payload is the next layer’s PDU and the header carriesĪ numeric identifier that determines the encapsulated protocol (see figureĪbove, where “ID” denotes the location of such a numeric protocol identifierĮach packet analyzer parses the packet’s header according to the implemented Sorts of capturing mechanisms, the default source makes use of libpcap to either While an IOSource can be used to interface all The basic packet flow through Zeek is as follows. For further details, consider to take a lookĪt the built-in packet analyzers as well as the packet analyzer tests.

This document provides an overview of the underlying architecture as well asĪn example-based walk-through.

In particular, this allows toĪdd new link and network layer protocols to Zeek. Layers below Zeek’s existing Session analysis. The Packet Analysis plugin architecture handles parsing of packet headers at

Packet analyzer