Первые 30 минут нового сервера: SSH, файрвол и автообновления

Новый сервер с публичным адресом почти сразу получает попытки подбора паролей, поэтому первые минуты решают многое. Базовая настройка в каждой нашей статье упоминается одной строкой: «вход по ключам, файрвол, обновления». Здесь она разобрана целиком, по порядку и с проверками, чтобы по дороге не закрыть доступ самому себе. Всё написано под Debian 13 «trixie»; на VPS и на собственном железе шаги одинаковые.

План на 30 минут

Шаг	Что делаем	Время
1	Обновляем систему	3 мин
2	Заводим администратора и SSH-ключ	7 мин
3	Закрываем вход по паролю и под root	5 мин
4	Настраиваем файрвол	4 мин
5	Включаем автообновления безопасности	5 мин
6	Проверяем время и имя сервера	2 мин
7	Ставим Fail2ban	1 мин
8	Проверяем снаружи и делаем снимок	3 мин

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

1. Обновляем систему

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

apt update && apt full-upgrade -y
apt install -y sudo

2. Администратор и SSH-ключ

Работать под root постоянно не нужно: заведите обычного пользователя с правом sudo. Имя выберите не самое очевидное, например sysadmin:

adduser sysadmin
usermod -aG sudo sysadmin

На своём компьютере (не на сервере) создайте ключ и отправьте его на сервер:

ssh-keygen -t ed25519 -C "sysadmin@мой-ноутбук"
ssh-copy-id sysadmin@IP-сервера

Если хостер уже отключил вход по паролю и ssh-copy-id не работает, добавьте содержимое файла ~/.ssh/id_ed25519.pub в /home/sysadmin/.ssh/authorized_keys вручную из root-сессии (права на каталог .ssh — 700, на файл — 600, владелец — sysadmin). Задайте для ключа парольную фразу: тогда украденный файл ключа сам по себе бесполезен. Теперь в новом окне терминала проверьте вход и sudo:

ssh sysadmin@IP-сервера
sudo -v

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

3. Закрываем вход по паролю и под root

Создайте файл /etc/ssh/sshd_config.d/00-hardening.conf:

PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
AllowUsers sysadmin
MaxAuthTries 3

Почему именно 00- в названии. sshd применяет первое прочитанное значение параметра, а не последнее, и файлы из sshd_config.d читает по алфавиту. Образы некоторых хостеров приносят свой файл вроде 50-cloud-init.conf с PasswordAuthentication yes. Ваш файл с большим номером проиграл бы ему, и вход по паролю остался бы открытым, хотя в вашем конфиге написано обратное.

Проверьте синтаксис, примените и убедитесь, что действуют именно ваши значения:

sudo sshd -t
sudo systemctl reload ssh
sudo sshd -T | grep -Ei 'permitrootlogin|passwordauthentication|allowusers'

В выводе должно быть permitrootlogin no и passwordauthentication no. Если стоит yes, значит, ваш файл перебит другим, посмотрите содержимое /etc/ssh/sshd_config.d/. Затем в новом окне снова проверьте вход по ключу.

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

4. Файрвол

Правило простое: всё входящее закрыто, кроме того, что нужно:

sudo apt install -y ufw
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw limit 22/tcp
sudo ufw allow 80,443/tcp
sudo ufw enable
sudo ufw status verbose

Команда ufw enable предупредит, что может прервать SSH-подключения, и попросит подтверждение. Порядок важен: разрешите SSH до ufw enable, иначе заблокируете себя. limit разрешает SSH, но ограничивает слишком частые подключения с одного адреса. Строку с портами 80 и 443 оставьте, только если на сервере будет веб-сервер. Для почты список портов другой, он есть в статье про Яндекс.Почту.

Две важные оговорки:

У хостера свой файрвол (в панели VPS). Используйте оба уровня: правила на самом сервере и правила хостера.
Сервисы в контейнерах публикуйте на 127.0.0.1, как в статьях про Nextcloud и Vaultwarden: тогда наружу они выходят только через Nginx, а не напрямую.

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

Большинство взломов используют давно известные уязвимости, поэтому обновления безопасности должны ставиться без вашего участия:

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

Ответьте «Да»: будут созданы настройки в /etc/apt/apt.conf.d/20auto-upgrades. По умолчанию Debian ограничивает автообновления официальными репозиториями стабильного выпуска и безопасности, и это разумно: обновления из -updates и backports на сервере лучше ставить сознательно.

Проверьте, что механизм работает:

sudo unattended-upgrade --dry-run --debug

Журнал работы: /var/log/unattended-upgrades/unattended-upgrades.log.

Перезагрузка. Автоматической перезагрузки по умолчанию нет, поэтому после обновления ядра сервер продолжает работать на старом, пока вы его сами не перезагрузите. needrestart сообщает, какие службы нужно перезапустить и нужна ли перезагрузка из-за ядра. Если окно обслуживания допускает ночную перезагрузку, включите её в /etc/apt/apt.conf.d/50unattended-upgrades:

Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-Time "04:00";

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

6. Время и имя сервера

sudo hostnamectl set-hostname имя.вашдомен.ру
sudo timedatectl set-timezone Europe/Moscow
timedatectl

В выводе timedatectl должно быть System clock synchronized: yes. Если синхронизации нет, поставьте systemd-timesyncd или chrony. Для почтового сервера имя должно совпадать с PTR-записью, а неверное время ломает TLS-сертификаты и двухфакторные коды. Проверьте, что новое имя есть в /etc/hosts.

7. Fail2ban

sudo apt install -y fail2ban
sudo fail2ban-client status sshd

На Debian защита SSH включается автоматически: вторая команда должна показать работающую тюрьму sshd (при ошибке посмотрите systemctl status fail2ban). Честная оговорка: когда вход по паролю отключён, подбор паролей уже не опасен, и Fail2ban лишь снижает шум и нагрузку. Но он понадобится для других сервисов, например почты.

8. Проверяем снаружи и делаем снимок

Слушающие порты на сервере: sudo ss -tulpn. Для каждого сервиса должно быть понятно, зачем он слушает и на каком адресе.
Снаружи. С другой машины просканируйте свой сервер (только свой!): nmap -Pn IP-сервера. Открыты должны быть только ожидаемые порты.
Вход по паролю закрыт: ssh -o PubkeyAuthentication=no sysadmin@IP-сервера должен ответить отказом, а вход под root по SSH — тоже.
Снимок VPS в панели хостера с чистой базовой настройкой. Он пригодится и как точка отката, и как эталон для сравнения, если сервер придётся проверять после инцидента (что делать при взломе).
Запишите: адрес, провайдера, имя пользователя, где лежат ключи, дату настройки и список установленных сервисов.

Что делать дальше

Это стартовый минимум, а не полная защита. Следующие шаги: резервные копии на другую площадку, доступ к администрированию через VPN (WireGuard), мониторинг и вынос журналов на отдельный сервер.

Типичные ошибки

Закрыли вход по паролю, не проверив вход по ключу. Доступ придётся возвращать через консоль хостера.
Включили ufw, не разрешив SSH. То же самое: сервер недоступен.
Параметр SSH «не работает». Файл хостера с меньшим номером перебил ваш. Проверяйте sshd -T, а не только содержимое файла.
Ключ без парольной фразы на ноутбуке без шифрования диска.
Автообновления включены, а перезагрузок нет. Ядро старое, уязвимость остаётся.
Автоперезагрузка без окна обслуживания. Сервер уходит в перезагрузку посреди рабочего дня.
Контейнер с базой опубликован на всех адресах. Файрвол не всегда это замечает, публикуйте на 127.0.0.1.
Ничего не записали. Через полгода никто не помнит, что и как настроено.
Единственный доступ. Нет второго ключа и консоли хостера на случай ошибки.

Итог

Тридцать минут на аккуратную базовую настройку закрывают большинство типичных путей взлома: пароли, открытые порты и неустановленные обновления. Главное в процессе не скорость, а порядок и проверка: сначала ключ и sudo, потом закрытие паролей, а файрвол включается только после разрешения SSH.