Как защитить VPS с ИИ-агентом: минимальная практическая настройка безопасности

Цель минимальной защиты — не сделать сервер неуязвимым. Нужно уменьшить доступную извне поверхность, ограничить последствия ошибки и сохранить возможность восстановить работу.

Практический порядок таков: резервный путь входа → SSH → firewall → bind сервисов → права процесса → журналирование → обновления → backup и restore. Если перепутать порядок, защитное изменение само может стать причиной простоя.

Не начинайте с отключения входа или включения firewall. Откройте отдельную SSH-сессию и оставьте текущую работающей. Убедитесь, что у провайдера VPS есть консоль или другой аварийный доступ. Сохраните копии изменяемых конфигурационных файлов без секретов и запишите, какие публичные порты действительно нужны.

Снимите безопасный минимум наблюдений:

lsb_release -a

ss -lntup

sudo ufw status verbose

Эти команды не исправляют сервер, но показывают, что вы собираетесь защищать. Не публикуйте вывод целиком: в нём могут быть имена процессов, адреса и внутренние детали.

Для повседневной эксплуатации используйте отдельного непривилегированного пользователя. Права sudo выдавайте только тому аккаунту, которому они действительно нужны. Публичный SSH-ключ добавьте в ~/.ssh/authorized_keys; приватный ключ остаётся на устройстве администратора и не отправляется агенту.

Проверяйте вход во второй сессии, не закрывая первую. Только после успешного подключения по ключу переходите к запрету паролей и root-login. Такой порядок сохраняет путь возврата, если в имени пользователя, пути к ключу или правах файла допущена ошибка.

В Ubuntu настройки OpenSSH могут собираться из основного файла и drop-in файлов. Создайте отдельный файл в /etc/ssh/sshd_config.d/, например 60-local-hardening.conf, чтобы изменение было понятно и обратимо.

В OpenSSH для большинства параметров используется первое найденное значение. Более ранний drop-in может перекрыть файл 60-local-hardening.conf. Проверяйте итог через sshd -T, включая правила Match; имя файла само по себе не доказывает, что настройка применена.

После того как вход по ключу доказан, обычно задают:

PasswordAuthentication no

PermitRootLogin no

Если инфраструктура использует иной утверждённый способ входа, сначала проверьте совместимость.

До reload выполните sudo sshd -t: команда проверяет синтаксис конфигурации и sanity host keys. Для просмотра эффективной конфигурации используйте sudo sshd -T, учитывая, что правила Match могут зависеть от пользователя и адреса.

Затем выполните sudo systemctl reload ssh и снова откройте новую SSH-сессию. Не ограничивайтесь тем, что текущая сессия не оборвалась: она могла сохраниться со старой конфигурацией.

Ожидаемый результат: новый пользователь входит по ключу в новой сессии; парольный вход и прямой root-login запрещены согласно выбранной политике; sshd -t завершается без ошибки.

Сначала разрешите действующий SSH-порт, затем добавьте действительно публичные сервисы и только после этого включайте UFW. Для типового веб-сервера это обычно SSH и вход reverse proxy на 80/443. Dashboard, база данных, внутренний API и порт агента не должны становиться публичными только ради удобной отладки.

Безопасная последовательность для стандартного SSH-профиля:

sudo ufw allow OpenSSH

sudo ufw default deny incoming

sudo ufw default allow outgoing

sudo ufw enable

sudo ufw status verbose

Если SSH слушает нестандартный порт, разрешите его точным правилом до enable. При ограничении по исходному IP заранее учтите, что адрес администратора может измениться.

Ожидаемый результат: доступ по SSH сохраняется, разрешены только утверждённые публичные сервисы, остальные входящие подключения блокируются.

Сервисный порт агента, dashboard и внутренние API привязывайте к loopback или приватной сети. Публичный доступ, если он нужен, организуйте через reverse proxy с TLS и отдельной аутентификацией.

Наличие firewall не отменяет безопасный bind. Две независимые границы уменьшают риск случайного открытия после будущего изменения правил.

Hermes Agent применяет pairing или allowlist для входящих личных сообщений, а группы по умолчанию ограничивает списком разрешённых чатов. Это не заменяет защиту VPS. Проверяйте каждую поверхность отдельно: сеть, операционную систему, права процесса и политику входящих сообщений.

Не запускайте весь рабочий набор от root. Выделите отдельного системного или обычного пользователя без интерактивного доступа, если он не требуется. Дайте процессу только нужные каталоги и операции.

Секреты храните вне репозитория и текста задания. У Hermes секретные значения находятся в ~/.hermes/.env, а обычные параметры — в ~/.hermes/config.yaml. Не печатайте секреты в командной строке, логах или диагностическом отчёте.

Если сервис управляется systemd, задайте явный User, WorkingDirectory, ExecStart и предсказуемую политику перезапуска. Дополнительные sandbox-параметры выбирайте после теста приложения. NoNewPrivileges, PrivateTmp, ProtectSystem и ограничения записи полезны, но могут сломать реальную функцию, если процессу нужен доступ к браузеру, медиа, Docker socket или рабочим файлам.

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

Автозапуск нужен не ради галочки. После reboot должно быть понятно, какой профиль стартовал, где лежит рабочая директория, почему процесс перезапустился и как его остановить.

Для systemd используйте:

systemctl status <service>

journalctl -u <service> --since today

Подставляйте имя реально созданного сервиса, а не копируйте условный шаблон.

Не пишите в журнал токены, заголовки авторизации, полные запросы с персональными данными и строки подключения. Hermes заявляет автоматическое редактирование секретов в собственных логах, но оператор всё равно обязан проверить дополнительные скрипты, reverse proxy и внешние инструменты.

На Ubuntu автоматические security updates обычно выполняет unattended-upgrades, а периодичность задаётся APT periodic configuration и systemd timers.

Проверьте:

systemctl status unattended-upgrades

/etc/apt/apt.conf.d/20auto-upgrades

/etc/apt/apt.conf.d/50unattended-upgrades

/var/log/unattended-upgrades/

Автоматическое обновление не гарантирует немедленную перезагрузку после обновления ядра. Решите заранее, кто видит reboot-required, когда допустимо окно перезапуска и каким smoke test подтверждается возврат агента.

В резервную копию включите код и проверяемую конфигурацию, пользовательские данные, базу состояния и список системных зависимостей. Секреты храните отдельно в защищённой системе: не превращайте обычный архив проекта в копию всех credentials.

Перед изменениями проверьте, какие данные Hermes хранит в ~/.hermes/, включая конфигурацию, state database, skills и cron.

Сделайте тест восстановления в отдельный каталог или на отдельной машине. Критерий — не наличие архива, а доказанный путь: файлы читаются, сервис стартует с безопасно восстановленными секретами, Telegram отвечает, нужные данные доступны, а старый или отозванный credential не используется.

Проводите перезагрузку в контролируемое окно. После возврата сервера проверьте:

1. Новую SSH-сессию по ключу.
2. sudo sshd -t.
3. sudo ufw status verbose.
4. Ожидаемые порты через ss -lntup.
5. Состояние и последние логи сервиса.
6. Ответ агента в разрешённом Telegram-чате.
7. Недоступность внутренних портов с внешней машины.
8. Чтение восстановленного тестового файла.

Готовность подтверждена, когда все проверки проходят после полного закрытия прежней SSH-сессии. До этого сервер лишь кажется работающим.

Отключил пароль — потерял доступ.

Вернитесь через оставленную сессию или консоль провайдера. Проверьте пользователя, authorized_keys, права каталога .ssh и эффективную конфигурацию sshd -T.

После UFW пропал SSH.

Правило было добавлено не для того порта или интерфейса. Используйте консоль провайдера, скорректируйте правило и только потом снова включайте firewall.

Dashboard открывается из интернета.

Проверьте bind процесса через ss -lntup, правила reverse proxy и UFW. Закройте прямой порт и оставьте только утверждённый путь.

После reboot агент не отвечает.

Сверьте systemctl status, journalctl -u, пользователя сервиса, WorkingDirectory, активный Hermes profile и доступ к требуемым runtime-файлам.

Ужесточение systemd сломало инструмент.

Добавляйте sandbox-настройки по одной, запускайте реальный сценарий и расширяйте только конкретно нужное право. Не отключайте всю защиту из-за одной несовместимости.

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

Не копируйте команды вслепую на нестандартную систему. Имена сервисов, SSH-порт, облачная консоль, IPv6, reverse proxy и способ запуска агента могут отличаться. Сначала проверяйте фактическую конфигурацию, затем меняйте минимальный необходимый слой.

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

Если Hermes Agent ещё не установлен, сначала используйте материал «Как установить Hermes Agent на VPS и получить работающего личного ИИ-агента». Больше бесплатных инструкций собрано в разделе статей «Человек 2.0», а полная программа настройки агента — на странице воркшопа.

Нужно ли менять SSH-порт?

Это не основная мера защиты. Новый порт уменьшает шум автоматического сканирования, но не заменяет ключи, запрет ненужной аутентификации, firewall и обновления.

Можно ли открыть dashboard только через VPN?

Да, приватная сеть или VPN часто лучше прямого публичного доступа. Но VPN тоже требует обновлений, контроля учётных записей и аварийного доступа.

Достаточно ли UFW?

Нет. UFW управляет сетевыми правилами, но не ограничивает права процесса, не защищает секреты и не проверяет настройки входящих сообщений агента.

Нужно ли включать все systemd sandbox-параметры сразу?

Нет. Выбирайте их по возможностям сервиса и проверяйте реальный пользовательский сценарий после каждого изменения.

• Ubuntu Server: OpenSSH server
• Ubuntu Server: Firewall
• Ubuntu Server: Automatic updates
• Ubuntu 24.04: sshd_config(5)
• Ubuntu 24.04: sshd(8)
• Ubuntu 24.04: ufw(8)
• systemd.exec
• systemd.service
• Hermes Agent Security
• Hermes Agent Configuration
• Hermes Agent Messaging
• Hermes Agent Web Dashboard

Команды сверены при подготовке 10 сентября 2026 года; официальные источники повторно проверены 14 октября 2026 года. Перед применением проверьте настройки своей системы. Технический TTL статьи: 30 дней.