Що робити після першого входу на новий VPS

Якщо ви орендували звичайний VPS-сервер, а не Керований VPS, про який ми поговоримо іншим разом, то найчастіше він надається власнику з досить скромним набором вихідних даних, таких як IP-адреса, логін і пароль. На цей момент, з технічної точки зору, сервер уже працює. Але за своєю суттю це поки що не можна назвати повноцінним сервером, оскільки зараз це, скоріше, заготовка для справжнього сервера.

Дуже часто адміністратори-початківці, одразу після отримання сервера, починають встановлювати на нього Nginx, Docker, панель управління або одразу ж кидаються переносити свій сайт. Але набагато важливіше буде витратити перші півгодини на базове налаштування свого нового VPS, адже якщо ви виконаєте всього кілька простих дій у правильному порядку, це помітно знизить ймовірність злому сервера, втрати доступу до нього та неприємних сюрпризів після запуску вашого проєкту.

Тому в цій статті ми з вами крок за кроком налаштуємо новий, абсолютно чистий віртуальний сервер з нуля - від першого входу в систему до робочого стану. Усе, що описано нижче, підійде для більшості VPS із Ubuntu, Debian, AlmaLinux або Rocky Linux.

 

 

 

 

Рекогносцировка

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

cat /etc/os-release
hostnamectl
free -h
df -h
ss -tulpn

 

Остання команда особливо корисна, оскільки новий VPS не обов’язково може бути абсолютно порожнім, адже образ провайдера може містити SSH, cloud-init, агент віртуалізації або додаткове ПЗ. Якщо якийсь сервіс уже доступний із мережі, то краще дізнатися про це зараз.

 

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

timedatectl

 

 

 

 

 

Перевірте мережу та DNS

Наступним кроком варто переконатися, що VPS отримав очікувану IP-адресу, надану провайдером. Одразу можна перевірити й маршрут до Інтернету, а також робочі DNS-сервери.

ip addr
ip route
ping
getent hosts
​

 

Команда ip addr покаже ваші мережеві пристрої з присвоєними їм IP-адресами. У ip route має бути присутній маршрут за замовчуванням через шлюз провайдера. За допомогою команди ping ви можете перевірити доступ до мережі, наприклад, перевіривши пінг на якийсь віддалений сервер в Інтернеті. А ось роботу DNS найпростіше перевірити таким запитом:

getent hosts example.com

 

 

 

 

Оновіть систему

Навіть встановлення свіжого образу Linux зовсім не означає, що всі встановлені в ньому пакети будуть актуальними, оскільки між створенням шаблону та запуском вашого VPS міг минути певний час, протягом якого могли з’явитися нові виправлення безпеки. Тому під час першого запуску сервера одразу варто оновити систему до актуального стану.

Для Ubuntu та Debian:

apt update && apt upgrade -y

Для AlmaLinux та Rocky Linux:

dnf upgrade -y

 

У Ubuntu та Debian можна перевірити, чи потрібне перезавантаження після оновлення, за допомогою команди:

test -f /var/run/reboot-required && cat /var/run/reboot-required

 

Якщо оновилося ядро або інші важливі компоненти, то сервер краще перезавантажити одразу, а після перезавантаження переконайтеся, що ваш VPS знову підключився до мережі

Пізніше буде корисно налаштувати автоматичну інсталяцію оновлень безпеки. У Debian та Ubuntu для цього використовується unattended-upgrades, а в RHEL-сумісних системах - інструмент dnf-automatic. Водночас повне оновлення системи краще залишати під контролем, виконуючи його вручну.

 

 

 

 

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

Звісно, постійно працювати під root дуже зручно, адже система ніколи не видає повідомлення Permission denied. У цьому ж і полягає велике зло, оскільки будь-яка помилкова команда виконується з максимальними повноваженнями й може призвести до непоправних наслідків, аж до повного видалення системи та даних з диска.

 

Для створення окремого користувача в Ubuntu або Debian використовуються команди:

adduser adminuser
usermod -aG sudo adminuser

У AlmaLinux та Rocky Linux:

useradd -m adminuser
passwd adminuser
usermod -aG wheel adminuser

 

Перевірити групи конкретного користувача можна за допомогою команди:

id adminuser

 

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

 

 

 

 

Налаштуйте SSH, але будьте обережні, щоб не втратити доступ до сервера

Пароль root, особливо отриманий від провайдера, ніколи не варто залишати основним способом входу на сервер. Для постійної роботи зручніше та безпечніше використовувати SSH-ключі.

Для цього на своєму комп’ютері, з якого ви будете підключатися до сервера в майбутньому, створіть пару RSA-ключів за допомогою команди:

ssh-keygen -t rsa -b 4096

 

За замовчуванням будуть створені два файли:

~/.ssh/id_rsa
~/.ssh/id_rsa.pub

id_rsa - приватний ключ, він залишається на вашому комп’ютері. На сервер потрібно перенести лише публічний id_rsa.pub:

ssh-copy-id -i ~/.ssh/id_rsa.pub adminuser@SERVER_IP

 

Якщо ssh-copy-id недоступний, тоді виведіть публічний ключ у консоль:

cat ~/.ssh/id_rsa.pub

 

Скопіюйте отриманий рядок і додайте його на сервері до файлу ~/.ssh/authorized_keys. Якщо каталогу та файлу ще немає, виконайте такі команди:

mkdir -p ~/.ssh
chmod 700 ~/.ssh
nano ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

 

Тепер відкрийте другий термінал і перевірте вхід саме за допомогою створеного RSA-ключа:

ssh -i ~/.ssh/id_rsa adminuser@SERVER_IP

Після входу перевірте роботу sudo:

sudo whoami

 

Команда має повернути root. Лише після перевірки входу за ключем можна вимкнути прямий SSH-вхід для root та парольну авторизацію. Для цього у файлі /etc/ssh/sshd_config або у файлах /etc/ssh/sshd_config.d/*.conf знайдіть і встановіть такі параметри:

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes

 

Перед застосуванням змін обов’язково перевірте конфігурацію командою:

sshd -t

 

Діючі налаштування SSH можна переглянути за допомогою команди:

sshd -T

 

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

Ось чому набагато корисніше налаштувати вхід за ключем і відключити парольну авторизацію, що ми зараз і зробили.

 

 

 

 

Закрийте непотрібні порти

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

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

Тому брандмауер нового сервера найпростіше будувати за принципом: заборонено все, що явно не дозволено.

 

Для Ubuntu та Debian зручно використовувати UFW (Uncomplicated Firewall), який уже вбудований у систему. Спочатку дозвольте SSH, щоб не втратити зв’язок із сервером, і лише потім увімкніть брандмауер:

ufw allow OpenSSH
ufw allow 80/tcp
ufw allow 443/tcp
ufw enable
ufw status verbose

Якщо веб-сервер поки що не встановлено, порти 80 і 443 можна відкрити пізніше.

 

У AlmaLinux і Rocky Linux зазвичай використовується firewalld:

firewall-cmd --permanent --add-service=ssh
firewall-cmd --permanent --add-service=http
firewall-cmd --permanent --add-service=https
firewall-cmd --reload
firewall-cmd --list-all

 

Після налаштування знову перевірте, які служби приймають з’єднання з мережі:

ss -tulpn

Брандмауер і ця команда показують різні сторони однієї картини. Брандмауер визначає, який трафік дозволено, а ss показує, які програми взагалі приймають з’єднання.

 

Для звичайного веб-сервера ситуація найчастіше виглядає приблизно так:

Сервіс Доступ з Інтернету
 

Якщо база даних потрібна лише додатку на цьому ж VPS, то очевидно, що відкривати її всьому Інтернету немає сенсу.

Не забувайте також і про IPv6 (якщо він взагалі присутній у послузі), тому якщо сервіс слухає адресу [::], то переконайтеся, що правила брандмауера захищають IPv6 так само, як і IPv4.

 

Перевірте сервер ззовні

Локальна перевірка - це, звичайно, добре, але краще ззовні перевірити, які порти дійсно доступні з Інтернету на вашому сервері. Для цього з іншого комп’ютера можна виконати команду:

nmap SERVER_IP

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

 

Сервіс	Доступ з інтернету
SSH 22	Так
HTTP 80	Так
HTTPS 443	Так
MySQL 3306	Зазвичай ні
PostgreSQL 5432	Зазвичай ні
Redis 6379	Ні
Docker API 2375	Ні

 

 

Чи потрібен Fail2ban?

Навіть після відключення входу за паролем SSH залишається доступним з Інтернету, а отже, у логах досить швидко з’являться автоматичні спроби підключення. Зменшити цей потік можна за допомогою утиліти Fail2ban.

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

 

В Ubuntu та Debian встановити Fail2ban можна командою:

apt install fail2ban -y

В AlmaLinux та Rocky Linux пакет доступний через EPEL:

dnf install epel-release -y
dnf install fail2ban -y

 

Після встановлення запустіть службу та додайте її до автозавантаження:

systemctl enable --now fail2ban

 

Тепер перевірте, які jail активні:

fail2ban-client status

Якщо серед них є sshd, перегляньте його стан окремо:

fail2ban-client status sshd

 

Там будуть видні невдалі спроби входу та заблоковані IP-адреси. Важливо, що просто встановити Fail2ban недостатньо, оскільки певний jail для SSH має бути увімкнений і дійсно працювати. Детальніше про налаштування Fail2ban читайте в цій статті.

 

 

 

Перевірте пам'ять, swap і диск

На невеликих VPS із мінімальним обсягом оперативної пам'яті часто рекомендується відразу створити файл підкачки або swap. І іноді це досить розумно, оскільки під час короткочасного стрибка споживання пам'яті він може надати системі додатковий запас замість негайного запуску OOM-killer.

Але, все ж таки, створювати swap за замовчуванням теж не варто, і для початку потрібно оцінити поточний стан справ з оперативною пам’яттю та диском, а також їх використання за допомогою команд:

free -h
swapon --show
df -h
df -i

 

Орієнтуватися можна так:

Ситуація	Що робити
Swap відсутній, мало RAM	Розглянути створення swap
Swap є, але майже не використовується	Це нормально
Swap постійно активно використовується	Перевірити використання RAM
OOM-killer завершує процеси	Знайти причину або збільшити обсяг RAM

Варто пам’ятати, що swap не є повноцінною заміною оперативної пам’яті, а є лише певною страховкою на випадок пікових навантажень.

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

 

 

 

 

Перевірте помилки після завантаження

Отже, ви виконали початкові налаштування та перезавантажили сервер. І ось ваш сервер відповідає через SSH - це вже добре, але це ще не означає, що система завантажилася без помилок. Адже якась служба могла не запуститися, а гіпотетична проблема з диском або мережею поки що просто не встигла проявитися.

Для швидкої перевірки достатньо двох команд:

systemctl --failed
journalctl -p err -b

Перша покаже служби, які завершилися з помилкою. Друга виведе повідомлення рівня error та вище лише для поточного завантаження системи.

 

Не варто лякатися кожного рядка в journalctl, оскільки в журналах Linux часто трапляються помилки, які жодним чином не заважають роботі сервера. Вам насамперед слід звертати увагу на служби, що зупинилися, повторювані повідомлення та помилки, пов’язані з мережею, дисками або файловими системами.

 

 

 

 

Налаштуйте моніторинг до першої аварії

Поки ваш VPS працює нормально, ви можете навіть не замислюватися про необхідність моніторингу. Але у разі, якщо сервер раптово зависне, вам просто необхідно буде знати, що відбувалося з процесором, пам’яттю та диском за кілька хвилин до збою.

На робочому сервері варто стежити хоча б за завантаженням CPU, використанням RAM, вільним місцем на диску та доступністю самого VPS. Звичайно, для поточної діагностики під рукою вже є стандартні інструменти Linux, такі як:

systemctl
journalctl
top

Але вони допоможуть вам лише тоді, коли ви вже зайшли на сервер і почали шукати проблему.

Тому для робочого VPS краще заздалегідь налаштувати зовнішній моніторинг із сповіщеннями. Він повідомить, коли сервер завис або потрібний сервіс перестав відповідати, а системні журнали допоможуть з’ясувати, що сталося перед цим. Про один із численних інструментів моніторингу, а саме про систему Netdata, ми писали в цій статті.

 

 

 

 

 

 

Налаштуйте резервне копіювання

Рано чи пізно на вашому сервері з’являться дані, втрата яких обійдеться набагато дорожче, ніж сам VPS. Тому резервне копіювання краще налаштувати ще до перенесення сайту або запуску робочого додатка.

Що саме зберігати, залежить від конкретного проєкту та стеку. Для звичайного сайту, як правило, це файли та база даних, для інфраструктур Docker - томи (volumes) та конфігурація контейнерів. Іноді навіть доцільно створювати резервну копію всієї віртуальної машини. До речі, 3v-Hosting робить це для вас абсолютно безкоштовно, щодня зберігаючи миттєвий знімок вашого віртуального сервера, з якого можна відновити сервер у разі збою або втрати даних.

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

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

 

 

 

 

Здійсніть контрольне перезавантаження та приступайте до роботи

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

reboot

 

Після завантаження знову підключіться через SSH і швидко перевірте стан VPS:

uptime
systemctl --failed
ss -tulpn

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

Якщо ж ви не змогли підключитися до свого сервера після перезавантаження, тоді ви можете увійти на нього через консоль noVNC у особистому кабінеті 3v-Hosting і вже звідти проаналізувати ситуацію та виправити те, що вийшло з ладу.

 

Після такої перевірки VPS вже можна використовувати за призначенням, наприклад, встановлювати веб-сервер, Docker, CMS, VPN або інше необхідне вам ПЗ.

Однак ніколи не встановлюйте програми «про всяк випадок», оскільки кожен зайвий демон може відкрити новий порт, вимагати оновлень і додати ще одну конфігурацію, за якою доведеться стежити.

 

 

 

 

Чек-лист після першого входу

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

У підсумку весь процес можна звести до короткого чек-листа:

1. Перевірити ОС, ресурси, час, мережу та відкриті порти;
2. Встановити оновлення;
3. Створити окремого користувача з sudo;
4. Налаштувати SSH-ключі та перевірити вхід у другій сесії;
5. Обмежити root-доступ та парольну авторизацію;
6. Налаштувати брандмауер і перевірити порти ззовні;
7. За необхідності встановити Fail2ban;
8. Перевірити RAM, swap, диск та inode;
9. Перевірити failed services та системний журнал;
10. Налаштувати моніторинг та сповіщення;
11. Організувати зовнішні резервні копії;
12. Перезавантажити VPS та переконатися, що все працює;
13. Лише після цього встановлювати робочі сервіси.

 

 

 

 

Поширені запитання щодо початкового налаштування VPS

 

Чи потрібно змінювати SSH-порт 22?

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

 

Чи потрібно відключати вхід root через SSH?

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

 

Чи потрібен Fail2ban, якщо вхід за паролем вимкнено?

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

 

Скільки swap потрібно VPS?

Універсальної формули тут немає й бути не може, оскільки його розмір залежить від обсягу RAM та навантаження на сервер. Важливішим є не конкретне співвідношення оперативної пам'яті та swap, а те, як сервер реально використовує пам'ять.

 

Які порти потрібно відкрити на новому VPS?

Тільки ті, що необхідні конкретному серверу. Для типового веб-сервера це SSH, HTTP та HTTPS. Порти баз даних, Redis, внутрішніх API та інших службових компонентів без необхідності краще не відкривати назовні.

 

Чи потрібно перезавантажувати VPS після оновлення?

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

 

Чи можна спочатку встановити Docker або панель, а безпеку налаштувати потім?

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