Кратко

  • conn.log — это сжатый вывод настроенного сенсора Zeek о попавшем к нему трафике, а не полный хронологический перечень пакетов.
  • Проверяемый вывод требует исходного журнала и схемы, версии Zeek, скриптов, точки и фильтра захвата, времени, данных о потерях и записей с тем же uid.

Сокращение потока было осознанным решением

В статье 1998 года о Bro, позднее переименованном в Zeek, Paxson разделил систему на два уровня. Механизм событий превращал отфильтрованный поток пакетов в события более высокого порядка. Интерпретатор политик решал, что эти события значат для конкретной сети. Наблюдение не было намертво соединено с локальным решением об оповещении или реакции.

Такое сокращение объёма делало возможным мониторинг загруженной линии в реальном времени. Оно же задавало предел доказательства. До аккуратной строки существовали место в топологии, интерфейс, фильтр, проверки целостности, машина состояний и загруженные скрипты. Журнал появился в результате этой цепочки; он не является нейтральной копией всего сетевого обмена.

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

У каждого поля есть невидимое «сенсор увидел»

Текущая документация Zeek говорит, что conn.log в основном описывает третий и четвёртый уровни: кто с кем говорил, когда, как долго и по какому протоколу. В журнал входят TCP и UDP. Для UDP и ICMP «соединение» понимается как поток пакетов, а не как TCP-сессия. Даже название объекта нельзя читать без протокольного контекста.

ts — время первого пакета, замеченного Zeek. Это не доказательство отсутствия более раннего пакета в другой точке пути. uid — уникальный ключ соединения внутри журналов Zeek; он позволяет связать запись с DNS, HTTP, TLS и другими протоколами. Конечные узлы этот идентификатор не выдавали и не подтверждали.

conn_state сжимает выведенное состояние. S0 означает замеченную попытку без ответа; SF — наблюдавшиеся нормальные установление и завершение. Другие коды описывают отказ, сброс или неполное закрытие. Сенсор, видящий одно направление, запущенный поздно или теряющий трафик, может иначе описать тот же обмен между узлами.

history тоже не равен последовательности пакетов. Заглавная буква относится к инициатору, строчная — к ответчику; буквами кодируются SYN, SYN-ACK, ACK, данные, FIN, RST, пробелы и повторные передачи. Некоторые события фиксируются не более одного раза на направление, другие повторяются логарифмически. Строка хорошо показывает форму разговора, но не сохраняет полные порядок и количество пакетов.

Счётчики основаны на правилах расчёта. Для TCP orig_bytes и resp_bytes выводятся из номеров последовательности и, согласно справочнику, могут быть неточными, в частности на больших соединениях. duration не включает некоторые поздние пакеты без новой полезной нагрузки, хотя history может их отразить. Счётчики пакетов необязательны и зависят от анализатора размера. Признаки local/remote зависят от Site::local_nets. Пустота поля может говорить о конфигурации, а не о сети.

Проверять, что пропустил наблюдатель

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

reporter.log хранит внутренние предупреждения и ошибки, относящиеся к обработке трафика и вычислительным условиям. Для интервала расследования эти сообщения надо сопоставлять с оценкой потерь, перезапусками, изменениями фильтра, состоянием интерфейса и возможной асимметрией маршрута.

Нулевой missed_bytes не исключает потери до интерфейса, трафика по другому пути, исключения фильтром или слепого периода до запуска. И наоборот, сигнал потери не обнуляет автоматически каждое поле. Полезная неопределённость указывает время, направление, сенсор и этап обработки.

Сохранять не строку, а проверяемый комплект

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

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

Если PCAP не сохранился, это надо написать прямо. Формулировка «сенсор Zeek в этой точке и конфигурации наблюдал и резюмировал…» задаёт проверяемое утверждение. Абсолютная фраза о пакетах выходит за пределы материала.

Схема должна оставаться рядом с данными. Текущая документация отмечает появление ip_proto в Zeek 7.1; скрипты могут добавлять поля и менять запись. Без версии и заголовка будущий инструмент способен применить сегодняшнее значение к вчерашней строке.

Источники