Hardening Ubuntu 24.04 за 30 хвилин: чекліст для нового VPS

Що ми налаштовуємо і навіщо

Новий VPS з Ubuntu 24.04 зазвичай доступний за публічною IPv4-адресою одразу після провіжинінгу. Інтернет-сканери знаходять таку адресу за лічені хвилини: вони перевіряють SSH, вебпорти, бази даних, Docker API, панелі керування та відомі вразливі сервіси. Навіть сервер без сайту та застосунків майже одразу починає отримувати спроби перебору паролів.

Мета цього посібника — створити безпечний базовий рівень для Ubuntu 24.04 LTS. Це не замінює аудит конкретного застосунку, захист коду, налаштування IAM або DDoS-захист, але усуває типові помилки нового VPS: доступ root за паролем, відкриті зайві порти, відсутність оновлень, необмежені спроби входу та відсутність резервних копій.

Після виконання чек-листа сервер матиме окремого адміністратора, вхід за SSH-ключами, обмежений firewall, Fail2ban, увімкнені автоматичні оновлення безпеки, аудит відкритих портів і основу для зашифрованих бекапів. Цей набір підходить для VPS із сайтом, API, VPN, Git-сервісом, Minecraft-сервером, ботом, Docker Compose та внутрішніми інструментами.

Що не входить до базового hardening

Hardening ОС не робить небезпечний застосунок безпечним. Якщо ви публікуєте WordPress, GitLab, Nextcloud, Grafana, Mattermost або власний API, потрібно окремо оновлювати сам застосунок, використовувати надійні паролі та MFA, вимикати тестові endpoints, обмежувати адміністративні URL і регулярно перевіряти логи.

Також не варто сприймати зміну SSH-порту як захист. Нестандартний порт зменшує шум у логах, але не замінює ключі, firewall і заборону паролів. Сканери швидко знаходять відкриті порти.

Правило безпечного порядку: спочатку додайте та протестуйте новий доступ, а потім посилюйте старий. Не закривайте поточну SSH-сесію, доки не переконаєтеся, що нова сесія працює.

Cloud-managed і self-hosted: що обрати

Self-hosted VPS обирають заради контролю: можна запускати потрібні версії ПЗ, зберігати дані у вибраній юрисдикції, не платити за кожен managed-компонент і не залежати від обмежень платформи. Ціна контролю — необхідність регулярно виконувати експлуатаційні роботи. Цей чек-лист зменшує початковий ризик, але його потрібно повторювати після змін інфраструктури.

Який VPS-конфіг потрібен для цього завдання

Сам hardening майже не потребує ресурсів. Ubuntu 24.04, OpenSSH, UFW, Fail2ban і unattended-upgrades нормально працюють на невеликому сервері. Ресурси визначає не захист, а ваш майбутній застосунок: база даних, Docker-контейнери, ігровий сервер, VPN, CI, файлове сховище або вебзастосунок.

Для універсального нового сервера під невеликий проєкт розумний старт — 2 vCPU, 4 ГБ RAM, 60–80 ГБ NVMe та публічний IPv4. Такий запас дає змогу використовувати Docker, reverse proxy, логи, swap і невелику базу даних без постійного дефіциту пам’яті. Як один із нейтральних варіантів можна взяти VPS із зазначеними характеристиками, але перед замовленням зіставте обсяг диска з розміром бекапів і зростанням даних.

Коли VPS достатньо

VPS підходить майже для всіх одиночних сервісів і невеликих команд. Ізоляція віртуальної машини, регулярні snapshots і можливість швидко збільшити тариф зручні для старту. Для WireGuard, вебзастосунку, моніторингу, кількох контейнерів і кількох десятків користувачів VPS зазвичай більш ніж достатньо.

Коли потрібен dedicated

Обирайте dedicated, якщо потрібен гарантований CPU без конкуренції із сусідами, дуже інтенсивний I/O, багато пам’яті, великі локальні масиви даних, висока пропускна здатність або передбачувана продуктивність під постійним навантаженням. Типові приклади: великий ігровий сервер, індексатор блокчейну, CI-раннери, кілька важких віртуальних машин, медіатранскодування та база даних на сотні гігабайтів.

Як впливає локація

Локація впливає на затримку, законодавство щодо даних і швидкість доступу до вашої аудиторії. Для VPN обирайте регіон поруч із користувачами. Для бази з персональними даними враховуйте вимоги вашої юрисдикції та договорів. Для адміністрування важлива не лише географія, а й стабільність маршруту: перевірте затримку командою ping і фактичну швидкість після запуску.

Підготовка сервера

Нижче передбачається, що провайдер надав IPv4-адресу та тимчасовий root-пароль або додав ваш публічний ключ. Працюйте зі звичайного локального термінала. У Windows підійдуть PowerShell, Windows Terminal або WSL. Усі команди виконуються на сервері, якщо не зазначено інше.

Перевірте систему й оновіть пакети

Ubuntu 24.04 LTS використовує гілку Linux 6.8 з HWE-оновленнями залежно від образу. Не орієнтуйтеся лише на номер версії: патчі безпеки часто бекпортяться, тому пакет може мати старий upstream-номер і водночас бути виправленим.

# Подключитесь к серверу по адресу, выданному после провижининга.
ssh root@SERVER_IP

# Проверьте релиз Ubuntu, ядро и текущего пользователя.
cat /etc/os-release
uname -r
whoami

# Обновите индекс пакетов и установленные пакеты.
apt update && apt full-upgrade -y

# Перезагрузите сервер, если обновилось ядро или systemd.
reboot

Після перезавантаження підключіться знову. Якщо SSH тимчасово не відповідає, зачекайте одну-дві хвилини та перевірте вебконсоль у провайдера. Не продовжуйте налаштування, доки не переконаєтеся, що система завантажилася.

Створіть окремого адміністратора

Не використовуйте root як щоденний обліковий запис. Окремий користувач забезпечує зрозумілий аудит дій, знижує ризик випадкової команди з повними правами й дає змогу безпечно вимкнути root-login через SSH.

# Создайте пользователя admin и добавьте его в группу sudo.
adduser admin
usermod -aG sudo admin

# Создайте каталог для SSH-ключей с корректными правами.
install -d -m 700 -o admin -g admin /home/admin/.ssh

# Скопируйте уже работающий root authorized_keys новому пользователю.
cp /root/.ssh/authorized_keys /home/admin/.ssh/authorized_keys
chown admin:admin /home/admin/.ssh/authorized_keys
chmod 600 /home/admin/.ssh/authorized_keys

Якщо в root немає файлу authorized_keys, створіть ключ на своєму комп’ютері. Для 2026 року практичний вибір — Ed25519. Не передавайте приватний ключ на сервер і не надсилайте його в месенджери.

# Выполните на локальном компьютере: создайте ключ Ed25519.
ssh-keygen -t ed25519 -a 100 -C "admin@my-vps"

# Скопируйте публичный ключ на сервер; команда спросит текущий пароль root.
ssh-copy-id -i ~/.ssh/id_ed25519.pub root@SERVER_IP

# На сервере повторите копирование ключа в учётную запись admin.
install -d -m 700 -o admin -g admin /home/admin/.ssh
cp /root/.ssh/authorized_keys /home/admin/.ssh/authorized_keys
chown admin:admin /home/admin/.ssh/authorized_keys
chmod 600 /home/admin/.ssh/authorized_keys

Відкрийте другий термінал і перевірте новий доступ. Стару root-сесію не закривайте.

# Выполните локально: вход должен пройти по ключу без пароля пользователя.
ssh -i ~/.ssh/id_ed25519 admin@SERVER_IP

# Проверьте, что sudo работает в новой сессии.
sudo whoami

Очікуваний результат останньої команди — root. Лише після цього переходьте до налаштування SSH. Якщо ключ не працює, спочатку виправте права на /home/admin/.ssh і authorized_keys.

Встановлення ПЗ — покроково

В Ubuntu 24.04 використовуються пакети OpenSSH 9.6p1 із патчами Ubuntu, UFW 0.36.x, Fail2ban 1.0.x і unattended-upgrades 2.9.x. Точну встановлену версію завжди перевіряйте через apt-cache policy: безпека визначається доступними оновленнями конкретного репозиторію, а не лише номером upstream-версії.

# Подключитесь под новым пользователем и установите базовые инструменты.
ssh admin@SERVER_IP
sudo apt update
sudo apt install -y ufw fail2ban unattended-upgrades apt-listchanges \
  curl ca-certificates gnupg jq vim-tiny lsof needrestart chrony

Пакет needrestart повідомляє, які служби потребують перезапуску після оновлення бібліотек. chrony підтримує точний час, що важливо для TLS, токенів, журналів і розслідування інцидентів.

# Проверьте версии и статус основных служб после установки.
apt-cache policy openssh-server ufw fail2ban unattended-upgrades
systemctl status ssh --no-pager
systemctl status chrony --no-pager
timedatectl status

Налаштуйте UFW до вимкнення слабких методів SSH

UFW керує правилами Netfilter. Безпечна послідовність: дозволити SSH, увімкнути firewall, перевірити статус, потім відкрити лише необхідні сервіси. Якщо ви використовуєте нестандартний SSH-порт, дозвольте саме його до застосування конфігурації.

# Задайте политику: входящие запрещены, исходящие разрешены.
sudo ufw default deny incoming
sudo ufw default allow outgoing

# Разрешите SSH и включите firewall.
sudo ufw allow 22/tcp comment 'OpenSSH'
sudo ufw enable

# Проверьте активные правила и номера правил.
sudo ufw status numbered

Якщо сервер обслуговуватиме звичайний HTTPS-сайт, відкрийте HTTP і HTTPS. Порт 80 потрібен Caddy або Certbot для випуску сертифіката через HTTP-01. Після отримання сертифіката його зазвичай залишають відкритим для автоматичного продовження та редиректу на HTTPS.

# Откройте веб-порты только если на сервере действительно будет HTTP/HTTPS-сервис.
sudo ufw allow 80/tcp comment 'HTTP'
sudo ufw allow 443/tcp comment 'HTTPS'

# Убедитесь, что доступен только ожидаемый набор портов.
sudo ufw status verbose
sudo ss -tulpn

Встановіть і увімкніть автоматичні security-оновлення

Автоматичне застосування оновлень безпеки не скасовує ручні оновлення. Воно закриває критичний проміжок між виходом патчу та вашим запланованим вікном обслуговування. Для production-сервісів, чутливих до рестартів, заздалегідь тестуйте оновлення на staging-сервері.

# Запустите интерактивную настройку автоматических обновлений Ubuntu.
sudo dpkg-reconfigure --priority=low unattended-upgrades

# Включите таймеры загрузки списков пакетов и установки обновлений.
sudo systemctl enable --now apt-daily.timer apt-daily-upgrade.timer

# Проверьте расписание системных таймеров.
systemctl list-timers --all | grep -E 'apt-daily|unattended'

Увімкніть Fail2ban

Fail2ban читає журнали та тимчасово блокує IP-адреси після серії невдалих спроб. Це корисно проти масового перебору, але не є заміною SSH-ключів. В Ubuntu 24.04 журнал SSH зазвичай доступний через systemd journal; нижче використовується backend systemd.

# Создайте локальный конфигурационный каталог Fail2ban.
sudo install -d -m 755 /etc/fail2ban/jail.d

# Создайте отдельную локальную конфигурацию для SSH.
sudo tee /etc/fail2ban/jail.d/sshd.local > /dev/null <<'EOF'
[sshd]
enabled = true
backend = systemd
port = ssh
maxretry = 5
findtime = 10m
bantime = 1h
banaction = ufw
EOF

# Проверьте конфигурацию и запустите службу.
sudo fail2ban-client -d > /dev/null
sudo systemctl enable --now fail2ban
sudo fail2ban-client status sshd

Не редагуйте файли /etc/fail2ban/jail.conf і /etc/ssh/sshd_config, що постачаються пакетом, без потреби: оновлення можуть їх змінити. Для локальних налаштувань використовуйте jail.d/.local і sshd_config.d/.conf.

Конфігурація

Посильте SSH без втрати доступу

Ubuntu 24.04 підтримує каталог /etc/ssh/sshd_config.d/. Створимо файл із пріоритетним локальним набором параметрів. Перед перезапуском завжди запускайте перевірку синтаксису: одна помилка в SSH-конфігурації може залишити сервер без віддаленого доступу.

# Создайте локальный файл с безопасными настройками OpenSSH.
sudo tee /etc/ssh/sshd_config.d/99-hardening.conf > /dev/null <<'EOF'
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
PermitEmptyPasswords no
UsePAM yes
X11Forwarding no
AllowUsers admin
MaxAuthTries 3
LoginGraceTime 30
ClientAliveInterval 300
ClientAliveCountMax 2
LogLevel VERBOSE
EOF

# Проверьте синтаксис и примените изменения без полного рестарта.
sudo sshd -t
sudo systemctl reload ssh

# Проверьте эффективные параметры, учитывая все include-файлы.
sudo sshd -T | grep -E 'permitrootlogin|passwordauthentication|kbdinteractiveauthentication|allowusers|maxauthtries'

Тепер відкрийте ще одне нове SSH-підключення як admin. Якщо підключення проходить, root-доступ через SSH вимкнено коректно. Якщо ви використовуєте кількох адміністраторів, перелічіть їх у AllowUsers через пробіл або видаліть цей рядок і керуйте доступом іншими способами.

# Выполните локально: проверьте вход администратора после hardening SSH.
ssh -o PreferredAuthentications=publickey admin@SERVER_IP

# Выполните локально: root-вход должен быть отклонён.
ssh root@SERVER_IP

Додайте параметри ядра через sysctl

Наступні параметри вимикають невикористовувану маршрутизацію IPv4 і зменшують ризик низки мережевих підмін. Не застосовуйте їх бездумно на VPS, який працює як маршрутизатор, WireGuard-шлюз, Kubernetes-нода або NAT-шлюз: там знадобиться окрема мережева конфігурація.

# Создайте безопасные sysctl-настройки для обычного публичного сервера.
sudo tee /etc/sysctl.d/99-hardening.conf > /dev/null <<'EOF'
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.send_redirects = 0
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1
net.ipv4.icmp_echo_ignore_broadcasts = 1
net.ipv4.icmp_ignore_bogus_error_responses = 1
net.ipv4.tcp_syncookies = 1
kernel.kptr_restrict = 2
kernel.dmesg_restrict = 1
fs.protected_hardlinks = 1
fs.protected_symlinks = 1
EOF

# Примените sysctl-файлы и проверьте один из параметров.
sudo sysctl --system
sysctl net.ipv4.tcp_syncookies

Зберігайте секрети поза кодом і репозиторієм

Паролі бази даних, токени API, ключі S3 та SMTP-облікові дані не мають потрапляти до Git, Dockerfile, shell history або публічних конфігів Nginx/Caddy. Для невеликого сервісу зберігайте змінні у файлі .env з правами 600. Для systemd використовуйте EnvironmentFile. У більшій інфраструктурі застосовуйте Vault, SOPS, cloud secret manager або аналогічне сховище секретів.

# Создайте защищённый каталог и файл переменных окружения для приложения.
sudo install -d -m 750 -o root -g root /etc/myapp
sudo tee /etc/myapp/app.env > /dev/null <<'EOF'
APP_ENV=production
DATABASE_URL=postgresql://app:[email protected]:5432/app
JWT_SECRET=CHANGE_ME_TO_A_LONG_RANDOM_VALUE
EOF
sudo chmod 600 /etc/myapp/app.env

# Сгенерируйте криптографически случайный секрет и замените placeholder вручную.
openssl rand -base64 48

TLS/HTTPS через Caddy

Якщо на VPS є веб-сервіс, публікуйте його через reverse proxy. Caddy автоматично отримує та продовжує TLS-сертифікати, якщо DNS-запис домену вказує на IP сервера, а порти 80 і 443 доступні ззовні. Не встановлюйте Caddy лише заради hardening: якщо веб-сервісу немає, тримайте 80 і 443 закритими.

# Добавьте официальный репозиторий Caddy для актуальной стабильной ветки 2.x.
sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | \
  sudo gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | \
  sudo tee /etc/apt/sources.list.d/caddy-stable.list
sudo apt update && sudo apt install -y caddy

# Проверьте установленную версию Caddy.
caddy version

Припустімо, застосунок слухає лише локальну адресу 127.0.0.1:3000. Це важливе обмеження: сервіс не повинен додатково відкривати порт 3000 в інтернет. Замініть домен і порт на власні значення.

example.com {
    encode zstd gzip

    reverse_proxy 127.0.0.1:3000

    header {
        -Server
        X-Content-Type-Options "nosniff"
        X-Frame-Options "DENY"
        Referrer-Policy "strict-origin-when-cross-origin"
        Strict-Transport-Security "max-age=31536000; includeSubDomains"
    }

    log {
        output file /var/log/caddy/example.com.access.log
        format json
    }
}

# Сохраните Caddyfile, проверьте его и перезагрузите Caddy.
sudo cp /etc/caddy/Caddyfile /etc/caddy/Caddyfile.bak
sudo vim /etc/caddy/Caddyfile
sudo caddy validate --config /etc/caddy/Caddyfile
sudo systemctl enable --now caddy
sudo systemctl reload caddy

# Проверьте HTTP-редирект, HTTPS и локальный health endpoint приложения.
curl -I http://example.com
curl -I https://example.com
curl -fsS http://127.0.0.1:3000/health || echo "Проверьте endpoint приложения"

Фінальна перевірка поверхні атаки

Перевіряйте не лише те, що ви налаштували, а й те, що реально слухає мережа. Команда ss показує локальні сокети. Порти, прив'язані до 127.0.0.1, не доступні безпосередньо з інтернету; адреси 0.0.0.0 і [::] доступні на всіх інтерфейсах за дозволеного firewall.

# Покажите все слушающие TCP/UDP-порты и процессы-владельцы.
sudo ss -tulpn

# Проверьте firewall, Fail2ban, обновления и необходимость перезагрузки.
sudo ufw status numbered
sudo fail2ban-client status sshd
sudo unattended-upgrade --dry-run --debug
sudo needrestart -r l

# Проверьте доступность сервера и TLS с локального компьютера.
ping -c 4 SERVER_IP
curl -fsSI https://example.com

Для зовнішньої перевірки використовуйте другий сервер або мобільний інтернет: переконайтеся, що відкриті лише 22, 80 і 443, якщо це ваш план. Не відкривайте PostgreSQL на 5432, MySQL на 3306, Redis на 6379, Docker API на 2375 і панелі адміністрування «на певний час»: такі тимчасові рішення часто залишаються назавжди.

Резервні копії та обслуговування

Знімок VPS корисний, але не має бути єдиною резервною копією. Він може перебувати в тому самому обліковому записі, тій самій локації й навіть на тій самій інфраструктурі, що й вихідний сервер. Робоча схема — правило 3-2-1: щонайменше три копії даних, на двох типах сховищ, одна копія поза основним сервером.

Що потрібно резервувати

• Конфігурацію: /etc, Caddyfile, systemd units, Docker Compose-файли, налаштування firewall і скрипти.
• Дані застосунків: каталоги uploads, volumes Docker, файли користувачів, медіа, ключі та сертифікати за потреби.
• Бази даних: логічний dump PostgreSQL або MySQL плюс перевірка відновлення.
• Секрети: зашифровані env-файли, ключі доступу, recovery codes. Не зберігайте секрети у звичайному незашифрованому архіві.
• Документацію: список доменів, користувачів, портів, порядок відновлення та дату останньої перевірки restore.

Для невеликого сервера зручний Restic 0.17.x або новіший: він шифрує дані на стороні VPS, підтримує S3-сумісні сховища, дедуплікацію та політики зберігання. Репозиторій Restic не замінює пароль: втрата пароля репозиторію без окремого безпечного зберігання означає втрату доступу до копій.

# Установите Restic и создайте каталог для защищённых переменных бэкапа.
sudo apt install -y restic
sudo install -d -m 700 /root/.config/restic

# Создайте файл окружения; замените все значения на реальные.
sudo tee /root/.config/restic/backup.env > /dev/null <<'EOF'
export RESTIC_REPOSITORY="s3:https://s3.example.net/my-vps-backup"
export RESTIC_PASSWORD="CHANGE_ME_TO_A_LONG_UNIQUE_PASSWORD"
export AWS_ACCESS_KEY_ID="CHANGE_ME"
export AWS_SECRET_ACCESS_KEY="CHANGE_ME"
EOF
sudo chmod 600 /root/.config/restic/backup.env

# Инициализируйте новый зашифрованный репозиторий только один раз.
sudo bash -c 'source /root/.config/restic/backup.env && restic init'

Для PostgreSQL спочатку створюйте дамп, а потім архівуйте його Restic. Наведена нижче команда розрахована на локальну базу та користувача з правами читання всіх потрібних об’єктів. Для Docker-контейнера БД використовуйте docker exec або офіційний механізм dump усередині контейнера.

# Создайте каталог для дампов, недоступный обычным пользователям.
sudo install -d -m 700 /var/backups/postgresql

# Пример: создайте сжатый дамп базы appdb от имени системного пользователя postgres.
sudo -u postgres pg_dump -Fc appdb > /var/backups/postgresql/appdb.dump
sudo chmod 600 /var/backups/postgresql/appdb.dump

# Создайте ежедневный скрипт: дамп БД, backup Restic, проверка и политика хранения.
sudo tee /usr/local/sbin/backup-server.sh > /dev/null <<'EOF'
#!/usr/bin/env bash
set -euo pipefail

source /root/.config/restic/backup.env

DATE="$(date +%F)"
BACKUP_PATHS=(
  /etc
  /home
  /opt
  /srv
  /var/lib/docker/volumes
  /var/backups/postgresql
)

restic backup "${BACKUP_PATHS[@]}" \
  --exclude-caches \
  --exclude='/home//.cache' \
  --tag "server" \
  --tag "$DATE"

restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
restic check --read-data-subset=1/50
EOF
sudo chmod 700 /usr/local/sbin/backup-server.sh

# Запустите первый бэкап вручную и убедитесь, что он завершается без ошибок.
sudo /usr/local/sbin/backup-server.sh
sudo bash -c 'source /root/.config/restic/backup.env && restic snapshots'

# Добавьте запуск каждый день в 03:20 и запись лога в отдельный файл.
sudo tee /etc/cron.d/server-backup > /dev/null <<'EOF'
20 3    root /usr/local/sbin/backup-server.sh >> /var/log/server-backup.log 2>&1
EOF

# Проверьте, что cron видит задание, и посмотрите последние строки лога после запуска.
sudo systemctl status cron --no-pager
sudo tail -n 50 /var/log/server-backup.log

Перевірка відновлення

Бекап вважається робочим лише після відновлення. Раз на місяць відновлюйте один файл і тестовий dump бази в окремий каталог або на окремий сервер. Не відновлюйте базу поверх production-даних без зупинки застосунку та підтвердженого плану відкату.

# Просмотрите содержимое последнего snapshot и восстановите его в тестовый каталог.
sudo bash -c 'source /root/.config/restic/backup.env && restic snapshots'
sudo mkdir -p /tmp/restic-restore
sudo bash -c 'source /root/.config/restic/backup.env && restic restore latest --target /tmp/restic-restore'

# Убедитесь, что нужные файлы и дамп действительно восстановились.
sudo find /tmp/restic-restore -maxdepth 4 -type f | head -n 30

План оновлень

Security-оновлення можна застосовувати автоматично, але оновлення застосунку, Docker-образів і великих версій бази краще планувати в maintenance window. Для stateless вебзастосунку використовуйте rolling-оновлення: запустіть нову версію, перевірте healthcheck, потім перемкніть reverse proxy. Для одиночної бази даних зазвичай потрібен короткий контрольований простій.

1. Раз на тиждень переглядайте journalctl -p warning..alert, стан диска та логи бекапа.
2. Раз на місяць виконуйте sudo apt update && sudo apt full-upgrade і перезавантаження за потреби.
3. Раз на місяць перевіряйте відновлення щонайменше одного файлу й одного дампа БД.
4. Раз на квартал переглядайте користувачів, SSH-ключі, відкриті порти та токени доступу.

Усунення несправностей + FAQ

Після налаштування SSH я отримую Permission denied (publickey)

Спочатку не закривайте стару сесію або використовуйте web-консоль. Перевірте, що входите потрібним користувачем: ssh admin@SERVER_IP. На сервері перевірте права: каталог ~/.ssh має мати режим 700, а authorized_keys — 600 і належати користувачеві. Перегляньте причину в sudo journalctl -u ssh -n 100. Поширена помилка — ключ скопійовано в root, а в конфігурації вже ввімкнено PermitRootLogin no.

UFW увімкнено, але сайт або SSH недоступні

Підключіться через консоль і виконайте sudo ufw status numbered та sudo ss -tulpn. Firewall може дозволяти порт, але застосунок не слухає його або прив’язаний лише до 127.0.0.1. Для SSH має бути рядок allow для фактичного порту. Для сайту перевірте правила 80/tcp і 443/tcp, DNS-запис домену та стан Caddy. У разі помилки правило можна видалити за номером через sudo ufw delete НОМЕР.

Fail2ban не блокує адреси або не бачить спроби SSH

Перевірте службу командою sudo systemctl status fail2ban, потім виконайте sudo fail2ban-client status sshd. В Ubuntu 24.04 для SSH зазвичай правильний backend — systemd, тому його вказано в локальному jail-файлі. Перегляньте журнали через sudo journalctl -u fail2ban -n 100. Переконайтеся, що в конфігурації вказано banaction = ufw, якщо UFW використовується як firewall.

Автоматичні оновлення ввімкнено, але сервер просить перезавантаження

Це нормальна ситуація після оновлення ядра, деяких бібліотек або systemd. Перевірте наявність файлу /var/run/reboot-required і вивід sudo needrestart -r l. Виберіть вікно обслуговування, попередьте користувачів і виконайте sudo reboot. Автоматичні security-оновлення зменшують вікно вразливості, але не можуть безпечно перезапустити всі застосунки без урахування вашого навантаження та залежностей.

Яка конфігурація VPS підійде мінімально?

Для самого hardening достатньо 1 vCPU, 1 ГБ RAM і 20 ГБ SSD, якщо сервер виконує роль bastion-host, простого VPN або невеликого бота. Для практичного універсального старту краще 2 vCPU, 2–4 ГБ RAM і 40–80 ГБ NVMe: залишиться місце для Docker, логів, оновлень і резервних дампів. Не розраховуйте диск лише під ОС: заздалегідь передбачте місце для даних, тимчасових файлів і локальних копій перед завантаженням у зовнішній backup.

Що обрати — VPS чи dedicated для цього завдання?

Для hardening, невеликого сайту, VPN, API та кількох контейнерів достатньо VPS. Він дешевший, швидше розгортається і простіше масштабується за пам’яттю або диском. Dedicated потрібен не через сам Ubuntu hardening, а за постійного значного навантаження: високого I/O бази, великого ігрового сервера, транскодування, CI або вимог до гарантованої продуктивності CPU. В обох випадках правила SSH, firewall, оновлення та бекапи залишаються обов’язком адміністратора.

Caddy не отримує TLS-сертифікат і видає помилку ACME

Перевірте, що A-запис домену вказує на публічний IPv4 VPS, а AAAA-запис або коректний, або відсутній. Порти 80 і 443 мають бути відкриті в UFW і зовнішньому firewall провайдера. Виконайте sudo journalctl -u caddy -n 100 --no-pager. Часто проблема в тому, що інший вебсервер уже зайняв порт 80 або домен вказує на стару IP-адресу. Після виправлення Caddy автоматично повторить спробу.

Як зрозуміти, що Docker випадково не відкрив базу або панель в інтернет?

Виконайте sudo ss -tulpn і перевірте адреси прив’язки. Небезпечні сервіси на 0.0.0.0:5432, 0.0.0.0:3306, 0.0.0.0:6379 і подібних портах. У Docker Compose публікуйте внутрішні сервіси як 127.0.0.1:5432:5432 або взагалі не використовуйте секцію ports, якщо контейнери взаємодіють через внутрішню мережу. Залиште назовні лише reverse proxy на 80/443 і SSH на вибраному порту.

Висновки та наступні кроки

Тепер новий VPS на Ubuntu 24.04 має базовий захист: оновлену систему, ключовий SSH-доступ, заборону root-входу, UFW, Fail2ban, налаштування sysctl, TLS для вебсервісу та зашифрований зовнішній бекап. Це помітно знижує ризик типових автоматизованих атак і помилок початкового налаштування.

Наступним кроком додайте моніторинг ресурсів і доступності, наприклад перевірку диска, пам’яті, терміну дії TLS-сертифікатів і стану backup-завдання. Потім налаштуйте окремі політики hardening для вашого застосунку: Docker, PostgreSQL, WireGuard, вебфреймворку або панелі керування.

Після кожного нового сервісу повторюйте короткий аудит: чи потрібен йому публічний порт, хто має доступ, де зберігаються секрети, як виконується оновлення і чи можна відновити дані з бекапа. Саме цей цикл перетворює одноразове налаштування VPS на інфраструктуру, яку можна підтримувати.