Як захистити VPS після розгортання

Коротка відповідь: як захистити VPS

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

1. Оновіть операційну систему та встановіть останні доступні виправлення безпеки.
2. Створіть окремий обліковий запис адміністратора та дотримуйтеся принципу мінімальних привілеїв.
3. Налаштуйте автентифікацію за SSH-ключами й обмежте віддалений адміністративний доступ.
4. Увімкніть міжмережевий екран і дозвольте лише порти, необхідні для роботи застосунків.
5. Видаліть непотрібне програмне забезпечення, служби, пакети та облікові записи.
6. Налаштуйте виявлення та запобігання вторгненням, наприклад Fail2ban, якщо це потрібно.
7. Захистіть вебзастосунки, бази даних, кінцеві точки API та секрети застосунків.
8. Увімкніть HTTPS, використовуйте дійсні TLS-сертифікати та захистіть налаштування домену й DNS.
9. Налаштуйте моніторинг системи, централізоване зберігання журналів, сповіщення й аудит безпеки.
10. Створюйте ізольовані резервні копії та регулярно перевіряйте процес відновлення.
11. Документуйте налаштування безпеки та переглядайте їх після кожної зміни конфігурації сервера.

Зміст

1. Розуміння ризиків безпеки VPS
2. Початкова оцінка безпеки
3. Оновлення операційної системи
4. Захист облікових записів і привілеїв
5. Посилення безпеки SSH
6. Налаштування міжмережевого екрана
7. Вимкнення непотрібних служб і портів
8. Налаштування захисту від вторгнень за допомогою Fail2ban
9. Захист застосунків і баз даних
10. Налаштування HTTPS і TLS
11. Виявлення підозрілої активності та шкідливого програмного забезпечення
12. Захист Windows VPS
13. Налаштування безпечного резервного копіювання
14. Моніторинг активності та продуктивності сервера
15. Захист VPS від DDoS-атак
16. Автоматизація обслуговування безпеки
17. Чекліст безпеки VPS
18. Поширені помилки під час захисту VPS
19. Поширені запитання
20. Висновок

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

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

У цьому посібнику описано, як захистити VPS після розгортання за допомогою практичних прикладів налаштування. Інструкції для Linux насамперед призначені для Ubuntu Server і дистрибутивів на базі Debian. Рекомендації для Windows наведено окремо. Команди та конфігураційні файли можуть відрізнятися залежно від версії операційної системи, тому перед застосуванням змін на робочому сервері перевірте доступні параметри.

1. Розуміння ризиків безпеки VPS

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

До найпоширеніших ризиків належать:

• Атаки методом перебору: автоматизовані спроби вгадати паролі SSH, RDP, панелі керування або застосунків.
• Неусунені вразливості: застарілі операційні системи, бібліотеки, плагіни та серверні застосунки з відомими недоліками безпеки.
• Відкриті служби: загальнодоступні бази даних, адміністративні інтерфейси, інструменти розробки та невикористовувані мережеві порти.
• Підвищення привілеїв: вразливості або помилки конфігурації, які дають змогу зловмиснику з обмеженим доступом отримати розширені права.
• Компрометація облікових даних: викрадені SSH-ключі, повторно використовувані паролі, витеклі токени API та облікові дані у вихідному коді.
• Атаки на вебзастосунки: експлуатація ненадійної автентифікації, вразливостей впровадження коду, механізмів завантаження файлів і вразливих залежностей.
• Втрата даних: випадкове видалення, програми-вимагачі, збої обладнання або сховища та руйнівні дії адміністратора.
• Атаки типу «відмова в обслуговуванні»: шкідливий трафік, який споживає доступну пропускну здатність мережі, ресурси CPU, пам’ять або обчислювальні ресурси застосунків.

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

2. Проведіть початкову оцінку безпеки

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

В Ubuntu або Debian виконайте такі команди:

cat /etc/os-release
hostnamectl
uptime
ip -br address
ip route
ss -tulpn
systemctl --type=service --state=running
df -h
free -h

Ці команди виводять інформацію про операційну систему, мережеву конфігурацію, порти TCP і UDP, що прослуховуються, запущені служби, використання диска та пам’яті. Для перегляду деяких даних можуть знадобитися права адміністратора.

Далі визначте, які порти мають бути доступними з інтернету. Наприклад, типовому загальнодоступному вебсерверу можуть бути потрібні порти 80 і 443, а для адміністрування — SSH. Інші порти варто обмежити, якщо архітектура застосунку не потребує іншого.

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

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

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

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

В Ubuntu або Debian оновіть індекси пакетів і встановіть доступні оновлення:

sudo apt update
sudo apt upgrade

Перед підтвердженням операції перевірте список змін, особливо на виробничих системах. Ширша команда apt full-upgrade може встановлювати або видаляти пакети для розв’язання залежностей, тому використовуйте її лише після перевірки запропонованих змін.

sudo apt full-upgrade

Після оновлення перевірте, чи потрібне перезавантаження:

if [ -f /var/run/reboot-required ]; then
  echo "A reboot is required"
fi

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

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

Автоматичне встановлення оновлень безпеки допомагає скоротити час між випуском виправлення та його застосуванням. В Ubuntu для автоматизації відповідних оновлень можна використовувати пакет unattended-upgrades.

sudo apt install unattended-upgrades
sudo dpkg-reconfigure unattended-upgrades

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

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

4. Захистіть облікові записи та привілеї

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

У Linux створіть окремий обліковий запис для кожного адміністратора та надавайте розширені права лише за потреби.

sudo adduser sysadmin
sudo usermod -aG sudo sysadmin

Замініть sysadmin на потрібне ім’я користувача. Членство в групі sudo надає адміністративні можливості, тому не додавайте до неї користувачів, яким такі права не потрібні.

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

Дотримуйтеся принципу мінімальних привілеїв

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

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

5. Посильте захист SSH

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

Налаштуйте автентифікацію за SSH-ключами

Створіть пару SSH-ключів на довіреному локальному комп’ютері, а не на VPS:

ssh-keygen -t ed25519 -C "[email protected]"

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

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

ssh-copy-id sysadmin@SERVER_IP

Замініть SERVER_IP IP-адресою сервера та вкажіть відповідне ім’я адміністративного облікового запису. Якщо ssh-copy-id недоступна, встановіть відкритий ключ через інструменти керування хостинг-провайдера або додайте його до файлу ~/.ssh/authorized_keys користувача, налаштувавши правильного власника та права доступу.

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

Вимкніть прямий вхід root і автентифікацію за паролем

Після підтвердження того, що адміністративний обліковий запис може підключатися через SSH-ключ, перевірте конфігурацію SSH-сервера. У багатьох системах Ubuntu та Debian відповідний файл розташований за шляхом /etc/ssh/sshd_config. На фактичні налаштування також можуть впливати додаткові конфігураційні файли.

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

PermitRootLogin no
PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no
AllowUsers sysadmin

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

Перед перезавантаженням або повторним читанням конфігурації SSH перевірте її коректність:

sudo sshd -t
sudo sshd -T | grep -E 'permitrootlogin|pubkeyauthentication|passwordauthentication|kbdinteractiveauthentication'

Якщо перевірка синтаксису пройшла успішно, перезавантажте конфігурацію відповідної служби SSH. В Ubuntu та Debian служба зазвичай називається ssh, хоча в деяких дистрибутивах використовується назва sshd.

sudo systemctl reload ssh

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

Обмежте мережевий доступ до SSH

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

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

6. Налаштуйте міжмережевий екран

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

В Ubuntu для керування правилами міжмережевого екрана на рівні хоста можна використовувати UFW.

Налаштування UFW в Ubuntu

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

sudo ufw allow OpenSSH
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw enable
sudo ufw status verbose

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

Для загальнодоступного вебсайту дозвольте HTTP і HTTPS, якщо вони потрібні:

sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw status numbered

Не відкривайте всі порти про всяк випадок. Перед додаванням правила перевірте документацію служби та мережеву архітектуру.

Обмежте доступ до адміністративних інтерфейсів і портів баз даних

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

Наприклад, щоб дозволити SSH лише з довіреної IPv4-адреси, після перевірки адреси та наявної політики міжмережевого екрана використовуйте правило:

sudo ufw allow from 203.0.113.10 to any port 22 proto tcp

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

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

7. Вимкніть непотрібні служби та порти

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

Виведіть список портів, що прослуховуються:

sudo ss -tulpn

Перегляньте активні служби:

systemctl --type=service --state=running

Для кожної неочікуваної служби визначте пов’язаний пакет, процес і залежності застосунків, перш ніж вносити зміни. Не вимикайте службу лише тому, що її назва вам незнайома.

Якщо підтверджено, що служба не потрібна, зупиніть її та вимкніть автоматичний запуск:

sudo systemctl disable --now SERVICE_NAME

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

Перевірте поширені джерела підвищеного ризику:

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

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

8. Налаштуйте захист від вторгнень за допомогою Fail2ban

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

В Ubuntu або Debian встановіть пакет:

sudo apt update
sudo apt install fail2ban
sudo systemctl enable --now fail2ban
sudo systemctl status fail2ban

Створіть локальний конфігураційний файл замість зміни стандартної конфігурації, якою керує пакет:

sudo nano /etc/fail2ban/jail.local

Базова конфігурація для SSH може мати такий вигляд:

[DEFAULT]
bantime = 10m
findtime = 10m
maxretry = 5

[sshd]
enabled = true

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

Перевірте конфігурацію та стан SSH-фільтра:

sudo fail2ban-client -t
sudo systemctl restart fail2ban
sudo fail2ban-client status
sudo fail2ban-client status sshd

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

Будьте обережні під час перевірки блокувань на робочих серверах. Не допускайте блокування власної адміністративної адреси та переконайтеся, що у вас є альтернативний спосіб відновлення доступу. Fail2ban — допоміжний інструмент, а не повноцінна система виявлення вторгнень.

9. Захистіть застосунки та бази даних

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

Захистіть залежності застосунків

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

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

Захистіть бази даних

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

Для служби бази даних переконайтеся, що:

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

Захистіть секрети та конфігураційні файли

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

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

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

10. Налаштуйте HTTPS і TLS

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

Щоб налаштувати HTTPS:

1. Спрямуйте відповідні DNS-записи на потрібний сервер або зворотний проксі-сервер.
2. Встановіть і налаштуйте вебсервер або шлюз застосунків.
3. Отримайте довірений TLS-сертифікат для необхідних доменних імен.
4. Налаштуйте сервер на використання сертифіката та відповідного закритого ключа.
5. За потреби налаштуйте перенаправлення HTTP на HTTPS.
6. Автоматизуйте поновлення сертифікатів і відстежуйте терміни їхньої дії.
7. Переконайтеся, що застосунок не передає конфіденційний вміст через незашифровані з’єднання.

Для Nginx в Ubuntu можна використовувати Certbot із сумісним центром сертифікації та підтримуваним способом встановлення. Дотримуйтеся інструкцій, які відповідають вашій операційній системі та конфігурації розгортання.

sudo nginx -t
sudo systemctl reload nginx

Ці команди перевіряють конфігурацію Nginx і повторно завантажують її після успішної перевірки. Самі по собі вони не отримують і не встановлюють сертифікат.

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

HTTPS не замінює безпеку застосунку. Автентифікація, контроль доступу, перевірка вхідних даних, безпечні cookie та правильне керування сеансами залишаються необхідними.

11. Виявляйте підозрілу активність і шкідливе програмне забезпечення

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

Перевіряйте журнали автентифікації та системи

В Ubuntu або Debian перегляньте останні події автентифікації та системні помилки:

sudo journalctl -p warning --since "24 hours ago"
sudo journalctl -u ssh --since "24 hours ago"
sudo last
sudo lastb

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

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

Перевіряйте процеси та мережеві з’єднання

ps aux --sort=-%cpu | head -n 15
sudo ss -tpn
systemctl --failed
sudo journalctl -p err -b

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

Використовуйте сканування на шкідливе програмне забезпечення за потреби

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

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

12. Захистіть Windows VPS

Захист Windows VPS ґрунтується на тих самих загальних принципах, що й посилення безпеки Linux, однак адміністративні інструменти та механізми налаштування відрізняються.

Встановіть оновлення Windows

Встановлюйте оновлення безпеки та якості для підтримуваних версій Windows Server через Windows Update або затверджену корпоративну систему керування оновленнями. За потреби плануйте перезавантаження та після них перевіряйте працездатність критично важливих застосунків.

Захистіть віддалений робочий стіл

Протокол віддаленого робочого столу (RDP) часто стає ціллю автоматизованих атак із підбором паролів. За можливості не відкривайте RDP безпосередньо для всього інтернету.

• Обмежте RDP довіреними IP-адресами, VPN або відповідним шлюзом віддалених робочих столів.
• Використовуйте надійні унікальні облікові дані та багатофакторну автентифікацію, якщо вона підтримується.
• Увімкніть автентифікацію на рівні мережі (Network Level Authentication), якщо вона сумісна із середовищем.
• Обмежте членство в групах віддаленого доступу та адміністраторів.
• Відстежуйте події автентифікації та розслідуйте неочікувані спроби входу.
• Вимкніть RDP, якщо він не потрібен, попередньо переконавшись, що доступний інший спосіб адміністрування.

Налаштуйте брандмауер Microsoft Defender

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

Захистіть облікові записи та служби

Використовуйте окремі адміністративні облікові записи, мінімальні привілеї, Microsoft Defender або інше підтримуване рішення для захисту кінцевих пристроїв, а також централізоване журналювання подій, якщо воно доступне. Видаляйте невикористовувані ролі та застосунки, захищайте адміністративні операції PowerShell і не допускайте компрометації облікових даних для резервного копіювання.

Також перевірте вимоги до ліцензування та підтримки використовуваної версії Windows Server і застосунків, що працюють на VPS.

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

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

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

Дотримуйтеся принципу резервного копіювання 3-2-1

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

Створюйте резервні копії всіх даних, необхідних для відновлення сервісу:

• Файлів застосунків і завантаженого вмісту.
• Баз даних із використанням процедур резервного копіювання, що забезпечують узгодженість даних застосунку.
• Конфігураційних файлів операційної системи та застосунків.
• Маніфестів розгортання та конфігурації інфраструктури.
• Сертифікатів і необхідної інформації для відновлення за умови безпечного зберігання.
• Важливої документації та інструкцій із відновлення.

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

Перевіряйте процедури відновлення

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

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

14. Моніторте активність і продуктивність сервера

Моніторинг забезпечує видимість стану сервера та допомагає виявляти проблеми безпеки до того, як вони призведуть до тривалого простою. Ефективна система моніторингу відстежує як інфраструктурні показники, так і поведінку застосунків.

Щонайменше слід відстежувати:

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

У Linux наведені команди дають змогу отримати базове уявлення про стан системи:

uptime
free -h
df -h
systemctl --failed
ss -tulpn
journalctl -p err -b

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

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

15. Захистіть VPS від DDoS-атак

Розподілені атаки типу «відмова в обслуговуванні» (DDoS) спрямовані на перевантаження мережевої пропускної здатності або ресурсів застосунку шкідливим трафіком. Міжмережевий екран на рівні хоста може блокувати частину небажаних з’єднань, але не здатен самостійно поглинути трафік, який уже повністю займає мережевий канал сервера.

Обирайте заходи захисту з урахуванням типу робочого навантаження та потенційного масштабу атаки:

• Фільтрація на мережевому рівні: використовуйте фільтрацію з боку провайдера, щоб блокувати небажаний трафік до його надходження на VPS.
• Зворотні проксі та CDN: спрямовуйте підтримуваний вебтрафік через сервіс, який забезпечує фільтрацію, кешування та захист на рівні застосунків.
• Обмеження частоти запитів: обмежуйте повторні запити до кінцевих точок автентифікації та ресурсомістких операцій застосунку.
• Контроль ресурсів: налаштовуйте розумні обмеження кількості з’єднань, часу очікування запитів і кількості робочих процесів застосунку.
• Моніторинг: створюйте сповіщення про незвичний обсяг трафіку, частоту з’єднань, затримки та вичерпання ресурсів.
• План реагування: документуйте порядок звернення до хостинг-провайдера та ввімкнення додаткових заходів захисту під час атаки.

Атаки на рівні застосунків можуть виглядати як легітимний трафік, тому для їх нейтралізації недостатньо блокувати окремі IP-адреси. Уникайте надто суворих обмежень, які можуть позбавити доступу законних користувачів.

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

16. Автоматизуйте обслуговування безпеки

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

Розгляньте можливість автоматизації таких процесів:

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

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

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

17. Чекліст безпеки VPS

Використовуйте цей список під час посилення захисту нового VPS або аудиту вже наявного сервера.

Операційна система й облікові записи

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

Віддалений доступ і мережа

• Налаштовано автентифікацію за SSH-ключами або відповідний безпечний альтернативний спосіб.
• Вимкнено прямий вхід root і непотрібний віддалений доступ за паролем після пер