Трафик в локальной сети часто является главным источником данных для диагностики инцидентов, выявления аномалий и контроля доступности сервисов. В этой статье покажем практический подход к автоматическому анализу сетевого трафика на мобильном устройстве в среде Termux с использованием Zeek (Bro) и последующей визуализацией результатов в Grafana.
Акцент будет на корректных и безопасных сценариях: сбор данных для анализа своей сети или тестового окружения, а также построение аналитики без «обходов» ограничений. Если потребуется изоляция/локальная маршрутизация, VPN допустим только для формирования локальной сети, а не для обхода блокировок.
Что будем делать
Установим Zeek в Termux и подготовим минимально необходимую структуру.
Настроим сбор сетевых событий (парсинг протоколов и метаданных).
Соберём события в формате, удобном для дальнейшей загрузки/агрегации (через CSV/JSON и/или промежуточный этап).
Передадим данные в инструмент аналитики/хранилище, поддерживающее Grafana (часто это Loki/InfluxDB/Prometheus или связка с PostgreSQL через промежуточные преобразования).
Построим интерактивные панели в Grafana: по времени, по хостам, по протоколам, по сессиям и аномалиям.
Требования и оговорки по среде Termux
Сразу обозначим важное:
Zeek — инструмент, ориентированный на сетевой захват. На мобильных устройствах доступ к захвату пакетов может зависеть от прав, типа сети и драйверов. В некоторых конфигурациях требуется запуск под терминальной подсистемой с расширенными возможностями захвата.
Цель статьи — дать рабочий «сквозной» подход: автоматизация, сбор событий, агрегация и визуализация. Конкретный способ захвата трафика может отличаться в зависимости от устройства и версии Android.
Для демонстрации в рамках своей сети удобно собирать трафик с точки доступа/роутера или зеркалирования порта (SPAN) на компьютере. Если же вы хотите именно Termux — потребуется подобрать способ захвата (вплоть до использования локального захвата/прокси-подхода), и мы это учтём в настройке.
Установка окружения в Termux
Начнём с подготовки Termux и базовых пакетов.
pkg update -y && pkg upgrade -ypkg install -y git clang make ndk-sysroot python libpcap tcpdump curl wget jqПояснение: libpcap и tcpdump часто нужны для работы с сетевым стеком и проверок доступности захвата. jq пригодится для обработки JSON.
Установка Zeek в Termux
Есть два типовых подхода:
Сборка Zeek из исходников (часто самый гибкий путь).
Использование готовых пакетов/сборок, если они доступны для вашей архитектуры и версии окружения.
Далее опишем сборку из исходников как универсальную.
cd $HOME
git clone --depth 1 https://github.com/zeek/zeek.git
cd zeekДальше потребуется конфигурация сборки. Простейший вариант — собрать с минимальными компонентами, а затем проверить успешность запуска.
./configure
make -j$(nproc)
make installЕсли конфигурация/зависимости на вашей сборке Android потребуют дополнительных пакетов, обычно требуется доустановка библиотек разработки (компилятор/заголовки). На практике это решается итеративно после просмотра логов сборки.
Проверим бинарник:
zeek -vПодготовка директорий и конфигураций
Сделаем структуру для результатов анализа.
mkdir -p $HOME/zeek-run/logs
mkdir -p $HOME/zeek-run/scripts
mkdir -p $HOME/zeek-run/spoolZeek хранит логи в каталоге, управляемом конфигами. Смысл — обеспечить предсказуемое место для последующей выгрузки в Grafana.
Базовая настройка Zeek
Для начала полезно использовать стандартные скрипты и стандартные логи. Часто достаточно: включить нужные модули, убедиться в корректном интерфейсе захвата и проверить, что логи создаются.
1) Определим доступные интерфейсы. Сначала посмотрим, какие интерфейсы видит система:
ip link show2) Выберите интерфейс, через который проходит нужный трафик. Далее — базовая проверка с tcpdump:
tcpdump -i <INTERFACE> -c 10 -nЕсли пакеты видны — двигаемся к Zeek. Если нет — тогда задача потребует альтернативного подхода (например, захват на другом узле сети и перенос логов на Termux).
Запуск Zeek для сбора логов
Запуск Zeek на интерфейсе (примерно):
zeek -i <INTERFACE> local > $HOME/zeek-run/zeek.logДайте несколько минут на накопление событий. Затем проверьте каталог логов:
ls -lah $HOME/zeek-run/logs
find $HOME/zeek-run -maxdepth 2 -type f | headТиповой состав Zeek-логов включает файлы вида conn.log, dns.log, http.log и др. Конкретный набор зависит от того, какие протоколы и скрипты активны.
Экспорт/агрегация данных для Grafana
Grafana сам по себе не «понимает» Zeek-форматы напрямую. Поэтому обычно делают одно из:
Преобразование логов в CSV/JSON, затем подача в хранилище.
Агрегация по времени (1 минута/5 секунд), ключам (src/dst host, protocol) и отправка в time-series базу.
Использование совместимого источника логов/метрик (например, Loki для логов или InfluxDB для метрик/агрегаций).
В рамках практичного подхода покажем: преобразование Zeek-логов в JSON построчно (для примеров ниже предполагаем, что логи доступны в читаемом формате).
1) Допустим, у нас есть файл:
$HOME/zeek-run/logs/current/conn.log2) Выполним быструю конверсию через скрипт (примерный шаблон). Zeek-логи часто имеют заголовки/комментарии; в реальном проекте лучше использовать встроенные утилиты Zeek или точно настроенный парсер.
# Примерно (идея): выделить data-строки и превратить в JSON
# На практике точный парсер зависит от версии Zeek и формата логов.
python3 - <<'PY'
import json, re, sys
path = sys.argv[1]
out = sys.argv[2]
PY Чтобы не вводить в заблуждение точностью формата, рекомендуем выбрать один из путей:
Использовать нативные возможности Zeek по логированию и правила для нужных полей.
Применить тестовую конверсию на небольшом логе и убедиться в корректности полей перед загрузкой в хранилище.
Если вам нужно, я могу адаптировать конкретный конвертер под ваши поля Zeek (conn/dns/http) — достаточно прислать структуру 10–20 строк из логов (без чувствительных данных).
Передача данных в Grafana (варианты)
Обычно выбирают один из вариантов:
Логи в Loki: удобны для поиска и корреляции, но для сложной статистики чаще делают агрегированные метрики.
Временные ряды в InfluxDB: хорошо для panel по запросам типа rates/percentiles.
Prometheus: если вы превратите события в набор метрик (например, количество новых соединений по протоколу в минуту).
PostgreSQL: допустимо для аналитических запросов (агрегации), но это чаще «тяжелее» и требует аккуратной схемы/индексации.
Самый практичный компромисс для старта: агрегировать Zeek-события в метрики «сколько/когда/какой протокол/какие пары src-dst» и отправлять в time-series базу, а сырые события хранить как логи.
Автоматизация: скрипт сбора и периодическая обработка
Идея: Zeek запускается на интервал, логи складываются в каталог, затем по расписанию выполняется преобразование/агрегация и загрузка в хранилище.
Пример оболочки для запуска с ограничением по времени (концептуально):
# run.sh
#!/data/data/com.termux/files/usr/bin/sh
INTERFACE="<INTERFACE>"
OUT_DIR="$HOME/zeek-run/$(date +%Y%m%d_%H%M%S)"
mkdir -p "$OUT_DIR"
# Запускаем zeek (пример)
zeek -i "$INTERFACE" > "$OUT_DIR/zeek.log" 2>&1 &
ZEek_PID=$!
# Ждём заданное время
sleep 300
# Останавливаем
kill "$ZEek_PID" 2>/dev/null || true
# Далее: конвертация/агрегация и отправка в хранилище
# ./convert_and_push.sh "$OUT_DIR"
Задача convert_and_push.sh зависит от того, куда именно вы загружаете данные. Важно разделить этапы и проверять корректность на тестовом окне (например, 5 минут трафика).
Построение интерактивных графиков в Grafana
Когда данные доступны в источнике (метрики/логи), в Grafana создаём панели. На практике полезны следующие дашборды:
Traffic overview: соединения/сек или соединения/мин по протоколам (TCP/UDP/HTTP/DNS).
Top talkers: топ источников/получателей по количеству сессий.
DNS activity: количество запросов, NXDOMAIN/ошибки (если логируется).
HTTP breakdown: распределение статусов (200/301/404/500) и объем по URL-уровню (в пределах политик приватности).
Аномалии: рост числа коротких соединений, всплески ошибок, резкие изменения географически/по подсетям (если у вас есть соответствующее обогащение).
Интерактивность обеспечивается переменными Grafana (template variables): выбираем интерфейс/подсеть/хост и получаем динамические графики. Например, переменные по src_host/dst_host и протоколу.
Для корректных панелей важно, чтобы вы заранее унифицировали ключи (названия полей) при загрузке: src/dst, proto, ts_bucket, count/bytes и т.д.
Практические рекомендации по качеству данных
Фильтрация: не загружайте в визуализацию лишние поля/сущности. Для дашборда достаточно агрегированных значений и нескольких идентификаторов.
Приватность: избегайте хранения персональных данных (в особенности payload, если он не требуется).
Таймзоны: синхронизируйте время на устройстве (Termux/Android) и на сервере Grafana.
Тестовые окна: сначала соберите 5–10 минут трафика в контролируемой среде, проверьте целостность и только затем увеличивайте время сбора.
Заключение
Автоматический анализ сетевого трафика в Termux с Zeek (Bro) и визуализация в Grafana — это реалистичный путь к быстрой диагностике и контролю сетевой активности. Ключ к успеху — не только правильный сбор событий, но и аккуратная агрегация/преобразование данных в формат, удобный для time-series и логовых систем, а также продуманная структура дашбордов.
Если хотите, мы в РыбинскЛАБ поможем: подберём архитектуру сбора на вашей среде, настроим Zeek под нужные протоколы и поля, разработаем конвертер и дашборды в Grafana, а также подготовим регламент автоматизации и проверки качества данных.