Чеклист базовой защиты VDS: SSH‑ключи, файрвол, fail2ban, обновления и бэкапы

Этот материал — практический чеклист по базовой защите VDS. Он рассчитан на админов и разработчиков, которые хотят быстро привести сервер к минимальному стандарту безопасности и не потерять доступ в процессе. Начнем с SSH‑ключей и отключения паролей, затем настроим файрвол, подключим fail2ban, включим автоматические обновления, поговорим про аудит/мониторинг и завершим темой бэкапов и тестов восстановления. Для экспериментов удобно поднять тестовый сервер на VDS.

Перед стартом: оговорки и принципы

Безопасность — это процесс, а не одноразовая настройка. Любые «усиления» внедряйте постепенно и проверяйте. Важно не сломать доступ и не потерять данные. Всегда держите открытой резервную консоль поставщика (VNC/serial/резервный доступ), чтобы восстановить управление, если ошиблись в конфигурации SSH или файрвола.

Главное правило: прежде чем запрещать пароли и root‑логин, убедитесь, что вход по ключу работает, и вы можете подключиться во второй сессии с новым пользователем. Только после этого применяйте ограничения.

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

1) Пользователь, SSH‑ключи и отказ от паролей

Создаем пользователя с sudo

На Debian/Ubuntu:

adduser deploy
usermod -aG sudo deploy

На RHEL/Rocky/Alma:

adduser deploy
usermod -aG wheel deploy

Генерация и установка SSH‑ключей

На вашей рабочей машине сгенерируйте ключ:

ssh-keygen -t ed25519 -a 100 -f ~/.ssh/id_ed25519

Загрузите публичный ключ на сервер:

ssh-copy-id -i ~/.ssh/id_ed25519.pub deploy@server.example.com

Или вручную (например, через временный пароль):

mkdir -p ~deploy/.ssh
chmod 700 ~deploy/.ssh
echo "ssh-ed25519 AAAA... your@host" >> ~deploy/.ssh/authorized_keys
chmod 600 ~deploy/.ssh/authorized_keys
chown -R deploy:deploy ~deploy/.ssh

Базовая защита SSH: запрет паролей и root

Отредактируйте /etc/ssh/sshd_config:

PubkeyAuthentication yes
PasswordAuthentication no
PermitRootLogin no
PermitEmptyPasswords no
ChallengeResponseAuthentication no
UsePAM yes
MaxAuthTries 3
LoginGraceTime 20
ClientAliveInterval 300
ClientAliveCountMax 2
# Опционально ограничить список пользователей
AllowUsers deploy

Если хотите сменить порт, добавьте, например, Port 2222, но помните: это не защита, а снижение шума в логах.

Проверьте синтаксис и перезапустите SSH:

sshd -t && systemctl reload sshd

Откройте новую сессию и проверьте вход под deploy с ключом. Закрывайте старую сессию только после успешной проверки.

2) Файрвол: UFW или iptables/nftables

Вариант A: UFW (Ubuntu/Debian)

Минимальный профиль: разрешить SSH, HTTP/HTTPS, запретить все остальное.

ufw default deny incoming
ufw default allow outgoing
ufw allow 22/tcp
# Если меняли порт SSH, соответствующе поправьте правило
# ufw allow 2222/tcp
ufw allow 80,443/tcp
# Легкий rate limit для SSH
ufw limit 22/tcp
ufw enable
ufw status verbose

Если на сервере есть дополнительные сервисы (например, PostgreSQL для внутренних адресов), ограничивайте по источнику:

ufw allow from 10.0.0.0/24 to any port 5432 proto tcp

Вариант B: iptables (совместимость с nft)

Базовые правила для IPv4:

iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT

iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -i lo -j ACCEPT

iptables -A INPUT -p tcp --dport 22 -j ACCEPT
iptables -A INPUT -p tcp -m multiport --dports 80,443 -j ACCEPT

# ICMP (ping) по желанию
iptables -A INPUT -p icmp -j ACCEPT

Сохранение правил на Debian/Ubuntu:

apt-get update && apt-get install -y iptables-persistent
netfilter-persistent save

На RHEL‑семействе рассмотрите firewalld:

yum install -y firewalld
systemctl enable --now firewalld
firewall-cmd --permanent --add-service=ssh
firewall-cmd --permanent --add-service=http
firewall-cmd --permanent --add-service=https
firewall-cmd --reload

После изменения файла sshd_config сначала разрешите новый порт в файрволе, и только затем применяйте конфигурацию SSH.

3) fail2ban: защита по логам

fail2ban автоматически «банит» источники, которые генерируют множество неудачных попыток входа. Это снижает шум и нагрузку от переборов паролей и ботов.

Установка:

apt-get update && apt-get install -y fail2ban
# RHEL/Rocky/Alma
# yum install -y epel-release fail2ban

Настройте /etc/fail2ban/jail.local (минимум для SSH):

[sshd]
enabled = true
port = ssh
# Для Debian/Ubuntu
logpath = /var/log/auth.log
# Для RHEL‑семейства используйте
# logpath = /var/log/secure
maxretry = 4
findtime = 10m
bantime = 1h
# Действие под UFW
banaction = ufw
# Либо под iptables
# banaction = iptables-multiport

Опционально включите «рецидив» для длительных банов активно «шумящих» IP:

[recidive]
enabled = true
logpath = /var/log/fail2ban.log
action = %(banaction)s[name=recidive]
findtime = 1d
bantime = 1w
maxretry = 5

Перезапустите и проверьте статус:

systemctl enable --now fail2ban
fail2ban-client status
fail2ban-client status sshd

Разбанить IP:

fail2ban-client set sshd unbanip 203.0.113.10

4) Обновления и перезагрузки

Своевременные обновления закрывают уязвимости. Базовый цикл: обновление пакетов, проверка перезапуска служб/ядра и планирование перезагрузки.

Debian/Ubuntu

apt-get update && apt-get -y upgrade
apt-get install -y unattended-upgrades needrestart

Включите автоматическую установку обновлений безопасности:

dpkg-reconfigure --priority=low unattended-upgrades

Ключевые параметры — в /etc/apt/apt.conf.d/50unattended-upgrades (например, автоочистка зависимостей и перезагрузка ночью).

RHEL/Rocky/Alma

yum update -y
yum install -y dnf-automatic
systemctl enable --now dnf-automatic.timer

Следите за уведомлениями needrestart или аналогов: если ядро/библиотеки обновились, запланируйте перезагрузку в окно обслуживания.

Синхронизация времени

Корректное время — это валидные лог‑метки, работа TLS и корректный аудит. Убедитесь, что включен NTP:

timedatectl status
sudo timedatectl set-ntp true

Запускаете веб‑сайт? Сразу подключайте HTTPS и HSTS, оформляйте актуальные SSL-сертификаты и следите за сроками их продления.

Надежные SSL-сертификаты

Мы предлагаем широкий спектр SSL-сертификатов от GlobalSign по самым низким ценам. Поможем с покупкой и установкой SSL бесплатно!

Подробнее

5) Аудит и мониторинг

Даже минимальный аудит помогает быстро ловить аномалии.

• Отслеживайте входы/неудачные попытки: journalctl -u ssh, tail -f /var/log/auth.log (или /var/log/secure), last и lastb.
• Проверяйте слушающие порты и неожиданные сервисы: ss -tulpen, systemctl --type=service --state=running.
• Смотрите сводку по банам: fail2ban-client status sshd.
• Включите ротацию логов и храните их достаточно долго для расследований (логически: logrotate, journald persistent).
• Минимальный мониторинг ресурсов: top/htop/glances. Для метрик и алертов — агент и внешний сервис мониторинга.

Для расширенного аудита полезны средства целостности (например, AIDE) и сканирование базовой конфигурации (например, Lynis). Запускайте периодически и сравнивайте результаты.

6) Бэкапы: стратегия и практика

Бэкап — последняя линия обороны. Без проверенного восстановления все бэкапы — лишь иллюзия.

Принципы

• Правило 3‑2‑1: три копии, на двух разных типах носителей, одна вне площадки.
• Шифрование резервных копий, если они покидают сервер.
• Регулярные тесты восстановления: выборочно разворачивайте бэкап на отдельной машине/каталоге.
• Разделяйте данные: файлы сайта/приложения, конфигурации, базы данных, загрузочные артефакты.

Простой сценарий на rsync + дампы БД

Скрипт ежедневного бэкапа: дамп БД, архив нужных каталогов и отправка на удаленный хост по SSH‑ключу «только для бэкапа».

#!/bin/bash
set -euo pipefail
DATE=$(date +%F)
HOST=$(hostname -s)
BACKUP_DIR=/root/backups/${DATE}
mkdir -p "${BACKUP_DIR}"

# MySQL/MariaDB (требуются права)
if command -v mysqldump >/dev/null; then
  mysqldump --all-databases --single-transaction | gzip > "${BACKUP_DIR}/mysql.sql.gz"
fi

# PostgreSQL (опционально)
if command -v pg_dumpall >/dev/null; then
  sudo -u postgres pg_dumpall | gzip > "${BACKUP_DIR}/postgres.sql.gz"
fi

# Конфиги и данные приложения
 tar -cpzf "${BACKUP_DIR}/etc.tar.gz" /etc
 tar -cpzf "${BACKUP_DIR}/www.tar.gz" /var/www

# Отправка на удаленный сервер бэкапов
RSYNC_SSH="ssh -i /root/.ssh/backup -o StrictHostKeyChecking=yes"
rsync -aHAX --delete -e "${RSYNC_SSH}" "${BACKUP_DIR}/" backup@198.51.100.10:/backups/${HOST}/daily/

# Локальная ротация (14 дней)
find /root/backups -mindepth 1 -maxdepth 1 -type d -mtime +14 -exec rm -rf {} +

Добавьте в crontab -e для root:

0 2 * * * /root/backup.sh >> /var/log/backup.log 2>&1

Убедитесь, что учетная запись backup@198.51.100.10 имеет ограниченный доступ и отдельный ключ. На стороне хранилища можно ограничить команду в authorized_keys, чтобы ключ использовался только с rsync.

Альтернативы: borg/restic

borgbackup и restic поддерживают дедупликацию и встроенное шифрование. Это удобно для экономии места и защиты бэкапов в пути и на диске. Как минимум настройте пароль и храните его в безопасном месте.

Тест восстановления

Периодически делайте «сухой прогон» восстановления: разверните архивы в отдельный каталог и проверьте целостность и актуальность данных.

mkdir -p /root/restore-test
cd /root/restore-test
tar -xpf /root/backups/2025-01-01/etc.tar.gz
# Проверить конфиги, версии, права и владельцев

7) Мини‑чеклист перед боевым запуском

• Создан отдельный пользователь с sudo, root‑вход по SSH запрещен.
• Доступ — только по SSH‑ключам, пароли отключены.
• Файрвол включен: входящие запрещены по умолчанию, открыты только нужные порты.
• fail2ban активен, виден jail для SSH, баны появляются в статистике.
• Обновления настроены, применены последние патчи; запланирована перезагрузка при необходимости.
• Синхронизация времени включена, логи имеют корректные метки.
• Аудит: понятны процессы/порты, есть базовый мониторинг и алерты.
• Бэкап ежедневно/еженедельно, хранение вне сервера, проверено тестовое восстановление.

8) Что улучшить дальше

• Двухфакторная аутентификация для SSH через PAM (TOTP) для чувствительных окружений.
• Более строгая сегментация сети и доступов (VPN, allow‑list для административных портов).
• Расширение fail2ban: фильтры для веб‑сервера и панелей администрирования.
• Инфраструктурный мониторинг с метриками, логами и алертами на SLO.
• Периодический технический аудит: обновления ОС/ПО, анализ CVE, проверка учетных записей и ключей.

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

Этот чеклист закрывает наиболее частые векторы риска для одиночного VDS и дает структурированную основу для дальнейшего наращивания защиты. Начинайте с ключей и файрвола, добавляйте fail2ban, не забывайте об обновлениях и бэкапах — и регулярно проверяйте, что все это действительно работает.