Linux-сервери найчастіше зламують не через екзотичні вразливості нульового дня, а через п’ять звичайних слабких місць: внутрішні сервіси, доступні з інтернету, застаріле програмне забезпечення, стандартні налаштування вебсервера, надто широкі права доступу до файлів і відсутність контролю за змінами файлів та журналами. Нижче для кожної дірки є спосіб перевірки, чекліст із командами, порівняння інструментів захисту і налаштування SSH з офіційної документації.
Ця стаття про VPS або виділений сервер із root-доступом. На віртуальному хостингу root-доступу у вас немає: операційною системою і вебсервером керує провайдер, а ваша зона відповідальності: сам сайт, CMS, плагіни, паролі та права на ваші файли. Якщо вам потрібна не теорія п’яти дірок, а покрокова перевірка конкретного сайту з реальним виводом команд, скористайтеся нашим аудитом безпеки сайту за годину.
Чому «базова безпека» лише створює ілюзію захисту
Коли ви орендуєте VPS або виділений сервер, зазвичай отримуєте голу систему: Ubuntu, Debian, AlmaLinux чи інший дистрибутив. Далі багато хто відкриває інструкцію з інтернету і робить стандартний набір:
- Змінює порт SSH з 22 на менш очевидний
- Забороняє вхід під root
- Встановлює UFW або iptables
- Випускає SSL-сертифікат Let’s Encrypt
- Вмикає автоматичні оновлення
Це розумні кроки, але вони замикають лише вхідні двері. За даними Verizon Data Breach Investigations Report 2024, ненавмисний людський чинник (помилка або соціальна інженерія) був присутній у 68% витоків, а використання вразливостей як первинного способу проникнення порівняно з попереднім роком зросло майже втричі і досягло 14% усіх витоків. Саме на це спрямований чекліст нижче: на помилки конфігурації і неоновлене програмне забезпечення.
П’ять вразливостей, які можуть бути на вашому сервері просто зараз
Ці дірки беруться не з екзотичного переліку атак. Вони виникають зі звичайних рішень: «лише для швидкого тесту», «потім приберу», «стандартних налаштувань вистачить».
- Відкриті порти внутрішніх сервісів. Memcached на порту 11211, Redis на 6379, MongoDB на 27017, відкриті «тимчасово» для тестів. Документація Redis прямо пише, що Redis розрахований на довірених клієнтів у довіреному середовищі і що зловмисник може стерти всі дані однією командою FLUSHALL. Новіші версії обережніші: у Redis з версії 3.2 є захищений режим, MongoDB за замовчуванням слухає тільки localhost, а в Memcached UDP вимкнено за замовчуванням із версії 1.5.6, бо його використовували для атак із підсиленням. Небезпека починається, коли хтось вимикає ці налаштування «для тесту».
- Застарілі версії PHP, Apache і Nginx з відомими CVE. Операційна система оновлена, але поруч із php8.2 досі працює php7.4-fpm «про всяк випадок». Підтримка PHP 7.4 завершилася 28 листопада 2022 року, виправлень безпеки він не отримує, а підтримка безпеки PHP 8.2 закінчується 31 грудня 2026 року.
- Стандартна конфігурація вебсервера. У Nginx параметр server_tokens увімкнено за замовчуванням, тож версія видна в заголовку Server і на сторінках помилок. Додайте autoindex on і перелік вмісту каталогу /uploads з повним доступом, і на вашому паркані з’являється табличка «ключі тут».
- Неправильні права доступу до файлів і каталогів. chmod 777 на /var/www: класика. Вебсервер може писати будь-куди, а зловмисник завантажує PHP-шелл через звичайну форму завантаження. Документація WordPress однозначна: жодному каталогу не можна давати 777. Як правильно виставити права доступу до файлів на хостингу, ми розібрали окремо.
- Немає контролю цілісності файлів. Зловмисник змінює один рядок у wp-config.php або підміняє .htaccess, і цього тижнями ніхто не помічає. Без AIDE, Tripwire чи хоча б inotify ви працюєте наосліп.
Безпека: це процес, а не разова дія. Сервер не налаштовують один раз назавжди: оновлення, перевірки і перегляд журналів входять у регулярне обслуговування.
Порівняння інструментів безпеки: що вони роблять і чого не роблять
Не кожен інструмент захищає від того, на що на нього розраховують. Таблиця підсумовує, що роблять поширені рішення згідно з їхньою документацією і де їхні межі. Це не наш власний тест ефективності.
| Інструмент | Що робить | Зусилля | Обмеження |
|---|---|---|---|
| fail2ban | Блокує IP після повторних невдалих входів за шаблонами в журналах | Низькі | Працює по окремих IP, мало допомагає проти розподілених атак із багатьох адрес |
| CrowdSec | Виявляє атаки в журналах, обмінюється між користувачами списками шкідливих IP | Середні | Реагує на поведінку, вразливостей не закриває |
| OSSEC / Wazuh | HIDS: аналіз журналів, контроль файлів, виявлення руткітів | Високі | Потребує налаштування й доводки, інакше багато хибних спрацювань |
| ModSecurity + OWASP CRS | WAF для Apache/Nginx | Середні | Хибні спрацювання без налаштування; підтримку Trustwave припинено 1 липня 2024 року, проєкт тепер підтримує OWASP |
| Lynis | Аудит безпеки системи з рекомендаціями | Низькі | Лише діагностика, захисту не дає |
| AppArmor / SELinux | Мандатний контроль доступу | Високі | Профілі й політики треба підтримувати; вимкнення «щоб запрацювало» прибирає захист |
Важливо: сам лише fail2ban захищає тільки від найпростіших атак. Навіть у README проєкту сказано, що fail2ban зменшує частоту невдалих спроб, але не може прибрати ризик слабкої автентифікації, і там радять ключі або двофакторний вхід. Які додаткові інструменти потрібні, залежить від того, що працює на сервері: WAF для вебзастосунків, HIDS на кшталт Wazuh або AIDE для цілісності файлів і журналів. Детальніше про різницю між ними в нашому порівнянні Fail2Ban, ModSecurity і CSF.
Практичний чекліст: шість кроків на сьогодні
Без теорії: ці кроки можна виконати вже сьогодні, навіть без двадцяти років досвіду системного адміністратора. Кожен крок зачиняє одне відчинене вікно.
- Проскануйте порти. Запустіть
nmap -sV your_server_ipіз зовнішньої машини. Усе, чого ви не впізнаєте, одразу закрийте у фаєрволі. - Перевірте версії встановлених програм.
apt list --installed | grep phpпокаже, які версії PHP ще встановлені. Старі версії видаліть, а не просто вимкніть. - Сховайте версію сервера. У Nginx:
server_tokens off;В Apache:ServerTokens ProdіServerSignature Off. З ServerTokens Prod Apache повідомляє лише «Apache», без версії. - Встановіть Lynis і запустіть аудит. Одна команда:
lynis audit system. Ви отримаєте попередження і поради, а журнал за замовчуванням пишеться в /var/log/lynis.log (документація Lynis). - Налаштуйте сповіщення про зміни критичних файлів. Мінімум: inotifywait на /etc, /var/www і конфігураційні файли. Приклад є нижче.
- Увімкніть автоматичні оновлення безпеки. В Ubuntu:
dpkg-reconfigure unattended-upgrades(згідно з документацією Ubuntu, за замовчуванням щодня встановлюються лише оновлення безпеки). У сімействі RHEL (AlmaLinux, Rocky Linux, CentOS Stream):dnf-automaticз таймером dnf-automatic-install.timer, як описано в документації Red Hat. Від вразливостей нульового дня це не врятує, але закриває більшість відомих.
За нашою оцінкою, ці шість кроків забирають приблизно 15-40 хвилин залежно від досвіду. Вони перекривають значну частину типових шляхів атаки на Linux-сервери.
На свіжому VPS з Ubuntu 24.04 ці основи зручно пройти по порядку за нашим перевіреним чеклістом початкового налаштування: користувач із sudo, SSH тільки за ключами, ufw, fail2ban, автоматичні оновлення безпеки і swap.
| Завдання | Команда або налаштування |
|---|---|
| Сканування портів | nmap -sV your_server_ip |
| Перевірка версій PHP | apt list --installed | grep php |
| Приховати версію Nginx | server_tokens off; |
| Приховати версію Apache | ServerTokens Prod, ServerSignature Off |
| Аудит безпеки | lynis audit system |
| Автооновлення (Ubuntu) | dpkg-reconfigure unattended-upgrades |
| Автооновлення (сімейство RHEL) | dnf-automatic |
Готові налаштування: SSH, порти, права, зміни файлів
Команди і рядки конфігурації нижче взято з офіційної документації кожного проєкту. Спершу спробуйте їх на тестовому сервері, а під час змін SSH завжди тримайте відкритою другу сесію.
SSH: вимкнути вхід під root і паролі
Згідно з документацією sshd_config, PermitRootLogin за замовчуванням має значення prohibit-password, а PasswordAuthentication: yes. Щойно ви можете підключитися по SSH із ключем, вимкніть паролі:
# /etc/ssh/sshd_config.d/10-hardening.conf
PermitRootLogin no
PasswordAuthentication noДля кожного параметра діє перше прочитане значення, а в Ubuntu файли з sshd_config.d підключаються на початку основної конфігурації. Тому файл cloud-init з PasswordAuthentication yes може перекрити ваше налаштування. Перевірте синтаксис і фактично чинні значення, потім перезавантажте службу:
sudo sshd -t
sudo sshd -T | grep -Ei 'permitrootlogin|passwordauthentication'
sudo systemctl reload sshУ Debian і Ubuntu служба називається ssh, у сімействі RHEL: sshd. Закривайте поточну сесію лише після того, як вхід спрацював із другого термінала.
fail2ban для SSH
Власні налаштування пишіть у jail.local, а не в jail.conf, який перезаписується під час оновлень:
# /etc/fail2ban/jail.local
[sshd]
enabled = true
maxretry = 5
bantime = 1hsudo systemctl restart fail2ban
sudo fail2ban-client status sshdСтатус покаже, скільки невдалих спроб виявлено і які IP заблоковано. Не заблокуйте самого себе: свою статичну IP-адресу можна виключити через ignoreip.
Знайти відкриті порти і закрити внутрішні сервіси
Спершу подивіться, які сервіси на яких адресах слухають. Усе, що висить на 0.0.0.0 або [::], доступне ззовні, якщо його не блокує фаєрвол:
sudo ss -tulpnRedis, Memcached і бази даних мають слухати тільки localhost, якщо вони не потрібні іншим серверам. Для Redis документація радить:
# /etc/redis/redis.conf
bind 127.0.0.1
protected-mode yesПотім фаєрвол: дозвольте SSH до того, як увімкнете UFW, інакше заблокуєте собі доступ.
sudo ufw allow OpenSSH
sudo ufw enable
sudo ufw status verboseПрава доступу до файлів сайту
Документація WordPress рекомендує 755 або 750 для каталогів, 644 або 640 для файлів і 440 або 400 для wp-config.php. Замініть example.com на свій каталог:
sudo find /var/www/example.com -type d -exec chmod 755 {} \;
sudo find /var/www/example.com -type f -exec chmod 644 {} \;
sudo chmod 440 /var/www/example.com/wp-config.phpЗначення 440 для wp-config.php передбачає, що PHP працює від імені власника файлів, інакше WordPress не зможе його прочитати. Після зміни перевірте сайт.
Стежити за змінами критичних файлів
inotifywait з пакета inotify-tools повідомляє про кожну зміну в реальному часі. Для сповіщень передайте його вивід у короткий скрипт, який надсилає лист або повідомлення:
sudo apt install inotify-tools
sudo inotifywait -m -r -e modify,create,delete,move /etc /var/wwwЗа дуже великої кількості файлів можна впертися в ліміт fs.inotify.max_user_watches. Для постійної перевірки цілісності за контрольними сумами краще підходять AIDE або Wazuh.
Помилка, якої припускаються навіть досвідчені адміністратори
Що спільного між молодшим розробником і адміністратором із десятирічним стажем? Обидва нехтують журналами. Журнали: це камери спостереження вашого сервера, але яка з камер користь, якщо записи ніхто не переглядає?
auth.log, syslog, access.log, error.log і журнали бази даних лежать у /var/log, їх ротує logrotate. Якщо строк зберігання короткий, то на момент виявлення інциденту журналів за потрібний період часто вже немає.
Централізований збір журналів: не розкіш, а необхідність. Мінімум: надсилати журнали на окремий сервер через rsyslog або аналізувати їх у Loki + Grafana. Хто отримав root, часто першим ділом намагається почистити журнали. Якщо копія лежить на іншій машині, слід лишається.
Із моніторингом у реальному часі, наприклад через Wazuh, аномалія на кшталт незвичного нічного навантаження одразу викликає сповіщення. Без моніторингу її помічають, лише коли хтось випадково погляне на сервер.
Коли стандартного захисту замало: ознаки, що потрібен фахівець
Не все можна зробити самотужки, і це нормально. У таких випадках варто залучити фахівця з безпеки серверів:
- Ваш сервер обробляє платіжні або персональні дані (GDPR і PCI DSS)
- Вас уже зламували, і ви не впевнені, що знайшли все, що залишив зловмисник
- На сервері працює понад п’ять різних сервісів, які взаємодіють між собою
- Ви не можете пояснити, навіщо потрібен кожен відкритий порт на сервері
Тест на проникнення або аудит безпеки оцінюють індивідуально. Порівняйте ціну з тим, скільки коштуватимуть вашому бізнесу простій і витік даних, разом із можливими штрафами за законами про захист персональних даних.
Безпека сервера: не разова дія і не галочка в списку, а регулярна гігієна. Насамкінець одне просте запитання: коли ви востаннє перевіряли, які порти відкриті на вашому сервері просто зараз? Можливо, варто зробити це раніше, ніж хтось інший.
Як ми перевіряли: для цієї статті ми не проводили власного тесту на проникнення і не запускали команди на нашому тестовому сервері. Значення за замовчуванням і налаштування взято з офіційної документації: OpenSSH sshd_config, nginx, Apache, Redis, MongoDB, Memcached 1.5.6, підтримувані версії PHP, права доступу у WordPress, fail2ban, Ubuntu, Red Hat, Lynis, OWASP ModSecurity і Trustwave; цифри взято з Verizon DBIR 2024. Перевірено 30 жовтня 2026 року. Час на чекліст: наша оцінка.
FAQ
Чи достатньо змінити порт SSH?
Ні. Інший порт зменшує кількість автоматичних спроб входу в журналах, але сканування портів його однаково знаходить. Важливіші SSH-ключі замість паролів і заборона входу під root.
Чи захищає fail2ban від будь-якого перебору паролів?
Ні. fail2ban блокує окремі IP, а атаки з багатьох адрес це обходять. Згідно з README проєкту, ризику слабких паролів він не усуває.
Як часто запускати оновлення і аудит?
Оновлення безпеки краще встановлювати автоматично і щодня, як за замовчуванням робить unattended-upgrades в Ubuntu. Аудит Lynis запускайте після великих змін і за розкладом, наприклад щомісяця. Для перевірки самого сайту (відкриті файли, плагіни, заголовки) підійде окремий аудит, посилання на який є на початку статті.
Чи треба робити це самому на віртуальному хостингу?
Ні, налаштуваннями сервера там керує провайдер. Ваші завдання: оновлення CMS і плагінів, надійні паролі і правильні права на ваші файли.
