Как защитить новый VPS с Ubuntu 24.04 за первые 10 минут

Новый VPS доступен из всего интернета с момента загрузки, и автоматические сканеры обычно находят свежий IP-адрес за считанные минуты, а не дни. Это руководство описывает первые десять минут работы на чистом сервере с Ubuntu 24.04: пользователь с sudo, вход по SSH только по ключам, файрвол, fail2ban, автоматические обновления безопасности и финальная проверка того, что реально слушает порты. Оно рассчитано на всех, кто сам разворачивает сервер и хочет разумную, воспроизводимую базу до установки чего-либо ещё.

Шаг 1: обновите систему

Войдите как root и обновите индекс пакетов и установленные пакеты. Это важно, потому что образ шаблона может отставать на несколько недель, а самые простые атаки используют уязвимости, для которых исправления давно опубликованы.

apt update && apt -y upgrade
apt -y autoremove

Перезагрузите сервер только если существует файл /var/run/reboot-required, иначе продолжайте.

Шаг 2: создайте пользователя с sudo

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

adduser deploy
usermod -aG sudo deploy

Замените deploy на любое другое имя. Прежде чем идти дальше, проверьте, что sudo работает:

su - deploy
sudo whoami

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

Шаг 3: ключи SSH и отключение входа по паролю

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

ssh-keygen -t ed25519
ssh-copy-id deploy@203.0.113.10

Убедитесь, что ssh deploy@203.0.113.10 пускает вас без пароля. Только после этого отключайте парольную аутентификацию на сервере. В Ubuntu 24.04 основной конфиг включает drop-in файлы из /etc/ssh/sshd_config.d/ в алфавитном порядке, и для каждой опции sshd оставляет первое прочитанное значение, поэтому выигрывает файл, который сортируется раньше. Облачные образы содержат файл вроде 50-cloud-init.conf со строкой PasswordAuthentication yes, поэтому ваш файл должен сортироваться раньше него: назовите его 00-hardening.conf.

printf 'PasswordAuthentication no\nKbdInteractiveAuthentication no\nPermitRootLogin prohibit-password\n' | sudo tee /etc/ssh/sshd_config.d/00-hardening.conf
sudo sshd -t && sudo systemctl restart ssh
sudo sshd -T | grep -i passwordauthentication

Последняя команда выводит действующую конфигурацию, поэтому убедитесь, что она показывает passwordauthentication no; если там всё ещё yes, выигрывает другой drop-in файл, и нужно проверить содержимое /etc/ssh/sshd_config.d/. Держите текущую сессию открытой и во втором терминале убедитесь, что вход по ключу по-прежнему работает; сломанный конфиг SSH без запасной сессии остаётся классическим способом потерять доступ к серверу.

Шаг 4: основы файрвола с ufw

Файрвол гарантирует, что установленные позже сервисы, например база данных, которая по умолчанию слушает все интерфейсы, не окажутся молча открыты в интернет. ufw в Ubuntu 24.04 уже установлен, поэтому остаётся разрешить SSH и включить его:

sudo ufw allow OpenSSH
sudo ufw enable
sudo ufw status verbose

Разрешите SSH до включения файрвола, иначе следующим отброшенным пакетом будет ваше собственное соединение. Если на сервере будет сайт, откройте и веб-порты:

sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

Шаг 5: fail2ban и автоматические обновления безопасности

fail2ban читает журналы аутентификации и временно блокирует IP-адреса с повторными неудачными попытками, что заметно снижает шум брутфорса и делает перебор украденных паролей практически бесполезным.

sudo apt -y install fail2ban
printf '[sshd]\nenabled = true\nbackend = systemd\n' | sudo tee /etc/fail2ban/jail.d/sshd.local
sudo systemctl enable --now fail2ban
sudo fail2ban-client status sshd

Строка backend = systemd заставляет fail2ban читать журнал systemd напрямую, поэтому он работает и на минимальных установках без классических файлов логов. Далее, unattended-upgrades ставит исправления безопасности автоматически, и это важно, потому что большинство реальных взломов используют уязвимости, закрытые задолго до атаки.

sudo apt -y install unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades

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

Шаг 6: часовой пояс, hostname и проверка портов

Установите часовой пояс, чтобы метки времени в логах совпадали с вашим мониторингом и вашей собственной памятью о событиях:

sudo timedatectl set-timezone Europe/Riga
timedatectl

Дайте машине настоящее имя, потому что через полгода "ubuntu-2404" в оповещении вам ничего не скажет:

sudo hostnamectl set-hostname web1.example.com

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

sudo ss -tulpn

Смотрите на колонку Local Address: записи на 127.0.0.1 или ::1 доступны только с самого сервера, а 0.0.0.0 или [::] означает, что порт открыт всему миру, если его не блокирует ufw. На чистой установке там должны быть только sshd и systemd-resolved; всё остальное требует объяснения.

Что у вас есть через десять минут

• Обновлённая система, которая продолжает обновляться сама
• Пользователь с sudo и вход по SSH только по ключам, пароли отключены
• Файрвол, который по умолчанию блокирует всё, кроме выбранных вами портов
• fail2ban, автоматически блокирующий источники брутфорса
• Правильное время, осмысленный hostname и известный список открытых портов

Ничто из этого не заменяет резервные копии и мониторинг, но закрывает дыры, которые автоматические сканеры используют в первые часы жизни сервера. Если вы ещё выбираете, где запустить такой сервер, наши тарифы VPS работают на нашем собственном оборудовании и сети AS58269 в дата-центре уровня Tier 3+ в Риге, и всё описанное выше работает на них точно так же.