DanLevy.net

Мой ИИ-ассистент дал мне доступ к оболочке

Как защитить локальную или VPS-установку OpenClaw/Moltbot

OpenClaw (ранее Clawdbot/Moltbot) предоставляет персонального ИИ-ассистента, работающего через WhatsApp, Slack, Discord, iMessage и другие каналы. Но если вы выставляете его шлюз, управление узлами или SSH в публичный интернет без надёжной аутентификации, вы даёте посторонним путь к получению доступа к оболочке на вашей машине.

Это руководство показывает самый безопасный вариант по умолчанию: держите шлюз OpenClaw на loopback-интерфейсе, открывайте доступ только к вашей tailnet-сети через Tailscale Serve, защищайте SSH и проверяйте извне, что шлюз не доступен публично.

Стремительное распространение проекта выявило реальные проблемы с безопасностью: сканирование Shodan обнаружило 2 847 открытых экземпляров за первые несколько недель, а аудит безопасности на GitHub сообщил о 512 находках в кодовой базе. Часть из этого — вывод автоматических сканеров, а часть изменилась после переименования в OpenClaw в январе 2026 года, так что воспринимайте эти цифры как предупреждение, а не как точный текущий счётчик уязвимостей. Вам не нужно быть экспертом по безопасности — достаточно не публиковать операторские поверхности до развёртывания.


Что именно вы выставляете наружу

В зависимости от того, как вы установили и настроили доступ, есть три поверхности, которые стоит проверить:

Текущая документация OpenClaw по удалённому доступу говорит, что WebSocket шлюза по умолчанию привязывается к loopback-интерфейсу и рекомендует оставлять его только на loopback, если вы осознанно не выбираете привязку к LAN/tailnet/кастомному интерфейсу. Это правильно. Риск появляется, когда вы переопределяете это поведение по умолчанию, публикуете порты Docker, добавляете обратный прокси, включаете Funnel или оставляете SSH открытым для всех.

Шлюз — самая важная поверхность. Это операторский интерфейс вашего ассистента, включая пути вызова инструментов. Если он доступен из интернета и аутентификация отсутствует, слаба, обходится или leaking, злоумышленник может управлять агентом или вызывать инструменты с правами вашего пользователя.

Управление браузером почти так же чувствительно. Текущая документация OpenClaw рекомендует запускать управление браузером через сопряжённый узел на машине с браузером и относиться к сопряжению узлов как к операторскому доступу. Если шлюз может вызывать system.run на сопряжённом узле, это удалённое выполнение кода на этом узле, с учётом политики узлов шлюза и собственных подтверждений выполнения узла.

SSH — это SSH. Если вы используете аутентификацию по паролю, попытки брутфорса неизбежны на публичном VPS.


Решение через Tailscale

Для OpenClaw Tailscale даёт удалённый доступ без публикации операторских сервисов:

  1. Ваш экземпляр OpenClaw работает на VPS или локальной машине
  2. Шлюз остаётся привязанным к loopback и доступен через Tailscale Serve, либо привязывается напрямую к IP tailnet с явной аутентификацией
  3. Вы устанавливаете Tailscale как на сервер, так и на свои личные устройства
  4. Вы получаете доступ к OpenClaw через его Tailscale IP или имя MagicDNS
  5. Все остальные в интернете ничего не видят, если вы сознательно не включили 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 или локальном сервере:

Terminal window
# Установка Tailscale
curl -fsSL https://tailscale.com/install.sh | sh
# Аутентификация (откроется браузер для входа)
sudo tailscale up
# Получите ваш Tailscale IP
tailscale 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:

Terminal window
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 после подтверждения, что контейнер всё ещё получает трафик:

Terminal window
TAILSCALE_IP=$(tailscale ip -4)
docker run ... -p "$TAILSCALE_IP:18789:18789" ...

После любого изменения Docker проверьте извне с помощью nmap и локально с помощью ss. Docker может обойти или изменить порядок предположений хост-файрвола, если вы это не учли.

Шаг 3: Защита SSH

Даже с Tailscale следует правильно настроить SSH:

Terminal window
# Держите текущую 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 no
PermitRootLogin no
KbdInteractiveAuthentication no
EOF
# Проверьте перед перезагрузкой. Не пропускайте это.
sudo sshd -t
sudo systemctl reload ssh || sudo systemctl reload sshd

Это отключает вход по паролю и вход от root. Следующий шаг использует UFW для полного предотвращения публичного SSH, всё ещё разрешая SSH через tailscale0.

Шаг 4: Правила файрвола

Настройте файрвол как второй слой защиты:

Terminal window
# Используя UFW (Ubuntu/Debian)
sudo ufw allow in on tailscale0
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw enable
sudo ufw delete allow 22/tcp || true
sudo ufw reload
sudo ufw status verbose

Собственное руководство Tailscale по усилению защиты Ubuntu использует ту же форму: разрешить tailscale0, запретить другой входящий трафик, затем проверить, что публичный SSH таймаутится, а SSH по адресу 100.x.y.z всё ещё работает. Если вы запускаете публичный сайт на том же VPS, оставьте только те публичные правила, которые вам действительно нужны, например 80/tcp и 443/tcp.


Проверка вашей экспозиции

Проверка открытых портов извне

С машины, которая НЕ находится в вашей сети Tailscale:

Terminal window
# Проверка, открыты ли распространённые публичные порты
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:

Terminal window
# Показать все слушающие порты и то, к чему они привязаны
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 включает команду аудита безопасности, которая проверяет вашу конфигурацию на соответствие лучшим практикам безопасности:

Terminal window
openclaw security audit --deep
openclaw security audit --deep --fix

Аудит проверяет экспозицию шлюза, режим Tailscale, настройки аутентификации, доступ к каналам, политику инструментов, инвентарь плагинов и права файлов. Воспринимайте --fix как полезного помощника, а не как замену чтению результатов.


Что это не решает

Tailscale убирает самую большую ошибку: публичную экспозицию операторских поверхностей. Но он не решает всё:

Хранение учётных данных: OpenClaw хранит транскрипты сессий, OAuth-токены и API-ключи на диске. Убедитесь, что у них правильные права файлов (chmod 600 для файлов, chmod 700 для приватных директорий конфигурации) и они не находятся в системе контроля версий. Встроенный аудит проверяет это.

Песочница плагинов: Плагины работают с полными правами вашего пользователя. Устанавливайте плагины только из доверенных источников и проверяйте, какие capabilities они запрашивают. Инструмент аудита инвентаризирует установленные плагины.

Безопасность устройств: Если кто-то скомпрометирует ваш аккаунт Tailscale или украдёт устройство в вашей tailnet, он получит доступ к вашему экземпляру OpenClaw. Включите авторизацию устройств Tailscale, чтобы требовать подтверждение для новых устройств.


Чек-лист развёртывания

Прежде чем считать ваш экземпляр OpenClaw/Moltbot готовым к продакшену:


Ресурсы