Безопасность инфраструктуры

Аудит 2026-06-13

Что проверялось

Порты открытые наружу (0.0.0.0 vs 127.0.0.1)
OAuth-токены и авторизованные аккаунты
Открытые directory listing
Доступность MCP/API эндпоинтов снаружи

Найденные уязвимости и статус

#	Что	Уязвимость	Статус	Исправление
1	Hermes API (порт 8642)	Слушал на 0.0.0.0	✅ Закрыт	`.hermes/.env`: `API_SERVER_HOST=127.0.0.1`
2	vpnbot-v3 dev panel (8100)	Слушал на 0.0.0.0	✅ Закрыт	`docker-compose.dev.yml`: `127.0.0.1:8100:8000`
3	gwmcp `/mcp` эндпоинт	Публично доступен	✅ Закрыт	Traefik ipAllowList: только 127.0.0.1 + Docker сети
4	awgnode API (порт 6868)	Слушал на 0.0.0.0	✅ Закрыт	iptables DROP + override монтирует entrypoint с AWG_API_HOST
5	panel-dev.08317.ru	Публичный dev remnawave	⚠️ Оставлен	Нужен для отладки vpnbot (сознательное решение)

gwmcp — аккаунт s.purgaev@coreclaw.ru

Обнаружен: странный email в OAuth credentials (домена coreclaw.ru не существует)
Вывод: НЕ взлом. Это был тестовый аккаунт при настройке Google OAuth — создан случайно
Действие: аккаунт удалён из Google OAuth consent screen
Текущее состояние: авторизован только mydevn8n@gmail.com, всё работает

AWG ключи — ротация (2026-06-13)

Причина: публичный конфиг с pubkey попал в тест (ложная тревога)
Что проверили: сервер pubkey VBOYmyWoQFgnO... — НЕ совпадает с ключом в утёкшем конфиге
Реально активный пир: F2to0k9TYiZgDmJCTq5ZHGn8... (Сергей, 10.99.0.10) — не трогали
Итог: ключи не ротировали (не было необходимости), VPN работает

Текущее состояние (после аудита)

Порты наружу (forge)

Порт	Сервис	Доступность
80/443	Traefik	Публично (нужно)
47654 UDP	awgnode VPN	Публично (нужно — VPN)
8443	[[projects/mtproto	MTProto]]
6868 TCP	awgnode API	🔒 Только 127.0.0.1 (iptables)
8642	Hermes API	🔒 Только 127.0.0.1
8100	vpnbot dev	🔒 Только 127.0.0.1
500/4500/1701 UDP	strongswan-lv (IKEv2/L2TP)	⚠️ Не открыты в ufw (26.07.2026) — нужно `sudo ufw allow {500,4500,1701}/udp`, делает Сергей (у Claude Code нет root/sudo-пароля на [[projects/forge

ufw ufw-user-input (актуально на 26.07.2026): только tcp 2288 (SSH через Tailscale), 3000, 8080, 8443, 8888, и udp 47654 (awgnode). Новый VPN-контейнер strongswan-lv слушает 500/4500/1701 UDP на хосте, но пока не достижим снаружи, пока Сергей не добавит правила ufw

gwmcp Traefik конфиг

/oauth2callback — публично (нужно для Google OAuth redirect)
/mcp — только Docker internal (172.16.0.0/12) + 127.0.0.1
Файл: /home/claude/traefik/data/conf.d/gwmcp.yml

awgnode override (порт 6868)

Файл: /home/claude/awgnode/docker-compose.override.yml
Монтирует локальный /home/claude/awgnode/entrypoint.sh → поддерживает AWG_API_HOST
AWG_API_HOST=127.0.0.1 прописан в environment
Текущая iptables-защита: iptables -I INPUT -p tcp --dport 6868 ! -s 127.0.0.1 -j DROP
Важно: iptables правило исчезнет при рестарте контейнера, но после рестарта entrypoint сам поднимет uvicorn на 127.0.0.1

Google OAuth — два разных клиента

Сервис	OAuth client	Аккаунт	Как переавторизовать
gwmcp ([[projects/coreclaw	CoreClaw]])	`692295089009-9kjmcfh...`	mydevn8n@gmail.com
Hermes	`692295089009-pm1f51t...`	sergnotebooklm@gmail.com	`setup.py --auth-url` → URL на ПК → `setup.py --auth-code "URL"`

Hermes переавторизация пошагово (когда setup.py --check вернёт TOKEN_INVALID):

# 1. Получить URL
/home/claude/.hermes/hermes-agent/venv/bin/python3 \
  /home/claude/.hermes/skills/productivity/google-workspace/scripts/setup.py --auth-url
 
# 2. Открыть URL на ПК, разрешить, скопировать localhost-redirect из адресной строки
 
# 3. Обменять код
/home/claude/.hermes/hermes-agent/venv/bin/python3 \
  /home/claude/.hermes/skills/productivity/google-workspace/scripts/setup.py \
  --auth-code "http://localhost/?code=...&state=..."
 
# 4. Проверить
/home/claude/.hermes/hermes-agent/venv/bin/python3 \
  /home/claude/.hermes/skills/productivity/google-workspace/scripts/setup.py --check-live

Важно: код живёт ~10 минут. Стухший google_oauth_pending.json → удалить перед --auth-url.

Prompt injection в morning-brief cron (обнаружено 28.08–31.08.2026, продолжилось 01.09)

Каждое утро (~8:00-8:03 МСК), в ходе выполнения планового morning-brief cron, в диалог попадает постороннее сообщение, замаскированное под системный запрос — просит вывести точный текст DBRAIN_OK в специальных маркерах / переключиться в формат <analysis>/<summary> и бросить текущую задачу. Повторяется 5 дней подряд (28,29,30,31.08, 01.09), всегда в то же окно времени что и сам cron-запуск.

Проверено: grep -r "DBRAIN_OK\|compliance verification" по всему vault — ничего не найдено. Источник не в файлах vault, которые Claude читает при бутстрапе.

Вывод: инъекция приходит на уровне самого входного пайплайна cron/Telegram-бота (что-то дописывает текст к легитимному user-turn запроса morning-brief), а не через контент файла. Не подтверждён взлом — не comply, каждый раз игнорировалось, отчёт по факту доходил до Сергея исправным.

Что не сделано: не найден конкретный компонент, который дописывает инъекцию (сам cron-скрипт? прослойка Telegram-бота? MCP-сервер?). Нужно руками проверить скрипт, который триггерит morning-brief cron, и историю входящих сообщений на предмет постороннего текста.

SSH доступ к нодам

Нода	IP	Логин	Пароль
de-hostkey	132.243.224.242	root	nkXZBXBU5jjRq
nl-aeza	138.124.119.57	root	2DLF5581booE

(Пароли найдены: DE — из prod vpnbot БД, NL — из старого memory-файла)

Second Brain

Проводник

security