Серверні логи як детектор вторгнень: що ваш сервер кричить вам щодня, а ви не чуєте
Уявіть ситуацію: ви спокійно п'єте ранкову каву, перевіряєте пошту, а в цей момент хтось методично перебирає паролі до вашого SSH. 300 спроб за хвилину. Ваш сервер фіксує кожну з них - старанно, посекундно, у файлі, який ви не відкривали з моменту налаштування. Серверні логи - це дзеркало заднього виду для вашої інфраструктури. Проблема в тому, що більшість адміністраторів дивляться в це дзеркало лише після аварії. А потрібно - до неї.
Ця стаття не про теорію. Вона про те, як навчитися читати те, що сервер вам уже давно говорить, і перетворити нудні текстові файли на систему раннього попередження, яка працює 24/7 без жодної додаткової підписки.
Чому 90% зламів починаються з рядка, який ніхто не прочитав
За даними звіту Verizon Data Breach Investigations Report 2024, у 83% випадків сліди компрометації були присутні в логах задовго до того, як інцидент виявляли. Не дні - тижні. Іноді місяці. Злочинець вже ходив по вашому серверу, а ви навіть не підозрювали.
Справа в тому, що логи - це не просто файли для аудиту "після факту". Це потік даних у реальному часі, який може розповісти про:
- Brute-force атаки - сотні невдалих спроб авторизації з однієї IP або розподілених ботнетів
- Сканування вразливостей - запити до неіснуючих шляхів типу /wp-admin, /phpmyadmin, /.env
- Ескалацію привілеїв - незвичні sudo-команди або створення нових користувачів
- Витік даних - аномально великі відповіді сервера на звичайні запити
- Бекдори - з'єднання на нестандартних портах у нічний час
Один знайомий DevOps-інженер з Варшави розповідав мені, як знайшов зламаний сервер клієнта тільки тому, що випадково помітив у auth.log рядок з успішним входом root о 3:47 ночі з IP-адреси в Індонезії. Ніякий антивірус цього не засік. А лог - засік.
Анатомія серверного логу: що де шукати і як не заблукати
Якщо ви працюєте з Linux-сервером (а це переважна більшість хостингових середовищ), ось головні файли, які треба моніторити щодня. Не раз на місяць. Щодня.
| Файл логу | Що фіксує | На що звертати увагу |
|---|---|---|
| /var/log/auth.log (або /var/log/secure) | Авторизація, SSH, sudo | Failed password, Accepted publickey з невідомих IP |
| /var/log/syslog | Системні події | Несподівані перезапуски сервісів, OOM-killer |
| /var/log/apache2/access.log (або nginx) | HTTP-запити | Масові 404, SQL-ін'єкції в URL, підозрілі User-Agent |
| /var/log/apache2/error.log | Помилки веб-сервера | PHP-помилки, permission denied, segfault |
| /var/log/fail2ban.log | Заблоковані IP | Частота банів, повторні атаки з тих самих підмереж |
| /var/log/kern.log | Ядро системи | Мережеві аномалії, hardware-помилки |
Головне правило: якщо ви не знаєте, де ваші логи - ви не знаєте, чи ваш сервер у безпеці. Це як мати камери спостереження в магазині, але ніколи не дивитися записи.
Практичний мінімум: 5 команд, які покажуть загрози прямо зараз
Не треба встановлювати SIEM-систему за $50 000 на рік, щоб почати. Достатньо терміналу і базових інструментів, які вже є на вашому сервері.
- Побачити всі невдалі SSH-спроби за останню добу:
grep "Failed password" /var/log/auth.log | tail -50- якщо бачите більше 100 рядків за годину, це brute-force - Знайти IP-адреси, що атакують найчастіше:
grep "Failed password" /var/log/auth.log | awk '{print $(NF-3)}' | sort | uniq -c | sort -rn | head -20 - Виявити підозрілі запити до веб-сервера:
grep -iE "(union|select|drop|script|eval|base64)" /var/log/nginx/access.log- класичні маркери SQL-ін'єкцій та XSS - Перевірити, хто заходив по SSH успішно:
grep "Accepted" /var/log/auth.log | awk '{print $1,$2,$3,$9,$11}'- порівняйте з вашими відомими IP - Відстежити створення нових користувачів:
grep "useradd|adduser" /var/log/auth.log- якщо ви нікого не додавали, це червоний прапор
Витратіть 5 хвилин прямо зараз. Відкрийте термінал і запустіть першу команду. Те, що ви побачите, може вас здивувати - або налякати.
Автоматизація: як перетворити логи на живу систему захисту
Ручне читання логів - це як патрулювання вулиці пішки в місті-мільйоннику. Героїчно, але неефективно. Вам потрібна автоматизація, і ось три рівні, залежно від бюджету та навичок.
Рівень 1: Fail2Ban (безкоштовно, 20 хвилин на налаштування)
Fail2Ban читає логи в реальному часі і автоматично блокує IP-адреси після N невдалих спроб. Мінімальна конфігурація для SSH - буквально 10 рядків. За статистикою, правильно налаштований Fail2Ban зменшує кількість brute-force атак на 95-98%.
Рівень 2: Logwatch + кастомні скрипти (безкоштовно, 1-2 години)
Logwatch щоранку надсилає вам дайджест подій: хто заходив, які помилки виникали, які сервіси перезапускалися. Додайте свій bash-скрипт, який шукає конкретні патерни і відправляє alert у Telegram через бота - і ви маєте бюджетну SIEM-систему.
Рівень 3: ELK Stack або Grafana Loki (безкоштовно, але потребує ресурсів)
Для серйозних проєктів з кількома серверами - централізований збір логів. Elasticsearch + Logstash + Kibana дають вам дашборди, графіки аномалій, кореляцію подій. Grafana Loki - легша альтернатива, яка їсть менше RAM.
"Логи без аналізу - це як чорна скринька літака, яку ніхто ніколи не відкриє. Вони мають цінність лише тоді, коли хтось їх читає - людина або машина." - Брюс Шнаєр, криптограф та експерт з кібербезпеки
Типові помилки, які перетворюють логи на макулатуру
Навіть досвідчені адміністратори допускають помилки, що знецінюють всю систему логування. Ось що я бачу найчастіше за 15 років роботи з серверною інфраструктурою.
Помилка перша: логи зберігаються на тому ж сервері. Якщо зловмисник отримав root-доступ, перше, що він зробить - зітре логи. Ваші докази зникнуть разом з ними. Рішення? Відправляйте логи на зовнішній syslog-сервер або в хмарне сховище. Rsyslog з TLS-шифруванням налаштовується за пів години.
Помилка друга: logrotate видаляє старі логи занадто рано. Дефолтна конфігурація часто зберігає лише 4 тижні. А середній час виявлення компрометації - 204 дні (IBM Cost of a Data Breach Report 2024). Бачите проблему? Збільшіть retention мінімум до 90 днів, а краще - до 180.
Помилка третя: ігнорування логів додатків. Всі дивляться auth.log, але забувають про логи WordPress, Laravel, Node.js. А саме там часто фіксуються спроби експлуатації вразливостей конкретного фреймворку.
Помилка четверта: відсутність синхронізації часу. NTP - це не розкіш. Якщо час на сервері відрізняється від реального на 3 хвилини, кореляція подій між різними логами стає неможливою. Одна команда timedatectl set-ntp true - і проблема зникає.
Готовий чекліст безпеки логування: роздрукуйте і повісьте над монітором
Я зібрав мінімальний набір дій, який перетворить ваші логи з мертвого вантажу на робочий інструмент захисту. Це не ідеальна конфігурація - це відправна точка, після якої ви вже не летите всліпу.
- Налаштуйте зовнішню доставку логів (rsyslog, Filebeat або хоча б scp за cron)
- Встановіть і сконфігуруйте Fail2Ban для SSH, HTTP-auth та поштових сервісів
- Збільшіть retention у logrotate до мінімум 90 днів
- Налаштуйте Logwatch або аналогічний інструмент для щоденного дайджесту на email
- Створіть bash-скрипт для пошуку критичних патернів ("root login", "useradd", "COMMAND=/bin/sh")
- Синхронізуйте час через NTP на всіх серверах
- Раз на тиждень вручну переглядайте top-20 IP з невдалими спробами входу
Весь цей список можна реалізувати за один вечір. Без бюджету. Без сторонніх сервісів. І він закриє 80% типових векторів атак, які починаються з того, що ніхто не дивився в логи.
Ваш сервер прямо зараз записує все, що з ним відбувається. Питання тільки одне: ви слухаєте - чи чекаєте, поки хтось інший прочитає ці записи замість вас? Відкрийте термінал. Прямо зараз. П'ять хвилин можуть змінити все.