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

Что такое OpenClaw и почему его нужно защищать в первую очередь

OpenClaw — это AI-агент для self-hosted размещения. Вы запускаете его на собственном сервере, подключаете к большой языковой модели, после чего он может выполнять shell-команды, управлять браузером, читать и изменять ваши файлы, а также отвечать на сообщения, которые вы отправляете ему из чат-приложений. Эти широкие возможности — главная цель инструмента и одновременно основной риск. Безопасность агента, способного выполнять любые команды, ограничена лишь защищенностью сервера, на котором он работает, и установленными вами лимитами.

Два факта определяют подход в этом руководстве. Во-первых, OpenClaw спроектирован так, чтобы вы сами занимались его защитой. Его модель безопасности возлагает ответственность за строгие политики инструментов, песочницы и тщательную настройку прав доступа на оператора, а не на безопасные настройки по умолчанию. Во-вторых, проект уже столкнулся с серьезными проблемами безопасности: в базе National Vulnerability Database числится 199 CVE для OpenClaw, опубликованных только в марте 2026 года, из них 46 — за четыре дня с 4 по 7 марта (данные проверены 13 октября 2026 года). Среди уязвимостей того месяца — критическая ошибка повышения привилегий CVE-2026-32922 с оценкой 9.9 из 10, исправленная в версии 2026.3.11. Эти факты не означают, что вам следует избегать OpenClaw. Они означают, что его нельзя запускать «как попало», и это руководство предлагает осторожный подход. Часть этого подхода — заранее определить, что агент может делать без запроса подтверждения. Это выбор, который Claude Code делает явным через свои режимы разрешений; сервер, за которым вы не сидите постоянно, требует более строгих настроек, чем ноутбук, за которым вы наблюдаете.

Есть и хорошие новости. OpenClaw уже делает один безопасный выбор за вас: его шлюз, единственный процесс, управляющий всем, по умолчанию слушает только loopback-адрес. Он недоступен из Интернета, если вы специально не откроете к нему доступ. Большая часть работы ниже направлена на то, чтобы сохранить это состояние и ограничить радиус поражения в случае сбоя.

Создание непривилегированного пользователя для OpenClaw

Никогда не запускайте агент от имени root. Если OpenClaw работает с правами root и происходит сбой — будь то ошибка в коде, неверная инструкция или CVE, подобная упомянутой выше, — масштаб ущерба ничем не ограничен. Создайте выделенного системного пользователя без доступа к оболочке входа и без прав sudo, а затем запускайте агент от имени этого пользователя:

sudo useradd --system --home /opt/openclaw --shell /usr/sbin/nologin openclaw

Все файлы, принадлежащие OpenClaw, находятся в /opt/openclaw и принадлежат этой учетной записи. Это самый важный этап, основанный на том же принципе, что описан в запуске сервисов от имени непривилегированного пользователя: учетная запись, от имени которой работает агент, определяет предел того, что он может повредить.

Установка OpenClaw

OpenClaw распространяется как npm-пакет, поэтому сначала установите Node.js, если его нет на сервере; проект требует Node 24.16 или новее, либо 26.1 или новее. Установите пакет глобально, что добавит бинарный файл openclaw в PATH для всех пользователей, а затем выполните однократную процедуру начальной настройки:

sudo npm install -g openclaw@latest --allow-scripts=openclaw
sudo -u openclaw openclaw onboard

Флаг --allow-scripts=openclaw необходим, так как npm 12 по умолчанию блокирует скрипты установки пакетов, а OpenClaw требует их выполнения. В npm 11.15 или более старых версиях, где такой опции нет, этот флаг можно опустить. Запуск настройки от имени пользователя openclaw гарантирует, что конфигурация агента попадет в его домашнюю директорию /opt/openclaw, а не в директорию root. Проект также предлагает установщик curl -fsSL https://openclaw.ai/install.sh | bash, который выполняет ту же установку одной командой. Пропустите флаг --install-daemon во время настройки: он зарегистрирует собственный сервис OpenClaw, а systemd-юнит, который вы создадите ниже, обеспечивает более строгие ограничения.

Оставьте шлюз на loopback-интерфейсе за межсетевым экраном

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

Установите межсетевой экран с политикой default-deny перед сервером, чтобы исключить случайное открытие портов:

sudo ufw default deny incoming
sudo ufw allow 22/tcp
sudo ufw enable

Избегайте двух распространенных ошибок. Межсетевой экран, настроенный только для IPv4, может оставить сервис доступным через IPv6 — это именно та брешь в IPv6-безопасности, на которую попадаются многие администраторы. Если вам нужно получить доступ к шлюзу со своего ноутбука, не открывайте порт. Используйте VPN или SSH-туннель, чтобы агент никогда не принимал соединения из открытого интернета.

Изоляция секретов

OpenClaw требует API-ключ для любой языковой модели, к которой вы подключаетесь. Этот ключ может расходовать ваши средства и, через агента, действовать от вашего имени, поэтому обращайтесь с ним как с паролем. Не храните его в unit-файле или в репозитории. Поместите его в файл, который может прочитать только пользователь OpenClaw:

sudo install -o openclaw -g openclaw -m 600 /dev/null /opt/openclaw/openclaw.env
sudoedit /opt/openclaw/openclaw.env      # add ANTHROPIC_API_KEY=... or your model provider's key

Systemd-юнит загружает этот файл с помощью EnvironmentFile, поэтому ключ попадает в процесс, не попадая при этом в командную строку, логи или историю оболочки. Этот шаблон применим к любому секрету на сервере: укрепление безопасности self-hosted Vaultwarden сводится к защите его административного токена и файла резервной копии, а не к шифрованию, поскольку именно права доступа к файлам фактически определяют, кто может прочитать секрет в состоянии покоя.

Запуск в качестве защищенного systemd-сервиса

Запуск агента через systemd обеспечивает автоматический перезапуск, чистые логи через journalctl и, что наиболее важно, набор опций изоляции на уровне ядра, которые ограничивают возможности процесса в случае его компрометации. Наиболее значимые для агента опции: NoNewPrivileges, чтобы процесс не мог получить новые привилегии, ProtectSystem=strict для перевода файловой системы в режим «только чтение» (за исключением разрешенных путей), PrivateTmp для создания изолированного временного каталога и ProtectHome, чтобы запретить доступ к домашним директориям.

Создайте готовый защищенный unit-файл, а затем скопируйте его в /etc/systemd/system/openclaw.service:

Unit запускает openclaw gateway — основной процесс, управляющий агентом. Если which openclaw указывает на другой путь в вашей системе, измените ExecStart соответствующим образом. Полный разбор этих директив, а также daemon-reload и enable --now, приведен в запуск программы как systemd-сервиса. Краткая инструкция после того, как вы вставили содержимое unit-файла:

sudo systemctl daemon-reload
sudo systemctl enable --now openclaw

Усиление защиты сервера

Безопасность агента зависит от защищенности сервера, на котором он работает. Для завершения настройки добавьте два уровня защиты. Переведите SSH на аутентификацию только по ключам и отключите вход для пользователя root, как описано в укрепление SSH на VPS, чтобы исключить возможность подбора пароля для вашей учетной записи. Затем установите Fail2ban, чтобы блокировать сканеры, которые постоянно проверяют открытые порты. Эти меры не затрагивают OpenClaw напрямую, но перекрывают пути, которые злоумышленник мог бы использовать для доступа к приложению.

Регулярное обновление

Раскрытие информации в марте 2026 года — наиболее убедительный аргумент в пользу поддержания актуальности ПО. Ошибка повышения привилегий в агенте гораздо опаснее, чем в обычном веб-приложении, поскольку агент уже имеет право выполнять команды. Следите за релизами проекта, оперативно устанавливайте обновления безопасности и относитесь к обновлению OpenClaw как к плановому обслуживанию, а не как к задаче, которую можно отложить.

Чтобы понять, что именно вы защищаете, ознакомьтесь с архитектурой агента типа OpenClaw, где описаны все компоненты системы, а также с руководством по развертыванию собственного ИИ-агента на VPS, в котором рассматривается общая структура любого агента. Если вы планируете запустить второй агент параллельно, помните, что два сеанса Claude Code на одной VPS могут передавать задачи друг другу, поэтому каждый из них должен использовать собственную учетную запись и собственные ограничения, а не наследовать ваши права.

FAQ

Безопасно ли запускать OpenClaw на публичном VPS?

Это может быть безопасно при условии усиления защиты. OpenClaw обладает широкими возможностями: он выполняет shell-команды и управляет браузером, поэтому небрежная настройка действительно опасна. В проекте уже была критическая уязвимость (CVE-2026-32922 в марте 2026 года). Модель безопасности предполагает, что вы, как оператор, самостоятельно установите ограничения. Запускайте его от имени непривилегированного пользователя, держите шлюз на loopback за межсетевым экраном с политикой default-deny, изолируйте API-ключи и запускайте сервис как защищенный systemd-юнит.

Стоит ли открывать шлюз OpenClaw в интернет?

Нет. По умолчанию шлюз привязывается к loopback, и его следует оставить в таком состоянии. Это единственный процесс, управляющий агентом, поэтому открытый шлюз — это удаленный путь к системе, которая по своей сути выполняет команды. Если вам нужен удаленный доступ, используйте VPN или SSH-туннель вместо открытия порта.

От имени какого пользователя должен работать OpenClaw?

От имени выделенного системного пользователя без оболочки входа и без прав sudo, но ни в коем случае не от root. Если агент будет скомпрометирован, учетная запись пользователя ограничит масштаб ущерба. Этот пользователь должен владеть только собственными файлами в директории вроде /opt/openclaw и ничем больше.

Как обеспечить безопасность API-ключей OpenClaw?

Храните их в файле, доступном для чтения только пользователю OpenClaw (права 600), и загружайте в сервис с помощью EnvironmentFile в systemd. Не храните ключ в файле юнита, в истории командной оболочки или в git-репозиториях. Смените ключ, если возникли подозрения в его утечке.