Базова безпека сервера - чеклист за один вечір

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

Цей чеклист робить близько 90% базового хардингу: прибрати очевидні діри, якими користується автоматика. Це фінальний пост серії «Захист сервера»: у попередніх ми вже навчили сервер самостійно банити брутфорс - fail2ban і CrowdSec. Тепер зберемо решту навколо них в одну цілісну картину.

Що потрібно зробити?

#

Пройти шість пунктів - по порядку, зверху вниз:

1. Завести окремого користувача з sudo і перестати працювати під root.
2. Перевести SSH на вхід тільки по ключах, вимкнути паролі.
3. Перевірити й дотягнути криптографію SSH через ssh-audit.
4. Підняти файрвол ufw і закрити все вхідне, крім потрібного.
5. Увімкнути автоматичні оновлення безпеки.
6. Поставити автоматичний бан брутфорсу - це вже зроблено в попередніх постах серії.

З чим працюю?

#

Свіжий сервер на Debian 13 (trixie) з OpenSSH 10.0p2. У прикладах це просто «сервер» (можеш уявляти srv-01), користувач - ops. Команди так само лягають на Ubuntu, шляхи й пакети ті самі.

1. Окремий користувач замість root

#

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

1
2

adduser ops
usermod -aG sudo ops

Тепер треба покласти свій SSH-ключ цьому користувачеві. Найпростіше - з ноутбука, одною командою:

1

ssh-copy-id ops@сервер

Вона сама створить /home/ops/.ssh/authorized_keys з правильними правами й допише туди твій публічний ключ. Після цього заходимо на сервер уже як ops, а root лишаємо виключно для адмінських дій через sudo. Переконайся, що вхід під ops працює й sudo питає твій пароль, - перш ніж рухатись далі.

2. SSH тільки по ключах, пароль - геть

#

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

Головне правило - не чіпати головний sshd_config. Усі свої налаштування кладемо в окремий файл-перевизначення /etc/ssh/sshd_config.d/99-hardening.conf. Він читається поверх основного конфіга, переживає оновлення пакета й легко вимикається, якщо щось піде не так:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

PermitRootLogin prohibit-password
PasswordAuthentication no
KbdInteractiveAuthentication no
X11Forwarding no
MaxAuthTries 3

# Тільки сучасні алгоритми
KexAlgorithms sntrup761x25519-sha512@openssh.com,curve25519-sha256,curve25519-sha256@libssh.org,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com

Що означає кожен рядок:

• PermitRootLogin prohibit-password - root може зайти лише по ключу, паролем - ніколи.
• PasswordAuthentication no - жодних паролів взагалі, тільки ключі.
• KbdInteractiveAuthentication no - прибираємо ще один обхідний шлях, яким теж можна тягнути паролі.
• X11Forwarding no - проброс графіки на сервері не потрібен, менше поверхні атаки.
• MaxAuthTries 3 - менше спроб автентифікації за одне підключення.

Другий блок - це явний список сучасних алгоритмів обміну ключами, шифрів і MAC. Навіщо він і звідки взявся - розберемо в наступному пункті про ssh-audit.

⚠️ Перш ніж перезапускати sshd - не замкни себе зовні. Переконайся, що твій ключ уже працює, і тримай відкриту другу сесію до сервера. Якщо конфіг виявиться з помилкою, а єдина сесія закриється, ти більше не зайдеш.

Застосовуємо так: спочатку перевірка синтаксису, і тільки якщо вона мовчить - перезапуск:

1
2

sshd -t
systemctl restart ssh

3. Криптографію перевіряємо ssh-audit

#

Строгі KexAlgorithms/Ciphers/MACs з попереднього пункту додані не навмання. На стоковому Debian 13 SSH із коробки приймає й частину старих, уже слабких алгоритмів. Перевіримо це інструментом ssh-audit:

1
2

apt install ssh-audit
ssh-audit <сервер>

(Якщо пакета немає в репозиторії - його можна поставити через pipx install ssh-audit.)

На незайманому Debian 13 звіт лається на кілька старих MAC:

• hmac-sha1 і hmac-sha1-etm - позначені як [fail]: SHA-1 давно зламаний.
• umac-64 - [warn]: замалий 64-бітний тег.
• ряд старих алгоритмів у режимі encrypt-and-MAC - теж [warn].

Саме тому в 99-hardening.conf ми й виписали явний строгий список - він викидає все це й лишає тільки сучасне. Після перезапуску sshd запускаємо ssh-audit ще раз - і він показує 0 помилок і 0 попереджень: жодного слабкого алгоритму не лишилось.

4. Файрвол ufw

#

За замовчуванням сервер може слухати більше портів, ніж ти думаєш. Правильний підхід - закрити все вхідне й відкривати точково тільки те, що реально потрібно. На Debian для цього є зручна обгортка над nftables - ufw:

1
2
3
4
5

apt install ufw
ufw default deny incoming
ufw default allow outgoing
ufw allow OpenSSH
ufw enable

Перший рядок - заборонити весь вхідний трафік, другий - дозволити вихідний, третій - відкрити SSH (профіль OpenSSH - це порт 22/tcp). Тільки після цього вмикаємо файрвол. Перевіряємо:

1

ufw status verbose

У відповіді має бути Status: active, дефолти deny (incoming) / allow (outgoing) і єдине дозволене правило - 22/tcp (OpenSSH). Далі, коли ставитимеш веб-сервіс, відкриватимеш під нього конкретні порти так само точково (ufw allow 80/tcp, ufw allow 443/tcp), а не навстіж.

5. Автоматичні оновлення безпеки

#

Найчастіше ламають не хитрими 0-day, а через діру, до якої вже місяць як є латка, - просто її не поставили. Хай критичні оновлення безпеки ставляться самі, без «колись потім»:

1
2

apt install unattended-upgrades
dpkg-reconfigure -plow unattended-upgrades

Те саме можна зробити й файлом /etc/apt/apt.conf.d/20auto-upgrades:

1
2

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

Перевіряємо, що сервіс увімкнений:

1

systemctl is-enabled unattended-upgrades

Відповідь enabled - означає, що сервер тепер сам підтягує й ставить латки безпеки.

6. Автоматичний бан брутфорсу

#

Цей пункт ми вже закрили в попередніх постах серії, тож тут лише нагадую. Хоч би як ти прикрутив SSH, боти все одно гатитимуть по порту 22 - нехай за це отримують бан:

• fail2ban - класичний сторож: читає логи, рахує невдалі входи й банить набридливий IP через nftables.
• CrowdSec - те саме плюс поведінкові сценарії й колективна база репутації: сервер блокує IP, які атакували інших, ще до першого стуку.

Досить одного з них - і шостий пункт чеклиста закрито.

Перевірка

#

Чеклист без перевірки - це віра, а не факт. Переконаймося, що все справді застосувалось.

SSH читає наш конфіг (значення збігаються з тим, що ми прописали):

1

sshd -T | grep -E 'permitrootlogin|passwordauthentication|kbdinteractive|x11forwarding|maxauthtries'

1
2
3
4
5

permitrootlogin without-password
passwordauthentication no
kbdinteractiveauthentication no
x11forwarding no
maxauthtries 3

Криптографія чиста - ssh-audit <сервер> дає 0 [fail] і 0 [warn].

І головне наочне - спроба зайти паролем розбивається одразу:

1

Permission denied (publickey).

Сервер навіть не питає пароль: лишився тільки вхід по ключу.

Куди далі

#

На цьому серію «Захист сервера» завершено. Маємо свіжий сервер, де: працюємо не під root, SSH пускає лише по ключах і тільки на сучасній криптографії, вхідний трафік закритий файрволом, латки безпеки ставляться самі, а брутфорс ловить автоматичний бан. Це той самий базовий рубіж, який варто пройти на кожному новому сервері, перш ніж вішати на нього щось корисне.

Далі - уже за смаком і задачею: рознести сервіси по контейнерах, винести веб за reverse-proxy з TLS, додати двофакторку на сам SSH, подумати про бекапи й моніторинг. Глибший хардинг (аудит системних сервісів, обмеження прав, профілі AppArmor) - тема окремої розмови, до якої ще повернемось. Але двері вже зачинені, і зачинені вчасно.