Серверні логи як детектив: читаємо сліди зловмисників до того, як вони щось зламають

Уявіть: ви приходите вранці на роботу, відкриваєте сайт - а там порожнеча. Або ще гірше - чужий контент. Серце падає, руки тремтять, ви гарячково шукаєте бекап. Знайома картина? А тепер уявіть інший сценарій: ви бачите підозрілу активність за три дні до злому, блокуєте її одним рядком у конфігурації і спокійно п'єте ранкову каву. Різниця між цими двома сценаріями - вміння читати серверні логи. Не просто дивитися на нескінченні рядки тексту, а розуміти, що за ними стоїть.

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

Що серверні логи розповідають за вашою спиною

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

Основні типи логів, які вам потрібно знати:

• Access log - записує кожен HTTP-запит до сервера: IP-адресу, час, URL, статус відповіді
• Error log - фіксує помилки: від банальних 404 до критичних збоїв PHP
• Auth log (він же secure log) - спроби авторизації через SSH, FTP, панелі керування
• Mail log - відправка пошти з сервера, часто перший сигнал про зламаний скрипт

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

Анатомія підозрілого запиту: що шукати в access log

Відкрийте свій access.log прямо зараз. Серйозно, відкрийте. Ось що повинно вас насторожити:

1. Масові запити до неіснуючих сторінок - якщо бачите сотні 404-х за хвилину з однієї IP, хтось сканує ваш сайт на вразливості. Типовий патерн: запити до /wp-admin/, /phpmyadmin/, /administrator/ з IP, який ніколи раніше не з'являвся.
2. Запити з підозрілими параметрами - рядки на кшталт union+select, ../../etc/passwd, <script> у URL - це класичні SQL-ін'єкції та XSS-атаки. Навіть невдалі спроби - тривожний знак.
3. Аномальна частота запитів - людина не робить 200 запитів за секунду. Бот - робить. Якщо бачите таке - або DDoS, або брутфорс.
4. POST-запити до файлів, які не приймають дані - коли хтось відправляє POST до якогось випадкового .php файлу в глибині вашого theme - це майже напевно спроба використати завантажений раніше бекдор.
5. User-Agent дивацтва - порожній User-Agent або щось на кшталт sqlmap/1.4, Nikto, dirbuster - це інструменти для зламу, і їхні автори навіть не намагаються це приховати.

«Більшість успішних зламів можна було б запобігти, якби адміністратор хоча б раз на тиждень переглядав auth.log. 90% атак - не геніальні хакерські операції, а банальний перебір паролів.» - Marcus Hutchins, дослідник кібербезпеки

Порівняння інструментів для аналізу логів

Читати логи вручну на сервері з тисячами відвідувачів - це як шукати конкретну піщинку на пляжі. Потрібні інструменти. Ось що реально працює у 2025 році:

Мій особистий фаворит для невеликих проєктів - зв'язка Fail2Ban + GoAccess. Fail2Ban автоматично банить IP після заданої кількості невдалих спроб входу, а GoAccess дає красиву панель з трафіком у реальному часі. Встановлення займає 10-15 хвилин, а ефект - як різниця між відчиненими і зачиненими дверима.

Fail2Ban за 10 хвилин: мінімальний захист, який рятує

Якщо ви прочитаєте тільки одну секцію з цієї статті - нехай буде ця. Fail2Ban - найпростіший спосіб скоротити кількість атак на 80-95%. Не перебільшую.

Що він робить? Моніторить логи в реальному часі, знаходить підозрілі патерни (невдалий логін, сканування портів, спроби SQL-ін'єкцій) і додає IP зловмисника у firewall. Автоматично. Без вашої участі.

Мінімальна конфігурація для захисту SSH:

• Встановіть пакет: apt install fail2ban (Debian/Ubuntu) або yum install fail2ban (CentOS)
• Створіть файл /etc/fail2ban/jail.local з параметрами: maxretry = 3, bantime = 3600, findtime = 600
• Увімкніть jail для sshd та перезапустіть сервіс
• Перевірте статус: fail2ban-client status sshd - побачите кількість заблокованих IP

За перший тиждень після налаштування на типовому VPS ви побачите від 50 до 500 заблокованих IP. Це не жарт. Стільки ботів щодня стукає у ваші двері, а ви навіть не знали.

Три сценарії з реального життя: як логи врятували сервер

Сценарій 1: тихий бекдор. Власник інтернет-магазину помітив у access.log регулярні POST-запити до файлу wp-content/uploads/2024/cache-widget.php. Назва виглядала невинно, але в uploads не повинно бути виконуваних PHP-файлів. Виявилося - бекдор, через який зловмисник вже місяць мав повний доступ до бази даних клієнтів.

Сценарій 2: поштовий спам. В mail.log раптово з'явились тисячі відправлених листів за ніч. Джерело - контактна форма без CAPTCHA. Хакер використовував її для розсилки фішингу. Ще день - і IP сервера потрапив би у чорний список, а всі легітимні листи перестали б доходити.

Сценарій 3: брутфорс адмінки. Auth.log показав 12 000 спроб входу в cPanel за добу з різних IP. Без Fail2Ban одна з комбінацій рано чи пізно спрацювала б - пароль адміна був 8-символьний. Після встановлення Fail2Ban + зміни пароля на 20-символьний з 2FA - атаки стали безглуздими.

Автоматизація: щоб не читати логи щоранку

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

1. Налаштуйте logwatch або logcheck - ці утиліти щоденно надсилають вам стислий звіт по email. 2 хвилини на прочитання замість 2 годин ручного аналізу.
2. Створіть cron-завдання для критичних перевірок - простий bash-скрипт, який шукає ключові слова (union select, /etc/passwd, POST до uploads) і відправляє алерт у Telegram.
3. Використовуйте ротацію логів - logrotate стискає старі логи і видаляє зовсім древні. Інакше вони з'їдять весь диск, і сервер ляже не від хакера, а від банальної нестачі місця.
4. Централізуйте логи - якщо у вас більше одного сервера, відправляйте логи в єдине сховище (Graylog, ELK). Шукати інцидент по трьох серверах окремо - це кошмар.

Один мій знайомий адмін написав Telegram-бота, який кожну годину повідомляє кількість заблокованих IP і нові 403/401 помилки. Каже, це як фітнес-трекер для сервера - бачиш пульс системи, не відкриваючи консоль.

Чекліст серверної безпеки: мінімум, який зобов'язаний виконати кожен

Ось те, що ви можете зробити сьогодні - прямо після прочитання цієї статті:

• Перевірте, чи увімкнено логування на вашому сервері (access, error, auth) - буває, що воно вимкнене за замовчуванням
• Встановіть Fail2Ban і налаштуйте jail для SSH та веб-панелі
• Змініть SSH-порт зі стандартного 22 на будь-який інший (наприклад, 2222 або 49152) - це відсіче 90% автоматичних ботів
• Вимкніть вхід під root через SSH і використовуйте ключі замість паролів
• Налаштуйте щоденний email-звіт через logwatch

Запам'ятайте головне правило: безпека - це не продукт, який купуєш один раз. Це процес. Щоденний, нудний, рутинний процес. Але саме ця рутина стоїть між вашим сайтом і тим хлопцем у капюшоні, який зараз сканує ваш сервер. Прямо зараз. Не вірите? Відкрийте auth.log і подивіться самі.

А тепер чесно: коли ви востаннє заглядали у свої серверні логи?