Как защитить VPS на Ubuntu: SSH-ключи, фаервол и автообновления

Почему важны первые десять минут

Стоит новому VPS получить публичный IP-адрес, как автоматические боты начинают подбирать по SSH популярные логины и пароли. В журнале почти любого свежего сервера это видно уже через несколько минут. Опасности нет, если вы успели выполнить базовую настройку: десяти минут достаточно, чтобы такие атаки ничего не дали.

В этой инструкции — стандартные первые шаги на Ubuntu 22.04 или 24.04 (на Debian всё почти так же): обновление системы, обычный пользователь, вход по SSH-ключу вместо пароля, фаервол, автоматические обновления безопасности и Fail2ban. Понадобится только терминал, IP-адрес сервера и данные root.

Шаг 1. Войдите и обновите систему

Подключитесь как root по IP-адресу из панели сервера:

ssh root@IP_СЕРВЕРА

Обновите списки пакетов и установите все доступные обновления:

apt update && apt upgrade -y

Если установилось новое ядро, система попросит перезагрузку. Выполните reboot, подождите минуту и подключитесь снова.

Шаг 2. Создайте обычного пользователя с sudo

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

adduser deploy
usermod -aG sudo deploy

Вместо deploy возьмите любое имя, а пароль сделайте длинным и уникальным. Он нужен для sudo, а не для входа.

Шаг 3. Настройте вход по SSH-ключу

Пара SSH-ключей надёжнее любого пароля. Закрытый ключ остаётся на вашем компьютере, на сервер копируется только открытый.

На своём компьютере (Linux, macOS или Windows PowerShell) создайте ключ:

ssh-keygen -t ed25519 -C "my-vps"

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

ssh-copy-id deploy@IP_СЕРВЕРА

В Windows без ssh-copy-id вставьте содержимое файла id_ed25519.pub в /home/deploy/.ssh/authorized_keys на сервере.

Теперь откройте второй терминал и проверьте:

ssh deploy@IP_СЕРВЕРА
sudo whoami

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

Шаг 4. Отключите вход по паролю и под root

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

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

Содержимое:

PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no

Проверьте синтаксис и перезагрузите службу:

sudo sshd -t
sudo systemctl reload ssh

Прежде чем закрывать что-либо, в третьем терминале убедитесь, что ssh deploy@IP_СЕРВЕРА по-прежнему работает. Командой sudo sshd -T | grep -i passwordauthentication проверьте, что действует no. Некоторые облачные образы содержат собственный файл, разрешающий пароли; SSH читает файлы по алфавиту, и побеждает первое значение, поэтому имя начинается с 00-.

Шаг 5. Включите фаервол UFW

UFW (Uncomplicated Firewall) уже есть в Ubuntu. Правило простое: запретить всё входящее и разрешить только нужное. Сначала разрешите SSH, иначе вы отрежете собственное соединение:

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verbose

Порты 80 и 443 нужны, только если сервер отдаёт сайт. Остальные службы (база данных, админка, игровой сервер) получают порт лишь при необходимости, лучше только для вашего IP: sudo ufw allow from ВАШ_IP to any port 5432.

Шаг 6. Автоматические обновления безопасности

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

sudo apt install unattended-upgrades -y
sudo dpkg-reconfigure --priority=low unattended-upgrades

Ответьте «Yes». Обновления ядра иногда требуют перезагрузки: время от времени проверяйте ls /var/run/reboot-required и, если файл есть, перезагрузите сервер в спокойное время.

Шаг 7. Fail2ban против перебора паролей

Fail2ban читает журналы и временно блокирует IP-адреса, с которых много раз подряд не удалось войти:

sudo apt install fail2ban -y
sudo systemctl enable --now fail2ban
sudo fail2ban-client status sshd

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

Чек-лист для каждого нового сервера

Система обновлена и перезагружена.
Есть обычный пользователь с sudo, вход под root отключён.
Вход по паролю выключен, SSH-ключ с парольной фразой.
UFW включён, открыты только нужные порты.
Автообновления безопасности включены.
Fail2ban работает.
Для важных данных настроены резервные копии или снимки.

Бонус: не забывайте про резервные копии

Фаервол и ключи снижают риск атак, но не защитят от сбоя диска, случайно удалённого файла или неудачного обновления. Планируйте регулярные копии важных данных: помимо снимков (snapshot) у провайдера полезно копировать дампы баз данных и файлы конфигурации на другой сервер с помощью rsync. Раз в месяц проверяйте, что копию действительно можно восстановить, — это так же важно, как сама копия.

Где разместить сервер

Безопасность — только половина решения: от расположения зависит и скорость. Если ваши посетители в Европе или России, дата-центр в Германии или другой точке со страницы локаций обычно даёт минимальную задержку. В HironServer можно развернуть Ubuntu в 50+ странах с почасовой, недельной или месячной оплатой и недорого проверить локацию; актуальные тарифы — на странице цен.

Частые вопросы

Безопасно ли оставлять SSH на порту 22?

Да, если вход по паролю отключён и вы используете ключи. Смена порта лишь уменьшает шум в журналах и не считается настоящей защитой. Ключи и фаервол важнее.

Я заблокировал себе доступ. Что делать?

Откройте веб-консоль или VNC-консоль в панели провайдера: она не зависит от SSH. Оттуда можно исправить настройки SSH или правила UFW. Поэтому при изменениях держите рабочую сессию открытой.

Нужен ли Fail2ban, если пароли отключены?

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

Нужен ли отдельный пользователь для каждого приложения?

Желательно. Если каждая служба работает от своего непривилегированного пользователя, взлом одного приложения наносит меньше вреда.

Как часто обновлять систему?

Оставьте обновления безопасности автоматическими, а раз в одну-две недели заходите, выполняйте sudo apt update && sudo apt upgrade и проверяйте reboot-required.