Когда речь заходит о хранении и анализе сетевого трафика в голове сразу возникают ассоциации с такими инструментами как tcpdump и Wireshark. На ресурсе конечно же есть статьи, посвященные работе с ними, но о формате файла, в который помещается захваченный трафик, ничего не написано. Попробую немного закрыть это упущение и в доступной форме рассказать о «новом» поколении открытого формата дампа сетевого трафика pcap (Packet CAPture), который называется pcapng (pcap Next Generation).

Пусть вас не смущает название статьи - никакого тихого и незаметного перехода пока вы спали на новый формат не произошло. Большинство известных открытых приложений - tshark, Wireshark и другие, использующие библиотеку pcap/libpcap/npcap/winpcap инструменты (scapy, pyshark), уже давно умеют работать с форматом pcapng. Поэтому новым его можно назвать с очень большой натяжкой. Хотя, тот же Tcpdump по умолчанию пишет еще в старый формат, а с новым может работать только если тот, соответствует некоторым требованиям.

История формата неразрывно связана с tcpdump/libpcap, которые впервые были созданы в 1987 Ваном Якобсоном (Van Jacobson), а сообщество вокруг них образовалось около 1998 года. В 2005 году был впервые опубликован формат pcap, а в 2009 увидело свет его новое поколение - формат pcapng. Но несмотря на свою долгую историю этот формат так и не стал RFC. Возможно, по причине того, что он заложник своей популярности и открытости, в связи с чем ему приходится обеспечивать обратную совместимость (сохранение блоков старой структуры, сложность отказа от собственных форматов канального уровня в пользу форматов IANA и др.).

Сейчас pcapng опубликован в виде интернет-черновика (Internet Draft, I-D) draft-tuexen-opsawg-pcapng-04. Дата последней публикации — октябрь текущего года. Интернет-черновики являются рабочими документами IETF, публикуются тут и пока не являются стандартами (и могут никогда ими и не стать).

Как видно из названия, это уже четвертая версия формата (первая версия в виде интернет-черновика появилась в 2014 году). Срок истечения действия текущего черновика — 7 апреля 2022 года. Далее он скорее всего будет продлен, возможно с небольшими дополнениями. Возможно, когда-нибудь он станет стандартом.

Эта статья не является переводом интернет-черновика, но вполне естественно, что вся основная информация взята из первоисточника. Цель статьи — в простой форме (возможно даже где-то и в умышленно упрощенной) познакомить читателей с форматом хранения дампа сетевого трафика, который де-факто уже около 15 лет является стандартом в мире открытого программного обеспечения.

Общая структура формата

Pcapng — это бинарный формат. Каждый pcapng-файл состоит из блоков, которые последовательно состыковываются друг с другом как кубики конструктора LEGO. Это позволяет конкатенировать различные блоки даже если они были записаны не последовательно, а, например, спустя какое-то время или с разных интерфейсов одной машины. Все блоки этого конструктора имеют одинаковую общую структуру, но как и цветные элементы LEGO в зависимости он назначения, могут быть разных типов. Так, каждый блок всегда состоит из четырех обязательных элементов:

• тип блока

• размер блока

• тело блока

• размер блока (повторно)

«Размер блока» указывается два раза для того, чтобы в процессе разбора двигаться по pcapng-файлу можно было в разных направлениях: не только по-блочно от начала в конец, но и наоборот. «Тип» и «тело блока» как раз и определяют его назначение, но об этом чуть далее. Для полей «типа блока» и его «размера» отведено по 4 байта. Тело блока ограничено только максимальным размером, которое может быть указано в поле «размер блока», при этом оно должно быть выровнено по ширине 32 бита, а неиспользованные позиции заполонены 0x0.

Например, взгляните на начало тестового pcapng-файла (файл взят отсюда):

Как и говорилось, файл состоит из последовательности блоков, отличающихся начальным кодом и размером. Зная это, можно накидать на коленке простейший парсер pcapng-файла на pythone (capinfos на минималках):

from pathlib import Path 
 
byteorder = 'little' #'big' 
data = Path('/home/user/test_2').read_bytes()
seek = 0

while seek < len(data):
     block_size = int.from_bytes(data[seek + 4:seek + 8], byteorder)
     block_kod  = '0x' + hex(int.from_bytes(data[seek:seek + 4], byteorder))[2:].zfill(8)
     block_data = data[seek + 8:seek + block_size - 8]
     print("\tKOD: {}\n\tSIZE: {}\n\tDATA: {}\n".format(block_kod,int(block_size/8),block_data))
     seek+= block_size

Здесь использован порядок следования байтов little-endian. Но так как pcapng-файлы могут создаваться на различных машинах, то и порядок следования байтов может зависеть от архитектуры этих машин. Для того, чтобы иметь возможность различать и обрабатывать такие файлы в самом первом блоке указывается порядок следования байтов. Как будет описано далее, таких «первых блоков» в одном файле может быть несколько, а значит и порядок следования байтов в рамках одного файла может различаться.

Также следует сказать про выравнивание, ориентированное на эффективную реализацию операций чтения/записи порций данных с диска. В зависимости от типа блока используется в основном 32-битное выравнивание, реже - 16-битное. Это, кстати, очень удобно для визуального представления, чем я и воспользовался. Поэтому далее на рисунках один прямоугольник будет обозначать 4 байта, а его половинка — 2 байта. Других размеров не предусмотрено. 64-битное выравнивание не используется.

В приведенном примере присутствуют блоки с кодами 0a0d0d0a,01000000,06000000 и 05000000, но на самом деле их состав немного шире. Дальнейший материал как раз и раскрывает их назначение и индивидуальную структуру. Но прежде, чем переходить к их рассмотрению необходимо окончательно понять как все блоки взаимосвязаны, в каком порядке должны располагаться. Для этого перечислю наиболее важные из них, пока не раскрывая их внутренней структуры.

Наиболее важные блоки:

• 0x0a0d0d0a - (SHB, Section Header Block) блок секции заголовка

• 0x00000001 - (IDB, Interface Description Block) блок описания интерфейса

• 0x00000003 - (SPB, Simple Packet Block) упрощенный блок пакетов данных

• 0x00000004 - (NRB, Name Resolution Block) блок разрешения имен

• 0x00000005 - (ISB, Interface Statistics Block) блок статистики интерфейса

• 0x00000006 - (EPB, Enhanced Packet Block) улучшенный блок описания данных

• 0x0000000А - (DSB, Decryption Secrets Block) блок расшифровки данных

Экспериментальные, устаревшие и зарезервированные блоки:

• (CB, Compression Block) - блок сжатия информации

• (SB, Event/Security Blocks) - блок событий безопасности

• 0x00000002 - (PB, Packet Block) устаревший блок пакетов данных pcap

• 0x000000BAD или 0x040000BAD - (CB, Custom Block) нестандартный блок

• Traffic Statistics and Monitoring Blocks - блок сетевой статистики

• Fixed Length Block - блок фиксированной длинны

• Directory Block и др.

Если у вас есть предложения по дополнению черновика новыми типами блоков — создавайте pull request в репозитарий github.com/pcapng/.

Минимальное требование к pcapng-файлу - наличие первым по порядку заголовочного блока SHB. В этом блоке задаются общие характеристики pcapng-файла (в том числе и порядок следования байтов). Наличие остальных блоков не является обязательным, но, конечно же, без блоков с пакетами сетевых данных сам по себе файл теряет смысл.

Три типа блоков (SPB, EBP и PB) как раз и предназначены для хранения одного пакета данных или их порций. PB - устарел и используется только для обратной совместимости со старым форматом хранения данных - pcap. А различие между SPB и EBP заключается в том, что первый из них хранит упрощенную информацию о пакетах (Simple), тогда как второй - расширенные сведения (Enhanced).

В любом случае, если в файле был использован один из этих трех пакетов, то перед ними обязательно должен размещаться блок с описанием интерфейса, с которого был захвачен трафик - IDB. Наличие блока IDB также необходимо, если в файле был использован блок статистики интерфейса ISB, в котором отражаются общие сведения об общем числе обработанных пакетов, количестве потерянных пакетов и т.д.

Блок разрешения имен NRB сопоставляет IP-адреса, использованные в пакетах, с их каноническими именами.

Таким образом минимальный осмысленный pcapng-файл - это файл с последовательно расположенными SHB, IDB и SPB блоками.

В каждом файле может присутствовать несколько заголовочных блоков SHB, но вся информация, следующая после одного из них относится только к нему до тех пор, пока не будет встречен другой блок SHB или конец файла. Поэтому правильнее сказать, что не SHB блоки в одном файле могут встречаться несколько раз, а несколько pcapng-файлов могут быть соединены друг с другом (со старым типом файла pcap так делать было нельзя).

Из не очевидного следует еще отметить, что следующие после IDB блоки с пакетами не относятся непосредственно к этому IDB, они могут содержать в себе также информацию и других, определенных ранее интерфейсов (конечно же, в рамках одного SHB). Поэтому, например, если имеется четыре интерфейса, то можно сразу последовательно включить четыре блока IDB, а далее блоки EBP даже, если данные захватывались только с одного из этих интерфейсов.

Без подробного разъяснения того, как формируются каждый из блоков сложно переставить себе порядок из компоновки. Но пока достаточно запомнить, что три блока составляют основу всего построения, а остальные блоки являются поясняющими, уточняющими и необязательными. Для закрепления, вот картинка с кубиками LEGO (блоками).

Кроме того, что все блоки имеют одинаковую общую структуру («код» - «размер» - «тело блока» - «размер»), каждый из блоков в секции «тело блока» может состоять еще из двух частей: специфичная для блока информация и часть с опциональными полями. Первая часть будет описана позже. Вторая часть - содержимое опциональных полей - не имеет прямого отношения к процессу захвата трафика, но может содержать различные уточняющие опции, комментарии, стеганографию и т.д., в том числе и критичную информацию, которой вы возможно не хотели делиться, отправляя свой дамп на анализ в стороннюю организацию.

Опциональные поля размещаются внутри «тела блока» после специфичных полей каждого из блоков (о которых я еще ничего не говорил, они будут описаны далее). У каждого блока имеются свой набор опциональных полей, но черновиком заданы три типа опциональных полей, общие для любого блока:

• конец блока опциональных полей

• комментарий

• зарезервированные поля

Первый из них - служебный. Он всегда должен располагаться последним в теле блока, если, конечно, в блоке вообще были представлены опциональные поля. Назначение полей комментариев очевидно. Последний тип полей закреплен за различными организациями.

Например, в tshark в с помощью опции --capture-comment в выходной файл будут добавлены комментарии как раз в виде опции.

Разрешено использовать опции для комментариев в любом блоке. Можно указать комментарий вплоть для пакета с отметкой, что это именно тот самый пакет, на который нужно обратить внимание.

Для задания опциональных полей используется тройка «код»- «размер»-«значение». Некоторые поля одного типа могут повторяться, а некоторые должны встречаться только один раз (например, IP-адрес для одного и того же интерфейса может быть и не один). «Код» - это двух-байтовый код опции, уникальный только в рамках своего блока. «Размер» -это двухбайтовое беззнаковое целое число, описывающее размер следующего за ним значения (без учета выравнивания). «Значение» опции - это непосредственно само значение опции, выровненное по размеру 32 бита. У специального опционального поля «конец блока опциональных полей» значение размера должно задаваться нулем, а значение опции вообще не указывается.

Полная таблица со всеми опциональными полями и привязкой к блокам приведена в конце статьи (спрятана под спойлер), а до этого будут лишь описываться наиболее интересные опциональные поля каждого из блоков. Еще раз напомню, что наличие опциональных полей не является обязательным и разработчик программного обеспечения для захвата трафика самостоятельно решает использовать их или нет, а также какую информацию туда помещать.

Теперь, получив общее представление о структуре pcapng-файла, можно познакомиться отдельно с каждым из его основных блоков.

0x0a0d0d0a SHB

Главный блок данных в pcapng-файле. Он не несет информации о захватываемом трафике. Его главная роль - обозначить точку начала процесса захвата трафика для следующих за ним блоков интерфейсов и пакетов. Структура блока:

Четыре поля из этого списка нам уже знакомы - «код» блока, «тело блока», дважды «размер блока» и опциональные поля. Здесь и далее я повторно их описывать не буду.

Если вы не обратили на это внимания ранее, то заметно, что в отличии от других блоков, номера которых перечислены относительно последовательно, этот блок имеет странный код типа - 0a0d0d0a (или в виде ASCII строки \n\r\r\n). Это сделано в следующих целях:

• для выявления потенциальных ошибок, которые могут возникать при неправильной передаче файла в ввиде текста по протоколу FTP или HTTP. В таких случаях строка \n\r\r\n будет искажена

• для однозначного определения типа файла в различных архитектурах (с различным порядком следования байтов), ведь код 0a0d0d0a одинаков для обоих порядков следования байтов

Магическое число 0x1A2B3C4D (32 бита) служит для определения порядка следования байтов, и, кроме того, исторически используется для определения файлов типа pcap. Хотя это и более актуально для Linux, так как в Windows тип файлов часто определяется их расширением. Все это создает небольшую путаницу, когда на выходе получается файл с расширением *.pcap, но по внутренней структуре это pcapng.

Следующие два поля (по 16 бит) определяют мажорную и минорную версию формата. В настоящий момент это версия 1.0. Но не забывайте, что после 22 апреля 2022 года (время очередного обновления интернет-черновика) все может поменяться.

Поле размера секции (64 бита) может задавать размер данных, относящихся к текущему SHB (исключая его самого). Но может и не задавать, и тогда его значение должно быть 0xFFFFFFFFFFFFFFFF. Задача этого поля - ускорение парсинга файла, состоящего из нескольких секций SHB, за счет пропуска этих секций при необходимости (например, если его мажорная или минорная версии не поддерживаются парсером). Но если это поле не задано, то единственная возможность распарсить файл — пройтись по всем составляющим его блокам.

В дополнение к общим опциональным полям для блока SHB определены дополнительные опциональные поля, описывающая «железо», операционную систему и приложение, с помощью которого был записан файл.

0x00000001 IDB

Этот блок описывает интерфейс, с использованием которого был захвачен трафик. Для одного интерфейса - один блок IDB .Каждому интерфейсу сопоставляется уникальный 32- битный код, начиная с 0 и увеличивается на 1 для каждого нового интерфейса. Далее этот код используется в других блоках, где имеется привязка к интерфейсу. Уникальный код уникален только в рамках текущего SHB. Важно отметить, что присвоенный код нигде в этом блоке не записывается. Он именно «сопоставляется» по порядку начиная с 0.

Т.е., самый первый блок IDB, описывающий некий интерфейс, «получает» код 0, следующий блок - 1 и т.д. В блоках PS под кодом 0x00000000 как раз и будет пониматься интерфейс, описанный в самом первом блоке IDB. К примеру, обратите внимание на четвертый или восьмой блоки первого рисунка — это блоки с пакетами данных, о структуре которых я расскажу чуть далее. Сразу за кодом блока (4 байта) и его размером (4 байта) идет 4-байтная величина 0x00000000, которая и говорит, что содержимое этого пакета было захвачено с интерфейса № «0», описанного во втором блоке (следует после SHB) потому, что среди блоков с интерфейсами (а их тут всего два — второй и третий) он идет в файле первым по порядку.

Структура блока:

Как и ранее, большинство полей уже знакомы или очевидны. Новые только поля: «тип канала» (извините за такой перевод слов link-type, но мне так нравится) и «максимальный размер пакета» в байтах, используемый в пакетах. Наиболее интересный - первый.

Именно это поле раскрывает понимание того, что же за пакеты такие захватываются (Packet CAPture): кадры, фреймы, пакеты... Перечень форматов кадров канального уровня приведен на сайте tcpdump по адресу.

Блок IDB содержит 16 опциональных полей, позволяющих описать различные свойства интерфейса: наименование интерфейса, IP-адреса интерфейса, MAC-адрес интерфейса, Interface Hardware EUI address, опции фильтрации, скоростные характеристики интерфейса, операционная система, производитель и др. Важным опциональным полем является «временное разрешение», используемое во временных отметках пакетов (задается в tcpdump опцией --time-stamp-precision). Но оно будет описано чуть позже, кода дойдем до блока EPB, там, где это разрешение используется.

0x00000003 SPB

Вообще, сбор и хранение полного дампа сетевой активности очень затратная операция: как с точки зрения получаемого объема данных, так и сложности последующей обработки бинарных данных. Поэтому, такие средства как tcpdump и wireshark чаще используют только для отладки или же переводят средства мониторинга трафика на подробный сбор информации автоматически по срабатыванию определенных триггеров безопасности (поведенческих или признаковых). Сбор же только статистических сведений о трафике чаще осуществляется с использованием других форматов (например, NetFlow, sFlow, IPFIX, tcpflow и т.д.).

Блок SPB, простой блок, как и следует из его наименования, необходим для компактного хранения минимально необходимой для сбора трафика информации. Это может потребоваться, например, для более быстрого сбора информации или же переключение записи в блоки этого типа может произойти по причине того, что операционная система не справляется с записью полных данных в более сложный блок EPB. Таким образом, может получиться, что часть данных была сначала записана в расширенный блок EBP, а затем из-за возросшей нагрузки продолжена записываться в упрощенном виде в SPB. Кроме того, структура SPB обеспечивает хорошую степень сжатия данных на диске (до 86%).

Также SPB в целях экономии не сохраняет временные метки. В SPB отсутствуют поля, хранящие уникальный код интерфейса. Поэтому блоки SPB сопоставляются с интерфейсом, описанным в блоке IDB, который расположен непосредственно перед ним. Т.е., единовременно для одного SPB можно записывать только данные с одного интерфейса. Можно, конечно, записать данные «отложенно» и потом их дописать, но при наличии таких возможностей проще сразу воспользоваться расширенным блоком EPB.

Структура блока:

Незнакомых два поля: «оригинальный размер пакета» и «данные пакета». Первый из них содержит размер данных, полученных из сети. Эта величина не всегда может совпадать с размером поля «данные пакета». Во первых, данные перед тем как быть помещенными в пакет могли пройти предварительную обработку (очистку, сжатие, шифрование и т.д.), а во вторых - данные, поступающие из сети, могут обрезаться для размещения в пакете, что задается величиной, упомянутой ранее при описании IDB (см. «максимальный размер пакета» в байтах). Но, все же, чаще всего они эквивалентны.

Наиболее важная часть блока SPB да и всего pcapng-файла - это содержимое раздела с данными. Именно там сохраняются все захватываемые данные, приходящие и уходящие в сеть через интерфейс. Способ их записи, организации и хранения в этом разделе определяется полем «тип канала», указанным в IDB. Это, возможно, самая сложная часть парсинга трафика: реализация фильтрации и разбора всех возможных форматов канального уровня и вложенных более высоких уровней модели OSI.

0x00000006 EPB

Сердце всего файла. Второй по важности после SHB блок. Этот блок расширяет возможности SPB за счет дополнительных полей с временными метками и поля для хранения кода конкретного интерфейса. Цена такого расширения: он обладает более медленной скоростью захвата пакетов и занимает больше места.

Поле «Номер интерфейса» содержит 32 битный код, определенный порядком следования блоков IDB.

«Временная отметка» (64 бита) складывается из двух полей (по 32 бита каждая). Эти поля не стоит рассматривать отдельно как поле для секунд и как поле для миллисекунд. Это единое беззнаковое 64-разрядное целое число, отражающее количество отрезков времени, прошедших с 1 января 1970 года до момента захвата текущего пакета. А вот отрезки времени не обязательно должны быть секундами. Величина отрезка (его разрешение), как уже говорилось, задается в опциональном поле «временное разрешение» в блоке IDB. Почему поле, от значения которого зависит целый другой блок, попало не в основные поля, а в опциональные? Вероятнее всего, это сделано из-за того, что оно не обязательное, и может быть пропущено.

«Временное разрешение» это однобайтное число. Если старший бит установлен в 0, то величина отрезка времени рассчитывается как отрицательная степень 10 (например, для 6 это будет соответствовать 10^-6 секунд). Если старший бит установлен в 1, то отрезок времени рассчитывается как отрицательная степень 2 (например, для 10 это будет соответствовать 2^-10 секунд). Если опция не задана, то по умолчанию отрезок времени принимается равным 10^-6 секунд, что равно одной микросекунде.

Из интересных опциональных полей блока EPB следует отметить поле, содержащее хеш-сумму текущего пакета (с включенным в первом октете кодом типа алгоритма хеширования — XOR, MD-5, CRC-32, SHA-1, Toeplitz).

Через опции также возможно маркировать одинаковые пакеты на разных интерфейсах, или отмечать тот же пакет при его обратном прохождении через тот же интерфейс (что-то похожее на iptables -j MARK). Такая возможность нацелена на изучение корреляции между пакетами.

Но, пожалуй, наиболее важным опциональным полем является поле с информацией о содержимом фрейма канального уровня. Это 32-битное число с порядком следования байтов, указанным в SHB. В зависимости от задействованного бита это поле может указывать о том, что текущий кадр является входящим или исходящим; unicast, multicast или broadcast-кадром; а также указывать на различные ошибки канального уровня (в составе и размере полей фрейма, ошибки контрольной суммы и других ошибках).

0x00000004 NRB

Необязательный блок разрешения имен позволяет сопоставлять IP-адреса, использованные в пакетах, с их каноническими именами. Этот блок необходим в тех случаях, когда для анализа требуются именно те канонические имена, которые были получены машиной во время формирования дампа. Ведь, если извлечь эти IP-адреса из блоков пакетов данных спустя некоторое время и воспользоваться DNS-серверами, которые имеются в доступе у машины на которой происходит анализ дампа, то их ответы могут отличаться (или из-за устаревания самих адресов, или из-за использования отличных DNS-серверов). Особенно это актуально, если анализ трафика происходит спустя длительный срок (например, при расследовании какого-нибудь старого инцидента безопасности). Кроме того, это может потребоваться для анализа дампа на машине, у которой вообще отсутствует доступ в интернет.

Блок NRB может располагаться в любом месте файла. Но обычно его располагают в самом начале. Блоков NRB в одном файле файле может быть несколько. Новые блоки могут регулярно и независимо добавляться в файл (например, от систем мониторинга сети). Это также означает, что данные о разрешении имен могут дублироваться и «противоречить». Под «противоречием» я имею в виду то, что одному IP-адресу может быть сопоставлено несколько канонических имен, и наоборот — несколько различных канонических имен могут принадлежать одному адресу.

Способ формирования записей о разрешении имен аналогичен опциональным полям - это тройка «тип» - «размер» - «значение». При этом возможность использования опциональных полей также сохраняется. Опциональные поля как и ранее должны идти только после специфических данных (записях о разрешении имен).

Сигналом окончания записей о разрешении имен и о возможном начале опциональных полей является специальная запись нулевого размера с 16-битным кодом типа 0x0000. Два других типа (с кодами 0x0001 и 0x0002) определяют записи для IP-адресов 4-ой версии и 6-ой соответственно. Например, значение IPv4-адреса записывается в первые 4 октета, далее следует одна или несколько UTF-8 строк DNS-записи, оканчивающаяся ноль-терминальным символом. Других записей пока не предусмотрено. Запись окончания записей разрешения имен (с кодом 0x0000) должна присутствовать всегда, даже если до нее нет ни одного разрешения имени.

Опциональные поля позволяют сохранить имя DNS-сервера и его IPv4 или IPv6 адрес.

0x00000005 ISB

Этот блок содержит статистические сведения с привязкой к конкретному интерфейсу. Обычно он располагается в конце файла, но это не обязательное требование.

В отличие о ранее описанных блоков этот блок не содержит собственных специфических полей, все данные о статистике записывается через опциональные поля. Эти поля включают статистику о времени начала и конца сбора трафика, количестве поступивших, отклоненных и прошедших через фильтр (firewall) пакетов, отклоненных операционной системой пакетах и о доставленных до пользовательского приложения.

Все поля этого блока уже встречались ранее.

0x0000000A DSB

Этот блок относится к экспериментальным. Но мне он представляется важным и потому я его тоже опишу. С помощью информации из этого блока можно получить содержимое зашифрованного соединения, например, TLS. Блок должен располагаться перед теми блоками с пакетами трафика, где требуется расшифровка. Этот блок, конечно, не обязательно включать в состав pcapng-файла и тогда всю необходимую информацию предоставлять для анализа отдельно. Если вы используете для анализа WireShark (который начиная с версии 3.0 поддерживает поле DSB в файлах формата pcapng), то это очень неудобно каждый раз для нового файла производить настройку приложения, указывая ему место хранения сертификатов и другой ключевой информации. Гораздо удобнее эту информацию уже иметь включенной для каждого анализируемого файла дампа сетевого трафика. Правда с таким дампом нужно быть особенно внимательным, а то можно передать и много лишнего, уже не зашифрованного.

В настоящее время коды закреплены за следующими типами шифрования: TLS, WireGuard и ZigBee. Новые коды - через pull request. Правда есть некоторые особенности записи данных и учет порядка следования байтов, так как каждый из этих типов имеет собственную структуру и состав ключевой информации. Все это записывается в поле «Данные».

Дополнительных опциональных полей у этого блока нет — только общие.

Экспериментальные блоки

В интерент-черновике выделено несколько экспериментальных блоков. Пока не ясно, как применять эти блоки. Разработчикам документа тоже пока не ясно, о чем они открыто и пишут: «экспериментальные блоки определенно представляют интерес, однако авторы уверены, что их реальное применение возможно только после серьезных дискуссий». Попробую пофантазировать (и вас приглашаю к этому в комментариях).

Так, документ экспериментально выделяет блок SB - Event/Security Blocks (ему даже не присвоен свой код). По всей видимости это задумка о записи сюда данных от каких-нибудь IDS или IPS, или от собственных правил фильтрации. Например, Suricata могла бы писать в этот блок временные отметки, если бы у нее срабатывало событие. Может быть наличие такой информации в одном документе (трафик и события) позволило бы удобнее организовать процесс анализа сетевого трафика на предмет безопасности.

Другой вариант применения экспериментальных блоков, это указание CPE и CVE идентифицированного программного обеспечения (машины, операционной системы, приложения собиравшего трафик, по MAC вероятный вендор и т.д.) или соседних машин (с кем идет обмен трафиком). Кстати tcpdump/libpcap уже является участником пилотной программы «CVE через GitHub». Вот ссылка на соответствующий репозитарий.

Заключение

Конечно, для детального просмотра сетевого дампа всегда проще, быстрее и безошибочнее воспользоваться специализированными приложениями или взять готовую библиотеку. Но иногда полезно интересно немного глубже разобраться в структуре файла, чтобы лучше представлять внутреннюю кухню тех приложений, с которыми работаешь.

Надеюсь данный обзор был интересен и не очень скучен. А за более строгим описанием всегда можно обратиться к исходнику интернет-черновика или ориентироваться на код главной реализации этого формата. Обещанную таблицу со всеми опциональными полями прячу под спойлер.

Для оформления всех рисунков использовался diagrams.net.