Как защитить VPS перед развертыванием

Итак, откройте вторую SSH-сессию, прежде чем выполнять ufw enable или отключать SSH с паролем. Самая опасная команда усиления защиты — та, которую вы выполняете, не проверив, что другой способ вернуться в систему действительно работает.

Безопасность VPS обеспечивается последовательностью действий: сохраните возможность восстановления, протестируйте администрирование по ключу, уменьшите публичную доступность, удалите ненужные привилегии, установите исправления, добавьте обнаружение изменений и проверьте восстановление. Это руководство предназначено для Ubuntu 24.04 и аналогичных систем на базе Debian. Панели провайдеров, сетевые настройки Docker и управляемые образы могут менять детали, поэтому воспринимайте команды как контролируемую процедуру, а не универсальный скрипт.

В этой статье

• Первые десять минут — период, когда усиление защиты чаще всего блокирует вам доступ
• Сделайте восстановление обязательным условием перед изменением SSH
• Замените парольный и root SSH на проверенный ключ
• Зеленый статус firewall доказывает очень мало
• Удалите сервисы и привилегии, которые не можете обосновать
• Установите исправления базовой системы и определите ответственного за обновления
• CIS Level 1 — это базовый уровень, а не вердикт
• Выберите обнаружение, которым сможете управлять
• Сохраняйте приватный трафик приватным
• Проверьте результат и назначьте ответственных

Первые десять минут — период, когда усиление защиты чаще всего блокирует вам доступ

Начните с вопроса: сможете ли вы по-прежнему администрировать, обновлять, отслеживать и восстанавливать сервер после следующего изменения.

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

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

Поэтому следуйте такой последовательности: восстановление, SSH, сетевой доступ, сервисы и привилегии, обновления, аудит CIS, обнаружение, приватный трафик и приемочное тестирование.

Сделайте восстановление обязательным условием перед изменением SSH

Перед изменением аутентификации или правил firewall соберите следующие данные:

• Доступ к восстановлению у провайдера. Протестируйте консоль или функцию восстановления, которую фактически предоставляет ваш провайдер. Провайдеры отличаются друг от друга, и функция, отображаемая в панели управления, бесполезна, пока вы не знаете, как ею пользоваться.
• Текущие данные доступа. Зафиксируйте имя пользователя, адрес, SSH-порт и используемые в данный момент учетные данные.
• Резервную копию или snapshot. Узнайте, что именно она сохраняет, как работает восстановление и что происходит с данными, записанными после этого.
• Второй терминал. Держите первую сессию открытой, пока вход с заменой не будет успешно выполнен.
• Инвентаризацию сервисов. Зафиксируйте текущие listeners и их назначение.

Snapshot — это не то же самое, что проверенное восстановление. Для production-данных проведите репетицию типичного восстановления на копии вне production или следуйте задокументированному процессу восстановления провайдера до развертывания.

В руководстве DigitalOcean по безопасности серверов также рекомендуется оставлять существующую сессию открытой во время проверки новой SSH-аутентификации. Эта небольшая привычка предотвращает на удивление дорогостоящую ошибку.

Проверьте listeners с помощью:

sudo ss -tulpn

Зафиксируйте каждый TCP- или UDP-listener, его адрес, порт, процесс-владелец и причину публичной доступности. Предположим, что этот новый VPS с Ubuntu 24.04 размещает небольшое веб-приложение: для администрирования требуется SSH, HTTPS работает на порту 443, HTTP может перенаправлять запросы или поддерживать получение сертификата, а базе данных нет причин быть доступной из публичной сети.

Сохраните эту инвентаризацию. Позже вы используете ее как приемочный тест.

Замените парольный и root SSH на проверенный ключ

Создайте именованную административную учетную запись без root с sudo. Если провайдер предоставил вам только доступ root, создайте учетную запись через задокументированный для Ubuntu процесс провайдера или его консоль, затем установите для нее ключ. Команда создания учетной записи зависит от вашей среды, поэтому это руководство не будет делать вид, что существует одна безопасная ветка для копирования и вставки.

Сгенерируйте ключ Ed25519 на своем локальном компьютере:

ssh-keygen -t ed25519 -C "you@example.com"

Защитите приватный ключ парольной фразой и храните его на своем компьютере. Правильно защищенный приватный ключ Ed25519 делает перебор паролей через интернет неактуальным для этого пути входа. Он не защищает скомпрометированную конечную точку.

Скопируйте публичный ключ в предназначенную для этого учетную запись:

ssh-copy-id user@your-server

Если ssh-copy-id недоступна, добавьте публичный ключ через консоль провайдера или процесс внедрения ключа. Ключ должен находиться в ~/.ssh/authorized_keys этой учетной записи, а не случайно в каталоге root.

Проверьте каталог и файл ключа:

ls -ld ~/.ssh
ls -l ~/.ssh/authorized_keys

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

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Откройте второй терминал и выполните проверку:

ssh user@your-server

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

Отредактируйте конфигурацию daemon:

sudoedit /etc/ssh/sshd_config

Установите:

PasswordAuthentication no
PermitRootLogin no

Перед перезапуском проверьте конфигурацию. В Ubuntu команда sshd -t обычно разрешается напрямую; если это не так, используйте путь к binary daemon, предоставленный установленным пакетом OpenSSH. Команда не должна возвращать вывода и должна завершиться с успешным статусом:

sudo sshd -t

Оставляйте существующую сессию открытой во время проверки и перезапуска:

sudo systemctl restart ssh

Снова протестируйте второй терминал. PermitRootLogin no блокирует root через SSH, а восстановление через консоль провайдера остается отдельным способом доступа.

Fail2ban может замедлить злоупотребления, но публичный SSH по-прежнему требует аутентификации по ключу, учетной записи без root, минимальных привилегий и проверенного пути восстановления.

Зеленый статус firewall доказывает очень мало

Firewall должен соответствовать инвентаризации сервисов. Для примера с этим хостом разрешите SSH и необходимый веб-трафик, а базу данных оставьте недоступной из публичной сети.

На уровне провайдера по возможности ограничьте SSH известным адресом администратора, VPN или контролируемым провайдером путем. В Ubuntu разрешите SSH до включения UFW:

sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verbose

Если SSH использует порт 2222, перед включением UFW разрешите вместо этого данный порт:

sudo ufw allow 2222/tcp

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

sudo ufw allow from 203.0.113.25 to any port 22 proto tcp

Замените пример адреса реальным доверенным источником. Перед изменением сохраните доступ к консоли.

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

Default: deny (incoming)

Firewall со статусом «active» не доказывает, что ваши приложения защищены. Docker может устанавливать правила iptables для опубликованных портов, а IPv6 может оставаться доступным через адрес, который вы никогда не проверяли.

Проверьте настройку IPv6 в /etc/default/ufw, затем протестируйте фактические публичные адреса IPv4 и IPv6 из внешней сети. ufw status verbose показывает политику, но не то, доступно ли ваше приложение по каждому маршруту.

Поведение Docker требует отдельного решения (см. наш гид по защите Docker-контейнеров в продакшене). Если reverse proxy работает на хосте, а приложению не нужен внешний путь, опубликуйте контейнер на loopback:

docker run -p 127.0.0.1:8080:8080 example/app

Это решение о публикации на хосте, а не полная политика сети Docker. Проверьте порт извне. Для базы данных используйте внутреннюю сеть Docker или localhost и не публикуйте порт хоста.

Удалите сервисы и привилегии, которые не можете обосновать

Используйте инвентаризацию listeners для расследования, а не скрипт удаления. Определите процесс за каждым публичным socket и поймите его зависимости, прежде чем отключать unit или удалять пакет.

По возможности привяжите базы данных, панели администрирования, серверы разработки и внутренние API к localhost или приватным адресам. Также проверьте маршруты reverse proxy и адреса привязки приложений. Firewall не исправит ситуацию, когда приложение намеренно предоставляет endpoint наружу.

Запускайте приложение от имени выделенного пользователя без root. Предоставьте ему права владения только на необходимые каталоги. Ограничьте файлы и каталоги с секретами подходящими владельцами и правами доступа, а учетные данные храните за пределами репозиториев, общедоступных конфигурационных путей и истории shell.

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

Правило остановки простое: если вы не можете объяснить, зачем существует listener, учетная запись или привилегированный процесс, расследуйте это до развертывания. Расследуйте это до удаления. Оставьте его приватным, если у вас нет причины делать его публичным.

Установите исправления базовой системы и определите ответственного за обновления

Обновите базовую систему:

sudo apt update
sudo apt upgrade

Проверьте изменения пакетов перед их принятием. Обновления могут менять поведение сервисов, зависимости, форматы конфигурации и требования к перезагрузке. Определите окно обслуживания, путь отката, smoke test приложения и ответственного.

В Ubuntu проверьте необходимость перезагрузки с помощью:

test -f /var/run/reboot-required && cat /var/run/reboot-required

Запланируйте перезагрузку, когда сервис это позволяет. Очевидный случай — обновление kernel, но важные библиотеки и сервисы также могут требовать перезапуска.

В документации Canonical по Ubuntu Security Guide говорится, что Ubuntu Pro предоставляет более 10 лет исправлений безопасности и установку исправлений kernel без перезагрузки. Pro — это вариант для требований к поддержке или покрытию; он не защищает ваше приложение и не заменяет регулярные обновления. Установка исправлений kernel без перезагрузки также не применяется ко всем обновлениям.

CIS Level 1 — это базовый уровень, а не вердикт

Формальные benchmarks полезны, когда вам нужны повторяемые проверки, аудиторские доказательства или общий стандарт усиления защиты. Они становятся вредными, если применять controls, не понимая свое приложение и план восстановления.

Эти команды предназначены для Ubuntu 24.04 с подключенным Ubuntu Pro. Это не универсальная процедура для Debian. Для USG требуется Ubuntu Pro:

sudo pro enable usg
sudo apt install usg

Проведите аудит до изменения рабочей конфигурации:

sudo usg audit cis_level1_server

Прочитайте каждое замечание. Зафиксируйте исключения для необходимых сервисов, журналирования, синхронизации времени, выбора firewall, удаленного доступа и восстановления. Только после этого рассматривайте исправление:

sudo usg fix cis_level1_server

usg fix может изменить рабочую конфигурацию. Запускайте его только после проверки замечаний, сохранения пути отката и обеспечения доступа к консоли.

Для адаптированного аудита используйте сгенерированный файл в соответствии с документацией Ubuntu по USG:

sudo usg generate-tailoring cis_level1_server tailoringfile.xml
sudo usg audit --tailoring-file tailoringfile.xml

Level 1 — практичный базовый уровень для большинства небольших production-развертываний VPS. Level 2 подходит для сред, где безопасность важнее удобства, и может увеличить объем журналирования, расход дискового пространства или затраты производительности. Слепое применение Level 2 к работающему production-серверу — это показная безопасность с операционными издержками. Оцените среду и сознательно определите исключения.

Соответствие CIS не доказывает, что ваше приложение безопасно, уведомления доходят или восстановление работает.

Выберите обнаружение, которым сможете управлять

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

AIDE или Tripwire могут сравнивать текущую файловую систему с базой данных, созданной в заведомо исправном состоянии, и сообщать о неожиданных изменениях. Я бы создал эту базовую конфигурацию после перевода сервера в утвержденное состояние, а затем отправлял уведомления туда, где VPS не сможет их стереть.

Используйте psad, когда вам нужны уведомления о сканировании портов, зафиксированном firewall. Он может менять правила firewall в соответствии со своей конфигурацией, поэтому протестируйте эти реакции до того, как начнете на них полагаться.

Bro, теперь называемый Zeek, обеспечивает более широкий мониторинг сетевых событий и политик. Не используйте его на небольшом одиночном VPS, если у вас уже нет collector и человека, отвечающего за анализ событий. В противном случае вы просто собираете документы в форме трафика.

Инструмент	Выбирайте его, когда	Остановитесь, если
AIDE или Tripwire	Изменения файловой системы требуют проверки	Вы не можете поддерживать доверенную baseline или уведомления за пределами хоста
psad	Для сканирования портов нужны уведомления или реакция	Никто не отвечает за проверку событий firewall
Bro/Zeek	Вы уже эксплуатируете сбор сетевых событий	У вас нет collector, хранилища или ответственного за анализ событий

Fail2ban замедляет повторяющиеся злоупотребления входом. Ключи, минимальные привилегии и восстановление защищают саму учетную запись.

Сохраняйте приватный трафик приватным

Рекомендации DigitalOcean по VPC описывают сети VPC как способ изолировать ресурсы от публичного интернета. Приватная маршрутизация сама по себе не авторизует трафик. По-прежнему необходимы controls провайдера, firewall хоста, привязки сервисов и аутентификация приложения.

Для нескольких ресурсов проектируйте приватные подсети и gateways на этапе provisioning. Перемещение существующего сервера в VPC может потребовать изменения IP и маршрутизации. Сначала используйте VPC провайдера для рабочей нагрузки в одном регионе; добавьте VPN, когда вам потребуется зашифрованный трафик между регионами или доступ удаленных пользователей.

Защищаемая схема выглядит так:

• VPS публично открывает только необходимые веб-порты.
• SSH использует ограниченного администратора, VPN или путь восстановления провайдера.
• База данных прослушивает localhost или приватный интерфейс.
• Резервные копии отправляются в отдельное место с контролируемым доступом.
• Журналы и уведомления покидают VPS.
• Восстановление было отрепетировано.

Проверьте результат и назначьте ответственных

Проведите приемочный тест на сервере и из внешней сети:

1. Откройте новую SSH-сессию с административным ключом.
2. Убедитесь, что приложение работает по HTTPS.
3. Убедитесь, что HTTP перенаправляет запросы или обслуживает только предназначенный вами endpoint.
4. Сравните правила UFW и firewall провайдера.
5. Проверьте неожиданные порты через внешний IPv4 и, если он включен, внешний IPv6.
6. Сравните текущие listeners с инвентаризацией, созданной при provisioning.
7. Убедитесь, что база данных недоступна из публичного интернета.
8. Убедитесь, что журналы и уведомления системы обнаружения поступают за пределы хоста.
9. Восстановите типичные production-данные на копии вне production. Не можете это сделать? Отрепетируйте процесс восстановления провайдера с эквивалентными данными и зафиксируйте ограничение.
10. Снова запустите аудит USG, если вы приняли базовый стандарт CIS.

Зафиксируйте операционное соглашение:

Owner:
Public ports and protocols:
IPv4/IPv6 exposure checked on:
SSH recovery method:
Last backup-restore test:
Last external exposure test:
Next patch window:
Last hardening audit:

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