Налаштування нового 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-, щоб він сортувався перед усіма іншими файлами в цьому каталозі. Хмарні образи Ubuntu постачаються з 60-cloudimg-settings.conf і PasswordAuthentication no, але якщо ваш провайдер задає ssh_pwauth у cloud-init, cloud-init записує 50-cloud-init.conf. Цей файл навмисно сортується перед файлом образу й може знову ввімкнути автентифікацію за паролем. sshd використовує перше прочитане значення, тому файл, який сортується пізніше, буде непомітно проігноровано:

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

PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no

Потім перезавантажте конфігурацію SSH:

sudo systemctl restart ssh

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

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 і автентифікацію за паролем, увімкніть firewall із політикою заборони за замовчуванням та встановіть Fail2ban. Такий порядок дає змогу безпечно виконати кожен крок і не втратити доступ до сервера.

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

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

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

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

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

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

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

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