EN Обрати сервер

Безпека

Базовий захист Linux-сервера: SSH, мережевий екран, оновлення

Оновлено 10 хв читання Read in English

Зміст статті

Стаття для адміністратора, який отримав виділений сервер з Ubuntu LTS або Debian і хоче за годину закрити типові прогалини в захисті. У підсумку вхід буде лише за ключами SSH, ззовні лишаться відкритими тільки потрібні порти, а оновлення безпеки встановлюватимуться самі.

Що знадобиться#

  • Ubuntu 24.04 LTS чи 26.04 LTS або Debian 13 (команди перевірено в жовтні 2026 року).
  • Користувач із правами sudo і вхід за ключем. На наших серверах його створено під час установки й названо за дистрибутивом (debian, ubuntu), пароль надходить листом, а вхід root за паролем вимкнено. Публічний ключ, переданий у коментарі до заявки, додадуть йому одразу. Див. також статті про першу годину на Linux-сервері та про ключі SSH.
  • nmap на вашому комп’ютері. У прикладах 203.0.113.10 — навчальна адреса сервера, 198.51.100.7 — адреса, з якої ви підключаєтеся.

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

Крок 1 SSH: лише ключі, без root, тільки потрібні користувачі#

В Ubuntu і Debian файл /etc/ssh/sshd_config на початку підключає файли з каталогу /etc/ssh/sshd_config.d/, і для кожного параметра діє перше знайдене значення. Наші образи Linux налаштовує cloud-init, тож там може бути його файл (в Ubuntu — 50-cloud-init.conf) із параметром PasswordAuthentication; тому створіть файл, який читається раніше за нього (sudo nano /etc/ssh/sshd_config.d/00-hardening.conf), і замість admin впишіть ім’я, під яким входите (наприклад, debian):

PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no
AllowUsers admin

Перші два рядки вимикають вхід за паролем. Третій забороняє root входити через SSH і за ключем (за паролем це вимкнено ще під час установки). Четвертий впускає лише перелічених користувачів: кого там немає, той не ввійде навіть із ключем. Якщо адміністраторів кілька, зручніша група: sudo groupadd sshusers, sudo usermod -aG sshusers admin і AllowGroups sshusers замість AllowUsers. Не вказуйте обидва параметри разом: тоді користувач мусить пройти обидві перевірки.

Перевірте синтаксис і підсумкові значення й лише тоді застосуйте зміни:

sudo sshd -t
sudo sshd -T | grep -Ei '^(passwordauthentication|kbdinteractiveauthentication|permitrootlogin|allowusers) '
sudo systemctl reload ssh

Якщо sshd -T показує інше значення, його задано у файлі, що читається раніше за ваш. Тепер відкрийте нове вікно термінала на своєму комп’ютері й виконайте:

ssh admin@203.0.113.10
ssh -o PubkeyAuthentication=no -o PreferredAuthentications=password admin@203.0.113.10

Перша команда має впустити вас за ключем, друга — завершитися відмовою Permission denied (publickey).

Чи змінювати порт SSH#

Чесно: це не захист, бо сканери знаходять SSH на будь-якому порту, а нестандартний порт лише зменшує шум у журналах. Якщо змінюєте, то після кроків 1 і 2: відкрийте новий порт в екрані, додайте Port 2222 у свій файл, виконайте sudo sshd -t і перезапустіть службу: у Debian — sudo systemctl restart ssh, в Ubuntu 24.04 і 26.04 (порт слухає systemd) — sudo systemctl daemon-reload і sudo systemctl restart ssh.socket. Лише після входу з -p 2222 з нового вікна закрийте порт 22 і допишіть port = 2222 у розділ [sshd] налаштувань fail2ban (крок 3).

Крок 2 Мережевий екран: вхідне заборонено, крім потрібного#

Забороніть усі вхідні з’єднання, крім портів, які справді мають бути доступні з інтернету; вихідні дозвольте. В Ubuntu для цього є ufw, у Debian — nftables. Оберіть щось одне.

Не забороняйте ping (ICMP echo-request) повністю: дата-центр перевіряє доступність сервера пінгом, і без відповіді моніторинг вважатиме сервер недоступним. Правила мають діяти й для IPv6: сервер отримує блок адрес (зазвичай /64), а на свіжих образах Linux першу з них налаштовано ще під час установки. Обидва приклади це враховують: ufw типово пропускає ping і застосовує правила й до IPv6, а таблиця inet у nftables охоплює обидва протоколи.

Увага. Правило для SSH додайте до ввімкнення екрана, а перед увімкненням заплануйте автоматичний відкат: якщо щось піде не так, за п’ять-шість хвилин правила знімуться самі. Після перевірки з нового вікна відкат скасуйте.

Ubuntu: ufw#

Якщо ви змінили порт SSH, підставте його замість 22. Коли ufw попередить про можливий розрив з’єднань SSH, відповідайте y: правило для SSH уже є.

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp
sudo systemd-run --on-active=5m --unit=fw-rollback /usr/sbin/ufw disable
sudo ufw enable

Увійдіть на сервер із нового вікна термінала. Якщо вдалося, скасуйте відкат і перегляньте правила:

sudo systemctl stop fw-rollback.timer
sudo ufw status verbose

Інші порти відкривайте за потреби, наприклад sudo ufw allow 80,443/tcp для сайту.

Debian: nftables#

Встановіть пакет, якщо його немає (sudo apt install nftables), збережіть копію типового файлу (sudo cp /etc/nftables.conf /etc/nftables.conf.bak) і замініть вміст /etc/nftables.conf:

#!/usr/sbin/nft -f

flush ruleset

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

        ct state established,related accept
        ct state invalid drop
        iif "lo" accept
        meta l4proto { icmp, ipv6-icmp } accept
        tcp dport 22 accept
    }

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

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

Рядок з ICMP потрібен для моніторингу, діагностики і роботи IPv6. Для сайту додайте tcp dport { 80, 443 } accept. Перевірте файл, не застосовуючи його, заплануйте відкат і завантажте правила:

sudo nft -c -f /etc/nftables.conf
sudo systemd-run --on-active=5m --unit=fw-rollback /usr/sbin/nft flush ruleset
sudo nft -f /etc/nftables.conf

Увійдіть із нового вікна. Якщо вхід працює, скасуйте відкат і ввімкніть завантаження правил під час запуску системи:

sudo systemctl stop fw-rollback.timer
sudo systemctl enable nftables
sudo nft list ruleset

Крок 3 fail2ban для sshd#

Програма fail2ban читає журнал і тимчасово блокує адреси, з яких надходять невдалі спроби входу. Встановіть її: sudo apt install fail2ban nftables. У пакетах Ubuntu 24.04, 26.04 і Debian 13 набір правил (jail) sshd увімкнено одразу: він читає журнал systemd і блокує через nftables, тому потрібна утиліта nft, навіть якщо екраном керує ufw. Файли .conf із пакета не редагуйте, свої значення записуйте у /etc/fail2ban/jail.local:

[DEFAULT]
bantime = 1h
findtime = 10m
maxretry = 5
ignoreip = 127.0.0.1/8 ::1

[sshd]
enabled = true
backend = systemd

Після п’яти невдалих спроб за десять хвилин адресу буде заблоковано на годину. Рядок backend = systemd повторює типове значення цих пакетів; у Debian 12 він потрібен разом із пакетом python3-systemd.

sudo fail2ban-client -t
sudo systemctl restart fail2ban
sudo fail2ban-client status sshd

Розблокувати адресу вручну: sudo fail2ban-client set sshd unbanip 198.51.100.7.

Крок 4 Автоматичні оновлення безпеки#

Пакет unattended-upgrades сам встановлює оновлення безпеки. В Ubuntu він зазвичай уже ввімкнений; у Debian встановіть, увімкніть і перевірте його:

sudo apt install unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades
cat /etc/apt/apt.conf.d/20auto-upgrades
sudo unattended-upgrade --dry-run --debug

У файлі 20auto-upgrades обидва параметри APT::Periodic мають дорівнювати "1"; остання команда — пробний запуск без змін у системі. Свої налаштування записуйте не в пакетний файл 50unattended-upgrades, а в окремий файл поруч — 52unattended-upgrades-local. Оновлення ядра починають діяти лише після перезавантаження, а типово сервер сам не перезавантажується. Якщо нічний простій на кілька хвилин прийнятний, дозвольте перезавантаження у своєму файлі:

Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-Time "04:00";

Якщо ні, перезавантажуйте сервер вручну, коли з’являється файл /var/run/reboot-required.

Крок 5 Мінімум відкритих служб#

sudo ss -tulpn

Адреси 0.0.0.0, [::] або * у стовпці локальної адреси означають, що служба слухає на всіх інтерфейсах, зокрема на публічному; 127.0.0.1 і [::1] — що вона доступна лише із самого сервера. Бази даних і службові вебінтерфейси мають слухати лише на локальній адресі, навіть якщо порт закрито екраном. У PostgreSQL за це відповідає listen_addresses = 'localhost', у MariaDB і MySQL — bind-address = 127.0.0.1. Підключайтеся до них через тунель SSH (ssh -L 5432:127.0.0.1:5432 admin@203.0.113.10), WireGuard або приватну мережу. Непотрібну службу зупиніть і вимкніть: sudo systemctl disable --now example.service.

Крок 6 Журнали: хто входив і хто намагався#

sudo journalctl -u ssh --since today
sudo journalctl -u ssh --since "7 days ago" | grep Accepted
sudo journalctl -u ssh --since today | grep -Ei 'invalid|failed'
last -n 20

Журнал доступний усюди, а last (історія входів) є одразу лише в Ubuntu 24.04. У Debian 13 і Ubuntu 26.04 його повертає sudo apt install wtmpdb libpam-wtmpdb; lastb там немає, невдалі спроби показує третя команда.

Як перевірити результат#

  1. Вхід із нової сесії. Повторіть дві команди з кроку 1: за ключем сервер впускає, за паролем — ні.
  2. Сканування своїх портів ззовні. На своєму комп’ютері, а не на сервері, виконайте nmap -Pn -p- 203.0.113.10. У стані open мають бути лише порти, які ви відкрили свідомо. Так само перевірте адресу IPv6 (параметр -6), якщо ваше підключення її підтримує. А ping 203.0.113.10 має отримувати відповіді.
  3. Стан fail2ban. sudo fail2ban-client status sshd показує лічильники невдалих спроб і заблоковані адреси.

Якщо відрізали собі доступ#

  • Стара сесія ще відкрита — виправляйте з неї: sudo ufw disable або sudo nft flush ruleset; якщо причина в SSH, приберіть помилковий рядок і виконайте sudo systemctl reload ssh.
  • Ви запланували відкат — зачекайте п’ять-шість хвилин і ввійдіть знову.
  • Вас заблокував fail2ban — зачекайте годину або ввійдіть з іншої адреси й розблокуйте себе.
  • Ніщо не допомогло — зверніться до технічної підтримки United Cloud, вона працює 24/7: телефон +38 044 206 08 08, пошта info@united.net.ua. За запитом підтримка дасть віддалену консоль (посилання працює лише з адреси, яку ви вкажете) або завантажить сервер у режим відновлення — тимчасову систему Linux з доступом по SSH, де можна змонтувати диск і виправити налаштування. На Лайт консолі може не бути, тож там відкат за таймером особливо важливий.

Типові помилки#

  • Docker і ufw. Порти, які публікує контейнер, обходять правила ufw. Внутрішні служби публікуйте лише на локальній адресі: -p 127.0.0.1:5432:5432.
  • Перезавантажили nftables.conf і втратили блокування. flush ruleset стирає всі таблиці, зокрема fail2ban і Docker; після зміни правил виконайте sudo systemctl restart fail2ban.

Що далі#

  • Захист від DDoS мережевого рівня входить у кожен сервер, але від атак рівня застосунку не захищає. Під час атаки сам вмикається фільтр на межі мережі — прості правила за адресами й портами без урахування стану з’єднань; на більшості лінійок його можна ввімкнути й через підтримку (на Лайт він може бути недоступний). Екрана на сервері він не замінює.
  • Резервні копії: правило 3-2-1 і restic для Linux.