5 дірок у вашому сервері, через які хакери заходять як до себе додому

Уявіть: ви залишаєте квартиру, зачиняєте двері на три замки, вмикаєте сигналізацію - а вікно на кухні стоїть навстіж. Саме так виглядає типовий сервер після «базового налаштування». Адміністратор поставив firewall, змінив SSH-порт, навіть fail2ban налаштував - і спокійно пішов пити каву. А тим часом зловмисники вже сканують його /tmp, знаходять застарілий PHP-модуль і заходять всередину за 4 хвилини. Це не страшилка з підручника - це реальний кейс, який я розбирав у грудні 2024 року на одному з українських інтернет-магазинів. Сьогодні ми поговоримо про ті самі вразливості, про які чомусь не пишуть у стандартних чек-листах.

Чому «базова безпека» - це ілюзія захисту

Коли ви орендуєте VPS чи виділений сервер, провайдер зазвичай дає вам голу систему. Ubuntu 22.04, CentOS Stream, Debian 12 - вибирайте на смак. Далі ви за гайдом з інтернету робите стандартний набір:

• Змінюєте порт SSH з 22 на щось менш очевидне
• Вимикаєте логін під root
• Ставите UFW або iptables
• Генеруєте SSL-сертифікат через Let's Encrypt
• Вмикаєте автоматичні оновлення

І все. Здавалося б, достатньо? Ні. За даними Verizon Data Breach Investigations Report 2024, 68% успішних атак на сервери використовують не брутфорс паролів, а неправильну конфігурацію. Тобто двері замкнені, а вікна - настіж.

П'ять вразливостей, які прямо зараз можуть бути на вашому сервері

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

1. Відкриті порти сервісів, які «тимчасово» підняли для тесту. Memcached на порту 11211 без аутентифікації, Redis на 6379, MongoDB на 27017. «Я потім закрию» - знайома фраза? За статистикою Shodan, понад 43 000 серверів у світі мають відкритий Redis без пароля прямо зараз.
2. Застарілі версії PHP, Apache, Nginx з відомими CVE. Ви оновили ОС, але забули про php7.4-fpm, який стоїть поруч з php8.2 «на всяк випадок». А в ньому - критична RCE-вразливість.
3. Дефолтні конфігурації веб-сервера. Server tokens: on. Autoindex: on. Directory listing каталогу /uploads з повним доступом. Це як повісити табличку «тут лежать ключі» на парканчику.
4. Неправильні права на файли і каталоги. chmod 777 на /var/www - класика жанру. Веб-сервер може записувати файли куди завгодно, і зловмисник через проста upload-форму заливає PHP-шелл.
5. Відсутність моніторингу цілісності файлів. Хакер змінив один рядок у wp-config.php або підмінив .htaccess - і ніхто не помітив тижнями. Без AIDE, Tripwire або хоча б inotify ви сліпі.

«Безпека - це не стан, а процес. Ви не можете одного разу налаштувати сервер і забути. Це як чистити зуби - потрібно кожен день.» - Брюс Шнаєр, криптограф і експерт з кібербезпеки

Порівняння інструментів захисту: що реально працює

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

Зверніть увагу: fail2ban, який стоїть на 90% серверів, сам по собі захищає лише від найпростіших атак. Це як замок на поштовій скриньці - зупинить цікавого сусіда, але не професійного зломщика. Якщо ви серйозно ставитесь до безпеки, мінімальний набір - це CrowdSec + Wazuh + ModSecurity.

Практичний чек-лист: 20 хвилин, які можуть врятувати ваш бізнес

Давайте без теорії. Ось конкретні кроки, які ви можете зробити прямо сьогодні, навіть якщо ви не сисадмін з двадцятирічним стажем. Кожен крок - це закрите вікно у вашій «квартирі».

1. Проскануйте свої порти. Запустіть nmap -sV your_server_ip із зовнішньої машини. Все, що ви не впізнаєте - закрийте через firewall негайно.
2. Перевірте версії всього встановленого ПЗ. Команда apt list --installed | grep php покаже вам кілька цікавих сюрпризів. Старе - видаляйте, не вимикайте.
3. Приберіть server tokens. У Nginx: server_tokens off; У Apache: ServerTokens Prod та ServerSignature Off. Навіщо хакеру знати вашу версію веб-сервера?
4. Поставте Lynis і запустіть аудит. Одна команда: lynis audit system. Він видасть список рекомендацій з пріоритетами. Зазвичай перший запуск показує 30-50 проблем.
5. Налаштуйте сповіщення про зміну критичних файлів. Хоча б через inotifywait на /etc, /var/www і конфігах. Це 10 рядків bash-скрипта, а ефект колосальний.
6. Увімкніть автоматичне оновлення безпекових пакетів. На Ubuntu: dpkg-reconfigure unattended-upgrades. На CentOS: dnf automatic. Нульових днів це не зупинить, але 95% відомих вразливостей закриє.

Ці шість кроків займуть від 15 до 40 хвилин залежно від вашого досвіду. Але вони закривають приблизно 70% типових векторів атак на Linux-сервери.

Помилка, яку роблять навіть досвідчені адміни

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

Типовий сервер генерує від 10 до 500 МБ логів на добу. Auth.log, syslog, access.log, error.log, журнали бази даних - все це лежить у /var/log і тихо ротується logrotate. А потім, коли щось трапляється, адмін із жахом розуміє: логи за потрібний період вже стерті, бо ротація налаштована на 7 днів.

Централізоване збирання логів - це не розкіш, а необхідність. Мінімальне рішення - відправляти логи на окремий сервер через rsyslog або використовувати Loki + Grafana для візуалізації. Якщо зловмисник отримає root на вашому сервері, перше, що він зробить - почистить логи. А якщо копія логів лежить на іншій машині, у вас залишається слід.

Ось мій улюблений приклад. У вересні 2024 року один з моїх клієнтів помітив аномальне навантаження на сервері о 3:00 ночі. Завдяки Wazuh, який моніторив логи в реальному часі, ми за 12 хвилин побачили: хтось через вразливість у плагіні WordPress завантажив криптомайнер. Без моніторингу це помітили б через місяць - коли прийшов би рахунок за трафік.

Коли стандартного захисту замало: ознаки того, що вам потрібен спеціаліст

Не все можна зробити самостійно. І це нормально. Ви ж не ремонтуєте зуби самотужки тільки тому, що подивились відео на YouTube? Ось ситуації, коли варто залучити професіонала з серверної безпеки:

• Ваш сервер обробляє платіжні дані або персональну інформацію (привіт, GDPR і PCI DSS)
• Ви вже були зламані і не впевнені, що знайшли всі «подарунки» від хакера
• На сервері більше 5 різних сервісів, які взаємодіють між собою
• Ви не можете пояснити, що робить кожен відкритий порт на вашій машині

Пентест одного сервера коштує від 500 до 3000 доларів залежно від глибини аналізу. Здається дорого? А тепер порахуйте, скільки коштує добу простою інтернет-магазину з оборотом 50 000 грн на день. Плюс репутаційні втрати. Плюс можливі штрафи за витік даних.

Безпека сервера - це не одноразова дія і не галочка у списку. Це щоденна гігієна, як миття рук. Ви можете ігнорувати її місяцями - і нічого не станеться. А можете прокинутись одного ранку і побачити порожню базу даних з файлом README.txt: «Перекажіть 0.5 BTC...»

Тож ось вам провокаційне запитання наостанок: коли ви востаннє перевіряли, які порти відкриті на вашому сервері прямо зараз? Може, варто зробити це до того, як перевірить хтось інший?