Первичная настройка безопасности нового VPS

Первые 10 минут определяют безопасность вашего сервера

Новый VPS не является безопасным. С момента получения публичного IP-адреса сканеры пытаются войти в систему, а стандартный образ предоставляет им широкие возможности: root часто доступен, пароли часто разрешены, брандмауэр отсутствует, а обновления не выполняются по расписанию. Хорошая новость заключается в том, что устранение этих уязвимостей занимает около десяти минут и требует выполнения нескольких команд. Это руководство я использую для каждого нового сервера перед размещением на нем каких-либо данных.

Выполняйте шаги по порядку, так как они логически связаны друг с другом. Для каждого шага предусмотрено отдельное руководство, ссылки на которые будут появляться по мере прохождения; эта страница представляет собой краткий путь, объединяющий все этапы.

Минута 1: Обновление системы

Войдите в систему под учетной записью root, используя предоставленные провайдером учетные данные, и выполните полное обновление системы перед выполнением любых других действий:

apt update && apt upgrade -y

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

Минута 2: создание обычного пользователя с правами sudo

Не продолжайте работу под учетной записью root. Создайте пользователя для себя и предоставьте ему права sudo:

adduser matt
usermod -aG sudo matt

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

Минута 4: Настройка SSH-ключей

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

ssh-keygen -t ed25519

Затем скопируйте открытую часть ключа на сервер:

ssh-copy-id matt@YOUR_SERVER

Для ssh-copy-id требуется, чтобы вход по паролю был включен для нового пользователя; если он уже отключен, скопируйте ~/.ssh/authorized_keys пользователя root в /home/matt/.ssh/authorized_keys (владельцем которого является matt) или вставьте свой открытый ключ в этот файл вручную.

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

Выйдите из системы и войдите снова под пользователем matt, используя ключ, и убедитесь, что всё работает, прежде чем переходить к следующему шагу. Если ограничить доступ по SSH до того, как вы настроите вход по ключу, можно потерять доступ к серверу. Если при входе вы получаете сообщение Permission denied (publickey), устраните проблему сейчас, не возвращаясь к использованию пароля, так как это сообщение охватывает пять различных ошибок, а вывод ssh -v укажет, какая именно возникла у вас.

Минута 6: Отключение входа для root и парольной аутентификации

Теперь, когда ваш ключ работает, закройте два входа, которые используют сканеры. Используйте отдельный файл конфигурации, чтобы обновления пакетов не перезаписали настройки. Назовите его 00-, чтобы он обрабатывался раньше 50-cloud-init.conf, который поставляется в облачных образах Ubuntu с PasswordAuthentication yes; sshd сохраняет первое прочитанное значение, поэтому файл, который считывается позже, будет проигнорирован:

sudo nano /etc/ssh/sshd_config.d/00-hardening.conf

PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no

Затем перезагрузите SSH:

sudo systemctl restart ssh

После этого проверьте настройки, которые фактически использует sshd, чтобы убедиться, что сторонний файл конфигурации не переопределил их:

sudo sshd -T | grep -Ei 'passwordauthentication|permitrootlogin'

После отключения паролей и входа для root постоянные попытки брутфорса против вашего сервера станут неэффективными. Полное руководство, включая смену порта, доступно в укреплении безопасности SSH на VPS.

Минута 8: Включение межсетевого экрана

Установите политику default-deny для всех входящих соединений, а затем разрешите только необходимое. Разрешите SSH до включения экрана, иначе вы прервете собственное соединение:

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

Добавьте правила allow для всех используемых сервисов, например 80/tcp и 443/tcp для веб-сайта. Если после этого новая SSH-сессия перестает подключаться, прочитайте текст ошибки, прежде чем что-либо менять, так как отказ в соединении означает, что sshd ответил, а таймаут обычно означает, что межсетевой экран отбросил пакет. Убедитесь, что правила охватывают как IPv4, так и IPv6, поскольку межсетевой экран, фильтрующий только IPv4, оставляет IPv6-интерфейс полностью открытым. Полное руководство доступно по ссылке Основы работы с межсетевыми экранами на VPS. Эти команды ufw предполагают использование Ubuntu или Debian; на системах Rocky или AlmaLinux цель default-deny остается прежней, но инструментом является firewalld, поэтому выполните версию этого шага для firewalld.

Минута 10: Замедление сканеров с помощью Fail2ban

Наконец, добавьте Fail2ban, чтобы блокировать адреса, которые сканируют ваши порты:

sudo apt install -y fail2ban

В Ubuntu 24.04 стандартная установка защищает SSH с момента первой загрузки. Поскольку использование ключей уже является обязательным, это решение служит дополнительным барьером, который снижает объем записей в логах и блокирует повторные попытки подключения, а не основной линией обороны.

Ваш контрольный список

Это ваш регламент действий (runbook). Используйте генератор ниже, чтобы отметить каждый пункт контроля и создать персонализированный список, который можно хранить вместе с сервером. Список будет содержать точные команды для каждого шага:

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

Как только основные меры приняты, автоматические обновления безопасности в Ubuntu будут поддерживать актуальность ПО без необходимости повторного входа в систему. Для каждого сервиса, который вы устанавливаете поверх, потребуется отдельная проверка, так как уязвимые места смещаются: при использовании собственного менеджера паролей сервер никогда не хранит их в открытом виде, поэтому реальные риски Vaultwarden сводятся к административному токену и файлу резервной копии.

FAQ

Что нужно сделать в первую очередь на новом VPS?

Обновите систему с помощью apt update && apt upgrade -y, затем создайте обычного пользователя с правами sudo и прекратите работу под учетной записью root. После этого настройте SSH-ключи, отключите вход для root и аутентификацию по паролю, включите межсетевой экран с политикой запрета по умолчанию и установите Fail2ban. Выполнение этих действий в таком порядке гарантирует, что каждый шаг будет безопасным и вы не потеряете доступ к серверу.

Как избежать потери доступа при настройке безопасности SSH?

Настройте и протестируйте вход по SSH-ключу до того, как отключать пароли или вход для root. Выйдите из системы и войдите снова с использованием ключа, чтобы убедиться в его работоспособности, и только после этого отключайте PasswordAuthentication и PermitRootLogin. При включении межсетевого экрана разрешите порт 22 перед выполнением ufw enable. Если вы всё же потеряли доступ, восстановить его можно через веб-консоль вашего провайдера, минуя SSH.

Действительно ли всё это нужно на маленьком сервере?

Да, потому что сканеры не учитывают размер вашего сервера. Они проверяют все публичные IP-адреса одинаково. Весь процесс настройки занимает около десяти минут и устраняет простые векторы атак: нет входа под root, нет подбора паролей, нет открытых портов, которые вы не планировали открывать, а известные уязвимости устраняются автоматически.

Какой шаг является самым важным?

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

Как убедиться, что сервер действительно защищен?

Перед тем как доверять настройкам, проверьте три вещи вручную. Запустите sudo ss -tlnp и убедитесь, что на публичном адресе прослушиваются только те порты, которые вы планировали открыть, и что нет забытых сервисов 0.0.0.0 или [::]. Запустите sudo ufw status verbose и убедитесь, что политика входящего трафика по умолчанию установлена в deny, а также присутствуют правила как для обычного, так и для (v6) трафика. Всегда открывайте вторую SSH-сессию перед закрытием первой: это позволит избежать блокировки доступа к серверу в случае ошибки в конфигурации SSH. Если все три проверки пройдены успешно, базовые меры безопасности приняты.