В этой статье разберём, как защитить Linux-сервер от 99% типовых атак: настроим SSH без пароля, включим firewall через nftables, поставим fail2ban, настроим автоматические обновления и добавим резервное копирование. Всё на реальных примерах для Debian/Ubuntu — те же принципы работают и в CentOS/RHEL.

Важно: перед любыми изменениями создайте снапшот VPS у провайдера или сделайте full-бэкап. Одна неверная команда с firewall может «вырезать» ваш доступ к серверу.

Содержание

  1. Почему стандартный сервер не защищён
  2. Шаг 1. Настройка SSH: убираем пароль и root
  3. Шаг 2. Firewall: nftables за пять минут
  4. Шаг 3. fail2ban против брутфорса
  5. Шаг 4. Автоматические обновления безопасности
  6. Шаг 5. Резервное копирование: правило «3-2-1»
  7. Бонус: что проверить, если сервер уже взломали
  8. Чек-лист защиты Linux-сервера

Почему стандартный сервер не защищён

Свежая установка дистрибутива — это «дом со всеми окнами нараспашку»:

  • SSH принимает подключения по паролю, включая root;
  • firewall по умолчанию открыт (или настроен очень слабо);
  • пакеты устарели и содержат известные уязвимости;
  • логи атак никто не читает, блокировок нет.

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

Шаг 1. Настройка SSH: убираем пароль и root

SSH — главная дверь в ваш сервер, поэтому начинаем с него.

1.1. Создайте отдельного пользователя

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

adduser work
usermod -aG sudo work

1.2. Включите вход по SSH-ключу

Сгенерируйте ключ на своём компьютере (если ещё нет):

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

Скопируйте публичный ключ на сервер:

ssh-copy-id work@ваш_сервер

Проверьте, что вход по ключу работает, откройте вторую сессию и только затем редактируйте конфиг.

1.3. Запретите пароль и root в /etc/ssh/sshd_config

Откройте файл и установите:

# /etc/ssh/sshd_config
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
Port 2222
MaxAuthTries 3
AllowUsers work

Перезапустите службу — из той сессии, в которой вы вошли по ключу:

systemctl restart ssh

⚠️ Если у вас VPS с консольным доступом через панель провайдера — оставьте его включённым как «аварийный выход». Это спасёт, если что-то пойдёт не так.

Что мы получили: боты, подбирающие пароли, больше не имеют шансов — пароль просто не принимается. Смена порта 22 на 2222 отсекает ещё и самый поверхностный скан портов (это не защита сама по себе, но снижает шум в логах).

Шаг 2. Firewall: nftables за пять минут

nftables — современный межсетевой экран Linux, замена устаревших iptables. Если нужна более глубокая теория, читайте наше подробное руководство по настройке nftables. Здесь — готовая рабочая схема для типичного сервера с сайтом и SSH на нестандартном порту.

Создайте файл /etc/nftables.conf:

#!/usr/sbin/nft -f

flush ruleset

table inet filter {
    chain input {
        type filter hook input priority 0; policy drop;

        # локальный трафик — всегда разрешаем
        iif "lo" accept

        # уже установленные соединения
        ct state established,related accept

        # защита от некорректных пакетов
        ct state invalid drop

        # SSH (только с вашего IP — замените на свой)
        tcp dport 2222 ip saddr 1.2.3.4 accept

        # веб-трафик
        tcp dport { 80, 443 } accept

        # ICMP для ping и диагностики (ограничим частоту)
        icmp type echo-request limit rate 4/second accept
    }

    chain forward {
        type filter hook forward priority 0; policy drop;
    }

    chain output {
        type filter hook output priority 0; policy accept;
    }
}

Применяем:

nft -f /etc/nftables.conf

Ключевые принципы:

  • policy drop на inходе — всё, что не разрешено явно, блокируется. Это инверсия «открытого по умолчанию» поведения;
  • SSH открываем только для своего IP. Если ваш IP динамический — откройте порт 2222 всем, но держите MaxAuthTries 3 и fail2ban (см. ниже);
  • если на сервере почта — добавьте правила для портов 25/587/993 в нашем примере почтового сервера.

Проверьте, что доступ не «отрезало»: откройте вторую сессию до применения правил и оставьте её открытой. Если всё сломалось — по ещё живой сессии можно откатить: nft flush ruleset.

Шаг 3. fail2ban против брутфорса

Даже при входе только по ключу порт SSH будут сканировать. fail2ban следит за логами и автоматически банит IP, который слишком часто ошибается.

Установка

apt update
apt install fail2ban

Настройка: /etc/fail2ban/jail.local

Создайте файл (не редактируйте jail.conf — он перезапишется при обновлении пакета):

[DEFAULT]
bantime  = 1h
findtime = 10m
maxretry = 3
ignoreip = 127.0.0.1/8 1.2.3.4   # ваш IP — обязательно!

[sshd]
enabled = true
port    = 2222
logpath = /var/log/auth.log

Запускаем:

systemctl enable --now fail2ban
fail2ban-client status sshd

Команда status покажет, сколько IP уже забанено. Обычно после первого дня работы цифра насмешлива.

Совет: если на сервере nginx — добавьте секцию для блокировки брутфорса по базам данных и админкам:

[nginx-http-auth]
enabled  = true
port     = http,https
filter   = nginx-http-auth
logpath  = /var/log/nginx/error.log
maxretry = 2

Подробнее про настройку самого веб-сервера — в наших статьях про Bitrix24 + nginx + php-fpm и авторизацию nginx через LDAP.

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

Устаревшие пакеты — вторая по частоте причина взломов после слабой SSH. Включите автоматическое обновление:

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

Проверьте, что автообновления включены в /etc/apt/apt.conf.d/20auto-upgrades:

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";

Теперь патчи безопасности будут устанавливаться сами. Для серверов с 1С или другими критичными сервисами имеет смысл настроить автообновления только для security-репозитория — это уже отдельная тонкая настройка, но базовый вариант выше закрывает основную проблему.

Шаг 5. Резервное копирование: правило «3-2-1»

Защита не нужна, если после взлома или случайной команды удаления файлов нет бэкапа. Минимально жизнеспособная схема:

  • 3 копии данных;
  • на 2 разных носителях;
  • 1 копия — вне сервера (облако, другой сервер).

Для малого сервера отлично работает restic + cron + удалённый S3/B2/Backblaze:

apt install restic

# раз в день, в 03:00
echo '0 3 * * * restic -r /etc/restic/repo backup /var/www /var/lib/postgresql --one-file-system' | crontab -

Ключи и пароль репозитория храните отдельно от сервера — в менеджере паролей. Бэкап без ключа = просто зашифрованный мусор, а бэкап с ключом на том же сервере бесполезен при взломе.

Если у вас 1С, не забудьте про резервные копии баз — их логика своя, и мы разбирали её в статье про установку 1С и PostgreSQL.

Бонус: что проверить, если сервер уже взломали

Признаки компрометации:

  • незнакомые процессы в top / htop, особенно «красивые» имена (kdevtmpfsi, systemd-updates);
  • новые пользователи в /etc/passwd с UID 0;
  • неизвестные ключи в ~/.ssh/authorized_keys;
  • входящие соединения на нестандартные порты: ss -tlnp.

Алгоритм действий (без иллюзий): не пытайтесь «починить» взломанный сервер. Любой, кто получил root, мог поставить бэкдор в библиотеки, ядро или cron. Правильный путь:

  1. Зафиксировать: логи (/var/log/auth.log, last, lastb), процессы, новые файлы за 7 дней;
  2. Перенести данные (БД, сайт, конфиги) на чистую установку;
  3. Сменить все пароли и ключи, которые хранились на сервере;
  4. Разобраться, как проникли, — и закрыть именно этот вектор.

Чек-лист защиты Linux-сервера

# Действие Статус
1 Снапшот VPS / полный бэкап перед изменениями ☐
2 Отдельный пользователь с sudo, без root'а ☐
3 SSH по ключу, PasswordAuthentication no ☐
4 PermitRootLogin no, нестандартный порт ☐
5 nftables: policy drop, открыты только нужные порты ☐
6 fail2ban для SSH (и nginx, если есть) ☐
7 unattended-upgrades включены ☐
8 Бэкап по схеме 3-2-1, ключи хранятся отдельно ☐
9 Консоль VPS у провайдера работает (аварийный доступ) ☐
10 Логи собираются и читаются хотя бы раз в месяц ☐

Итог

Защита Linux-сервера — это не «поставить антивирус», а последовательность простых шагов: SSH по ключу → закрытый firewall → fail2ban → автообновления → бэкапы. Каждый шаг закрывает целую категорию атак, а вместе они превращают ваш сервер из цели для ботов в систему, до которой ботам просто нет дела.

Начните с шага 1 прямо сегодня — настройка SSH по ключу занимает 10 минут и снижает риск взлома на порядок уже сейчас.