Як захистити VPS: базові налаштування безпеки сервера після запуску

Автор Редактор Останнє поновлення Сер 21, 2026

Налаштування безпеки VPS через термінал після запуску сервера

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

Зміст

Однієї універсальної команди, яка повністю вирішує питання безпеки VPS, не існує. Важливий не лише набір дій, а й їхня послідовність: спочатку потрібно підготувати запасний спосіб входу та перевірити SSH-ключ, потім обмежувати автентифікацію й увімкнути мережевий фільтр. Інакше навіть правильна на вигляд зміна може заблокувати легітимного адміністратора.

Наведені нижче приклади орієнтовані переважно на Linux-сервери Ubuntu або Debian. Для AlmaLinux, Rocky Linux і Red Hat Enterprise Linux окремо вказані основні відмінності. Перед виконанням команд слід звірити назви служб, розташування конфігураційних файлів і правила хостинг-провайдера з документацією конкретної операційної системи.

Як захистити VPS одразу після запуску: короткий порядок дій

Практичний базовий порядок виглядає так:

Переконатися, що в панелі провайдера доступні вебконсоль, режим відновлення або інший аварійний спосіб входу.
Оновити операційну систему та встановлені пакети.
Створити окремого користувача з правом виконувати адміністративні команди через sudo.
Згенерувати SSH-ключ на локальному пристрої, додати публічний ключ на сервер і перевірити вхід у новому сеансі.
Заборонити віддалений вхід root і, коли ключ уже перевірено, вимкнути парольну автентифікацію SSH.
Переглянути всі служби та порти, які слухають мережеві інтерфейси.
Налаштувати firewall у панелі провайдера й у самій операційній системі, залишивши відкритими лише потрібні порти.
Увімкнути автоматичне отримання виправлень безпеки або встановити чіткий графік оновлень.
Організувати окремі резервні копії та перевірити відновлення.
Налаштувати моніторинг доступності, ресурсів, входів, помилок служб і результатів резервного копіювання.

Цей список є базовою лінією захисту, а не кінцевою конфігурацією. Вебсервер, поштовий вузол, VPN, база даних, контейнерна платформа та сервер із персональними даними потребують додаткових правил відповідно до своєї ролі.

Спочатку підготуйте аварійний доступ

Перед зміною SSH або firewall потрібно перевірити, чи надає хостинг-провайдер консоль у браузері, VNC-консоль, rescue mode або можливість підключити диск VPS до іншої віртуальної машини. Це дає шанс виправити конфігурацію, якщо мережевий вхід перестане працювати.

Корисно також зберегти поточні конфігураційні файли перед редагуванням і зафіксувати параметри підключення: IP-адресу, ім’я користувача, активний SSH-порт та розташування приватного ключа. Знімок диска перед великими змінами може спростити відновлення, але він не замінює регулярної резервної копії.

Головне правило: після зміни доступу не закривайте поточний SSH-сеанс. Відкрийте друге вікно термінала, виконайте нове підключення та перевірте, що можете застосувати sudo. Лише після успішного тесту завершуйте старий сеанс.

Оновіть операційну систему та перевірте строк підтримки

Вразливість у мережевій службі не компенсується складним паролем або нестандартним портом. Першим технічним кроком має бути встановлення доступних оновлень із довірених репозиторіїв.

Для Ubuntu та Debian зазвичай використовують:

sudo apt update && sudo apt full-upgrade

Для AlmaLinux, Rocky Linux або RHEL:

sudo dnf upgrade –refresh

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

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

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

На Ubuntu та Debian можна встановити механізм unattended-upgrades:

sudo apt install unattended-upgrades

sudo dpkg-reconfigure -plow unattended-upgrades

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

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

Створіть окремого адміністратора й обмежте права

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

Приклад для Ubuntu або Debian, де замість adminuser потрібно вказати власне ім’я:

sudo adduser adminuser

sudo usermod -aG sudo adminuser

У системах сімейства RHEL адміністративна група зазвичай має назву wheel:

sudo usermod -aG wheel adminuser

Навіть якщо віддалений вхід за паролем буде вимкнено, пароль адміністративного користувача має бути унікальним і стійким: він може знадобитися для sudo або аварійного локального доступу. Редагувати правила sudo слід через visudo, оскільки ця утиліта перевіряє синтаксис і зменшує ризик пошкодити конфігурацію.

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

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

Переведіть SSH на автентифікацію за ключем

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

Сучасний ключ Ed25519 можна створити на локальному комп’ютері:

ssh-keygen -t ed25519 -C “vps-admin”

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

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

ssh-copy-id adminuser@SERVER_IP

Інший варіант — додати вміст файла з розширенням .pub до ~/.ssh/authorized_keys потрібного користувача через консоль провайдера. Типові права доступу:

chmod 700 ~/.ssh

chmod 600 ~/.ssh/authorized_keys

Кожен адміністратор повинен мати власну пару ключів. Спільний ключ ускладнює відкликання доступу та не дає зрозуміти, хто саме виконав дію. Для особливо важливих серверів можна розглянути апаратний ключ безпеки, VPN для адміністративного доступу або багатофакторну автентифікацію, але ці механізми потрібно впроваджувати й тестувати окремо.

Посильте конфігурацію OpenSSH без втрати доступу

Після успішного входу новим користувачем за ключем можна обмежити SSH. На Ubuntu конфігурація міститься в /etc/ssh/sshd_config і файлах каталогу /etc/ssh/sshd_config.d/. OpenSSH для більшості параметрів використовує перше знайдене значення, а файли з шаблону завантажуються в лексикографічному порядку. Тому файл із назвою 99-hardening.conf не обов’язково перекриє параметр, уже заданий у 50-cloud-init.conf. Перед змінами потрібно переглянути наявні фрагменти та ефективну конфігурацію.

Базовий набір параметрів може виглядати так:

PermitRootLogin no

PubkeyAuthentication yes

PasswordAuthentication no

KbdInteractiveAuthentication no

PermitEmptyPasswords no

MaxAuthTries 3

AllowUsers adminuser

X11Forwarding no

Назву adminuser потрібно замінити. Якщо сервер використовує окремі облікові записи для резервного копіювання, автоматизації або SFTP, їх також слід додати до AllowUsers. Інакше вони втратять доступ. Параметр KbdInteractiveAuthentication не вимикають бездумно, якщо через PAM налаштовано одноразові коди або іншу багатофакторну автентифікацію.

На Ubuntu зручно створити ранній фрагмент на кшталт /etc/ssh/sshd_config.d/00-hardening.conf, але спочатку треба переконатися, що він не конфліктує з налаштуваннями образу провайдера. Фактичні значення можна переглянути командою:

sudo sshd -T

До перезапуску або перезавантаження служби обов’язково перевірте синтаксис:

sudo sshd -t

Якщо команда не вивела помилок, на Ubuntu або Debian конфігурацію зазвичай застосовують так:

sudo systemctl reload ssh

У системах сімейства RHEL назва служби переважно sshd:

sudo systemctl reload sshd

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

Чи допомагає зміна SSH-порту

Перенесення SSH з порту 22 на інший може зменшити кількість автоматичних записів у журналах, але не усуває вразливостей і не замінює ключі, firewall або оновлення. Сканер здатен знайти службу й на нестандартному порту.

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

Перевірте відкриті порти та непотрібні служби

Безпека VPS значною мірою залежить від площі атаки. Чим менше програм приймає з’єднання з інтернету, тим менше потенційних точок входу. Перелік TCP- і UDP-сокетів разом із процесами можна переглянути командою:

sudo ss -tulpn

Звертайте увагу на адресу прослуховування. Значення 127.0.0.1 або ::1 означає локальний інтерфейс, тоді як 0.0.0.0 і :: зазвичай вказують на всі доступні IPv4- або IPv6-інтерфейси. Сам факт прослуховування ще не доводить, що порт доступний з інтернету, адже трафік може блокувати firewall, але таку службу потрібно перевірити.

Активні системні служби можна переглянути так:

sudo systemctl –type=service –state=running

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

Бази даних, Redis, черги повідомлень, панелі адміністрування та внутрішні API зазвичай не мають слухати публічний інтерфейс. Їх прив’язують до localhost, приватної мережі або VPN, а доступ надають лише конкретним вузлам. Відкритий порт бази даних із паролем усе одно є зайвим ризиком.

Налаштування Firewall на VPS: заборонено все, крім потрібного

Базова модель для вхідного трафіку — deny by default: усі нові з’єднання блокуються, а дозволи створюються лише для відомих служб. Для звичайного вебсервера це часто SSH для адміністрування та порти 80 і 443 для сайту. Поштовий сервер, VPN або DNS потребуватимуть іншого набору правил.

Перед увімкненням firewall обов’язково дозвольте поточний SSH-порт. Краще виконувати перше налаштування, маючи відкриту консоль провайдера та активний SSH-сеанс.

Приклад UFW для Ubuntu або Debian

Спочатку задають політики за замовчуванням:

sudo ufw default deny incoming

sudo ufw default allow outgoing

Якщо SSH працює на стандартному порту 22, можна дозволити профіль OpenSSH:

sudo ufw allow OpenSSH

Для нестандартного порту потрібно вказати фактичний номер, наприклад:

sudo ufw allow 2222/tcp

Для публічного вебсервера додають HTTP та HTTPS:

sudo ufw allow 80/tcp

sudo ufw allow 443/tcp

Після перевірки правил firewall можна ввімкнути й переглянути:

sudo ufw enable

sudo ufw status numbered

Якщо адміністратор підключається з постійної IP-адреси, SSH можна дозволити лише з неї:

sudo ufw allow proto tcp from 203.0.113.10 to any port 22

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

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

Приклад firewalld для AlmaLinux, Rocky Linux або RHEL

Спочатку перевіряють активні зони та інтерфейси. Базова послідовність для сервера з SSH і вебсайтом може бути такою:

sudo systemctl enable –now firewalld

sudo firewall-cmd –get-active-zones

sudo firewall-cmd –permanent –zone=ZONE_NAME –add-service=ssh

sudo firewall-cmd –permanent –zone=ZONE_NAME –add-service=http

sudo firewall-cmd –permanent –zone=ZONE_NAME –add-service=https

sudo firewall-cmd –reload

sudo firewall-cmd –zone=ZONE_NAME –list-all

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

Які порти не варто відкривати без потреби

Служба	Типовий порт	Базова рекомендація
SSH	22/tcp	Дозволити лише адміністраторам, бажано через ключі, VPN або перелік довірених IP.
HTTP і HTTPS	80/tcp, 443/tcp	Відкрити публічно, якщо VPS обслуговує сайт або API.
MySQL або MariaDB	3306/tcp	Не відкривати в інтернет; використовувати localhost або приватну мережу.
PostgreSQL	5432/tcp	Дозволяти лише конкретним серверам застосунків або через захищену приватну мережу.
Redis	6379/tcp	Не публікувати; обмежити локальним або приватним інтерфейсом і налаштувати автентифікацію.
Панель керування чи внутрішній API	Залежить від програми	Закрити від загального інтернету, надати доступ через VPN, proxy з автентифікацією або список IP.

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

Поєднуйте хмарний і локальний firewall

Багато провайдерів мають власні security groups, network firewall або списки контролю доступу. Такий фільтр відсікає небажаний трафік ще до VPS і корисний як перший рубіж. Локальний firewall у системі залишається потрібним: він захищає у разі помилки в хмарному правилі, контролює приватні інтерфейси та рухається разом із конфігурацією сервера.

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

Окремо перевірте IPv6. Сервер може бути добре закритий за IPv4, але слухати ті самі служби на публічній IPv6-адресі. Правила мають охоплювати обидва протоколи або IPv6 слід коректно вимкнути на всіх рівнях, якщо він свідомо не використовується. Просте ігнорування IPv6 не є захистом.

Зменште ризик перебору входів

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

На Ubuntu або Debian пакет встановлюють так:

sudo apt install fail2ban

Локальні зміни краще зберігати в jail.local або окремому файлі каталогу jail.d, не редагуючи базовий jail.conf. Після ввімкнення правила для sshd перевіряють, чи програма читає правильне джерело журналів, знає фактичний SSH-порт і справді додає блокування до використовуваного firewall.

sudo fail2ban-client status

sudo fail2ban-client status sshd

Не копіюйте чужу конфігурацію без перевірки: шлях до журналу, backend і firewall-дія залежать від дистрибутива та версії. Також обережно налаштовуйте ignoreip, щоб не створити надто широкий виняток. Fail2ban не виправляє слабкий пароль і не закриває вразливу службу.

Оновлюйте й ізолюйте прикладні сервіси

Захищена операційна система не компенсує застарілий CMS, вебфреймворк, панель керування, базу даних або бібліотеку. Для кожного компонента має бути зрозуміло, звідки надходять оновлення, хто їх встановлює, як перевіряється працездатність і як виконати відкат.

Встановлюйте програми з офіційних репозиторіїв або перевірених джерел, контролюйте ключі підпису й адреси репозиторіїв.
Не запускайте від root випадкові сценарії за схемою завантажити з інтернету та одразу передати оболонці.
Видаляйте тестові сторінки, демонстраційні облікові записи, невикористані модулі, старі версії середовищ і тимчасові панелі.
Для публічних вебсервісів використовуйте TLS і стежте за автоматичним поновленням сертифікатів.
Обмежуйте права процесу: вебзастосунок не повинен мати можливість змінювати власний виконуваний код, якщо це не потрібно архітектурі.
Зберігайте завантажені користувачами файли окремо від коду та не дозволяйте виконувати їх як сценарії.
Базу даних і кеш відкривайте лише тим вузлам, яким вони справді потрібні.

Адміністративні інтерфейси краще приховувати за VPN, приватною мережею або додатковою автентифікацією. Саме нестандартна URL-адреса панелі не є достатнім обмеженням.

Особливості безпеки VPS із Docker

Контейнери не скасовують захист хоста. Опублікований Docker-порт може оброблятися правилами переспрямування раніше, ніж звичайні правила UFW, тому команда ufw status не завжди показує фактичну зовнішню доступність контейнера. Кожен параметр ports у Compose або ключ -p у docker run потрібно розглядати як окреме мережеве рішення.

Якщо сервіс має бути доступний лише локальному reverse proxy, його доцільно прив’язати до loopback-адреси, наприклад 127.0.0.1:8080, а не до всіх інтерфейсів. Після запуску контейнера перевіряють ss, конфігурацію Docker, правила мережевого фільтра й реальне підключення ззовні.

Доступ до Docker socket фактично дає дуже високі привілеї. Додавання користувача до групи docker не слід трактувати як звичайний дозвіл на запуск програми: такий користувач може отримати контроль над хостом. Не відкривайте Docker API в інтернет без взаємної TLS-автентифікації або захищеного SSH-доступу. За сумісності з проєктом можна розглянути rootless mode, запуск процесів у контейнерах не від root, read-only файлові системи та відмову від зайвих capabilities.

Контейнерні образи також потрібно регулярно оновлювати й перебудовувати. Простий перезапуск старого образу не встановлює виправлення, що з’явилися в базовій системі образу.

Не вимикайте AppArmor або SELinux заради швидкого виправлення

AppArmor в Ubuntu та SELinux у дистрибутивах сімейства RHEL додають обов’язковий контроль доступу поверх звичайних прав Unix. Вони можуть обмежити процес навіть тоді, коли зловмисник уже використав помилку в застосунку.

Стан AppArmor можна переглянути командою:

sudo aa-status

Для SELinux використовують:

getenforce

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

Захистіть секрети та обліковий запис хостинг-провайдера

Компрометація панелі провайдера може дозволити скинути пароль, відкрити консоль, створити знімок диска, змінити firewall або видалити VPS. Тому безпека сервера починається не лише всередині операційної системи.

Увімкніть багатофакторну автентифікацію для панелі, пошти власника домену, DNS і сховища резервних копій.
Використовуйте різні унікальні паролі та зберігайте коди відновлення окремо від основного пристрою.
Створюйте API-токени з мінімальними правами й обмеженим строком дії, якщо сервіс це підтримує.
Видаляйте старі токени, SSH-ключі, паролі застосунків та доступ підрядників.
Увімкніть сповіщення про входи, створення ресурсів, зміну мережевих правил і незвичні витрати.

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

Організуйте резервні копії, які можна відновити

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

До резервування зазвичай включають:

користувацькі файли та завантаження;
узгоджені дампи або фізичні копії баз даних відповідно до вимог конкретної СУБД;
конфігурацію системи, вебсервера, firewall, планувальника та служб;
файли розгортання, Compose-конфігурацію або інфраструктурний код;
секрети в зашифрованому вигляді та окремо збережений спосіб їх розшифрування;
перелік пакетів, версій і коротку інструкцію відновлення.

Копія не повинна залежати лише від того самого VPS або одного облікового запису провайдера. Знімок диска зручний для швидкого відкату, але може бути втрачений разом із сервером чи акаунтом. Щонайменше одна копія має зберігатися в окремому сховищі з обмеженими правами; для важливих даних корисні версіонування, незмінність і захист від масового видалення.

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

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

Налаштуйте журнали, моніторинг і сповіщення

Без журналів важко з’ясувати, коли почалася проблема, з якої адреси входили та які зміни передували збою. Без сповіщень інформація може залишатися непоміченою, доки сервер не перестане відповідати.

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

sudo systemctl –failed

sudo ss -tulpn

sudo journalctl -p warning –since today

last

sudo lastb

Назва SSH-служби в journald залежить від дистрибутива. На Ubuntu це часто ssh, а в RHEL-подібних системах — sshd. Приклад перегляду:

sudo journalctl -u ssh –since today

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

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

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

Типові помилки під час налаштування безпеки VPS

Вимкнути парольний SSH до перевірки ключа. Це найпростіший спосіб втратити мережевий доступ.
Увімкнути firewall, не дозволивши SSH-порт. Виправлення потім потребуватиме консолі провайдера.
Вважати нестандартний порт повноцінним захистом. Він лише зменшує шум від примітивних сканерів.
Відкрити базу даних для всіх адрес. Краще використовувати localhost, приватну мережу, VPN або точковий список джерел.
Залишити невикористані служби та тестові панелі. Кожен додатковий компонент потребує оновлень і контролю.
Запускати застосунок від root. Вразливість у програмі тоді одразу дає максимальні привілеї.
Надати права 777 замість виправлення власника й групи. Це маскує помилку та відкриває зайвий доступ.
Вимкнути AppArmor або SELinux. Проблему сумісності потрібно діагностувати, а не прибирати захисний шар.
Покладатися лише на знімок VPS. Він може бути видалений разом із сервером або скомпрометованим акаунтом.
Не перевіряти Docker-порти ззовні. Опублікований контейнер може бути доступним попри очікувану заборону UFW.
Встановити автоматичні оновлення без контролю. Потрібні журнали, сповіщення, план перезавантаження та відновлення.
Використовувати один SSH-ключ для всіх. Доступ неможливо відкликати точково, а дії складніше пов’язати з людиною.

Базовий чекліст безпеки VPS після налаштування

Операційна система підтримується та повністю оновлена.
Є аварійна консоль або перевірений режим відновлення.
Створений окремий адміністративний користувач із sudo.
Вхід за SSH-ключем перевірено в окремому сеансі.
Віддалений вхід root заборонено.
Парольну автентифікацію SSH вимкнено або обґрунтовано захищено MFA.
Ефективну конфігурацію перевірено через sshd -T, а синтаксис — через sshd -t.
Відомо призначення кожного порту з результату ss -tulpn.
У хмарному й локальному firewall відкрито лише необхідні служби.
Правила перевірені окремо для IPv4 та IPv6.
Бази даних, кеші й адміністративні панелі не доступні всьому інтернету.
AppArmor або SELinux працює в режимі примусового застосування політик.
Обліковий запис провайдера, DNS і сховище копій захищені MFA.
Резервні копії зберігаються окремо, а відновлення протестовано.
Налаштовані сповіщення про збій служб, заповнення диска, помилки копіювання та підозрілі входи.
Для Docker перевірені всі опубліковані порти та права групи docker.

Поширені запитання

Який firewall краще для VPS — UFW, firewalld чи nftables?

Для простого Ubuntu-сервера UFW зручний як зрозумілий інтерфейс до мережевого фільтра. У RHEL-подібних системах типовим вибором є firewalld. nftables дає більше контролю для складної маршрутизації та власних політик, але потребує кращого розуміння порядку правил. Найважливіше не назва інструмента, а послідовна політика, перевірка результату та відсутність паралельних конфігурацій, які конфліктують між собою.

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

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

Чи можна повністю закрити SSH від інтернету?

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

Як часто потрібно оновлювати VPS?

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

Що робити, якщо після зміни firewall або SSH сервер недоступний?

Скористайтеся вебконсоллю або rescue mode провайдера, перевірте стан SSH-служби, синтаксис sshd_config, активний порт, локальні правила та хмарний firewall. Не варто хаотично вимикати всі захисні механізми: краще знайти конкретний рівень, на якому блокується з’єднання, і виправити правило.

Чи відповідає хостинг-провайдер за безпеку VPS?

Провайдер захищає фізичну інфраструктуру, платформу віртуалізації та власні сервіси в межах своїх умов. Налаштування гостьової ОС, облікових записів, застосунків, firewall, резервних копій і секретів зазвичай залишається відповідальністю власника VPS. Точний розподіл потрібно перевірити в договорі та документації послуги.

Висновок

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

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

Перед тим як розгортати VPN, важливо не просто орендувати будь-який сервер, а вибрати оптимальний VPS під реальне навантаження. У актуальній лінійці DeltaHost використовуються KVM VPS із NVMe: Linux-конфігурації починаються з 2 віртуальних ядер, 4 ГБ RAM і 50 ГБ NVMe, а старші тарифи доходять до 8 ядер, 32 ГБ RAM і 250 ГБ NVMe.