Ваш ИИ-помощник дал мне доступ к шеллу

Как защитить локальный или VPS-сервер OpenClaw/Moltbot

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

Это руководство показывает самый безопасный вариант по умолчанию: держать шлюз 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 открытым для всего мира.

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

Управление браузером почти так же чувствительно. Текущая документация 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 может аутентифицировать трафик панели управления и WebSocket с помощью заголовков идентификации Tailscale и проверять источник через tailscale whois. Это правильный режим для большинства личных развёртываний.

Режим Funnel открывает шлюз публично через публичный endpoint Tailscale. В документации Tailscale сказано, что Funnel направляет трафик из интернета к локальному сервису. OpenClaw отказывается запускать Funnel, если режим аутентификации шлюза не password, но вы всё равно выбираете публичную открытость операторской поверхности.

В документации OpenClaw по безопасности ясно сказано, что инъекция промптов и доступ к инструментам — основные риски для персонального ассистента. Не давайте агенту возможности тихо сделать себя публичным. Используйте Serve осознанно, избегайте Funnel, если вам действительно не нужен публичный доступ, и требуйте подтверждения выполнения для любых команд tailscale.

Безопасная настройка OpenClaw

Шаг 1: Установка Tailscale

На вашем VPS или локальном сервере:

# Установка 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:

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 или другом контейнерном рантайме, будьте особенно осторожны с публикацией портов. Публикация вида -p 18789:18789 обычно биндится на все интерфейсы хоста. Предпочитайте loopback плюс Tailscale Serve, или привязывайте сторону хоста явно к Tailscale IP после того, как убедитесь, что контейнер всё ещё получает трафик:

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

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

Шаг 3: Блокировка SSH

Даже с Tailscale стоит надёжно защитить SSH:

# Держите текущую SSH-сессию открытой.
# Сначала с клиентской машины убедитесь, что можете подключиться по SSH через Tailscale:
ssh ваш-пользователь@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: Правила фаервола

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

# Используя 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:

# Проверьте, открыты ли распространённые публичные порты
nmap -p 22,80,443,18789 ВАШ_ПУБЛИЧНЫЙ_IP

# Ожидаемый вывод для защищённого экземпляра:
# 22/tcp   filtered ssh
# 18789/tcp filtered unknown

Если 22 или 18789 показывает open вместо filtered или closed, у вас проблема. Если 80 или 443 открыт, убедитесь, что это только ваш намеренный публичный сайт или endpoint 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 --deep
openclaw security audit --deep --fix

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

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

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

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

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

Безопасность устройств: Если кто-то скомпрометирует ваш аккаунт 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 или Tailscale IP
• Файлы учётных данных имеют права 600, а приватные конфигурационные директории — 700
• Запущен openclaw security audit --deep и обработаны все находки
• При использовании управления Tailscale через OpenClaw включены подтверждения выполнения
• Настроено регулярное резервное копирование (данные OpenClaw + конфиги)

Ресурсы

• OpenClaw Security Guide
• OpenClaw Tailscale Integration
• Tailscale Serve CLI Reference
• Tailscale Funnel
• Use UFW to Lock Down an Ubuntu Server
• Security Audit: 512 Findings (GitHub Issue)
• Nmap Network Scanning Guide