VPS Hardening (Укрепление и безопасность Linux VPS)

1. Обзор концепции и системная проблема

Сразу после инициализации виртуального сервера (VPS) у облачного провайдера (Hetzner, DigitalOcean, AWS) инстанс попадает под сканирование глобальных ботнетов в течение первых 5-15 минут. По умолчанию многие образы ОС имеют включенную парольную аутентификацию для пользователя root, открытые служебные порты и отсутствие базовой защиты от перебора паролей.

VPS Hardening (Укрепление сервера) — это инженерный регламент усиления безопасности операционной системы Linux по стандарту CIS Benchmarks (Center for Internet Security). Цель укрепления:

• Минимизировать площадь потенциальной атаки (Attack Surface).
• Полностью исключить возможность входа по паролю через незащищенные каналы.
• Изолировать выполнение процессов от имени суперпользователя (Root).
• Настроить аудит событий, автоматическое закрытие уязвимостей нулевого дня (0-day) и пакетную фильтрацию на уровне ядра.

Начальное состояние VPS (Высокий риск):
[Интернет] ---> [Порт 22: SSH (Root + Пароль)] ---> [Полный взлом системы]

После Hardening (Многоуровневая оборона):
[Интернет] ---> [UFW Фаервол (Default Deny)]
                     |
                     v
                [Fail2ban (Блокировка сканеров)]
                     |
                     v
                [SSH: Только Ed25519 ключи, Non-Root sudo]
                     |
                     v
                [Автономные обновления (unattended-upgrades)]

2. Архитектурная таксономия и ментальная модель

Укрепление разворачивается в четырех изолированных плоскостях безопасности:

1. Уровень аутентификации и контроля доступа (Identity & Access):
   • Полная деактивация прямого входа под root через SSH (PermitRootLogin no).
   • Запрет парольной аутентификации (PasswordAuthentication no).
   • Создание непривилегированного пользователя с обязательным членством в группе sudo.
   • Установка криптографических ключей Ed25519.
2. Сетевой уровень (Network Perimeter):
   • Включение ufw с политикой сброса всех входящих пакетов (default deny incoming).
   • Открытие только жизненно необходимых портов (например, 2222/tcp, 80/tcp, 443/tcp).
   • Развертывание fail2ban для автоматического бана хостов, генерирующих аномальные запросы.
3. Уровень операционной системы и ядра (OS & Kernel):
   • Тюнинг параметров sysctl для защиты сетевого стека (запрет ICMP redirect, защита от SYN-flood атак).
   • Включение расширенных безопасных обновлений (unattended-upgrades).
4. Уровень приложений и среды выполнения (Runtime Isolation):
   • Запуск докер-контейнеров и AI-агентов под отдельными непривилегированными UID/GID без доступа к /var/run/docker.sock.

3. Технический пайплайн и внутренняя механика

Шаг 1. Создание sudo-пользователя и деплой SSH-ключа

Подключившись к чистому серверу под временным root-паролем, немедленно создаем инженерного пользователя:

# Создание пользователя deploy с домашней директорией и zsh/bash
adduser --gecos "" deploy
usermod -aG sudo deploy

# Копирование публичного ключа Ed25519
mkdir -p /home/deploy/.ssh
cp /root/.ssh/authorized_keys /home/deploy/.ssh/
chown -R deploy:deploy /home/deploy/.ssh
chmod 700 /home/deploy/.ssh
chmod 600 /home/deploy/.ssh/authorized_keys

Шаг 2. Укрепление демона OpenSSH (/etc/ssh/sshd_config.d/99-hardening.conf)

Создаем изолированный файл конфигурации SSH для защиты от перезаписи во время обновления пакетов:

# Изменение порта (опционально, но рекомендовано)
Port 2222

# Полный запрет root-доступа и паролей
PermitRootLogin no
PasswordAuthentication no
ChallengeResponseAuthentication no
KbdInteractiveAuthentication no

# Разрешение исключительно надежных криптографических ключей
PubkeyAuthentication yes
AuthenticationMethods publickey

# Защита сессий от зависания
ClientAliveInterval 300
ClientAliveCountMax 2

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

Тестирование конфигурации перед перезапуском:

# Валидация синтаксиса (если пустой вывод — конфиг корректен)
sudo sshd -t
sudo systemctl restart sshd

Шаг 3. Настройка параметров ядра Linux (/etc/sysctl.d/99-security.conf)

# Защита от TCP SYN Flood атак
net.ipv4.tcp_syncookies = 1

# Запрет перенаправления пакетов маршрутизации (защита от Man-in-the-Middle)
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0

# Игнорирование подделанных ICMP-ответов
net.ipv4.icmp_echo_ignore_broadcasts = 1

# Запрет IP Source Routing
net.ipv4.conf.all.accept_source_route = 0

Применение изменений ядра без перезагрузки:

sudo sysctl --system

4. Практические инженерные сценарии в продакшене

01. Автоматизированное Hardening через Cloud-Init на Hetzner Cloud

Во время создания виртуального сервера через Terraform или панель управления Hetzner передается User Data скрипт (cloud-init). Сервер запускается уже с закрытым root, предварительно созданным пользователем, сгенерированными правилами UFW и настроенным SSH на нестандартном порту, полностью устраняя окно уязвимости в первые минуты жизни машины.

02. Автоматическое обновление безопасных патчей ядра без вмешательства

Настройка пакета unattended-upgrades в Ubuntu:

sudo apt install unattended-upgrades update-notifier-common
sudo dpkg-reconfigure --priority=low unattended-upgrades

Сервер самостоятельно загружает и устанавливает критические обновления безопасности из официальных репозиториев Security каждую ночь, а утилита needrestart автоматически перезапускает скомпрометированные сервисы без перезагрузки операционной системы.

03. Изоляция внутреннего трафика Docker-демона

Docker автоматически пытается выставить порты на все сетевые интерфейсы (0.0.0.0). Во время укрепления файл /etc/docker/daemon.json конфигурируется с ограничением привязки по умолчанию:

{
  "iptables": true,
  "live-restore": true,
  "userland-proxy": false
}

Это гарантирует, что сервисы без явного маппинга на локальный хост остаются внутри виртуального сетевого моста Docker и не светят портами в публичный интернет.

5. Подводные камни, типовые ошибки и безопасность

1. Случайный самоблок (SSH Lockout): Наиболее распространенная ошибка инженера: закрыть доступ по паролю и запретить root, забыв проверить, работает ли публичный ключ для нового пользователя или разрешен ли новый порт в UFW. Никогда не закрывайте начальную сессию терминала, пока успешно не подключитесь в параллельной вкладке.
2. Сохранение пароля sudo в скриптах или .bash_history: Использование echo "password" | sudo -S ... в shell-скриптах или ввод паролей в терминал приводит к утечке в открытом тексте в истории команд. Используйте sudo visudo для делегирования конкретных команд без пароля (NOPASSWD) для узкоспециализированных сервисных аккаунтов CI/CD.
3. Игнорирование безопасности Out-of-band консоли провайдера: Даже идеально защищенный сервер можно скомпрометировать, если учетная запись в консоли хостинг-провайдера (Hetzner Cloud Console, DigitalOcean Dashboard) защищена простым паролем без аппаратной двухфакторной аутентификации (2FA / WebAuthn). Доступ к консоли провайдера эквивалентен прямому физическому доступу к материнской плате сервера.