Мой ИИ-ассистент дал мне доступ к оболочке
Как защитить локальную или VPS-установку OpenClaw/Moltbot
OpenClaw (ранее Clawdbot/Moltbot) предоставляет персонального ИИ-ассистента, работающего через WhatsApp, Slack, Discord, iMessage и другие каналы. Но если вы выставляете его шлюз, управление узлами или SSH в публичный интернет без надёжной аутентификации, вы даёте посторонним путь к получению доступа к оболочке на вашей машине.
Это руководство показывает самый безопасный вариант по умолчанию: держите шлюз OpenClaw на loopback-интерфейсе, открывайте доступ только к вашей tailnet-сети через Tailscale Serve, защищайте SSH и проверяйте извне, что шлюз не доступен публично.
Стремительное распространение проекта выявило реальные проблемы с безопасностью: сканирование Shodan обнаружило 2 847 открытых экземпляров за первые несколько недель, а аудит безопасности на GitHub сообщил о 512 находках в кодовой базе. Часть из этого — вывод автоматических сканеров, а часть изменилась после переименования в OpenClaw в январе 2026 года, так что воспринимайте эти цифры как предупреждение, а не как точный текущий счётчик уязвимостей. Вам не нужно быть экспертом по безопасности — достаточно не публиковать операторские поверхности до развёртывания.
Что именно вы выставляете наружу
В зависимости от того, как вы установили и настроили доступ, есть три поверхности, которые стоит проверить:
- Порт 22: SSH-доступ на VPS
- Порт 18789: Панель управления шлюзом и WebSocket API
- Управление браузером/узлами: удалённое выполнение кода и автоматизация браузера через модель шлюз/узел
Текущая документация OpenClaw по удалённому доступу говорит, что WebSocket шлюза по умолчанию привязывается к loopback-интерфейсу и рекомендует оставлять его только на loopback, если вы осознанно не выбираете привязку к LAN/tailnet/кастомному интерфейсу. Это правильно. Риск появляется, когда вы переопределяете это поведение по умолчанию, публикуете порты Docker, добавляете обратный прокси, включаете Funnel или оставляете SSH открытым для всех.
Шлюз — самая важная поверхность. Это операторский интерфейс вашего ассистента, включая пути вызова инструментов. Если он доступен из интернета и аутентификация отсутствует, слаба, обходится или leaking, злоумышленник может управлять агентом или вызывать инструменты с правами вашего пользователя.
Управление браузером почти так же чувствительно. Текущая документация OpenClaw рекомендует запускать управление браузером через сопряжённый узел на машине с браузером и относиться к сопряжению узлов как к операторскому доступу. Если шлюз может вызывать system.run на сопряжённом узле, это удалённое выполнение кода на этом узле, с учётом политики узлов шлюза и собственных подтверждений выполнения узла.
SSH — это SSH. Если вы используете аутентификацию по паролю, попытки брутфорса неизбежны на публичном VPS.
Решение через Tailscale
Для OpenClaw Tailscale даёт удалённый доступ без публикации операторских сервисов:
- Ваш экземпляр OpenClaw работает на VPS или локальной машине
- Шлюз остаётся привязанным к loopback и доступен через Tailscale Serve, либо привязывается напрямую к IP tailnet с явной аутентификацией
- Вы устанавливаете Tailscale как на сервер, так и на свои личные устройства
- Вы получаете доступ к OpenClaw через его Tailscale IP или имя MagicDNS
- Все остальные в интернете ничего не видят, если вы сознательно не включили Funnel или другой публичный прокси
Стоит ли доверить OpenClaw управление Tailscale?
OpenClaw имеет встроенную интеграцию с Tailscale, которая может настроить tailscale serve или tailscale funnel для шлюза.
Режим Serve оставляет всё только в вашей tailnet-сети. Шлюз остаётся привязанным к 127.0.0.1, а Tailscale обрабатывает маршрутизацию и HTTPS. Когда включён gateway.auth.allowTailscale, OpenClaw может аутентифицировать трафик Control UI/WebSocket с использованием заголовков идентичности Tailscale и проверять источник через tailscale whois. Это правильный режим для большинства персональных установок.
Режим Funnel открывает шлюз публично через функцию публичной конечной точки Tailscale. Собственная документация Tailscale описывает Funnel как маршрутизацию трафика из более широкого интернета к локальному сервису. OpenClaw отказывается запускать Funnel, если режим аутентификации шлюза не password, но вы всё равно выбираете публичную экспозицию операторской поверхности.
Документация по безопасности OpenClaw ясно указывает, что инъекции промптов и доступ к инструментам — ключевые риски для персонального ассистента. Не давайте агенту возможность тихо сделать себя публичным. Используйте Serve осознанно, избегайте Funnel, если вам действительно не нужен публичный доступ, и требуйте подтверждения выполнения для любой команды tailscale.
Настройка OpenClaw с защитой
Шаг 1: Установка Tailscale
На вашем VPS или локальном сервере:
# Установка Tailscalecurl -fsSL https://tailscale.com/install.sh | sh
# Аутентификация (откроется браузер для входа)sudo tailscale up
# Получите ваш Tailscale IPtailscale ip -4# Вывод: 100.x.x.xНа клиентской машине установите Tailscale с официальной страницы загрузки и войдите в ту же tailnet-сеть.
Теперь обе машины находятся в одной частной сети. Вы можете пинговать ваш VPS по его Tailscale IP, и трафик пойдёт через зашифрованный туннель.
Шаг 2: Настройка OpenClaw для работы с Tailscale
Самый безопасный текущий паттерн: держите шлюз на loopback и открывайте его для вашей tailnet через Tailscale Serve.
В конфигурации OpenClaw:
{ gateway: { bind: "loopback", tailscale: { mode: "serve" }, },}Затем запустите шлюз с Serve:
openclaw gateway --tailscale serveДокументация OpenClaw говорит, что это держит шлюз на 127.0.0.1, а Tailscale обеспечивает HTTPS и маршрутизацию tailnet. Вы открываете его по адресу https://<magicdns-name>/, а не по публичному IP вашего VPS.
Если вы предпочитаете прямую привязку к tailnet вместо Serve, используйте явную аутентификацию шлюза:
{ gateway: { bind: "tailnet", auth: { mode: "token", token: "замените-на-длинный-случайный-токен", }, },}Затем подключитесь с другого устройства tailnet:
http://<tailscale-ip>:18789/ws://<tailscale-ip>:18789Если вы работаете в Docker или другом контейнерном runtime, будьте особенно осторожны с публикацией портов. Публикация вида -p 18789:18789 обычно привязывается ко всем интерфейсам хоста. Предпочитайте loopback плюс Tailscale Serve или явно привяжите сторону хоста к IP Tailscale после подтверждения, что контейнер всё ещё получает трафик:
TAILSCALE_IP=$(tailscale ip -4)docker run ... -p "$TAILSCALE_IP:18789:18789" ...После любого изменения Docker проверьте извне с помощью nmap и локально с помощью ss. Docker может обойти или изменить порядок предположений хост-файрвола, если вы это не учли.
Шаг 3: Защита SSH
Даже с Tailscale следует правильно настроить SSH:
# Держите текущую SSH-сессию открытой во время этих действий.# Сначала с клиентской машины подтвердите, что можете подключиться по SSH через Tailscale:ssh your-user@SERVER_TAILSCALE_IP
# Поместите усиление защиты в drop-in файл вместо перезаписи sshd_config.sudo tee /etc/ssh/sshd_config.d/99-openclaw-hardening.conf >/dev/null <<'EOF'PasswordAuthentication noPermitRootLogin noKbdInteractiveAuthentication noEOF
# Проверьте перед перезагрузкой. Не пропускайте это.sudo sshd -tsudo systemctl reload ssh || sudo systemctl reload sshdЭто отключает вход по паролю и вход от root. Следующий шаг использует UFW для полного предотвращения публичного SSH, всё ещё разрешая SSH через tailscale0.
Шаг 4: Правила файрвола
Настройте файрвол как второй слой защиты:
# Используя UFW (Ubuntu/Debian)sudo ufw allow in on tailscale0sudo ufw default deny incomingsudo ufw default allow outgoingsudo ufw enablesudo ufw delete allow 22/tcp || truesudo ufw reloadsudo ufw status verboseСобственное руководство Tailscale по усилению защиты Ubuntu использует ту же форму: разрешить tailscale0, запретить другой входящий трафик, затем проверить, что публичный SSH таймаутится, а SSH по адресу 100.x.y.z всё ещё работает. Если вы запускаете публичный сайт на том же VPS, оставьте только те публичные правила, которые вам действительно нужны, например 80/tcp и 443/tcp.
Проверка вашей экспозиции
Проверка открытых портов извне
С машины, которая НЕ находится в вашей сети Tailscale:
# Проверка, открыты ли распространённые публичные портыnmap -p 22,80,443,18789 ВАШ_ПУБЛИЧНЫЙ_IP
# Ожидаемый вывод для защищённого экземпляра:# 22/tcp filtered ssh# 18789/tcp filtered unknownЕсли 22 или 18789 показывает open вместо filtered или closed, у вас проблема. Если 80 или 443 открыты, убедитесь, что это только ваш преднамеренный публичный сайт или конечная точка Tailscale Funnel, а не шлюз OpenClaw по ошибке.
Проверка слушающих портов локально
На вашем сервере OpenClaw:
# Показать все слушающие порты и то, к чему они привязаныsudo ss -tulpn | grep LISTEN
# Ищите строки вроде этой (хорошо для Serve):# tcp LISTEN 0 128 127.0.0.1:18789 *:*## Или такой (приемлемо для прямой привязки к tailnet с аутентификацией):# tcp LISTEN 0 128 100.x.y.z:18789 *:*## НЕ такой (плохо):# tcp LISTEN 0 128 0.0.0.0:18789 *:*Если вы видите 0.0.0.0 или ::: (эквивалент IPv6), этот сервис доступен всему миру.
Встроенный аудит безопасности
OpenClaw включает команду аудита безопасности, которая проверяет вашу конфигурацию на соответствие лучшим практикам безопасности:
openclaw security audit --deepopenclaw security audit --deep --fixАудит проверяет экспозицию шлюза, режим Tailscale, настройки аутентификации, доступ к каналам, политику инструментов, инвентарь плагинов и права файлов. Воспринимайте --fix как полезного помощника, а не как замену чтению результатов.
Что это не решает
Tailscale убирает самую большую ошибку: публичную экспозицию операторских поверхностей. Но он не решает всё:
Хранение учётных данных: OpenClaw хранит транскрипты сессий, OAuth-токены и API-ключи на диске. Убедитесь, что у них правильные права файлов (chmod 600 для файлов, chmod 700 для приватных директорий конфигурации) и они не находятся в системе контроля версий. Встроенный аудит проверяет это.
Песочница плагинов: Плагины работают с полными правами вашего пользователя. Устанавливайте плагины только из доверенных источников и проверяйте, какие capabilities они запрашивают. Инструмент аудита инвентаризирует установленные плагины.
Безопасность устройств: Если кто-то скомпрометирует ваш аккаунт Tailscale или украдёт устройство в вашей tailnet, он получит доступ к вашему экземпляру OpenClaw. Включите авторизацию устройств Tailscale, чтобы требовать подтверждение для новых устройств.
Чек-лист развёртывания
Прежде чем считать ваш экземпляр OpenClaw/Moltbot готовым к продакшену:
- Tailscale установлен и аутентифицирован как на сервере, так и на клиенте
- Шлюз оставлен на loopback с Tailscale Serve или привязан к
tailnetс явной аутентификацией - SSH настроен на отключение аутентификации по паролю и входа root
- Файрвол (UFW или iptables/nftables) настроен на разрешение
tailscale0и запрет ненужного публичного входящего трафика - Внешнее сканирование nmap показывает все порты
filteredилиclosed - Внутренний
ss -tulpnпоказывает шлюз, привязанный только к127.0.0.1,::1или IP Tailscale - Файлы учётных данных имеют права 600, приватные директории конфигурации — 700
- Запущен
openclaw security audit --deepи все находки устранены - Если используется управление Tailscale через OpenClaw, включены подтверждения выполнения
- Настроены регулярные бэкапы (данные OpenClaw + конфигурации)
Ресурсы
- Руководство по безопасности OpenClaw
- Интеграция OpenClaw с Tailscale
- Справочник Tailscale Serve CLI
- Tailscale Funnel
- Использование UFW для защиты Ubuntu-сервера
- Аудит безопасности: 512 находок (GitHub Issue)
- Руководство по сканированию сети Nmap