Termux как мобильный SIEM‑агент: интеграция OSSEC, Wazuh и Kibana с локальной индексацией в OpenSearch и ротацией логов в S3

Мобильные устройства сотрудников и полевых инженеров все чаще становятся источником ценных телеметрических данных: события приложений, системные логи, сетевые индикаторы, результаты проверок, статусы устройств. При этом классический SIEM-стек (OSSEC/Wazuh + Kibana + поисковая платформа) традиционно рассчитан на серверную инфраструктуру. Выход — развернуть Termux как мобильный агент, который собирает и передает события в вашу локальную аналитическую платформу.

В этой статье описывается практический подход: Termux как транспортный агент для OSSEC/Wazuh-событий, локальная индексация в OpenSearch (как замена/аналог типового Elasticsearch-стека), визуализация в Kibana (в совместимых конфигурациях), а также ротация логов с архивированием в S3 для долгосрочного хранения.

Материал ориентирован на корректные, допустимые с точки зрения законодательства и корпоративной политики применения: без обхода блокировок и без использования VPN для уклонения от ограничений — только при необходимости для создания локальной сети между устройством и инфраструктурой.

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

Ниже — рекомендуемая схема, которая хорошо масштабируется и упрощает эксплуатацию.

Termux (мобильный агент): сбор событий/файлов журнала, подготовка сообщений и передача в Wazuh/OSSEC-совместимую обработку.
Wazuh manager (или OSSEC compatible manager): прием событий, корреляция/агрегация, формирование нормализованных алертов.
OpenSearch: локальная индексация событий и алертов через соответствующий pipeline/шаблоны.
Kibana: построение дашбордов, поиск по индексам и управление визуализацией.
S3-стордж (опционально локально/облачно): ротация и архивирование исходных логов/сырых событий для compliance и резервного восстановления.

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

Перед началом определите:

Сетевую доступность между Termux и вашим менеджером (Wazuh/OSSEC). Обычно это достигается через локальную сеть.
Политику хранения: срок «горячего» хранения (OpenSearch) и срок «холодного» хранения (S3).
Модель безопасности: отдельные учетные данные для приема/передачи событий, минимальные привилегии, TLS при необходимости.

Если требуется VPN, используйте его только для создания локальной сети между устройством и инфраструктурой (например, site-to-site или client-to-site), а не для обхода блокировок.

Установка Termux и базовые зависимости

Начните с обновления пакетов и установки утилит, необходимых для работы со сбором данных и отправкой событий.

pkg update -y
pkg upgrade -y
pkg install -y openssh tar curl wget proot procps nano logrotate ca-certificates

Дальше по месту решается, какой транспорт использовать: прямую отправку в manager (если предусмотрен формат), либо промежуточную прослойку (например, shipper/pipeline). В рамках этой статьи делаем акцент на том, как выстроить совместимый SIEM-поток: от Termux до индексации в OpenSearch.

Сбор и нормализация событий в Termux

Чтобы OSSEC/Wazuh смог корректно обработать события, важно сформировать сообщения в ожидаемом формате или использовать механизм «агентского» приема. На практике чаще используют один из подходов:

Агентный формат: передача событий так, чтобы они воспринимались manager как стандартные syscheck/log events.
Лог как файл: генерация лог-файла в Termux и последующая доставка менеджеру/шипперу, который читает файл и отправляет события.

Ниже пример минимального каркаса: ведем отдельный лог мониторинга устройства и подготавливаем его для дальнейшей передачи.

mkdir -p ~/siem/logs
touch ~/siem/logs/termux-monitor.log
chmod 600 ~/siem/logs/termux-monitor.log

Пример добавления тестовой записи (для проверки пайплайна):

date '+%Y-%m-%d %H:%M:%S' >> ~/siem/logs/termux-monitor.log
echo "termux agent initialized" >> ~/siem/logs/termux-monitor.log

Интеграция с OSSEC/Wazuh: доставка событий на manager

OSSEC и Wazuh исторически совместимы на уровне концепций агента/менеджера. В корпоративных установках чаще всего используется Wazuh manager, который умеет принимать данные от агентов и строить корелляцию. Для Termux обычно применяют:

Либо «тонкий агент» с отправкой событий в формате, поддерживаемом manager;
Либо shipper-логика на стороне хоста/прокси, куда Termux передает логи.

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

На стороне Termux для иллюстрации — подготовим отправку лог-файла на вашу принимающую сторону (placeholder), чтобы дальше вы подставили актуальный адрес/порт и формат под ваш manager.

# Пример: упаковка лога для передачи (в реальном проекте формат и транспорт подбираются под Wazuh/OSSEC)
tar -czf ~/siem/logs/termux-monitor-$(date '+%Y%m%d-%H%M%S').tar.gz -C ~/siem/logs termux-monitor.log

Дальше используйте ваш согласованный метод доставки. Например, если у вас есть сервер-репозиторий (прокси) для приемки файлов, можно переносить архив по защищенному каналу. Пример с SCP/SSH (если разрешено политикой и настроено на сервере):

# Замените user/host на вашу инфраструктуру
# Примечание: настройки доступа и ключи должны быть подготовлены заранее
scp ~/siem/logs/.tar.gz user@YOUR_MANAGER_OR_PROXY_HOST:/var/incoming/termux/

После этого на стороне Wazuh/OSSEC-стека запускается обработка входящих данных (например, через pipeline/агент-логический импорт). Конкретные команды зависят от способа загрузки в manager, поэтому в продакшене лучше опираться на документацию вашей версии Wazuh и утвержденную схему приема.

Локальная индексация в OpenSearch

Чтобы события SIEM отображались и искались пользователями, их нужно индексировать. Для локальной индексации используйте OpenSearch и настройте:

индексы под события Wazuh (шаблоны/маппинги);
pipeline для нормализации полей;
права доступа и жизненный цикл индексов (hot/warm/cold при необходимости).

На практике часто используется integration layer (например, через Wazuh-to-OpenSearch/Logstash/ingest pipeline). Ниже приведен общий каркас, а вы подставляете параметры согласно вашей инфраструктуре.

1) Проверка доступности OpenSearch:

curl -k -u 'opensearch_user:YOUR_PASSWORD' 
'https://YOUR_OPENSEARCH_HOST:9200/_cluster/health?pretty'

2) Создание индекса/шаблонов — обычно выполняется средствами интеграции. Если у вас есть готовый шаблон для Wazuh-событий, примените его через REST API или UI.

Важно: избегайте «ручного» создания индексов без маппингов, если планируете использовать готовые дашборды Kibana (совместимые с Wazuh/OSSEC полями). Иначе часть полей может индексироваться неверно.

Визуализация в Kibana

Kibana используется для построения дашбордов по индексам OpenSearch (в зависимости от выбранного стека совместимости). Ключевые шаги:

Подключите Kibana к OpenSearch (указание URL, креденшл, TLS).
Создайте index patterns (или эквивалент в вашей сборке) под индексы Wazuh.
Импортируйте или адаптируйте dashboards.

Пример проверки, что OpenSearch отдаёт индексные данные (ориентируйтесь на ваши индексы):

curl -k -u 'opensearch_user:YOUR_PASSWORD' 
'https://YOUR_OPENSEARCH_HOST:9200/_cat/indices?v'

После появления событий проверьте, что нужные поля доступны для фильтрации и агрегаций (например, timestamp, agent.id, rule.id, level, location).

Ротация логов и архивирование в S3

Для долгосрочного хранения и соответствия требованиям (audit/compliance) полезно архивировать исходные логи/сырые события в S3. При этом OpenSearch держит «горячие» индексы ограниченное время.

Практика:

В Termux ведите локальный лог (минимальный и безопасный).
На принимающем сервере (proxy/manager host) применяйте logrotate для ротации по времени/размеру.
После ротации — архив/отправка в S3.

Пример конфигурации logrotate на принимающем сервере (не в Termux, чтобы не усложнять мобильную среду):

nano /etc/logrotate.d/termux-incoming

Пример содержимого (адаптируйте пути и частоту):

/var/log/termux/termux-incoming.log {
  daily
  rotate 14
  missingok
  notifempty
  compress
  delaycompress
  copytruncate
  create 0600 root adm
}

Для отправки архивов в S3 обычно используют отдельный скрипт, вызываемый из logrotate по postrotate/prerotate. Пример каркаса:

nano /usr/local/bin/upload-termux-to-s3.sh

#!/usr/bin/env bash
set -euo pipefail

BUCKET="YOUR_S3_BUCKET"
REGION="YOUR_REGION"
FILE="$1"

# AWS CLI должен быть установлен и настроен (credentials лучше хранить в защищенном виде).
aws s3 cp "$FILE" "s3://${BUCKET}/termux-logs/$(hostname)/" --region "$REGION"

Сделайте скрипт исполняемым:

chmod +x /usr/local/bin/upload-termux-to-s3.sh

И добавьте вызов в logrotate (пример, чтобы срабатывало после ротации):

nano /etc/logrotate.d/termux-incoming

/var/log/termux/termux-incoming.log {
  daily
  rotate 14
  missingok
  notifempty
  compress
  delaycompress
  copytruncate
  create 0600 root adm
  postrotate
    # пример: ищем последние сжатые файлы за цикл и отправляем
    # в продакшене лучше сделать точнее по шаблону времени/именам
    for f in /var/log/termux/termux-incoming.log-.gz; do
      [ -e "$f" ] || continue
      /usr/local/bin/upload-termux-to-s3.sh "$f" || true
    done
  endscript
}

Плюсы такого подхода: OpenSearch хранит индексы в рамках SLA, а S3 выступает архивом для последующего анализа и расследований.

Операционная надежность и безопасность

Чтобы система не развалилась при нагрузках и в условиях мобильной сети:

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

Типовой план внедрения

Пилот: 1–2 устройства Termux → тестовая доставка → проверка формата событий в manager.
Индексация: настройка OpenSearch индексов/маппингов и проверка появления документов.
Визуализации: проверка index pattern в Kibana, создание базовых дашбордов (по времени, уровню, agent).
Ротация/архив: внедрение logrotate и отправка архивов в S3.
Закрепление SLA: определение времени задержки доставки, сроков хранения hot/cold, процедур восстановления.

Заключение

Termux как мобильный SIEM‑агент позволяет расширить видимость вашей инфраструктуры за счет событий с мобильных устройств, сохраняя при этом единый аналитический контур. Интеграция OSSEC/Wazuh с локальной индексацией в OpenSearch и визуализацией в Kibana, дополненная ротацией логов и архивированием в S3, дает практичную связку для мониторинга, расследований и соответствия требованиям по хранению.

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