Tropic Host

Как защитить VPS сервер от взлома: пошаговое руководство по харденингу Linux

29 мин чтения
Tropic

Краткий вывод:

Содержание

  1. Быстрый аудит периметра: с чего начинается защита VPS от взлома
  2. Харденинг SSH: ликвидация базового вектора несанкционированного доступа
  3. Фильтрация сетевого трафика: настройка межсетевых экранов UFW и nftables
  4. Автоматическая изоляция атак: внедрение Fail2ban и CrowdSec
  5. Внедрение двухфакторной аутентификации (2FA) для доступа к серверу
  6. Разграничение прав и изоляция процессов: AppArmor, sudo и rootless окружения
  7. Автоматизация обновлений безопасности и контроль целостности системы
  8. Аппаратная безопасность гипервизора: почему KVM NVMe превосходит контейнеры
  9. Чек-лист харденинга: проверка защищенности VPS перед вводом в эксплуатацию
  10. Часто задаваемые вопросы (FAQ)

Быстрый аудит периметра: с чего начинается защита VPS от взлома

Новый сервер попадает в радар автоматических ботнетов в течение первых 90–180 секунд после назначения публичного IPv4-адреса. Готовые образы операционных систем у большинства хостинг-провайдеров поставляются с предустановленным балластом: агентами мониторинга, утилитами облачной инициализации и почтовыми демонами. Каждый забытый сетевой сокет расширяет поверхность атаки, превращая периметр безопасности в уязвимую цель для сканеров уязвимостей. Первичная задача инженера до переноса боевых данных — провести полную ревизию сетевых интерфейсов.

Внутренняя ревизия сокетов: локальный срез через ss -tulpn

Использование устаревшего netstat в современных дистрибутивах Linux неоправданно: утилита медленно парсит /proc/net/ и часто отсутствует в базовой поставке. Стандартом для аудита сокетов ядра является утилита ss из пакета iproute2.

Сразу после первого входа на сервер выполняется инвентаризация открытых портов:

sudo ss -tulpn

Разбор ключевых флагов команды: * -t — отображение TCP-сокетов. * -u — отображение UDP-сокетов (критично для DNS, NTP и VPN-сервисов, о которых часто забывают). * -l — фильтрация только слушающих (LISTEN) портов. * -p — вывод имени процесса и его PID (требует прав root). * -n — запрет резолвинга IP и портов в доменные имена (ускоряет вывод и предотвращает подвисание команды при сбоях DNS).

Что искать в выводе: 1. Привязка к 0.0.0.0 или [::] — сервис доступен всему интернету. На «чистом» сервере единственным внешним демоном на этом этапе должен быть sshd. 2. Лишние службы — демоны вроде rpcbind, exim4, postfix, cupsd или telemetry-агенты хостера. Если процесс не используется напрямую вашим стеком, он должен быть немедленно остановлен и удален из автозагрузки: bash sudo systemctl stop rpcbind && sudo systemctl disable rpcbind 3. Локальные сервисы — СУБД (PostgreSQL, MySQL/MariaDB) и кэш-серверы (Redis, Memcached) обязаны слушать исключительно 127.0.0.1 или Unix domain sockets, но ни в коем случае не 0.0.0.0.

Взгляд со стороны атакующего: сканирование через nmap

Локальная проверка сокетов через ss показывает состояние сетевого стека внутри ОС, но не учитывает маршрутизацию гипервизора, трансляцию адресов (NAT) или внешние фильтры провайдера. Для объективной оценки периметра необходимо провести сканирование сервера с внешнего хоста при помощи nmap.

Базовое SYN-сканирование полного диапазона TCP-портов с детектированием версий ПО:

nmap -sS -sV -p- -T4 --open <IP_АДРЕС_VPS>

Параметры запуска: * -sS — скрытное SYN-сканирование (не завершает трехстороннее рукопожатие TCP, снижая нагрузку на логгеры). * -sV — опрос баннеров служб для определения точной версии запущенного ПО. * -p- — сканирование всех 65 535 TCP-портов (стандартный запуск без флагов проверяет только топ-1000 портов, пропуская кастомные порты сервисов). * --open — отображение только доступных портов без загромождения вывода статусами filtered или closed.

Полученный список баннеров версий проверяется на наличие известных уязвимостей (CVE). Если nmap обнаруживает устаревшую сборку OpenSSH или веб-сервера, содержащую критический CVE с удаленным выполнением кода (RCE), сервер компрометируется в автоматическом режиме до развертывания рабочего окружения.

Принцип Zero Trust: радикальное сужение периметра

Модель нулевого доверия (Zero Trust) в контексте системного администрирования требует считать любую сеть, включая локальные подсети дата-центра, потенциально враждебной.

Базовые правила для сжатия вектора атак:

  • Политика Default DROP: межсетевой экран (nftables или ufw) настраивается на сброс всего входящего трафика по умолчанию: bash sudo ufw default deny incoming sudo ufw default allow outgoing sudo ufw allow 22/tcp # Или нестандартный SSH-порт sudo ufw enable
  • Изоляция административного интерфейса: доступ к демону sshd ограничивается белым списком IP-адресов администратора либо выносится внутрь закрытого VPN-туннеля (WireGuard / Tailscale). Открытый во внешний мир порт SSH — основной источник мусорного трафика и подбора паролей.
  • Привязка к Loopback-интерфейсу: конфигурации баз данных и брокеров сообщений жестко фиксируются на локальный адрес (bind 127.0.0.1).
  • Контроль UDP: мониторинг скрытых UDP-портов (NTP, DNS-резолверы), которые злоумышленники могут использовать в сценариях амплификации сетевых атак (DDoS amplification).

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

Харденинг SSH: ликвидация базового вектора несанкционированного доступа

Стандартный инстанс VPS попадает под автоматизированное сканирование ботнетами через 3–7 минут после выделения публичного IPv4-адреса. До 95% входящего мусорного трафика в журнале auth.log (/var/log/secure) составляют распределенные попытки перебора паролей (brute-force) к учетной записи root. Дефолтная конфигурация OpenSSH ориентирована на обратную совместимость, а не на безопасность, поэтому перевод демона в защищенный режим — первоочередная задача до развертывания любого прикладного стека.

1. Создание непривилегированного пользователя и делегирование прав через sudo

Прямой вход под root лишает систему персонализированного аудита действий и открывает вектор мгновенной компрометации при утечке учетных данных. Работа строится через создание системного оператора с ограниченными правами и контролируемым переключением через sudo.

Создайте пользователя в изолированной домашней директории:

adduser deployer

Добавьте созданную учетную запись в группу суперпользователей: * Для Debian/Ubuntu: bash usermod -aG sudo deployer * Для RHEL, Rocky Linux, AlmaLinux: bash usermod -aG wheel deployer

Проверьте работоспособность конфигурации в отдельной сессии терминала:

su - deployer -c "sudo whoami"

Если вывод возвращает root, права назначены корректно.

2. Отказ от устаревших RSA и переход на криптографию Ed25519

Ключи RSA длиной 2048 бит более не обеспечивают достаточный уровень криптостойкости против современных атак перебором, а RSA 4096 создает избыточную вычислительную нагрузку на CPU при хэндшейке и уязвим к тайминг-атакам на стороне клиента. Стандартом для производственных контуров является алгоритм Ed25519 (эллиптическая кривая Curve25519 с подписью EdDSA).

Преимущества Ed25519: * Фиксированная длина ключа (256 бит) при стойкости, превосходящей RSA 3072 бит; * Иммунитет к атакам по сторонним каналам (constant-time execution); * Компактный открытый ключ (68 символов), минимизирующий риск ошибок при копировании; * Высокая скорость генерации подписи и аутентификации.

Генерация ключевой пары выполняется на локальной рабочей станции командой ssh-keygen с параметром деривации ключа через функцию PBKDF2 (-a 100 раундов хеширования для защиты от локального перебора при краже приватного ключа):

ssh-keygen -t ed25519 -a 100 -C "ops-deployer-prod"

Перенос открытого ключа на целевой сервер:

ssh-copy-id -i ~/.ssh/id_ed25519.pub deployer@<SERVER_IP>

Выставьте строгие POSIX-права на сервере для предотвращения блокировки со стороны SSH-демона (StrictModes):

chmod 700 /home/deployer/.ssh
chmod 600 /home/deployer/.ssh/authorized_keys
chown -R deployer:deployer /home/deployer/.ssh

3. Сравнительный анализ механизмов и алгоритмов аутентификации

Алгоритм / Метод Длина ключа Стойкость к атакам по времени Скорость хэндшейка Статус в production
Парольная аутентификация 8–32 симв. Нулевая (brute-force / dictionary) Зависит от хеша Запрещен (уязвимость №1)
RSA 2048 2048 бит Низкая (SHA-1 депрекейтнут в OpenSSH 8.8+) Средняя Устарел (выводить из оборота)
RSA 4096 4096 бит Средняя Низкая (высокий CPU overhead) Допустим как legacy
ECDSA (nistp256) 256 бит Сомнительная (потенциальные бэкдоры NIST) Высокая Не рекомендуется
Ed25519 256 бит Абсолютная (constant-time) Максимальная Отраслевой стандарт

4. Конфигурация демона OpenSSH (sshd_config)

Все изменения вносятся в файл /etc/ssh/sshd_config либо в отдельный подключаемый файл конфигурации /etc/ssh/sshd_config.d/99-hardening.conf.

Откройте конфигурационный файл:

sudo nano /etc/ssh/sshd_config

Задайте жесткие параметры авторизации и таймаутов:

# Запрет прямого логина суперпользователя
PermitRootLogin no

# Полный запрет передачи паролей по сети
PasswordAuthentication no
PermitEmptyPasswords no
AuthenticationMethods publickey

# Отключение интерактивной клавиатурной аутентификации
KbdInteractiveAuthentication no
ChallengeResponseAuthentication no

# Ограничение попыток авторизации на одну сессию
MaxAuthTries 3
MaxSessions 2

# Дроп зависших сессий (keepalive 300 сек * 2 попытки = 10 мин)
ClientAliveInterval 300
ClientAliveCountMax 2

# Отключение небезопасных протоколов и перенаправлений
X11Forwarding no
AllowAgentForwarding no
AllowTcpForwarding no

Директива PermitRootLogin no блокирует вектор перебора дефолтного аккаунта root. Директива PasswordAuthentication no закрывает любые попытки словарного брутфорса — сервер перестает запрашивать пароль и сбрасывает соединение при отсутствии валидного ключа в authorized_keys.

Перед перезапуском службы обязательно выполните синтаксическую проверку файла конфигурации:

sudo sshd -t

Если вывод пуст — ошибок нет. Перезапустите службу:

# Debian / Ubuntu
sudo systemctl restart ssh

# RHEL / Rocky / AlmaLinux
sudo systemctl restart sshd
Критическое правило безопасности: Не закрывайте текущее активное терминальное окно. Откройте вторую независимую сессию терминала и проверьте вход по ключу: ssh -i ~/.ssh/id_ed25519 deployer@<SERVER_IP>. Только после успешного подтверждения сессии предыдущее подключение можно закрывать.

5. Смена стандартного порта 22: демистификация и границы применимости

Перенос порта на произвольный диапазон (например, 22222 или 49152–65535) часто ошибочно преподносится как самодостаточная мера защиты. Это не криптографический барьер, а классический метод Security through obscurity (безопасность через неясность).

  • Реальный эффект: Смена порта отсекает до 99% фонового шума низкоуровневых скрипт-кидди и распределенных ботнетов, которые сканируют исключительно диапазон стандартных портов. Это защищает журнал системных событий от переполнения гигабайтами записей об ошибках входа и снижает бессмысленную нагрузку на CPU.
  • Технические ограничения: Любое целенаправленное сканирование через nmap -sS -Pn -p- или masscan обнаружит баннер OpenSSH на нестандартном порту за несколько десятков секунд.

Если принято решение перенести порт, выполните последовательность шагов:

  1. Отредактируйте директиву в /etc/ssh/sshd_config: sshconfig Port 22222
  2. Откройте новый порт в активном межсетевом экране до перезапуска демона SSH:
  3. UFW (Ubuntu/Debian): bash sudo ufw allow 22222/tcp sudo ufw reload
  4. Firewalld (RHEL/Rocky/Alma): bash sudo firewall-cmd --permanent --add-port=22222/tcp sudo firewall-cmd --reload
  5. SELinux (если активен): добавьте порт в контекст безопасности: bash sudo semanage port -a -t ssh_port_t -p tcp 22222
  6. Протестируйте и перезапустите службу: bash sudo sshd -t && sudo systemctl restart ssh

Фильтрация сетевого трафика: настройка межсетевых экранов UFW и nftables

Новый публичный IP-адрес попадает под сканирование ботнетами с помощью masscan и zmap уже через 40–90 секунд после инициализации сетевого интерфейса. Любой открытый порт со вспомогательным сервисом (Redis без пароля, bind 0.0.0.0 для СУБД, отладочные метрики Prometheus или сокет Docker daemon) гарантирует компрометацию узла в течение первых часов аптайма.

Базовый уровень сетевой изоляции VPS требует внедрения принципа Zero Trust: отказ от выборочного бана атакующих IP в пользу абсолютной drop policy (молчаливый сброс всех входящих пакетов, не прошедших строгий white-list). В отличие от действия REJECT, отвечающего пакетом ICMP Port Unreachable или TCP RST, действие DROP вынуждает сетевые сканеры ждать истечения таймаута TCP ACK, замедляя фазу внешней разведки злоумышленника в десятки раз.

Вариант 1. Быстрое развертывание: UFW (Uncomplicated Firewall)

UFW представляет собой высокоуровневую интерфейсную обертку над подсистемой Netfilter. Этот инструмент оптимален для автономных виртуальных серверов, где не требуются сложные правила маршрутизации, разделение таблиц по сетевым пространствам имен (network namespaces) или динамический mangle трафика.

1. Установка жестких политик по умолчанию

Перед активацией фаервола критически важно зафиксировать базовые правила обработки трафика: запретить весь входящий входящий поток, разрешить исходящий (чтобы сервер мог обновлять пакеты и обращаться к DNS) и сбросить транзитный роутинг:

# Сброс правил к заводским параметрам
ufw --force reset

# Глобальная drop policy на входящий трафик
ufw default deny incoming

# Разрешение исходящих соединений
ufw default allow outgoing

# Запрет форвардинга пакетов (защита от превращения VPS в транзитный маршрутизатор)
ufw default deny routed

2. Точечный проброс сервисных портов

Никогда не включайте фаервол до добавления правила для SSH — это приведет к моментальной потере доступа к серверу. Если демон SSH перенесен на нестандартный порт (например, 2222/tcp):

# Допуск веб-трафика
ufw allow 80/tcp comment 'HTTP Nginx'
ufw allow 443/tcp comment 'HTTPS Nginx'

# Допуск кастомного SSH с активацией встроенного механизма защиты от брутфорса
ufw limit 2222/tcp comment 'SSH rate-limited'

Параметр ufw limit: активирует механизм rate limiting на уровне ядра — если с одного IP-адреса фиксируется более 6 попыток установки TCP-соединения за 30-секундный интервал, UFW временно сбрасывает пакеты от этого источника.

3. Активация и проверка состояния

# Запуск демона с сохранением правил после перезагрузки
ufw enable

# Проверка активных цепочек с номерами правил
ufw status verbose numbered

Вариант 2. Промышленный стандарт: nftables

Для высоконагруженных систем классический стек iptables устарел. Он страдает от фрагментации (отдельные независимые утилиты iptables, ip6tables, arptables), отсутствия атомарности и линейной деградации производительности ядра при росте числа правил.

Фреймворк nftables решает эти проблемы: * Единое адресное пространство inet объединяет правила для IPv4 и IPv6 в одну таблицу. * Пакеты обрабатываются внутренней компактной виртуальной машиной (JIT-байткод), что снижает оверхед CPU при пакетном шторме. * Конфигурация компилируется и загружается в память атомарно через одну транзакцию: при синтаксической ошибке старый набор правил не сбрасывается, исключая блокировку администратора.

1. Боевая конфигурация /etc/nftables.conf

Файл конфигурации содержит минималистичный, жесткий набор правил: валидацию состояний через сопоставитель conntrack, защиту от аномальных флагов сканирования, фильтрацию SYN flood и точечный проброс портов:

#!/usr/sbin/nft -f

# Очистка предыдущих цепочек и сетов
flush ruleset

table inet filter {
    # Сет для временных блокировок нарушителей (динамический черный список)
    set autoban {
        type ipv4_addr
        flags timeout
    }

    chain input {
        # Точка входа: хук input, приоритет фильтрации (0)
        # Установка базовой drop policy на входящий трафик
        type filter hook input priority filter; policy drop;

        # 1. Трафик локальной петли (loopback)
        iif "lo" accept comment "Allow internal loopback traffic"

        # 2. Немедленный сброс поврежденных и невалидных пакетов
        ct state invalid drop comment "Drop invalid conntrack states"

        # 3. Допуск уже установленных и связанных сессий (критично для стабильности соединений)
        ct state { established, related } accept comment "Allow established/related traffic"

        # 4. Проверка черного списка
        ip saddr @autoban drop comment "Drop blacklisted IPs"

        # 5. Дроп аномальных комбинаций TCP-флагов (Null scan, Xmas scan, SYN-FIN scan)
        tcp flags & (fin | syn | rst | psh | ack | urg) == 0 drop comment "Drop NULL scan"
        tcp flags & (fin | syn | rst | psh | ack | urg) == fin | syn | rst | psh | ack | urg drop comment "Drop XMAS scan"
        tcp flags & (syn | fin) == syn | fin drop comment "Drop SYN-FIN scan"
        tcp flags & (syn | rst) == syn | rst drop comment "Drop SYN-RST scan"

        # 6. Защита от SYN flood на периметре через rate limiting
        # Разрешаем не более 30 новых SYN-пакетов в секунду с всплеском до 50
        tcp flags syn limit rate over 30/second burst 50 packets drop comment "Mitigate SYN flood bursts"

        # 7. ICMP-контроль (Echo Request с ограничением частоты для защиты от ICMP-флуда)
        icmp type echo-request limit rate 5/second accept comment "Allow rate-limited ping IPv4"
        icmpv6 type echo-request limit rate 5/second accept comment "Allow rate-limited ping IPv6"
        icmpv6 type { nd-neighbor-solicit, nd-neighbor-advert, nd-router-advert } accept comment "Allow essential IPv6 SLAAC"

        # 8. Разрешенные сервисные порты: HTTP (80) и HTTPS (443)
        tcp dport { 80, 443 } ct state new accept comment "Web traffic"

        # 9. Кастомный SSH (2222/tcp) с защитой от перебора (brute-force rate limiting)
        # Допускается не более 4 попыток установления соединения в минуту на один IP
        tcp dport 2222 ct state new meter ssh-flood { ip saddr limit rate 4/minute burst 8 packets } accept comment "Rate-limited SSH"

        # Логирование попыток неавторизованного доступа (опционально, с лимитом для предотвращения спама в /var/log)
        limit rate 3/minute burst 5 packets log prefix "[NFT_DROPPED]: " level warn
    }

    chain forward {
        # Сброс любого сквозного трафика
        type filter hook forward priority filter; policy drop;
    }

    chain output {
        # Разрешение исходящего трафика с сервера
        type filter hook output priority filter; policy accept;
    }
}

2. Валидация синтаксиса и запуск

Перед перезапуском службы обязательно выполните проверку синтаксиса на сухом прогоне (dry-run):

# Проверка конфигурационного файла на синтаксические ошибки без применения
nft -c -f /etc/nftables.conf

# Если проверка прошла без ошибок — перезагрузка и добавление в автозагрузку systemd
systemctl restart nftables
systemctl enable nftables

Аудит активности и диагностика блокировок

Для контроля работы фаервола и отслеживания отраженных атак используйте стандартные инструменты мониторинга ядра:

  • Просмотр счетчиков пакетов в реальном времени: bash nft -a list ruleset Флаг -a выводит дескрипторы правил (handle), что позволяет удалять или модифицировать проблемные правила на лету без перезагрузки файла: nft delete rule inet filter input handle 14.
  • Анализ сброшенных пакетов в системном журнале: bash journalctl -k -g "\[NFT_DROPPED\]" -f
  • Инспекция состояния таблицы отслеживания соединений conntrack: ```bash # Подсчет текущего количества отслеживаемых сессий cat /proc/sys/net/netfilter/nf_conntrack_count

# Проверка лимита таблицы (превышение лимита вызывает сброс легитимных пакетов) sysctl net.netfilter.nf_conntrack_max ```

Если сервер подвергается массированному сканированию портов или distributed SYN-флуду, стандартный лимит nf_conntrack_max (обычно 65536 на небольших инстансах) может быть исчерпан за секунды. Для высоконагруженных сетевых узлов увеличьте емкость таблицы до 262144 или 524288 записей через /etc/sysctl.d/99-network.conf:

net.netfilter.nf_conntrack_max = 262144
net.netfilter.nf_conntrack_tcp_timeout_syn_recv = 15
net.netfilter.nf_conntrack_tcp_timeout_established = 600

Автоматическая изоляция атак: внедрение Fail2ban и CrowdSec

Любой публичный IP-адрес с открытыми портами 22, 80 или 443 подвергается от 2 000 до 20 000 автоматизированных сканирований в сутки. Ботнеты перебирают учетные данные по словарям, сканируют уязвимости в CMS и ищут открытые панели управления (/phpmyadmin, /.env, /.git). Ручное добавление правил в фаервол не работает: реакция администратора запаздывает на часы, пока сервер расходует ресурсы CPU и дисковый I/O на обработку паразитного трафика.

Для нейтрализации распределенного подбора и сканирования эксплойтов применяются системы поведенческого анализа: классический Fail2ban и современная платформа коллективной безопасности CrowdSec.

Архитектура: локальный парсинг Fail2ban против распределенной сети CrowdSec

Принципиальная разница между инструментами заключается в источнике данных и векторе противодействия.

  • Fail2ban работает по замкнутому реактивному циклу на одном конкретном хосте. Демон на Python считывает системные журналы через регулярные выражения. Если IP-адрес превышает лимит ошибок за заданный интервал, скрипт вызывает команду фаервола для блокировки. Слабое место: сервер учится исключительно на собственных инцидентах. Пока злоумышленник не совершит maxretry неудачных попыток, доступ открыт.
  • CrowdSec разделяет детектирование и исполнение блокировки. Движок на Go анализирует события из логов, метрик и journald, сопоставляя их со сценариями атак. Главное преимущество — встроенная глобальная сеть threat intelligence. Информация о вредоносных IP агрегируется с сотен тысяч серверов по всему миру, верифицируется алгоритмами консенсуса и отправляется подписчикам. Атакующий хост блокируется на вашем VPS еще до того, как он отправит первый SYN-пакет на порт SSH.
  • Механизм блокировки: Fail2ban жестко привязан к локальным таблицам пакетного фильтра через системные вызовы. В CrowdSec исполнением правил занимаются независимые компоненты — bouncers. Они блокируют трафик на уровне ядра через nftables bouncer, отдают страницу с капчей через модуль Nginx/Caddy или закрывают доступ на уровне CDN (Cloudflare).

Сравнительная матрица защитных систем

Критерий Fail2ban CrowdSec
Язык разработки Python Go
Потребление RAM в покое 30–70 МБ (растет при тяжелых jail) 40–80 МБ (стабильно фиксировано)
База знаний об угрозах Отсутствует (только локальный контекст) Глобальная распределенная сеть threat intelligence
Механизм детекта RegEx-сопоставление строк логов Парсеры YAML + конечные автоматы (сценарии)
Точки блокировки iptables, nftables, hosts.deny Модульные bouncers (nftables, Nginx, Cloudflare, Traefik)
Нагрузка на дисковый I/O Высокая при чтении объемных текстовых логов Минимальная при работе с сокетами и structured logs
Защита от распределенных атак Неэффективен (1 попытка с 1 000 разных IP) Эффективен (IP уже находятся в глобальном черном списке)

Практическая конфигурация Fail2ban: тюнинг jail.local

По умолчанию конфигурация Fail2ban часто настроена некорректно: системные файлы /etc/fail2ban/jail.conf перезаписываются при обновлениях пакета, а бэкенд чтения файлов создает избыточный I/O.

Все кастомные параметры объявляются исключительно в файле /etc/fail2ban/jail.local.

1. Создание боевого конфига

# /etc/fail2ban/jail.local
[DEFAULT]
# Игнорировать локальные интерфейсы и доверенную подсеть администратора
ignoreip = 127.0.0.1/8 ::1 198.51.100.45/32

# Время блокировки (инкрементный бан: 1 час -> 1 день -> 1 неделя)
bantime  = 1h
bantime.increment = true
bantime.factor = 2
bantime.maxtime = 4w

# Окно анализа попыток
findtime = 10m
maxretry = 5

# Использование системного журнала вместо парсинга сырых файлов
backend = systemd
banaction = nftables-multiport
banaction_allports = nftables-allports

# -------------------------------------------------------------
# Защита SSH
# -------------------------------------------------------------
[sshd]
enabled = true
port    = 2222
mode    = aggressive
maxretry = 3

# -------------------------------------------------------------
# Защита веб-сервера (Nginx)
# -------------------------------------------------------------
[nginx-http-auth]
enabled = true
port    = http,https
logpath = /var/log/nginx/error.log

[nginx-botsearch]
enabled  = true
port     = http,https
logpath  = /var/log/nginx/access.log
maxretry = 2
findtime = 2m

2. Применение параметров и верификация

systemctl restart fail2ban
fail2ban-client status sshd

Команда выведет текущее состояние изолятора: число отслеживаемых инцидентов и список заблокированных IP.

Развертывание CrowdSec и nftables bouncer

CrowdSec обеспечивает наивысшую производительность при фильтрации трафика благодаря изоляции сетевых правил внутри сетов ядра Linux.

1. Установка агента и коллекций защиты

# Подключение официального репозитория и установка ядра
curl -s https://packagecloud.io/install/repositories/crowdsec/crowdsec/script.deb.sh | bash
apt-get update && apt-get install -y crowdsec

# Установка коллекций сигнатур для SSH и Nginx
cscli collections install crowdsecurity/sshd
cscli collections install crowdsecurity/nginx
systemctl reload crowdsec

2. Установка и активация nftables bouncer

Для немедленного сброса пакетов на уровне сетевого стека без накладных расходов пользователя устанавливается nftables bouncer:

apt-get install -y crowdsec-firewall-bouncer-nftables

После инициализации компонент создает отдельную таблицу в nftables со списком IP-адресов типа set. Поиск по таким множествам выполняется за время $O(1)$ вне зависимости от количества заблокированных адресов (даже при 50 000+ записей).

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

nft list set inet crowdsec-blacklists crowdsec-blacklists-ipv4
cscli decisions list

Оптимизация потребления CPU и I/O при парсинге логов на NVMe VPS

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

1. Перевод Fail2ban с pyinotify на systemd-journald

При активном обращении к веб-серверу (от 500 RPS) стандартный Python-механизм мониторинга файлов (polling или pyinotify) нагружает одно ядро CPU на 80–100%.

  • Укажите backend = systemd в блоке [DEFAULT] файла jail.local.
  • Убедитесь, что сервисы (Nginx, OpenSSH) пишут логи напрямую в журнал: nginx # В конфигурации nginx.conf access_log syslog:server=unix:/dev/log,facility=local7,tag=nginx,nohostname combined; error_log syslog:server=unix:/dev/log,facility=local7,tag=nginx error; Это исключает операции сброса буфера на NVMe и последующего повторного чтения тех же блоков демоном Fail2ban.

2. Защита от OOM Killer через systemd cgroups

Если сервер подвергнется мощной распределенной L7-атаке, генерация миллионов строк логов в секунду может спровоцировать утечку памяти в парсерах. Задайте жесткие ограничения на потребление ресурсов демонами изоляции через systemd drop-in файлы.

Для Fail2ban (/etc/systemd/system/fail2ban.service.d/override.conf):

[Service]
MemoryMax=256M
MemoryHigh=192M
CPUQuota=50%
Nice=10

Для CrowdSec (/etc/systemd/system/crowdsec.service.d/override.conf):

[Service]
MemoryMax=300M
CPUQuota=40%

Примените директивы:

systemctl daemon-reload
systemctl restart fail2ban crowdsec

3. Тюнинг сброса буферов файловой системы

Чтобы убрать микрозадержки NVMe при ротации логов веб-сервисов, скорректируйте параметры ядра в /etc/sysctl.d/99-security-io.conf:

# Уменьшение интервала удержания «грязных» страниц в оперативной памяти
vm.dirty_background_ratio = 5
vm.dirty_ratio = 10

Применение: sysctl -p /etc/sysctl.d/99-security-io.conf.

Такая конфигурация гарантирует: парсинг аномалий и блокировка атакующих происходят в оперативной памяти без задержек в очереди ожидания дискового I/O (iowait) и без деградации производительности продакшн-сервисов.

Внедрение двухфакторной аутентификации (2FA) для доступа к серверу

Компрометация приватного SSH-ключа (утечка локальной рабочей станции, перехват через инфостилер или скомпрометированный CI/CD-раннер) предоставляет злоумышленнику беспрепятственный доступ к системе. Чтобы защитить VPS сервер от взлома даже в случае утечки закрытого ключа, на уровне операционной системы разворачивается второй эшелон проверки — связка криптографического ключа с одноразовым временным кодом (TOTP, Time-based One-Time Password).

При такой конфигурации атакующему недостаточно украсть файл id_ed25519 — ему потребуется физический доступ к аппаратному генератору кодов или аутентификатору администратора.

1. Установка и инициализация libpam-google-authenticator

Обработка дополнительного фактора делегируется подсистеме подключаемых модулей аутентификации Linux (PAM). На сервере разворачивается библиотека libpam-google-authenticator:

sudo apt update && sudo apt install -y libpam-google-authenticator

Генерация секретного ключа и профиля привязки выполняется из-под учетной записи пользователя, которому настраивается доступ (ни в коем случае не из-под root для обычных пользователей):

google-authenticator -t -d -f -r 3 -R 30 -W

Разбор флагов инициализации: * -t (TOTP): активация алгоритма генерации одноразовых паролей по времени (RFC 6238) вместо счетчика событий (HOTP). * -d: запрет повторного использования одного и того же токена (защита от атак повторного воспроизведения — replay attacks). * -f: принудительная запись конфигурации в файл ~/.google_authenticator. * -r 3 -R 30: жесткий рейт-лимит на уровне PAM — не более 3 попыток ввода кода за 30-секундное окно (блокировка перебора 6-значных кодов). * -W: сужение допустимого временного окна рассинхронизации часов до 1 шага (снижает уязвимость к атакам со сдвигом времени).

После выполнения команды в терминале отобразится QR-код для мобильного приложения (Aegis Authenticator, 2FAS, Google Authenticator) и секретный строковый ключ.

2. Безопасное хранение аварийных кодов (recovery codes)

В выводе команды утилита генерирует 5 одноразовых резервных кодов (recovery codes). Каждый код состоит из 8 цифр и сгорает сразу после первого использования:

Your emergency scratch codes are:
  48291048
  92810394
  18492015
  59201847
  30194820

Регламент работы с аварийными кодами: * Запрет хранения на сервере: файл ~/.google_authenticator содержит хэши этих кодов, однако копировать их в текстовые файлы на VPS или оставлять в буфере терминала недопустимо. * Изолированный vault: коды выгружаются исключительно в зашифрованные корпоративные хранилища паролей (KeePassXC, Bitwarden/Vaultwarden) с отдельной мастер-фразой либо распечатываются на бумажный носитель для физического сейфа. * Мониторинг расхода: если утерян телефон с генератором TOTP, единственный способ попасть на сервер без вызова rescue-консоли хостера — ввести один из recovery codes вместо 6-значного токена. После экстренного входа база 2FA немедленно перегенерируется заново.

3. Настройка стека PAM для изоляции паролей

По умолчанию стек PAM настроен на запрос пароля учетной записи. Задача инженера — исключить слабые пароли из цепочки, заменив их на связку «SSH-ключ + TOTP».

Откройте конфигурационный файл сервиса OpenSSH в PAM:

sudo nano /etc/pam.d/sshd
  1. Закомментируйте строку стандартной парольной аутентификации Unix:
# @include common-auth

(Если оставить эту директиву активной, OpenSSH потребует ввести сначала системный пароль пользователя, а затем TOTP).

  1. Добавьте в самый конец файла вызов модуля:
auth required pam_google_authenticator.so nullok
Критическая директива nullok: флаг nullok временно разрешает вход без 2FA тем пользователям, которые еще не выполнили команду google-authenticator. Как только 2FA настроена для всех доверенных учетных записей, параметр nullok удаляется из строки, делая присутствие второго фактора безапелляционным (auth required pam_google_authenticator.so).

4. Конфигурация демона OpenSSH

Для связывания SSH-ключей и PAM-модуля редактируется рабочий конфигурационный файл демона:

sudo nano /etc/ssh/sshd_config

Задаются следующие параметры:

# Активация интерактивного опроса подсистемы PAM
KbdInteractiveAuthentication yes
UsePAM yes

# Отключение чистого парольного доступа
PasswordAuthentication no

# Требование выполнения обоих условий последовательно:
AuthenticationMethods publickey,keyboard-interactive

Директива AuthenticationMethods задает строгий порядок аутентификации через запятую: 1. Клиент обязан предоставить валидный закрытый ключ (publickey). 2. При успешной проверке ключа SSH-сервер инициирует интерактивный диалог (keyboard-interactive) и запрашивает 6-значный одноразовый код TOTP через модуль PAM.

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

Authenticated with partial success.
Verification code:

5. Валидация и применение изменений без риска локаута

Перед перезапуском службы обязательно выполняется синтаксический аудит конфигурационных файлов:

sudo sshd -t

Если команда ничего не вывела в терминал — синтаксис корректен.

Применение параметров выполняется перезагрузкой юнита демона:

sudo systemctl reload ssh
# или на RHEL/AlmaLinux:
# sudo systemctl reload sshd

Тестовое подключение: текущая сессия терминала не закрывается. В новом окне запускается тестовая сессия с флагом вербозности для проверки факта срабатывания цепочки:

ssh -v -i ~/.ssh/id_ed25519 user@your_server_ip

Клиент должен автоматически отдать публичный ключ, после чего появится приглашение терминала: Verification code:
После ввода шести цифр из приложения TOTP сессия успешно открывается. При попытке входа без ключа или с неверным кодом сервер разрывает TCP-сессию с кодом ошибки Permission denied (keyboard-interactive).

Разграничение прав и изоляция процессов: AppArmor, sudo и rootless окружения

Успешная эксплуатация уязвимости в веб-стеке (RCE через уязвимый плагин CMS, SQL-инъекция с выходом в файловую систему или баг парсера) не должна приводить к компрометации всего VPS. Концепция эшелонированной обороны (Defense-in-Depth) на уровне ОС требует изоляции каждого сервиса в отдельный контекст выполнения: компрометация рабочего процесса Nginx или PHP-FPM обязана локализоваться в песочнице с нулевой возможностью горизонтальной или вертикальной эскалации привилегий.

Аудит /etc/sudoers и ликвидация векторов эскалации через служебных пользователей

Привилегия выполнения команд от имени суперпользователя без ввода пароля (NOPASSWD) в конфигурации sudoers — критическая точка отказа. Злоумышленник, получивший доступ к шеллу непривилегированного сервисного аккаунта (например, www-data или deploy), первым делом выполняет команду sudo -l, выявляя пути немедленного побега в root через встроенные бинарные файлы (методология GTFOBins).

Правила безопасного конфигурирования подсистемы sudo:

  1. Запрет NOPASSWD для учетных записей демонов: Сервисные пользователи (www-data, nginx, redis, postgres) вообще не должны находиться в файле /etc/sudoers или в директории /etc/sudoers.d/. Им запрещен доступ к интерактивному шеллу: bash usermod -s /usr/sbin/nologin www-data
  2. Изоляция административных прав: Права sudo выдаются исключительно конкретным пользователям-администраторам с обязательным требованием ввода пароля. Файлы в /etc/sudoers.d/ обязаны иметь права доступа 0440 и редактироваться строго через утилиту visudo: bash visudo -f /etc/sudoers.d/sec-ops
  3. Блокировка исполнения дочерних оболочек: Если пользователю требуется дать доступ к запуску конкретного скрипта бэкапа или перезапуску службы, используйте флаг NOEXEC, предотвращающий запуск подпроцессов (shell spawns): text deploy ALL=(ALL) NOEXEC: /usr/bin/systemctl restart nginx.service
  4. Аудит SUID/SGID-битов: Атакующие эксплуатируют забытые бинарные файлы с битом смены идентификатора пользователя. Регулярно сканируйте систему на наличие нестандартных SUID-файлов: bash find / -xdev -perm -4000 -type f -exec ls -la {} + 2>/dev/null Любые бинарники, не требующие повышенных прав для обычных пользователей (например, устаревшие компиляторы или сетевые утилиты), лишаются флага: bash chmod u-s /path/to/binary

Запуск сервисов в rootless Docker и минимализация Linux capabilities

Классический Docker Daemon работает с правами root и слушает сокет /var/run/docker.sock. Проброс этого сокета внутрь любого контейнера эквивалентен передаче злоумышленнику полного контроля над родительской системой.

Переход на rootless Docker переносит dockerd и жизненный цикл контейнеров в изолированное пользовательское пространство (User Namespaces). Даже если атакующий взломает приложение и получит UID 0 внутри контейнера, в таблице процессов хостового ядра этот процесс будет соответствовать непривилегированному UID (например, 1001), исключая изменение системных файлов ядра, установку руткитов или перехват raw-сокетов.

Настройка жестких границ безопасности для контейнеризированных нагрузок:

  • Сброс системных возможностей ядра (Linux capabilities): По умолчанию Docker выдает контейнерам избыточный пул прав (включая CAP_CHOWN, CAP_DAC_OVERRIDE, CAP_FOWNER). Безопасная конфигурация требует сброса всех прав с точечным подключением только критически необходимых: bash docker run -d \ --name backend-app \ --read-only \ --tmpfs /tmp:rw,noexec,nosuid,size=64m \ --cap-drop=ALL \ --cap-add=NET_BIND_SERVICE \ --security-opt=no-new-privileges:true \ myapp:stable
  • Флаг --read-only блокирует модификацию корневой файловой системы контейнера (защита от записи веб-шеллов).
  • Параметр --security-opt=no-new-privileges:true гарантирует, что процессы внутри контейнера не смогут повысить свои привилегии через вызовы setuid/setgid программ.
  • CAP_NET_BIND_SERVICE — единственная оставленная привилегия, необходимая для открытия привилегированных портов (<1024).
  • Лимитирование ресурсов через cgroups v2: Контрольные группы (cgroups) предотвращают DoS-атаки хоста (Fork bomb, истощение оперативной памяти и вызов паники ядра OOM Killer): bash docker run -d \ --memory="512m" \ --memory-swap="512m" \ --cpus="1.5" \ --pids-limit=100 \ myapp:stable Параметр --pids-limit=100 отсекает возможность исчерпать таблицу PID ядра процессами эксплойта.

Мандатный контроль доступа: внедрение профилей AppArmor

Дискреционный контроль доступа (DAC — стандартные права rwx владельца и группы) не защищает систему, если уязвимый процесс скомпрометирован от имени его штатного владельца. Системы мандатного доступа (MAC) — AppArmor в дистрибутивах Debian/Ubuntu и SELinux в семействах RHEL/Rocky Linux — задают предельную матрицу разрешений на уровне системных вызовов ядра, независимо от прав текущего пользователя.

AppArmor привязывает профили политик безопасности к путям исполняемых файлов, блокируя доступ к файлам, сокетам и системным возможностям, которые не описаны в явных правилах allow.

Алгоритм развертывания и перевода профилей в строгий режим:

  1. Проверка текущего статуса подсистемы: bash aa-status Утилита выводит список загруженных профилей и их режимы: enforce (активная блокировка недозволенных действий) или complain (только логирование отклонений в auditd без блокировки).
  2. Активация базовых профилей Nginx и сетевых демонов: Дистрибутивные профили устанавливаются из пакета apparmor-profiles: bash apt-get install -y apparmor-utils apparmor-profiles Перевод профиля веб-сервера из мягкого аудита в боевую блокировку: bash aa-enforce /etc/apparmor.d/usr.sbin.nginx
  3. Изоляция PHP-FPM через кастомный профиль: Для изоляции PHP-интерпретатора создается профиль /etc/apparmor.d/php-fpm-security, запрещающий чтение конфигураций других служб, доступ к /root, /home и запуск системных командных оболочек: ```text #include

/usr/sbin/php-fpm* { #include#include

 # Запрет доступа к критическим путям ОС
 deny /etc/shadow r,
 deny /etc/sudoers* r,
 deny /root/** rwklx,
 deny /home/** rwklx,

 # Запрет запуска интерпретаторов для защиты от Reverse Shell
 deny /bin/bash x,
 deny /bin/sh x,
 deny /bin/dash x,
 deny /usr/bin/python* x,
 deny /usr/bin/perl x,

 # Разрешение только для кода веб-приложения и сессий
 /var/www/my-site/ r,
 /var/www/my-site/** r,
 /var/www/my-site/uploads/** rw,
 /run/php/php*-fpm.sock rw,
 /tmp/ rw,
 /tmp/** rw,

} ```

  1. Загрузка и валидация политики: bash apparmor_parser -r /etc/apparmor.d/php-fpm-security aa-enforce php-fpm-security

Если веб-приложение подвергнется инъекции веб-шелла, вызов функции system('/bin/bash') будет мгновенно заблокирован ядром Linux на уровне системного вызова execve(), а в журнал /var/log/audit/audit.log поступит событие безопасности с флагом apparmor="DENIED". Сервер продолжит функционировать в штатном режиме без риска глубокого проникновения в ОС.

Автоматизация обновлений безопасности и контроль целостности системы

Окно между публикацией публичного эксплойта под свежий Linux kernel CVE (например, в подсистемах netfilter, ebpf или io_uring) и массовым сканированием диапазонов IP-адресов ботнетами составляет от 30 минут до нескольких часов. Если злоумышленник получает непривилегированный доступ, следующими шагами становятся повышение привилегий, подмена системных бинарников (/bin/login, /usr/sbin/sshd, библиотеки PAM) и закрепление в системе через LKM-руткиты (Loadable Kernel Modules).

Эшелонированная защита строится на трех неразрывных уровнях: немедленное устранение уязвимостей в пакетах, фиксация эталонных хэшей файлов и непрерывный эвристический аудит скрытых процессов.

1. Безостановочный патчинг: настройка unattended-upgrades

Установка пакетных обновлений вручную раз в месяц гарантирует наличие открытых векторов атак. Однако слепой запуск apt upgrade опасен поломкой конфигураций или внеплановым падением продакшена. Решение — изоляция автообновлений исключительно в рамках репозиториев безопасности с помощью unattended-upgrades.

Развертывание и изоляция источников

Установите пакет и утилиту управления расписанием:

sudo apt update && sudo apt install unattended-upgrades apt-listchanges bsd-mailx -y

Отредактируйте конфигурационный файл /etc/apt/apt.conf.d/50unattended-upgrades. Запретите обновление обычного софта и оставьте только security-потоки:

Unattended-Upgrade::Allowed-Origins {
    "${distro_id}:${distro_codename}-security";
    // "${distro_id}:${distro_codename}-updates"; // Отключено: предотвращает поломку зависимостей
};

// Запрет на автообновление критических сервисов без ручного тестирования
Unattended-Upgrade::Package-Blacklist {
    "nginx";
    "postgresql.*";
    "docker-ce";
};

// Автоматическое удаление устаревших зависимостей и ядер
Unattended-Upgrade::Remove-Unused-Kernel-Packages "true";
Unattended-Upgrade::Remove-Unused-Dependencies "true";

// Контроль перезагрузки при обновлении ядра Linux
Unattended-Upgrade::Automatic-Reboot "false";
// Если перезагрузка допустима в ночное сервисное окно (раскомментировать при необходимости):
// Unattended-Upgrade::Automatic-Reboot "true";
// Unattended-Upgrade::Automatic-Reboot-Time "04:30";

Активируйте периодический триггер в /etc/apt/apt.conf.d/20auto-upgrades:

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

Проверьте корректность работы демона в режиме имитации без применения изменений:

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

2. Контроль целостности файлов: AIDE и связка с auditd

Когда периметр скомпрометирован, злоумышленники маскируют трояны под стандартные утилиты ОС (ps, ls, netstat, top). В то время как демон ядра auditd отслеживает системные вызовы (execve, openat, ptrace) в реальном времени, утилита AIDE (Advanced Intrusion Detection Environment) выполняет роль детерминированного статического арбитра. Она строит базу криптографических хэшей (SHA-256/SHA-512), прав доступа, inode и таймстампов системных файлов.

Инициализация базы данных AIDE

  1. Установите пакет: bash sudo apt install aide -y
  2. Сконфигурируйте отслеживаемые зоны в /etc/aide/aide.conf. Для системных каталогов используется строгое правило FIPSR (хэш, размер, права, владелец, inode), для динамических логов — только атрибуты: ```text # Кастомное правило проверки критических бинарников BIN_RULE = p+i+n+u+g+s+b+m+c+sha256

/bin BIN_RULE /sbin BIN_RULE /usr/bin BIN_RULE /usr/sbin BIN_RULE /etc BIN_RULE

# Исключения для каталогов с регулярной записью !/etc/aide. !/var/log/. !/var/tmp/.* ```

  1. Сгенерируйте первичный снимок файловой системы: bash sudo aideinit
  2. Зафиксируйте эталон (снапшот), сделав сгенерированную базу рабочей: bash sudo mv /var/lib/aide/aide.db.new /var/lib/aide/aide.db

Защита от фальсификации и автоматический аудит

База /var/lib/aide/aide.db — приоритетная цель атакующего с правами root. Защитите ее установкой флага иммутабельности:

sudo chattr +i /var/lib/aide/aide.db

Запуск инспекции целостности выполняется по расписанию через systemd.timer или cron:

sudo aide --check
Инженерный нюанс: При каждом легитимном срабатывании unattended-upgrades обновленные пакеты изменят свои хэши, вызвав алерт AIDE. Настройте пост-апдейт хук в /etc/apt/apt.conf.d/99aide-update, который автоматически временно снимает chattr -i, пересобирает базу (aide --update) и возвращает защиту, исключая ложные срабатывания мониторинга.

3. Детектирование руткитов и бэкдоров: rkhunter

Классические утилиты аудита не видят модификации памяти ядра и скрытые сетевые сокеты. rkhunter (Rootkit Hunter) специализируется на выявлении конкретных сигнатур известных эксплойтов, аномалий в procfs, хуков системных вызовов и скрытых LKM-модулей.

Настройка и калибровка базового состояния

  1. Установите сканер: bash sudo apt install rkhunter -y
  2. Сконфигурируйте /etc/rkhunter.conf: ```text # Включение строгой проверки скрытых процессов и сокетов ENABLE_TESTS="all" DISABLE_TESTS="suspscan deleted_files"

# Предотвращение ложных срабатываний на валидных SSH-конфигурациях ALLOW_SSH_ROOT_USER=prohibit-password ALLOW_SSH_PROT_V2=yes

# Отправка логов в syslog для дальнейшего перехвата SIEM-системами USE_SYSLOG=authpriv.notice ```

  1. Зафиксируйте текущие системные хэши пакетов в базе rkhunter: ```bash # Обновление сигнатур угроз из базы авторов sudo rkhunter --update

# Фиксация хэшей текущих бинарников через базу менеджера пакетов (dpkg) sudo rkhunter --propupd ```

Автоматизация сканирования и алерт

Ручной запуск утилиты требует флагов пакетной обработки, исключающих блокировку терминала:

sudo rkhunter --check --skip-keypress --report-warnings-only

Для ежедневного контроля создайте юнит /etc/systemd/system/rkhunter-scan.service:

[Unit]
Description=Daily Rootkit Hunter Scan
After=network.target

[Service]
Type=oneshot
ExecStartPre=/usr/bin/rkhunter --update
ExecStart=/usr/bin/rkhunter --cronjob --report-warnings-only
StandardOutput=journal
StandardError=journal

Дополните его таймером /etc/systemd/system/rkhunter-scan.timer с запуском каждые 24 часа со случайным сдвигом (RandomizedDelaySec=1800), чтобы исключить пиковые нагрузки на I/O дисковой подсистемы виртуального сервера. При появлении предупреждений парсер логов /var/log/rkhunter.log должен немедленно генерировать алерт инженеру: появление неизвестного файла в /dev/shm или хука на sys_call_table указывает на активную компрометацию ядра.

Аппаратная безопасность гипервизора: почему KVM NVMe превосходит контейнеры

Краткий вывод: Использование контейнерной виртуализации (OpenVZ, LXC) на публичных VPS открывает вектор компрометации через общее ядро хоста: любая 0-day уязвимость ядра (Dirty Pipe, eBPF escape) позволяет злоумышленнику перехватить контроль над всеми арендаторами ноды. Полноценная изоляция гипервизора на базе KVM запускает изолированное ядро для каждого гостя с аппаратной защитой Intel VT-x/AMD-V. В сочетании с локальными NVMe snapshots и неизменяемыми WORM-бэкапами в S3 это формирует отказоустойчивую среду, защищенную как от побегов из виртуальной машины, так и от деструктивных действий шифровальщиков.

Архитектурная изоляция: аппаратный KVM против общего ядра OpenVZ/LXC

Контейнерные среды (OpenVZ, LXC) используют изоляцию на уровне пространства имен ядра (namespaces, cgroups, chroot). Все арендаторы делят одну таблицу системных вызовов (syscalls), драйверы устройств и сетевой стек хост-системы.

  • Вектор атаки на общее ядро: Эксплойты классов Local Privilege Escalation (например, CVE-2022-0847 Dirty Pipe или уязвимости подсистемы io_uring) при выполнении внутри LXC-контейнера дают злоумышленнику права root на физической ноде. Результат — мгновенный доступ к сырым блочным устройствам, оперативной памяти и сетевым интерфейсам соседних VPS.
  • Аппаратная изоляция гипервизора KVM: Каждая виртуальная машина работает как отдельный процесс ОС хоста (qemu-kvm), изолированный аппаратными инструкциями процессора (Intel VT-x / AMD-V) и расширенными таблицами страниц (EPT/NPT). Гостевая ОС запускает собственное независимое ядро Linux или BSD. Дополнительно гипервизор ограничивает гостевой процесс политиками sVirt (SELinux/AppArmor) и жесткими фильтрами seccomp, блокируя несанкционированные системные вызовы к хосту.
  • Шумящие соседи (Noisy Neighbors): В средах OpenVZ арендаторы конкурируют за dentry-кэш, дескрипторы сокетов и буферы ядра. Атака типа DoS на соседний контейнер может вызвать срабатывание глобального OOM Killer на хосте. В KVM vCPU, RAM и страницы памяти жестко зафиксированы за виртуальной машиной, что исключает деградацию производительности из-за чужих аномальных нагрузок.
Критерий безопасности и архитектуры KVM (Kernel-based Virtual Machine) OpenVZ / LXC (Контейнеры)
Архитектура ядра Выделенное ядро гостевой ОС (любая версия/сборка) Общее разделяемое ядро хостовой ноды
Уровень изоляции Аппаратная (изоляция гипервизора через VT-x/AMD-V + EPT) Программная (namespaces, cgroups, capabilities)
Риск побега (Escape to Host) Минимальный (требуется сложный пробив QEMU/KVM + SELinux) Критический (любой эксплойт ядра хоста компрометирует ноду)
Устойчивость к «шумящим соседям» Полная (жесткие лимиты памяти, vCPU и IOPS на уровне KVM) Низкая (общие структуры ядра, риск утечки буферов и OOM)
Модификация ядра и модулей Доступны собственные модули, sysctl, WireGuard, eBPF Заблокированы хостером либо ограничены для всей ноды
Механизм резервирования диска Атомарные NVMe snapshots на уровне блочных устройств Файловое копирование или снимки файловой системы хоста

Снапшоты на NVMe-дисках: мгновенные точки отката перед апдейтами

Установка обновлений безопасности, сборка модулей ядра и патчинг systemd несут риск падения системы (kernel panic) или блокировки доступа по SSH. Традиционное создание бэкапов через tar или rsync во время работы базы данных приводит к несогласованным данным (inconsistent state) и создает долгую I/O-нагрузку на диск.

  • Принцип работы NVMe snapshots: Технология Copy-on-Write (CoW) на уровне контроллера хранилища или тонкого пула LVM/QCOW2 фиксирует метаданные диска за микросекунды. Запись новых данных перенаправляется в дельта-блоки, не затрагивая исходное состояние.
  • Сценарий применения перед обновлением ядра:
  • Остановка транзакций или сброс буферов БД на диск (sync; fsfreeze -f /).
  • Инициация снапшота через API провайдера или CLI гипервизора (virsh snapshot-create-as).
  • Разморозка файловой системы (fsfreeze -u /) и накат патчей безопасности (apt update && apt dist-upgrade).
  • В случае сбоя сети или проблем с загрузчиком GRUB возврат к рабочей точке занимает менее 30 секунд без потери времени на развертывание архивов.

Стратегия неизменяемых (Immutable) бэкапов в изолированное S3

Локальные снапшоты диска не являются полноценной резервной копией: при компрометации root-доступа злоумышленник удаляет локальные точки восстановления перед шифрованием файловой системы. Для защиты критических данных необходима архитектура с изоляцией сред и неизменяемостью данных (WORM — Write Once, Read Many).

[VPS Сервер: KVM] 
       │ 
       │ (1) Дамп БД + инкрементный архив через шифрованный TLS-канал
       ▼
[Изолированное S3-хранилище (MinIO / Ceph / AWS)]
       ├── S3 Object Lock (Compliance Mode: retention 30 days)
       ├── Раздельный IAM: ключ VPS имеет только права s3:PutObject
       └── Запрет на s3:DeleteObject / s3:PutObjectRetention
  • S3 Object Lock (Режим Compliance): Параметр запрещает изменение или удаление объектов на уровне API объектного хранилища в течение установленного периода (например, 30 или 60 дней). Даже если атакующий получит конфигурационные файлы бэкапера с учетными данными (Access Key / Secret Key), сервер S3 вернет 403 Access Denied на любые команды удаления (DeleteObject, AbortMultipartUpload).
  • Разделение привилегий по принципу Least Privilege: Учетной записи на VPS запрещается вызов операций чтения прошлых архивов (GetObject) и просмотр дерева бакетов. Инструменты вроде restic или kopia настраиваются в режиме append-only: агент отправляет новые дельта-блоки в репозиторий, но не может переписать историю.
  • Сетевая и инфраструктурная изоляция: S3-хранилище должно располагаться в отдельном дата-центре или у независимого поставщика с аутентификацией через выделенный сервисный аккаунт, полностью изолированный от панели управления виртуальным сервером.

Чек-лист харденинга: проверка защищенности VPS перед вводом в эксплуатацию

Вывод неизолированного Linux-сервера в публичный сегмент без верификации базовой линии безопасности по стандартам CIS Benchmark (Center for Internet Security) приводит к автоматической компрометации в первые часы работы: сканеры Shodan, Censys и ботнеты начинают подбор реквизитов и зондирование открытых портов сразу после фиксации анонса IP-префикса в BGP. Финальный рубеж защиты хоста — системная верификация конфигураций ядра, файловой системы и сетевого периметра.

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

1. Автоматизированный аудит системы: сканер Lynis и Hardening Index

Вместо ручного перебора сотен параметров аудит базовой конфигурации автоматизируется с помощью Lynis — консольного сканера безопасности open-source уровня с модулями глубокого анализа ядра, привилегий и демонов.

Чтобы не засорять систему сторонними зависимостями перед запуском в продакшен, запуск сканера выполняется из отдельного каталога:

git clone https://github.com/CISOfy/lynis /opt/lynis
cd /opt/lynis && ./lynis audit system --quick --warnings-only

По завершении аудита сканер формирует детальный отчет в /var/log/lynis.log и агрегирует метрику Hardening Index в файле данных:

grep -E "hardening_index|warning" /var/log/lynis-report.dat
  • Целевой показатель: Hardening Index обязан составлять $\ge 80$ пунктов. При значениях ниже 70 сервер возвращается на доработку конфигурации.
  • Анализ предписаний: Раздел Suggestions в логе парсится однострочником: bash grep -A 2 'suggestion\[\]' /var/log/lynis-report.dat Каждый пункт содержит идентификатор теста (например, KRNL-5830, SSH-7408), жестко привязанный к рекомендациям CIS Benchmark.

2. Матрица сетевого стека: sysctl hardening против IP-спуфинга и SYN-flood

Дефолтные настройки сетевого стека ядра Linux оптимизированы под совместимость, а не под противодействие активным сетевым атакам. Для защиты стека TCP/IP, блокировки атак с подменой исходящих адресов (IP spoofing), переполнения буферов SYN-flood и атак типа «человек посередине» (MITM) через ICMP создается изолированный конфигурационный файл /etc/sysctl.d/99-security-hardening.conf.

Конфигурационная матрица sysctl hardening:

Параметр ядра Значение Вектор атаки / Эксплуатация Эффект применения
net.ipv4.conf.all.rp_filter
net.ipv4.conf.default.rp_filter		 1 IP Spoofing, маршрутизация пакетов с фальшивыми источниками Активирует строгую проверку обратного пути (RFC 3704). Ядро отбрасывает входящие пакеты, если ответ на них уходит через другой сетевой интерфейс.
net.ipv4.tcp_syncookies 1 SYN-flood DoS (исчерпание TCP SYN-backlog очереди) Переключает ядро на генерацию криптографических SYN-cookie при переполнении таблицы соединений; отпадает необходимость хранить полуоткрытые сокеты в памяти.
net.ipv4.conf.all.accept_source_route
net.ipv6.conf.all.accept_source_route		 0 Source Routing Bypass (обход списков контроля доступа фаервола) Запрещает отправителю указывать жесткий маршрут следования пакета через транзитные шлюзы; исключает подмену топологии сети.
net.ipv4.conf.all.accept_redirects
net.ipv6.conf.all.accept_redirects		 0 ICMP Redirect MITM (перехват или сброс трафика) Блокирует прием ICMP-пакетов перенаправления маршрутов от посторонних хостов в локальном L2-сегменте хостинга.
net.ipv4.conf.all.send_redirects 0 Несанкционированная маршрутизация трафика Запрещает узлу передавать ICMP Redirect; гарантирует, что VPS не будет использован как паразитный транзитный маршрутизатор.
net.ipv4.icmp_echo_ignore_broadcasts 1 Smurf-атаки (усиление DoS через широковещательный ICMP) Игнорирует ping-запросы на широковещательные адреса (255.255.255.255 и broadcast подсетей).
net.ipv4.tcp_rfc1337 1 TCP TIME-WAIT Assassination (инъекция сброса RST в соединение) Защищает сокеты в состоянии TIME-WAIT от несанкционированного закрытия поддельными RST-сегментами (согласно RFC 1337).
fs.protected_hardlinks
fs.protected_symlinks		 1 Символьные/жесткие гонки (Symlink TOCTOU Escalation) Запрещает переход по симлинкам в общедоступных каталогах (/tmp, /var/tmp), если владелец ссылки не совпадает с владельцем целевого файла.
kernel.kptr_restrict 2 Утечка адресов памяти ядра (KASLR Bypass) Скрывает указатели ядра в /proc/kallsyms и сетевых таблицах даже от суперпользователя root, усложняя сборку ROP-цепочек эксплойтов.

Применение параметров без перезагрузки ноды:

sysctl --system

3. Инженерный чек-лист безопасности: предпусковой аудит прав доступа

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

Шаг 1: Аудит бинарных файлов с флагами SUID/SGID

Файлы с битом SUID исполняются с привилегиями владельца (root). Любая ошибка переполнения буфера в них ведет к мгновенному локальному повышению привилегий (LPE).

  • Сканирование нестандартных SUID-файлов: bash find / -xdev -type f \( -perm -4000 -o -perm -2000 \) -exec ls -ld {} + > /tmp/suid_list.txt
  • Исключение опасных бинарников: Инструменты вроде pkexec, exim4, chfn, chsh, если они не задействованы в бизнес-логике, лишаются SUID-бита: bash chmod u-s /usr/bin/pkexec /usr/bin/chfn /usr/bin/chsh

Шаг 2: Аудит прав доступа к критическим конфигурационным файлам

Конфигурация учетных записей и демонов закрывается от чтения непривилегированными пользователями:

chmod 644 /etc/passwd
chmod 000 /etc/shadow
chmod 000 /etc/gshadow
chmod 644 /etc/group
chmod 600 /etc/ssh/sshd_config
chmod 700 /root/.ssh
chmod 600 /root/.ssh/authorized_keys

Шаг 3: Верификация открытых сетевых сокетов

Сервер не должен слушать ни одного лишнего порта на внешних интерфейсах 0.0.0.0 или :::

ss -tulpn
  • Служебные базы данных (PostgreSQL, Redis, MySQL) жестко биндятся на 127.0.0.1 или работают исключительно через UNIX-сокеты.
  • Протокол RPC (rpcbind), cups, avahi-daemon удаляются из автозагрузки: bash systemctl disable --now rpcbind avahi-daemon

4. Регламент ротации ключей доступа и аудита межсетевого экрана

Харденинг не является статичным состоянием: деградация защиты происходит по мере накопления временных правил в фаерволе и старения учетных данных. Эксплуатация VPS регламентируется периодическим графиком технического обслуживания:

  1. Ротация SSH-ключей (Каждые 90 дней):
  2. Все ключи устаревшего стандарта RSA (менее 4096 бит) запрещаются. Стандартом является исключительно эллиптическая криптография: ssh-keygen -t ed25519 -a 100 -C "admin-vps-$(date +%Y%m)".
  3. При компрометации или плановой ротации старый публичный ключ удаляется из /root/.ssh/authorized_keys и пользовательских профилей; процесс завершается принудительным сбросом активных мультиплексированных сессий: pkill -u <username> -f sshd.
  4. Аудит правил фаервола nftables / iptables (Ежемесячно):
  5. Инспекция неактуальных белых списков IP-адресов разработчиков и CI/CD: bash nft -a list ruleset
  6. Удаление неиспользуемых правил по их системному дескриптору handle: bash nft delete rule inet filter input handle <handle_number>
  7. Проверка счетчиков трафика: отслеживание аномального роста дропнутых пакетов (drop) на пограничных портах для выявления направленного сканирования.
  8. Контроль целостности системных бинарников (Еженедельно):
  9. Верификация контрольных сумм пакетов через встроенный менеджер пакетов дистрибутива: bash # Для Debian/Ubuntu: debsums -c -s # Для RHEL/Rocky Linux: rpm -Va --nomtime
  10. Обнаружение модификаций в системных ELF-бинарниках свидетельствует о внедрении руткита и требует немедленного отзыва сертификатов и развертывания системы из чистого Snapshot/IaC-манифеста.

Часто задаваемые вопросы (FAQ)

Достаточно ли сменить стандартный порт SSH с 22 на другой, чтобы защитить сервер от взлома?

Нет. Смена порта отсекает лишь автоматические сканеры ботнетов, но не защищает от целенаправленной разведки через nmap. Базовой защитой является вход исключительно по SSH-ключам Ed25519 с отключенной парольной авторизацией.

Что надежнее для защиты VPS: Fail2ban или CrowdSec?

Fail2ban подходит для автономного анализа локальных логов, но CrowdSec значительно эффективнее за счет коллективной базы скомпрометированных IP-адресов и меньшей нагрузки на CPU при больших потоках запросов.

В чем преимущество KVM VPS перед OpenVZ в плане информационной безопасности?

KVM обеспечивает полную аппаратную виртуализацию с собственным изолированным ядром Linux. Взлом или DoS-атака на соседний VPS на той же ноде не позволит злоумышленнику повлиять на вашу систему через уязвимости общего ядра хоста.

Как не заблокировать самому себе доступ при настройке UFW или nftables?

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

Нужно ли устанавливать антивирус на Linux VPS сервер?

Классический антивирус (например, ClamAV) нужен преимущественно серверам, принимающим файлы от пользователей. Для защиты самого сервера критичнее сканеры целостности файлов (AIDE), анализаторы руткитов (rkhunter) и аудит уязвимостей (Lynis).

Назад к блогу