Налаштування нового VPS за перші 10 хвилин

Перші 10 хвилин визначають безпеку сервера

Новий VPS не є безпечним. Щойно він отримує публічну IP-адресу, сканери починають спроби входу. Стандартний образ робить сервер легкою ціллю: root часто доступний, вхід за паролем часто дозволений, firewall відсутній, а оновлення не встановлюються за розкладом. Добра новина полягає в тому, що на закриття всіх цих проблем потрібно близько десяти хвилин і кілька команд. Це runbook, який я виконую на кожному новому сервері, перш ніж розміщувати на ньому будь-які сервіси.

Виконуйте кроки по порядку, оскільки вони залежать один від одного. Для кожного кроку є окремий посібник, на який веде відповідне посилання. Ця сторінка містить швидкий порядок дій і об’єднує всі кроки.

Хвилина 1: оновіть усе

Увійдіть як root, використовуючи облікові дані, надані вашим провайдером, і спочатку повністю оновіть систему:

apt update && apt upgrade -y

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

Хвилина 2: Створіть звичайного користувача з sudo

Не продовжуйте працювати як root. Створіть для себе користувача та надайте йому sudo:

adduser matt
usermod -aG sudo matt

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

Хвилина 4: Налаштуйте SSH-ключі

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

ssh-keygen -t ed25519

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

ssh-copy-id matt@YOUR_SERVER

Для ssh-copy-id має бути ввімкнений вхід за паролем для нового користувача. Якщо його вже вимкнено, скопіюйте ~/.ssh/authorized_keys користувача root у /home/matt/.ssh/authorized_keys, який належить matt, або вручну вставте свій відкритий ключ у цей файл.

Модель, що лежить в основі цього кроку, — один ключ на пристрій, права доступу, через які вхід за ключем не працює, і відкликання втраченого ключа — описана в розділі Основи керування SSH-ключами.

Вийдіть із системи та знову увійдіть як matt за допомогою ключа. Переконайтеся, що вхід працює, перш ніж переходити до наступного кроку. Якщо обмежити SSH до того, як ви зможете ввійти за ключем, можна заблокувати собі доступ. Якщо під час входу з’являється Permission denied (publickey), виправте проблему зараз, а не повертайтеся до входу за паролем. Це повідомлення охоплює п’ять різних помилок, а вивід ssh -v показує, яка саме з них виникла у вас.

Хвилина 6: Вимкніть вхід root і автентифікацію за паролем

Тепер, коли ваш ключ працює, закрийте два способи доступу, на які розраховують сканери. Використайте drop-in-файл, щоб оновлення пакетів не перезаписали його. Назвіть його 00-, щоб він сортувався перед 50-cloud-init.conf, який постачається з хмарними образами Ubuntu разом із PasswordAuthentication yes; sshd зберігає перше прочитане значення, тому файл із пізнішим порядком сортування непомітно втратить чинність:

sudo nano /etc/ssh/sshd_config.d/00-hardening.conf

PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no

Потім перезавантажте SSH:

sudo systemctl restart ssh

Потім перевірте фактичні налаштування, які використовує sshd, щоб конфліктний drop-in-файл не ввів вас в оману:

sudo sshd -T | grep -Ei 'passwordauthentication|permitrootlogin'

Коли автентифікацію за паролем вимкнено, а вхід root заборонено, постійний brute-force-трафік до вашого сервера не може завершитися успішно. Повний опис, зокрема необов’язкову зміну порту, наведено в розділі Посилення захисту SSH на VPS.

Хвилина 8: Увімкніть firewall

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

sudo ufw default deny incoming
sudo ufw allow 22/tcp
sudo ufw enable

Додайте правила allow для кожного сервісу, який ви справді використовуєте, наприклад 80/tcp і 443/tcp для вебсайту. Якщо після цього нова SSH-сесія перестала підключатися, прочитайте помилку, перш ніж щось змінювати, оскільки відмова означає, що sshd відповів, а тайм-аут зазвичай означає, що firewall заблокував пакет. Переконайтеся, що правила охоплюють IPv4 та IPv6, оскільки firewall, який фільтрує лише IPv4, залишає частину IPv6 повністю відкритою. Повний посібник наведено в розділі Firewalls 101 на VPS. Ці команди ufw розраховані на Ubuntu або Debian; на сервері Rocky чи AlmaLinux мета — така сама заборона за замовчуванням, але використовується firewalld, тому виконайте версію цього кроку для firewalld.

Хвилина 10: Сповільніть сканери за допомогою Fail2ban

Насамкінець додайте Fail2ban, щоб блокувати адреси, які безперервно надсилають запити на ваші порти:

sudo apt install -y fail2ban

В Ubuntu 24.04 стандартне встановлення захищає SSH із першого запуску. Якщо вхід за ключами вже обов’язковий, Fail2ban є додатковим захистом: він зменшує кількість зайвих записів у журналі та блокує повторних порушників, але не замінює основний захист.

Ваш чекліст

Це runbook. Скористайтеся наведеним нижче генератором, щоб позначити кожен контроль і створити персоналізований чекліст, який можна зберігати разом із сервером, включно з точною командою для кожного кроку:

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

Після налаштування основних компонентів автоматичні оновлення безпеки в Ubuntu підтримують сервер в актуальному стані без повторного входу в систему. Кожен сервіс, який ви додасте, потрібно перевірити окремо, а потенційні слабкі місця змінюються: self-hosted password vault не зберігає на сервері дані у відкритому вигляді, тому реальні ризики Vaultwarden пов’язані з admin token і backup file.

FAQ

Що слід зробити спочатку на новому VPS?

Оновіть систему за допомогою apt update && apt upgrade -y, потім створіть звичайного користувача з sudo і припиніть працювати під root. Далі налаштуйте ключі SSH, вимкніть вхід під root і автентифікацію за паролем, увімкніть брандмауер із політикою заборони за замовчуванням та встановіть Fail2ban. Такий порядок дає змогу безпечно виконати кожен крок і не втратити доступ до сервера.

Як не втратити доступ під час посилення захисту SSH?

Налаштуйте та перевірте вхід до SSH за ключем, перш ніж вимикати автентифікацію за паролем або вхід під root. Вийдіть із системи та знову увійдіть за допомогою ключа, щоб переконатися, що все працює. Лише після цього вимкніть PasswordAuthentication і PermitRootLogin. Коли вмикаєте брандмауер, дозвольте порт 22 перед запуском ufw enable. Якщо доступ усе ж буде втрачено, вебконсоль вашого провайдера дасть змогу знову увійти без SSH.

Чи справді все це потрібно на невеликому сервері?

Так, оскільки сканери не зважають на розмір сервера. Вони однаково перевіряють кожну публічну IP-адресу. Увесь план налаштування займає приблизно десять хвилин і усуває найпростіші способи атаки: вхід під root заборонено, підбір паролів неможливий, не відкрито нічого зайвого, а відомі вразливості виправляються автоматично.

Який крок є найважливішим?

Вхід до SSH лише за ключем із вимкненим входом під root. Більшість атак на новий VPS — це автоматизований підбір паролів для root. Вимкнення обох способів повністю усуває цю категорію атак. Брандмауер і Fail2ban додатково обмежують доступні сервіси та сповільнюють атаки, які залишилися.

Як переконатися, що сервер справді захищений?

Перед тим як довіряти налаштуванням, вручну перевірте три речі. Виконайте sudo ss -tlnp і переконайтеся, що на публічній адресі прослуховуються лише потрібні порти, а також немає забутого сервісу 0.0.0.0 або [::]. Виконайте sudo ufw status verbose і перевірте, що політика вхідних підключень за замовчуванням має значення deny, а також присутні правила для звичайного протоколу та (v6). Перед закриттям першого SSH-сеансу завжди відкривайте другий. Так помилка в конфігурації SSH не заблокує вам доступ до сервера. Якщо всі три перевірки пройдено успішно, базові налаштування виконано.