Создание распределённого honeypot‑кластерa на базе Termux: сбор, агрегация и аналитика атак в реальном времени

Honeypot — это специально подготовленная среда, имитирующая уязвимые сервисы или типовые точки входа, чтобы отслеживать попытки атак, не подвергая риску реальные активы. В отличие от «разведки на живых системах», honeypot позволяет собирать наблюдаемые индикаторы компрометации (IOА/IOCs), профилировать тактики злоумышленников и улучшать защиту.

Termux на Android удобен тем, что позволяет развернуть контролируемые агенты на множестве устройств (разных сетей и географий), централизовать сбор телеметрии и вести аналитику событий в реальном времени.

Важно: ниже описан подход к исследовательской и защитной модели honeypot, без рекомендаций по обходу ограничений, атакующим действиям или компрометации чужих систем. Любые действия выполняйте только в рамках собственных ресурсов и с соблюдением требований законодательства РФ.

Правовые и организационные рамки (РФ)

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

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

Если планируется мониторинг внешнего трафика, согласуйте это с владельцем сети/инфраструктуры и обеспечьте документируемую легальность наблюдения.

Архитектура распределённого кластера

Рекомендуемая архитектура состоит из трёх уровней:

Агенты (Termux): собирают локальные события (запросы к «приманкам», метрики, логи систем/сетевого стека) и отправляют телеметрию на центральный сборщик.
Сборщик (aggregator): принимает события от агентов, приводит их к единой схеме (JSON), обогащает (например, гео/ASN по внешним справочникам — при соблюдении правовых ограничений) и сохраняет в хранилище.
Аналитика/дашборды: потоковая агрегация и визуализация в реальном времени (очереди/streaming по вашей инфраструктуре) и расследование по запросу.

Для локальной сети (например, в рамках стенда) допустим VPN/туннель, но только для организации собственной сети между агентами и сборщиком, а не для обхода блокировок.

Подготовка Termux: базовые пакеты и структура проекта

Начните с подготовки Termux и создания рабочего каталога агента.

pkg update -y
pkg install -y curl jq rsyslog nano openssl coreutils

Дальше создайте структуру:

mkdir -p ~/honeypot-agent/{bin,config,logs,spool}
chmod 700 ~/honeypot-agent/spool

Идея: агент должен быть «тонким». Он читает события, нормализует формат и отправляет их на сборщик. Если сеть нестабильна — складывает в spool и повторяет отправку.

Имитация сервисов и безопасный сбор событий

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

Варианты безопасной имитации:

Ложные баннеры (TCP/HTTP endpoints), которые отвечают статически и логируют запросы.
Локальные «тестовые» сервисы, доступные только из заранее определённого сегмента сети.
Логирование попыток через системные источники (rsyslog/journald — в зависимости от окружения), а также метаданные соединений, если вы реализуете простой сервер.

Ниже — шаблон безопасного HTTP-эндпойнта на Python. Он отвечает 200/404 и логирует метаданные запроса. Используйте его только в рамках вашей инфраструктуры.

pkg install -y python

cat > ~/honeypot-agent/bin/http_dummy_server.py <<'PY'
#!/usr/bin/env python3
import json, time
from http.server import BaseHTTPRequestHandler, HTTPServer

LOG_PATH = "/data/data/com.termux/files/home/honeypot-agent/logs/http_events.log"

class Handler(BaseHTTPRequestHandler):
    def _log(self, status):
        event = {
            "ts": int(time.time()),
            "client_ip": self.client_address[0],
            "method": self.command,
            "path": self.path,
            "user_agent": self.headers.get("User-Agent",""),
            "status": status
        }
        with open(LOG_PATH, "a", encoding="utf-8") as f:
            f.write(json.dumps(event, ensure_ascii=False) + "
")

    def do_GET(self):
        # Статическая имитация: определённые пути отвечают предсказуемо
        if self.path.startswith("/admin") or self.path.startswith("/login"):
            self.send_response(200)
            self.end_headers()
            self.wfile.write(b"OK - simulated endpoint")
            self._log(200)
        else:
            self.send_response(404)
            self.end_headers()
            self.wfile.write(b"Not Found - simulated")
            self._log(404)

    def log_message(self, format, *args):
        # Отключаем дефолтный вывод, оставляем только наш JSON-лог
        return

if name == "main":
    addr = ("0.0.0.0", 8080)
    httpd = HTTPServer(addr, Handler)
    httpd.serve_forever()
PY

chmod +x ~/honeypot-agent/bin/http_dummy_server.py

Запуск сервера (в тестовой среде):

mkdir -p ~/honeypot-agent/logs
nohup ~/honeypot-agent/bin/http_dummy_server.py > ~/honeypot-agent/logs/server_stdout.log 2>&1 &

Агент: отправка логов на сборщик с очередью (spool)

Агент читает новые строки из файла событий и отправляет их на центральный endpoint.

cat > ~/honeypot-agent/bin/forwarder.sh <<'SH'
#!/usr/bin/env bash
set -euo pipefail

CONFIG="$HOME/honeypot-agent/config/agent.conf"
source "$CONFIG"

LOG_FILE="$HOME/honeypot-agent/logs/http_events.log"
SPOOL_DIR="$HOME/honeypot-agent/spool"
STATE_FILE="$SPOOL_DIR/forwarder.offset"
URL="$FORWARD_URL"

mkdir -p "$SPOOL_DIR"

# По умолчанию — читаем с начала, если оффсет не задан
OFFSET=0
if [ -f "$STATE_FILE" ]; then
  OFFSET="$(cat "$STATE_FILE")"
fi

# Читаем построчно начиная с оффсета (упрощённо для примера)
# В проде лучше использовать более надёжный подход по inode/позиции.
LINES="$(tail -n +$((OFFSET+1)) "$LOG_FILE" 2>/dev/null || true)"
COUNT=0

echo "$LINES" | while IFS= read -r line; do
  [ -z "$line" ] && continue
  COUNT=$((COUNT+1))
  payload="$(echo "$line" | jq -c --arg device_id "$DEVICE_ID" '{device_id: $device_id, event: .}')"

  # Очередь: если сервер недоступен — складываем payload
  if curl -fsS -X POST -H "Content-Type: application/json" -d "$payload" "$URL" >/dev/null; then
    :
  else
    echo "$payload" >> "$SPOOL_DIR/pending.log"
  fi
done

# Перезапишем оффсет: если COUNT==0 — может быть пустой лог
if [ "$COUNT" -ge 0 ]; then
  OFFSET=$((OFFSET+COUNT))
fi
echo "$OFFSET" > "$STATE_FILE"

# Попытка повторной отправки pending
if [ -s "$SPOOL_DIR/pending.log" ]; then
  tmpfile="$(mktemp)"
  while IFS= read -r p; do
    [ -z "$p" ] && continue
    if curl -fsS -X POST -H "Content-Type: application/json" -d "$p" "$URL" >/dev/null; then
      :
    else
      echo "$p" >> "$tmpfile"
    fi
  done < "$SPOOL_DIR/pending.log"
  mv "$tmpfile" "$SPOOL_DIR/pending.log"
fi
SH

chmod +x ~/honeypot-agent/bin/forwarder.sh

Конфигурация агента:

cat > ~/honeypot-agent/config/agent.conf <<'CONF'
# URL сборщика (например, http://192.168.1.10:9000/ingest)
FORWARD_URL="http://192.168.1.10:9000/ingest"
DEVICE_ID="termux-01"
CONF

Запуск отправки раз в минуту (для простоты):

mkdir -p ~/honeypot-agent/bin
# Запуск через while+sleep (без cron)
nohup bash -c 'while true; do ~/honeypot-agent/bin/forwarder.sh >> ~/honeypot-agent/logs/forwarder.log 2>&1; sleep 60; done' &

Для промышленного режима используйте systemd/конкурентные очереди там, где это уместно, но на Termux часто достаточно аккуратного цикла и spool.

Центральный сборщик: схема приёма и нормализация

Сборщик должен принимать JSON, валидировать минимальный набор полей и сохранять события. Пример — небольшой HTTP-сервис на Python (функциональный каркас).

pip install flask

cat > ingest_server.py <<'PY'
from flask import Flask, request, jsonify
import json, os, time

app = Flask(name)
OUT_DIR = "./ingest_data"
os.makedirs(OUT_DIR, exist_ok=True)

@app.route("/ingest", methods=["POST"])
def ingest():
    try:
        data = request.get_json(force=True)
        device_id = data.get("device_id","")
        event = data.get("event",{})
        ts = int(event.get("ts", int(time.time())))
        if not device_id or not isinstance(event, dict):
            return jsonify({"ok": False, "error": "bad payload"}), 400

        out_path = os.path.join(OUT_DIR, f"events_{time.strftime('%Y%m%d')}.jsonl")
        record = {"device_id": device_id, "ts": ts, "event": event}
        with open(out_path, "a", encoding="utf-8") as f:
            f.write(json.dumps(record, ensure_ascii=False) + "
")
        return jsonify({"ok": True}), 200
    except Exception as e:
        return jsonify({"ok": False, "error": str(e)}), 400

if name == "main":
    # Порт задайте под вашу инфраструктуру
    app.run(host="0.0.0.0", port=9000)
PY

python ingest_server.py

Агрегация и аналитика в реальном времени

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

Потоковая агрегация поверх jsonl: периодически считывать новые строки и пересчитывать метрики.
Публикация в очередь (если у вас она есть): ingestion → stream → storage → dashboard.
Непосредственная выгрузка в OLAP (если инфраструктура позволяет).

Ниже — практичный пример «быстрого» аналитического агрегатора, который читает jsonl и обновляет простую статистику по источникам.

pip install pandas

cat > quick_analytics.py <<'PY'
import os, json, time
from collections import Counter

OUT_FILE = "./ingest_data/summary.txt"
DAY = time.strftime('%Y%m%d')
IN_FILE = f"./ingest_data/events_{DAY}.jsonl"

def safe_read():
    if not os.path.exists(IN_FILE):
        return []
    with open(IN_FILE, "r", encoding="utf-8") as f:
        return [json.loads(line) for line in f if line.strip()]

events = safe_read()
c = Counter()
for r in events:
    ip = r.get("event", {}).get("client_ip", "")
    if ip:
        c[ip] += 1

top = c.most_common(10)
with open(OUT_FILE, "w", encoding="utf-8") as f:
    f.write("Top client_ip by attempts
")
    for ip, cnt in top:
        f.write(f"{ip}\t{cnt}
")

print("Updated summary:", OUT_FILE)
PY

python quick_analytics.py

Для продвинутой аналитики добавьте:

кластеризацию по path, user_agent, временным паттернам;
ранжирование IP по скорости (attempts/min);
правила корреляции: «серии» обращений к /admin и /login;
хэширование и дедупликацию, чтобы не хранить лишнее.

Масштабирование кластера: несколько устройств Termux

Распределение по агентам даёт вам разнообразие сетевого контекста. Для масштабирования придерживайтесь стандарта:

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

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

Надёжность, безопасность и минимизация рисков

Чтобы система была полезной и безопасной:

Изолируйте окружение: honeypot не должен иметь доступ к вашим критичным данным.
Ограничьте права: агенту достаточно прав на чтение собственных логов и сетевое подключение к сборщику.
Сократите сбор данных: собирайте только нужные поля (ts, client_ip, method/path, user_agent). Избыточные поля повышают риски.
Шифруйте транспорт там, где возможно (TLS на сборщике). На уровне примера выше использован HTTP — в проде предпочтите HTTPS.
Следите за хранением: определите срок хранения jsonl и summary, реализуйте ротацию.

Практический план внедрения (короткий чек-лист)

Подготовьте один Termux-агент: поднимите имитатор и проверьте локальные JSON-логи.
Разверните сборщик в локальной/контролируемой сети и протестируйте приём POST на /ingest.
Включите forwarder.sh, убедитесь, что события уходят и spool пустеет.
Запустите аналитику: сначала простой top-N, затем усложните корреляции.
Добавляйте устройства по одному, контролируя качество данных и формат схемы.
Зафиксируйте политику хранения, доступов и ответственность участников.

Заключение

Распределённый honeypot‑кластер на базе Termux позволяет собрать ценную телеметрию о попытках доступа к имитируемым сервисам, агрегировать события в едином формате и анализировать их в «почти реальном времени». При грамотной архитектуре (агенты → сборщик → аналитика), строгих правовых рамках и принципе минимизации данных система становится эффективным инструментом для повышения защищённости.

Если вы хотите спроектировать кластер под вашу инфраструктуру (выбор схемы событий, настройка агентов, сборщика, хранилища и дашбордов, а также аудит безопасности и соответствия требованиям) — обратитесь в РыбинскЛАБ. Мы поможем внедрить решение и довести его до промышленной устойчивости.