Безпека VPS: 7 дірок у вашому сервері, через які хакери заходять як до себе додому

Ваш VPS зламали о третій ночі. Ви дізналися про це о дев'ятій ранку, коли клієнти почали писати, що сайт роздає рекламу онлайн-казино. Знайомо? Мені - так. Я бачив цю історію десятки разів, і щоразу причина була банальною, як незачинені двері в квартирі. Не якийсь геніальний злом. Не вразливість нульового дня. Просто відчинені двері, в які зайшов перший-ліпший бот, що просканував інтернет за п'ять хвилин.

Більшість власників VPS вважають, що безпека - це «потім». Спочатку запустити проєкт, налаштувати домен, залити файли. А потім, колись, руки дійдуть до захисту. Проблема в тому, що «потім» настає рівно через 48 годин після створення сервера - саме стільки в середньому потрібно ботам, щоб знайти ваш незахищений VPS і почати стукати у двері. Давайте розберемо сім найпоширеніших дірок і закриємо їх раз і назавгди.

SSH на порту 22 з паролем root - класика жанру

Якщо ваш сервер досі приймає SSH-з'єднання на стандартному порту 22 з паролем для root-користувача, це як вивісити на дверях табличку «Ласкаво просимо, замок декоративний». За даними дослідження Rapid7, щодня в інтернеті фіксується понад 2.5 мільйона спроб брутфорсу SSH. Ваш сервер - один із потенційних адресатів.

«Понад 80% успішних зламів серверів починаються з компрометації облікових даних через SSH. Не вразливість софту, не експлойт ядра - просто слабкий пароль або дефолтні налаштування.» - звіт Verizon Data Breach Investigations Report, 2024

Що робити? Три кроки, п'ять хвилин:

1. Змініть порт SSH з 22 на будь-який нестандартний (наприклад, 49152). Це не панацея, але відсікає 90% автоматичних сканерів.
2. Вимкніть вхід для root через SSH. У файлі /etc/ssh/sshd_config встановіть PermitRootLogin no.
3. Перейдіть на автентифікацію за ключами замість паролів. Генеруєте пару ключів через ssh-keygen, додаєте публічний на сервер - і забуваєте про паролі назавжди.

Це буквально як поміняти замок на дверях. Проста дія, але 60% адміністраторів її ігнорують.

Відкриті порти, про які ви навіть не знаєте

Коли я вперше запустив nmap на свіжому VPS одного клієнта, побачив 14 відкритих портів. Чотирнадцять. При тому, що для роботи сайту потрібні були три: 80, 443 і той самий SSH. Решта - спадок дефолтних налаштувань операційної системи та панелі управління.

Кожен відкритий порт - це потенційна точка входу для атакуючого. Уявіть квартиру з 14 вікнами, де ви замикаєте лише вхідні двері. Абсурд? Саме так виглядає типовий VPS після створення.

Мінімальний набір портів для вебсервера:

• 80 (HTTP) і 443 (HTTPS) - для вебтрафіку
• Ваш кастомний порт SSH - для адміністрування
• Все інше - заблокувати через iptables або ufw

Команда ufw default deny incoming && ufw allow 443/tcp && ufw allow 80/tcp && ufw allow 49152/tcp && ufw enable займає 10 секунд. Десять секунд проти потенційного злому.

Застаріле програмне забезпечення - тиха бомба

Порівняю це з їжею в холодильнику. Ви ж не їсте йогурт, який прострочений на три місяці? Але чомусь спокійно тримаєте на сервері PHP 7.4, підтримка якого закінчилася ще у листопаді 2022-го, або Apache з відомими CVE-вразливостями.

Ось реальна таблиця ризиків для популярних компонентів:

Кожна з цих вразливостей - не теоретична загроза. Це готові експлойти, які вільно лежать на GitHub. Автоматизовані боти знають про них і перевіряють ваш сервер регулярно. apt update && apt upgrade раз на тиждень - це ваша гігієна. Як чистити зуби, тільки для сервера.

Відсутність Fail2Ban - як жити без сигналізації

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

Fail2Ban - це автоматичний «вишибала» вашого сервера. Він читає логи, бачить підозрілу активність і банить IP-адреси. Налаштування займає буквально хвилини:

1. Встановіть: apt install fail2ban
2. Створіть локальний конфіг: cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
3. Налаштуйте параметри для SSH: maxretry = 3, bantime = 3600 (бан на годину після трьох невдалих спроб)
4. Перезапустіть: systemctl restart fail2ban

Після встановлення Fail2Ban на один із моїх серверів я побачив у логах, що за першу добу було заблоковано 847 IP-адрес. Вісімсот сорок сім. І це був звичайний невеликий VPS з одним сайтом.

Один користувач на всіх - рецепт катастрофи

Є така порочна практика: дати всім розробникам, контент-менеджерам і SEO-спеціалістам один root-пароль. «Щоб простіше було». Знаєте, що ще простіше? Втратити всі дані, коли один із цих людей випадково запустить rm -rf / або його ноутбук вкрадуть у кав'ярні.

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

• Розробник - доступ до директорії проєкту і деплой-скриптів
• Контент-менеджер - SFTP до папки uploads, і крапка
• Ви (адмін) - sudo-права через іменований обліковий запис, не через root
• Ніхто - прямий root-доступ через SSH

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

SSL/TLS «для галочки» і незашифровані з'єднання

Ви встановили Let's Encrypt? Чудово. А ваш phpMyAdmin досі працює по HTTP на порту 8080? А бекенд-з'єднання між вебсервером і базою даних - незашифроване? А FTP (не SFTP, а саме старий добрий FTP) все ще активний?

SSL на фронтенді - це лише верхівка айсберга. Повна картина шифрування на VPS виглядає так:

• Фронтенд - HTTPS з актуальним сертифікатом та вимкненими старими протоколами (TLS 1.0, 1.1 - геть)
• Адміністративні панелі - тільки через HTTPS або SSH-тунель, ніяких відкритих портів з веб-інтерфейсами
• Передача файлів - SFTP або SCP, класичний FTP вимкнений повністю
• Внутрішні з'єднання - якщо база на окремому сервері, підключення через SSL або приватну мережу

Перевірте прямо зараз: зайдіть на ssllabs.com/ssltest і вкажіть свій домен. Якщо оцінка нижче A - у вас проблема, яку бачить кожен, хто захоче перевірити.

Бекапи без перевірки - ілюзія безпеки

«У мене є бекапи» - чую я постійно. «А ви їх перевіряли?» - питаю у відповідь. Тиша. Бекап, який ви ніколи не тестували, - це коробка з парашутом, яку ви ніколи не розкривали. Може, там парашут. А може, хтось поклав туди старі газети.

Правило 3-2-1 працює і для VPS:

1. 3 копії даних (робоча + дві резервні)
2. 2 різні типи носіїв (наприклад, локальний снапшот + зовнішнє S3-сховище)
3. 1 копія поза основним дата-центром (географічна ізоляція)

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

Знаєте, що мене дивує найбільше? Всі ці сім дірок закриваються за один вечір. Не потрібен штатний безпечник з зарплатою $5000. Не потрібен аудит за $10 000. Потрібні кілька годин уваги, базові команди Linux і бажання не стати наступною жертвою статистики. Ваш VPS вже просканували сьогодні мінімум десять разів. Питання лише в тому - знайшли щось цікаве чи ні?