Termux как мобильный SOC‑узел: сбор, агрегация и корреляция логов с помощью ELK‑стека и Zeek‑трафика

Современные расследования инцидентов часто начинаются не в офисе, а «на выезде»: когда нужно быстро собрать артефакты, унифицировать телеметрию и получить корреляцию событий с сетевым поведением. Termux на Android — удобная платформа для развертывания легковесных сборщиков и агентских компонентов, которые могут работать в полевых условиях без тяжёлой инфраструктуры.

Ниже — практический подход к построению мобильного SOC‑узла: Termux выполняет роль сборщика и транспортного звена, ELK‑стек (Elasticsearch/Logstash/Kibana) — роль хранения и визуализации, а Zeek — роль протокольного анализа трафика с последующей корреляцией сетевых событий с логами.

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

Базовая схема выглядит так:

Точка сбора (Termux): сбор логов с приложений/служб, системных событий и артефактов, их нормализация и упаковка в структурированный формат (JSON).
Транспорт: отправка событий в центральный сбор (ELK/Logstash) по защищённому каналу в локальной сети (например, через VPN/туннель для создания локальной сети; не для обхода ограничений).
Протокольный анализ (Zeek): запуск Zeek на месте анализа (на той же машине/шлюзе/виртуалке) для получения журналов conn, dns, http, ssl и т.д.
Агрегация и индексация (Logstash): маршрутизация входящих событий, нормализация полей, обогащение (гео/хэши/таймзоны при необходимости) и запись в Elasticsearch.
Корреляция и аналитика (Kibana): поиск по IOC, временным окнам, сопоставление логов с сетевыми событиями по IP/порту/хостам/идентификаторам сессий.

Требования и безопасная эксплуатация

При работе с журналами и сетевыми данными важно соблюдать организационные политики и нормы законодательства РФ. Рекомендуется:

Собирать только данные, необходимые для расследования/анализа, и ограничивать доступ к хранилищу.
Обеспечить контроль целостности (хеширование артефактов/журналов при необходимости).
Использовать защищённый транспорт в рамках локальной сети (например, при настройке VPN для формирования локальной сети между узлами).
Фиксировать версии инструментов и параметры конфигурации (в случае ретроспективного анализа).

Примечание: ниже приведены общие инструкции по настройке аналитической платформы. Реальные режимы мониторинга и периметры должны соответствовать вашей правовой базе и внутренним регламентам.

Подготовка Termux: базовые компоненты

Установите необходимые пакеты: curl/rsync/ca-certificates и утилиты обработки JSON. В зависимости от вашего набора сборщиков могут потребоваться дополнительные инструменты.

pkg update -y
pkg install -y curl ca-certificates jq

Далее подготовьте структуру проекта для удобства:

mkdir -p ~/soc/logs ~/soc/scripts ~/soc/config

Принцип: Termux генерирует события, приводит их к единому формату и отправляет их в Logstash. Даже если сборка ограничена, унификация формата критична для корреляции в Kibana.

Нормализация логов на Termux в JSON

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

event.dataset (какой источник: system/android/app)
event.action (что произошло)
@timestamp
host.name (устройство/псевдоним)
source.ip / destination.ip (если применимо)
process.name, process.pid
message (человекочитаемо)
tags и метаданные

Пример простого скрипта-обёртки, который формирует JSON-событие из текстового источника. Его можно адаптировать под ваши реальные логи.

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

DATASET="${1:-custom}"
ACTION="${2:-log}"
MESSAGE="${3:-no message}"

HOST_NAME="${HOST_NAME:-termux-mobile}"
TS="$(date -u +"%Y-%m-%dT%H:%M:%SZ")"

jq -n 
  --arg dataset "$DATASET" 
  --arg action "$ACTION" 
  --arg ts "$TS" 
  --arg host "$HOST_NAME" 
  --arg msg "$MESSAGE" 
  '{
    "@timestamp": $ts,
    "event": { "dataset": $dataset, "action": $action },
    "host": { "name": $host },
    "message": $msg,
    "tags": ["termux"]
  }'
EOF

chmod +x ~/soc/scripts/emit_event.sh

В реальном сценарии вместо «MESSAGE» вы подставляете фрагменты логов, выбранные по фильтрам (например, только ошибки/подозрительные события приложения, либо события изменения конфигурации).

Отправка событий из Termux в Logstash (ELK)

Есть разные способы передачи: напрямую в Elasticsearch, через Logstash HTTP input, через Beats. Для мобильного узла практична модель «Termux → Logstash endpoint», где Logstash принимает JSON и индексирует.

Допустим, у вас в Logstash настроен HTTP endpoint (или вы используете аналогичный приём). На Termux можно отправлять через curl.

EVENT_JSON="$(~/soc/scripts/emit_event.sh system boot "Termux SOC узел запущен")"

curl -sS -X POST "http://<logstash-host>:8080/events" 
  -H "Content-Type: application/json" 
  -d "$EVENT_JSON"

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

Logstash: индексирование и подготовка к корреляции

Цель Logstash — привести разные источники к согласованным полям и записывать данные в индексы, удобные для Kibana. В типовом варианте создают индексы по датасетам или по типам событий.

Ниже демонстрационный фрагмент логики (конкретные настройки зависят от вашего способа приёма событий в Logstash):

# Пример: фильтры для нормализации и добавления служебных полей
filter {
  # Если данные уже в JSON и приходят с валидным "@timestamp", оставляем как есть.
  # При необходимости преобразуйте поля/таймзоны.
  if [host][name] == "" {
    mutate { add_field => { "[host][name]" => "unknown" } }
  }

  # Пример добавления тега типа события
  if [event][dataset] {
    mutate { add_tag => "%{[event][dataset]}" }
  }
}

# Вывод (output) — в зависимости от вашей структуры индексов
output {
  elasticsearch {
    hosts => ["<elasticsearch-host>:9200"]
    index => "soc-termux-%{+YYYY.MM.dd}"
  }
}

Ключ к корреляции: одинаковые имена полей и одинаковые типы (особенно ip, keyword, date). Это снижает риск того, что Kibana не сможет эффективно фильтровать и строить таймлайны.

Zeek: получение сетевых журналов для последующей корреляции

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

conn.log — сетевые соединения
dns.log — DNS запросы/ответы
http.log — HTTP метрики/события
ssl.log — параметры TLS/сертификатов
notice.log — алерты Zeek на основе сигнатур/политик

Далее журналы Zeek нужно отправить в ELK. Подход зависит от вашей реализации: можно писать в файл и использовать Logstash tail/прочтение, либо задействовать специализированные коннекторы. С точки зрения конечного результата важно:

Наличие @timestamp (или корректная маппинг лог-таймстемпа в Elasticsearch).
Нормализация IP/порта в согласованные поля, например source.ip, destination.ip, source.port, destination.port.
Сопоставимые идентификаторы сессий/соединений (например, uid Zeek, где применимо).

Пример (общий) идеи получения данных: Logstash читает Zeek-журналы и индексирует по датам/типам.

# Демонстрационный псевдоконфиг: чтение Zeek логов как JSON/строк и индексация
# (точная реализация зависит от формата журналов и выбранного input-плагина)

input {
  file {
    path => ["/var/log/zeek/current/conn.log"]
    start_position => "end"
    sincedb_path => "/var/lib/logstash/sincedb-zeek-conn"
  }
}

filter {
  # Парсинг конкретного формата Zeek-лога и маппинг в поля ECS-подобной структуры
  # В реальном проекте нужно описать парсинг под формат Zeek.
}

output {
  elasticsearch {
    hosts => ["<elasticsearch-host>:9200"]
    index => "soc-zeek-conn-%{+YYYY.MM.dd}"
  }
}

На практике полезно использовать заранее согласованную схему полей (например, ориентированную на ECS или вашу внутреннюю). Так корреляция между Termux-логами и Zeek-событиями будет стабильной.

Корреляция: как связать события Termux и Zeek в Kibana

Корреляция — это не одна магия, а набор правил сопоставления. Наиболее типовые варианты:

По IP: если Termux логирует обращение к адресу (или косвенно указывает сервер/шлюз), сопоставляйте с conn.log и dns.log.
По хостам/FQDN: сопоставляйте DNS-имена из dns.log с доменами/URL из http.log или логами приложений.
По тайм-окнам: ограничивайте поиск корреляции временным интервалом (например, ±5/±15 минут вокруг события из Termux).
По портам и протоколам: сопоставляйте source.port/destination.port и протокол/метод (если есть).

Практика: создайте в Kibana «обзорные» представления (dashboard) под типы инцидентов (например, подозрительная активность приложения, сетевые аномалии, повторяющиеся DNS-запросы).

Пример сценария расследования:

На Termux зафиксировано событие «приложение инициировало сетевой контакт / подозрительный URL».
В Kibana находите соответствующее событие и фиксируете время.
В интервале времени ищете в soc-zeek-conn- соединения с совпадающим IP/портом.
Если IP не совпадает, проверяете DNS-резолв: dns.log поможет связать домен → IP.
Дальше проверяете http.log/ssl.log для деталей (SNI, сертификаты, URL‑path, user-agent).

Схема разработки корреляционных правил

Чтобы корреляция не превращалась в ручной «поиск по всем индексам», вводите простые формальные правила:

Правило 1 (Window Join): если событие Termux имеет поле destination.ip и попадает в окно ±N минут к событиям conn.
Правило 2 (DNS Pivot): если Termux содержит домен (destination.domain), сначала ищем в dns.log соответствие домен → IP, затем в conn.log.
Правило 3 (Protocol Enrichment): если Zeek conn показывает необычный протокол/политики (notice), помечаем связанный Termux-событие тегом network_notice.

Если вы используете Kibana/Elasticsearch Watcher/Rules, оформляйте триггеры по заранее описанным условиям. Важно держать поля однотипными и проверять маппинги индексов.

Производительность и устойчивость в полевых условиях

Termux работает на мобильном устройстве, поэтому учитывайте:

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

Пример упрощённой отправки батчем (идея):

# Собрать несколько событий в файл и отправить пачкой
# (реализуйте свой механизм очереди/диска в Termux)

ls ~/soc/logs/.json > /dev/null
# Далее: cat > payload и POST в endpoint, если он поддерживает массив.

Практические заметки по маппингам и полям

Чтобы Kibana уверенно работала с корреляцией, заранее определите:

Типы полей: IP — как ip, даты — как date, домены — как keyword (если точное сравнение), тексты — как text (если нужен full‑text).
Единые названия: выбирайте один нейминг и придерживайтесь его между Termux и Zeek (например, источник/назначение в одинаковых полях).
Схему тегов: используйте tags для быстрой фильтрации (например, tag:termux, tag:zeek, tag:notice).

Заключение

Termux можно превратить в эффективный мобильный SOC‑узел: он быстро собирает и нормализует события, ELK‑стек централизованно индексирует и визуализирует телеметрию, а Zeek даёт протокольный контекст сетевого поведения. При грамотной унификации полей и тайм‑окон корреляция между логами устройства и сетевыми журналами становится воспроизводимой и полезной в расследованиях.

Если вы хотите спроектировать и внедрить такую связку под вашу инфраструктуру (с учётом маппингов, очередей, безопасности и сценариев реагирования), команда РыбинскЛАБ поможет: от аудита требований и подготовки архитектуры до настройки ELK/Zeek, построения правил корреляции и разработки dashboard под ваши use‑case.