VPS Hardening (Харденінг та безпека Linux VPS)(Харденінг та безпека 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). Доступ до консолі провайдера еквівалентний прямому фізичному доступу до материнської плати сервера.