Чи безпечний VPS hosting і що ви контролюєте

Чи безпечний VPS hosting? Коротка відповідь

Так. VPS hosting безпечний для більшості завдань, заради яких його орендують, і це суттєве покращення порівняно зі shared hosting. VPS (virtual private server) — це віртуальна машина із власним kernel, власною пам’яттю, власним диском і власними обліковими записами користувачів. Hypervisor, на якому вона працює, ізолює ці чотири ресурси від інших клієнтів. Користувач, який орендує сервер поруч із вашим на тому самому фізичному комп’ютері, не може прочитати ваші файли, переглянути список процесів, увійти на ваш сервер або побачити ваш мережевий трафік.

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

Що саме розділяє гіпервізор

Гіпервізор — це програмне забезпечення, яке запускає віртуальні машини на одному фізичному хості. На KVM VPS (KVM означає kernel based virtual machine, стандарт для Linux-хостів) ваш сервер є повноцінною віртуальною машиною. Він завантажує власне ядро. Хост виділяє йому фіксовану область фізичної пам’яті, а блок керування пам’яттю процесора забороняє будь-який доступ за межі цієї області. Тому код, що працює в іншому гостьовому середовищі, взагалі не може звертатися до вашої оперативної пам’яті. Спільної файлової системи та спільної таблиці користувачів немає, тому права доступу до файлів на сервері сусіда нічого не означають на вашому сервері.

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

Перевірте, що саме ви купуєте, оскільки не кожен тариф, який продають як VPS, є віртуальною машиною. Тарифи на основі контейнерів (OpenVZ, LXC, Virtuozzo) використовують спільне ядро хоста та розділяють клієнтів за допомогою просторів імен і cgroups замість апаратної віртуалізації. Це слабша межа ізоляції, оскільки помилка в ядрі хоста є також помилкою в ядрі вашого сервера. На таких тарифах також не можна завантажувати модулі ядра, через що деяке програмне забезпечення не працюватиме. KVM є безпечнішим типовим варіантом. До оплати уточніть, який саме тип віртуалізації ви отримуєте.

Що може зробити проблемний сусід

Спільне використання фізичного хоста впливає на швидкість, і це єдиний його недолік. Віртуальні машини на одному хості спільно використовують фізичний процесор і диски. Коли процесор зайнятий роботою іншого клієнта, ваш віртуальний процесор очікує, а Linux показує цей час очікування як steal time: поле %st у top і vmstat. Якщо steal time протягом кількох годин перевищує кілька відсотків, це означає, що ресурси хоста перепідписані. Це не означає, що хтось читає ваші дані. Рішення — вибрати інший тариф або іншого провайдера. Перед цим ви можете виміряти фактичну продуктивність процесора й диска.

Є один ефект між клієнтами, про який варто знати. Це не вразливість системи безпеки. Якщо ви надсилаєте email зі свого VPS, ваша IP-адреса належить до діапазону, яким також користуються інші клієнти. Сусід, який надсилає спам, може спричинити внесення частини цього діапазону до blocklist. Через це ваші листи потраплятимуть у папки зі спамом, хоча причиною були не ваші дії. Провайдери, які контролюють зловживання, підтримують чистіші діапазони адрес. Якщо email важливий для вас, запитайте про це під час вибору провайдера.

Що зловмисний сусід не може зробити і в рідкісних випадках може

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

Вихід за межі гіпервізора — реальна загроза. Помилка на рівні віртуалізації може дозволити коду всередині одного гостьового середовища отримати доступ до хоста, а через хост — до всіх гостьових середовищ на ньому. Такі помилки виявляють, публікують для них ідентифікатор CVE (common vulnerabilities and exposures) і виправляють. Провайдери хостингу швидко встановлюють виправлення, оскільки весь їхній бізнес залежить від цього рівня. Використання такої вразливості потребує робочого експлойта для конкретної версії гіпервізора. Для невеликого облікового запису хостингу це надто дорогий ресурс.

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

Де закінчується відповідальність провайдера і починається ваша

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

Ви відповідаєте за все, що належить до рівня операційної системи та вище. Це означає встановлені вами пакети, відкриті порти, облікові записи й ключі, за допомогою яких можна виконати вхід, застосовані оновлення, резервні копії та власний код застосунків. Більшість тарифів VPS є unmanaged. Це означає, що ніхто не встановлює оновлення на ваш сервер замість вас, і звернення до служби підтримки цього не зробить. Відмінності між managed і unmanaged варто прочитати до придбання тарифу, оскільки саме вони визначають, яка частина цього переліку буде вашою відповідальністю.

Є одна частина вашої зони відповідальності, про яку легко забути: сама панель керування хостингом. Той, хто має доступ до цього облікового запису, може перебудувати ваш сервер або підключити його диск до rescue system, навіть не знаючи жодного пароля всередині сервера. Увімкніть двофакторну автентифікацію (2FA) для облікового запису хостингу та не використовуйте цей пароль в інших місцях.

Чи може ваш хостинг-провайдер бачити ваші дані?

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

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

Що насправді призводить до злому VPS

Сервіс, що прослуховує всі інтерфейси. Бази даних, кеші, черги повідомлень і панелі адміністрування часто за замовчуванням прив’язуються до 0.0.0.0. Це означає всі мережеві інтерфейси, зокрема публічний. Сканування Інтернету відбувається постійно й автоматично, тому нова IP-адреса отримує перший небажаний запит протягом кількох хвилин після підключення. Redis без пароля, вузол Elasticsearch без автентифікації, відкритий Docker API на порту 2375 і панель адміністрування зі стандартними обліковими даними виявляються саме так — сканером, якому байдуже, хто ви. Прив’язуйте сервіс до 127.0.0.1, якщо він потрібен лише локальній машині, а решту доступу блокуйте на firewall.

Docker, який обходить firewall. Публікація порту контейнера створює правила трансляції мережевих адрес (NAT), які обробляються перед правилами ufw (uncomplicated firewall). Тому контейнер може бути доступним з Інтернету, хоча ufw status повідомляє, що цей порт заборонено. Це часто стається з тими, хто правильно налаштував усе інше. Перед публікацією порту контейнера варто прочитати Чому порт Docker ігнорує ufw.

SSH із увімкненою автентифікацією за паролем. Перегляньте /var/log/auth.log на будь-якому публічному сервері — і побачите рядки на кшталт Failed password for root from 203.0.113.10 port 54312 ssh2, тисячі таких записів удень і вночі. Боти перебирають поширені імена користувачів і паролі. Автентифікація за паролем разом із можливістю входу для облікового запису root — усе, що потрібно зловмиснику. Якщо дозволено лише ключі, а вхід для root вимкнено, цей трафік перетворюється на шум, який можна ігнорувати.

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

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

Розкритий секрет. Паролі баз даних і API-ключі зберігаються у файлах .env, а ці файли потрапляють до публічного репозиторію або обслуговуються веб-сервером, налаштованим на неправильний каталог. Усе, що вставлено в контекст AI-агента для написання коду, також може потрапити до журналу. Це окрема тема: як не допустити доступу агента до секретів.

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

Ваша частина роботи

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

• Правильно виконайте початкове налаштування: перші десять хвилин на новому VPS охоплюють створення користувача не root і налаштування брандмауера.
• Захистіть віддалений доступ: посилення безпеки SSH на VPS.
• Закрийте порти, які ви не використовуєте: основи брандмауера ufw.
• Надавайте кожному сервісу лише потрібний йому доступ: користувачі з мінімальними привілеями на VPS.
• Ускладніть перебір паролів під час входу: fail2ban на Ubuntu 24.04.
• Зберігайте резервну копію, відновлення з якої ви перевірили хоча б один раз: резервні копії VPS за допомогою restic.

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

FAQ

Чи може інший клієнт на тому самому фізичному сервері прочитати мої файли?

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

Чи безпечніший VPS за shared hosting?

Для ізоляції — так. У shared hosting багато сайтів працюють в одній операційній системі, а єдиною межею є дозволи на файли. Тому помилка в іншому обліковому записі іноді може відкрити доступ до файлів. У VPS межею є віртуальна машина. Компроміс полягає в тому, що на shared hosting оновлення встановлює хостинг-провайдер, а в некерованому VPS — ви. VPS безпечніший лише за умови, що ви справді встановлюєте оновлення та закриваєте порти.

Чи може мій хостинг-провайдер прочитати мої дані?

У принципі, так. Жоден продукт VPS цього не змінює. Образ диска зберігається на обладнанні провайдера, консоль надає доступ на рівні екрана до запущеної машини, а rescue mode може завантажити іншу систему з підключеним диском вашого сервера. Якщо певні дані мають залишатися недоступними для хоста, шифруйте їх у застосунку перед записом. Шифрування диска всередині гостьової системи все одно зберігає ключ у пам’яті під час роботи сервера, тому не усуває провайдера з моделі довіри.

Який спосіб компрометації VPS є найпоширенішим?

Із великим відривом — використання відкритого сервісу або слабкого входу через SSH. Автоматизовані сканери постійно перевіряють кожну публічну IP-адресу. Тому базу даних, прив’язану до 0.0.0.0 без пароля, або панель адміністратора зі стандартними обліковими даними знаходять за кілька хвилин, а не за кілька місяців. /var/log/auth.log на будь-якому публічному сервері показує частину проблеми, пов’язану з SSH: повторювані рядки Failed password for root з адрес з усього світу. Виходи з гіпервізора трапляються, але це атаки дослідницького рівня, спрямовані на цінні цілі, а не причина звичайних зламів.