Автоматизированный сбор и анализ сетевого трафика в Termux с использованием Zeek, Suricata и Elastic Stack

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

В этой статье рассмотрим, как организовать пайплайн «сбор → нормализация → обнаружение → индексация в поиске» с использованием Zeek, Suricata и Elastic Stack. Подход ориентирован на легитимные сценарии: аудит собственных систем, мониторинг вашей локальной сети и анализ трафика при наличии соответствующих полномочий.

Правовые и организационные замечания

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

Если потребуется «виртуализация доступа» (например, организация локальной сети через VPN), рассматривайте её только как способ построения локального сегмента/маршрутизации внутри вашей архитектуры, а не как обход ограничений.

Архитектура решения

Логическая схема пайплайна:

• Сбор трафика: получение пакетов/снимков из сетевого интерфейса в Termux (или через локальный сбор на устройстве/шлюзе).
• Нормализация и контекст: Zeek формирует «события» (logs) в табличном/структурированном виде.
• Обнаружение: Suricata применяет правила и генерирует предупреждения/alerts.
• Индексация: Elastic Stack (обычно Elasticsearch + Logstash или Filebeat/Elastic Agent) принимает логи Zeek/Suricata и индексирует их.
• Аналитика: Kibana строит дашборды, временные графики, фильтры и корреляции.

Ключевая цель — единообразие формата событий и воспроизводимость настройки.

Требования и подготовка

Для реализации понадобятся:

• Termux на Android-устройстве.
• Права/возможность работать с нужными интерфейсами (в зависимости от сценария может потребоваться запуск с дополнительными возможностями или использование сетевого шлюза).
• Сервер/хост для Elastic Stack (может быть на ПК, в VM или в локальном контуре).
• Доступ к файловой системе Termux, где будут храниться логи Zeek и Suricata.

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

Установка базового окружения в Termux

Обновим пакеты и установим зависимости. Рекомендуется начать с минимального набора инструментов для сборки и работы с сетью.

pkg update
pkg upgrade -y
pkg install -y git wget curl tar clang make autoconf automake libpcap ncurses tzdata python python-requests

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

Сбор трафика: варианты

Существует два типовых подхода:

• Вариант A (локальный сбор в Termux): Termux обрабатывает пакеты и сохраняет/передаёт в анализаторы. Подходит, если платформа поддерживает нужный доступ к интерфейсам.
• Вариант B (сбор на внешнем хосте): на Linux-шлюзе делается запись pcap (tcpdump/вывод в файлы/потоки), затем Termux/анализатор обрабатывает файлы или получает поток. Этот подход чаще надежнее.

Ниже для ясности покажем рабочий стиль: сначала Zeek/Suricata ориентируем на обработку pcap или файлов логов, а дальше вы интегрируете сбор трафика под ваш сценарий.

Zeek в Termux: настройка логирования

Zeek известен как платформа сетевого мониторинга, которая превращает трафик в интерпретируемые события (logs). Для Termux на практике удобнее:

• либо собрать Zeek под вашу среду;
• либо запускать в контейнере/на отдельном Linux-хосте и использовать Termux для управления.

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

Создадим рабочую директорию:

mkdir -p ~/netmon/zeek ~/netmon/suricata ~/netmon/elastic
mkdir -p ~/netmon/zeek/logs
mkdir -p ~/netmon/suricata/fastdata

Пример минимальной структуры конфигурации Zeek (логирование в папку):

cat > ~/netmon/zeek/node.cfg <<'EOF'
[zeek-node]
type=standalone
host=localhost
EOF

cat > ~/netmon/zeek/logger.cfg <<'EOF'
[zeek-log]
path=~/netmon/zeek/logs
EOF

Дальше вы будете запускать Zeek на PCAP. Пример команда (подставьте реальный путь к pcap и имя бинарника zeek):

# Ориентир по синтаксису: запуск анализа pcap и получение .log файлов
# Команду скорректируйте под вашу установку zeek
zeek -C -r /sdcard/pcaps/sample.pcap -j ~/netmon/zeek

После прогона вы получите набор логов Zeek (например, connection.log, dns.log, http.log и др.). Именно их дальше удобно индексировать в Elasticsearch.

Suricata в Termux: правила и генерация alerts

Suricata — IDS/IPS с поддержкой сигнатур и генерацией событий. В контуре мониторинга мы обычно используем правила (rule set), которые определяют, что считать подозрительным.

Создадим базовые каталоги Suricata:

mkdir -p ~/netmon/suricata/etc
mkdir -p ~/netmon/suricata/rules
mkdir -p ~/netmon/suricata/logs

Пример конфигурационного файла suricata.yaml (фрагмент):

cat > ~/netmon/suricata/etc/suricata.yaml <<'EOF'
modbus:
  enabled: no
af-packet:
  - device: any
    cluster-id: 1
    defrag: yes

outputs:
  - fast:
      enabled: yes
      filename: fast.log

default-rule-path: /sdcard/netmon/suricata/rules

logging:
  default-log-level: Info
  outputs:
    - file:
        enabled: yes
        filename: ~/netmon/suricata/logs/suricata.log
EOF

Важно: путь и интерфейс зависят от вашего окружения. Для начала поднимайте правило-движок на анализе pcap, чтобы снизить риски с правами на интерфейс.

Загрузите/подготовьте правила. Минимально можно взять локальный rule set или использовать свой. Далее запускайте анализ pcap:

# Пример: запуск Suricata на pcap
suricata -c ~/netmon/suricata/etc/suricata.yaml -r /sdcard/pcaps/sample.pcap -l ~/netmon/suricata/logs

В результате Suricata создаст логи и alerts (формат зависит от настроек outputs). Для Elastic Stack будет удобнее собирать эти логи как текст/JSON (если вы настроите output json в конфигурации).

Единый формат событий для Elastic Stack

Чтобы аналитика в Kibana была стабильной, желательно стандартизировать поля. У вас будут два источника:

• Zeek: табличные .log файлы (часто TSV), плюс различная семантика полей.
• Suricata: события/alerts, потенциально в JSON или в текстовом формате (зависит от outputs).

Практика: приводите оба источника к «единым» индексам или хотя бы к предсказуемым названиям полей, чтобы затем строить единые визуализации.

Elastic Stack: развёртывание и индексация

Рассмотрим ориентир: Elasticsearch как хранилище и Kibana как витрина. Для доставки логов удобно использовать Logstash (transform/pipeline) или Filebeat (если форматы уже удобны).

Если вы используете Docker (на хосте), пример стека:

docker network create elastic-net

docker run -d --name elasticsearch --net elastic-net -p 9200:9200 -p 9300:9300 
  -e "discovery.type=single-node=true" 
  -e "xpack.security.enabled=false" 
  docker.elastic.co/elasticsearch/elasticsearch:8.12.0

docker run -d --name kibana --net elastic-net -p 5601:5601 
  -e "ELASTICSEARCH_HOSTS=http://elasticsearch:9200" 
  -e "xpack.security.enabled=false" 
  docker.elastic.co/kibana/kibana:8.12.0

docker run -d --name logstash --net elastic-net 
  -p 5044:5044 
  -e "xpack.security.enabled=false" 
  docker.elastic.co/logstash/logstash:8.12.0

Далее — настройка Logstash для приёма и парсинга файлов.

Logstash pipeline: пример для Zeek и Suricata

Принцип: Logstash читает логи, парсит их в структурированные поля и отправляет в Elasticsearch.

Пример pipeline для Zeek (TSV). Допущение: Zeek logs содержат заголовки/поля. Точный парсер зависит от того, какие файлы у вас получаются.

cat > ~/logstash/pipelines/zeek-suricata.conf <<'EOF'
input {
  file {
    path => ["/data/zeek/.log"]
    start_position => "beginning"
    sincedb_path => "/tmp/sincedb-zeek"
    codec => plain { charset => "UTF-8" }
  }
}

filter {
  # Примерный каркас: реальную схему парсинга нужно подстроить под Zeek формат.
  # Для TSV часто удобны grok/kv/dissect, но лучше использовать структуру, которую вы получите из Zeek.
  mutate {
    add_field => { "source.type" => "zeek" }
    add_field => { "event.dataset" => "zeek" }
  }
}

output {
  elasticsearch {
    hosts => ["http://elasticsearch:9200"]
    index => "zeek-%{+YYYY.MM.dd}"
  }
}
EOF

Для Suricata аналогично: если вы настроите output в JSON, парсинг становится проще (json codec). Каркас:

cat > ~/logstash/pipelines/suricata.conf <<'EOF'
input {
  file {
    path => ["/data/suricata/.json", "/data/suricata/.log"]
    start_position => "beginning"
    sincedb_path => "/tmp/sincedb-suricata"
    codec => plain { charset => "UTF-8" }
  }
}

filter {
  mutate {
    add_field => { "source.type" => "suricata" }
    add_field => { "event.dataset" => "suricata" }
  }

  # Если формат JSON, используйте json filter:
  # json { source => "message" target => "suricata" }
}

output {
  elasticsearch {
    hosts => ["http://elasticsearch:9200"]
    index => "suricata-%{+YYYY.MM.dd}"
  }
}
EOF

Чтобы Logstash стартовал с нужными pipeline-файлами, обеспечьте соответствие структуре каталогов и конфигурации (зависит от вашей сборки/образа).

Автоматизация: доставка логов из Termux в контур Elastic

Самый практичный механизм — периодически переносить файлы логов из Termux на хост Elastic (по SSH/SCP, через общий каталог или через HTTP-эндпоинты).

Схема: после завершения сессии Zeek/Suricata вы копируете логи в папку на сервере, где Logstash их забирает.

Пример скрипта-обвязки в Termux:

cat > ~/netmon/run_and_export.sh <<'EOF'
#!/data/data/com.termux/files/usr/bin/bash
set -euo pipefail

PCAP_PATH="/sdcard/pcaps/sample.pcap"
OUT_DIR_ZEEK="$HOME/netmon/zeek/logs"
OUT_DIR_SUR="$HOME/netmon/suricata/logs"

echo "Running Zeek..."
# Подстройте команду под вашу установку/конфигурацию
zeek -C -r "$PCAP_PATH" -j "$HOME/netmon/zeek" || true

echo "Running Suricata..."
suricata -c "$HOME/netmon/suricata/etc/suricata.yaml" -r "$PCAP_PATH" -l "$OUT_DIR_SUR" || true

echo "Exporting logs..."
# Пример через rsync/ssh: настройте user/host:/path под ваш сервер
rsync -av --ignore-existing 
  "$OUT_DIR_ZEEK/" user@ELASTIC_HOST:/data/zeek/ 
  --partial
rsync -av --ignore-existing 
  "$OUT_DIR_SUR/" user@ELASTIC_HOST:/data/suricata/ 
  --partial

echo "Done."
EOF

chmod +x ~/netmon/run_and_export.sh

В реальной эксплуатации вы можете:

• делать экспорт по расписанию;
• использовать inotify/watch для автозагрузки при появлении новых файлов;
• добавлять отметки сессии (session_id) для сквозного трекинга.

Корреляция и визуализация в Kibana

После индексации данные можно использовать для аналитики:

• Таймлайн событий по источникам: zeek- и suricata-*.
• Топ доменов/URI (если доступно из Zeek http/dns логов).
• Список сработавших правил Suricata и фильтрация по severity.
• Сопоставление «подозрительный домен → затем alert по соответствующему трафику» (нужно настроить корреляционные ключи, например IP/порт/время).

Для улучшения качества корреляции рекомендуется стандартизировать поля (IP, proto, src/dst, timestamp, event.dataset) до индексации либо в Logstash, либо через ingest pipeline.

Практические советы по надежности

• Тестируйте на PCAP: сначала проверяйте настройки Zeek/Suricata на заранее сохраненных captures, затем переходите к live-сценарию.
• Лимитируйте размер логов: на мобильных устройствах важно контролировать дисковое пространство (логи и fastdata).
• Версионируйте конфиги: храните рабочие конфиги Zeek/Suricata и Logstash в Git.
• Учитывайте точность времени: NTP на хосте и корректная временная зона критичны для корреляции.
• Разделяйте индексы по датам: это ускоряет поиск и упрощает чистку данных.

Безопасность и эксплуатация

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

Заключение

Построение автоматизированного контура анализа сетевого трафика в Termux с Zeek, Suricata и Elastic Stack позволяет превратить наблюдения за сетью в структурированные события, быстро находить подозрительные паттерны и визуализировать результаты в Kibana. Ключ к успеху — правильная организация пайплайна, стандартизация полей, надежная доставка логов и аккуратная корреляция источников.

Если вы хотите внедрить решение под ваши задачи (мониторинг локальной сети, аудит своих сегментов, настройка индексов/дашбордов, оптимизация пайплайна), команда РыбинскЛАБ поможет с проектированием и внедрением «под ключ».