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

Поширені ознаки компрометації:

• Несанкціоновані зміни контенту (реклама, редиректи, спам-посилання)
• Зниження продуктивності сервера
• Блокування сайту пошуковими системами
• Підозріла активність у журналах доступу
• Неочікувані перезавантаження або збої в роботі сервера
• Незвичайна поведінка користувацьких акаунтів

Аналіз журналів сервера

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

Аналіз доступу до сайту

У першу чергу слід вивчити файли (access.log), які містять інформацію про всі запити до веб-сервера:

192.168.1.100 - - [10/Apr/2025:13:55:36 +0200] "GET /wp-admin/install.php HTTP/1.1" 200 1324 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
45.227.255.34 - - [10/Apr/2025:13:58:42 +0200] "POST /wp-admin/admin-ajax.php HTTP/1.1" 200 5237 "http://example.com/wp-admin/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36"
45.227.255.34 - - [10/Apr/2025:13:59:01 +0200] "GET /wp-content/uploads/backdoor.php HTTP/1.1" 200 0 "-" "Mozilla/5.0"

На що звернути увагу:

• Підозрілі IP-адреси з множинними запитами.
• Спроби доступу до адміністративних розділів (/wp-admin/, /administrator/, /admin/).
• Незвичайні або неіснуючі URL-адреси.
• Запити до файлів з підозрілими розширеннями (.php, .aspx, .jsp).
• Великий обсяг запитів за короткий період часу з однієї IP-адреси.

Аналіз помилок сервера

Файли журналів помилок (error.log) можуть містити цінну інформацію про збої в роботі сервера, які могли бути викликані атакою:

2025/04/10 13:59:15 [error] 31923#31923: *17 FastCGI sent in stderr: "PHP Warning: include(/tmp/backdoor.php): failed to open stream: Permission denied in /var/www/html/index.php on line 23" while reading response header from upstream

Пошук нещодавно змінених файлів

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

1. Пошук змінених файлів за останні дні

Використаємо команду find, щоб дізнатися, які файли були змінені, наприклад, за останні 7 днів:

find ~/www -type f -mtime -7 -ls | sort -k 8,9

• -type f – шукаємо тільки файли
• -mtime -7 – змінені за останні 7 днів
• -ls – показує повну інформацію про файл
• sort -k 8,9 – сортує за датою і часом

Приклад результату:

1234567 12 -rw-r--r-- 1 www-data www-data 2048 Apr 28 03:22 /www/test/wp-content/themes/twentytwentyone/functions.php
1234568  8 -rw-r--r-- 1 www-data www-data  512 Apr 29 02:14 /www/test/.htaccess

2. Отримати точну дату і час зміни файлу

Якщо ви знайшли підозрілий файл — перевірте його детальні метадані:

stat ~/www/test.com.ua/wp-content/themes/twentytwentyone/functions.php

Приклад результату:

Modify: 2025-04-28 03:22:10.000000000 +0300
Change: 2025-04-28 03:22:11.000000000 +0300
Access: 2025-04-29 08:00:02.000000000 +0300

3. Пошук змін у нічний або нетиповий час

Також корисно буде ініціювати пошук у нетиповий час

find ~/www -type f -newermt "2025-04-28 23:00" ! -newermt "2025-04-29 06:00" -ls

• find – Утиліта для пошуку файлів у файловій системі
• ~/www – Каталог, у якому здійснюється пошук (замість ~ можна вказати повний шлях)
• -type f – Обмежує пошук лише файлами (без директорій);
• -newermt “2025-04-28 23:00” – Знайти файли, змінені після вказаного часу (MT = Modification Time)
• -newermt “2025-04-29 06:00” – Виключити файли, змінені після 06:00 (тобто знайти тільки між 23:00–06:00);
• -ls – Виводить детальну інформацію про кожен знайдений файл (як ls -l)

4. Зв’язати змінений файл з HTTP-запитами

Після того як ви виявили точний час зміни підозрілого файлу, варто перевірити access-лог за той самий часовий проміжок, щоб з’ясувати, який запит потенційно викликав зміну.

Пошук у журналі доступу за часовим діапазоном ±1 хвилина від часу зміни:

# Ця команда знайде всі запити, здійснені о 03:22 28 квітня 2025 року з виключенням "шуму" від статичних ресурсів.
grep "\[28/Apr/2025:03:22" ~/logs/*.access.log | grep -v ".js\|.css\|.jpg\|.gif\|.png"

Наступна команда буде корисна для виявлення HTTP-запитів до конкретного файлу:

grep "functions.php" ~/logs/*.access.log

Приклад результату:

45.227.255.34 - - [28/Apr/2025:03:22:11 +0300] "POST /wp-content/themes/twentytwentyone/functions.php HTTP/1.1" 200

Якщо ваші логи архівуються в .gz (наприклад, access.log.1.gz, access.log.2.gz), використовуйте zgrep:

zgrep "functions.php" ~/logs/access.log*.gz

Пошук шкідливого коду у файлах сайту

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

1. Пошук небезпечних функцій у PHP-файлах

Найпоширеніші функції, які використовуються у бекдорах:

• eval()
• base64_decode()
• gzinflate()
• system(), exec(), passthru(), shell_exec()
• assert() – часто використовується як eval-алтернатива

grep -r --include="*.php" -E "eval\(|base64_decode\(|gzinflate\(|system\(|shell_exec\(|assert\("~/www

Приклад результату:

www/test.com.ua/wp-includes/load.php: eval(base64_decode($payload));

2. Пошук довгих обфусцьованих рядків:

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

grep -r --include="*.php" -E "[A-Za-z0-9+/]{200,}"~/www/html

Приклад:

3. Пошук файлів із нетиповими іменами або підозрілими розширеннями:

find ~/www -type f \( -iname "*.php*" -o -iname "*.phtml" \) -size -20k

• -size -20k — часто шкідливі скрипти дуже маленькі, до 20 КБ, але це не обов’язково;
• Пошук по .php — охоплює навіть файли з подвійним розширенням: file.php.jpg;
• .phtml це приклад нетипового/підозрілого розширення.

4. Аналіз .htaccess на приховані редиректи

grep -iE "redirect|RewriteRule" ~/www/test.com.ua/.htaccess

Шукайте:

• Перенаправлення на зовнішні сайти
• Маскування URL
• Обмеження доступу на основі User-Agent

Типові місця розміщення шкідливого коду

• Кореневі директорії веб-сервера.
• Директорії для завантаження файлів (/uploads/, /media/).
• Теми та плагіни CMS.
• Директорії з тимчасовими файлами (/tmp/, /temp/).
• Приховані директорії (імена починаються з .).

Аналіз вразливостей CMS

Якщо ваш сайт використовує систему керування контентом (CMS), таку як WordPress, Joomla або Drupal, ретельна перевірка її компонентів є обов’язковою при підозрі на злам.

Перевірка плагінів та тем

Вразливі або застарілі плагіни — один із найпоширеніших векторів атак.

1. Виведіть список усіх плагінів/тем із зазначенням версій.
2. Порівняйте з відкритими базами CVE та WPScan.io.
3. Скануйте плагіни на наявність змін у коді — порівняйте з офіційною версією.

Аналіз змін, ініційованих плагінами та компонентами CMS

Використовуйте логи CMS і помилки сервера для виявлення підозрілих дій:

# Перевірка журналів помилок на наявність активності підозрілих плагінів
grep -r "plugin_name" ~/logs/*.error.log

# Логи CMS (WordPress debug.log)
grep -r "plugin" ~/www/test.com.ua/wp-content/debug.log

Якщо плагін викликає підозри:

1. Деактивуйте його тимчасово
2. Перевірити вихідний код плагіна на наявність шкідливих функцій (особливо функції eval(), base64_decode() та зовнішні включення).
3. Порівняти код встановленого плагіна з оригінальною версією з офіційного репозиторію.
4. Проаналізувати, які файли були змінені або створені плагіном.

Перевірка прав доступу

Неправильно налаштовані права доступу можуть дозволити зловмиснику завантажувати та виконувати шкідливий код:

find ~/www -type f -name "*.php" -perm -o+w

Наступні команди допоможуть налаштувати потрібні права доступу:

# Для файлів (наприклад, .php, .html, .js тощо)
find ~/www -type f -exec chmod 644 {} \;

# Для директорій
find ~/www -type d -exec chmod 755 {} \;

• права 644:
  • власник – читання + запис
  • група/інші – тільки читання
• права 755:
  • власник – читання + запис + виконання
  • група/інші – читання + виконання

Перевірка бази даних CMS

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

Виконати нижченаведені SQL-запити можна через phpMyAdmin — веб-інтерфейс для керування базою даних, який доступний у панелі керування хостингом:

-- Для WordPress: перевірка активованих плагінів
SELECT option_value FROM wp_options WHERE option_name = 'active_plugins';

-- Перевірка змін у таблиці опцій за останній час (для MySQL)
SELECT * FROM wp_options WHERE option_name LIKE '%plugin%' 
AND option_name NOT LIKE '%active_plugins%' ORDER BY autoload;

-- Перевірка подій, пов'язаних з плагінами (якщо є таблиця логів)
SELECT * FROM wp_logs WHERE action LIKE '%plugin%' ORDER BY timestamp DESC LIMIT 50;

Поширені вектори атак

SQL-ін’єкція – атака, при якій зловмисник впроваджує шкідливий SQL-код у запити до бази даних сайту.

Ознаки:

• Незвичайні запити до бази даних у журналах.
• Дивні параметри в URL-адресах (наприклад, '1'='1').

Приклад:

SELECT * FROM users WHERE '1'='1';

Відкриває доступ до всієї таблиці без авторизації.

XSS (Cross-Site Scripting) дозволяє зловмиснику впровадити шкідливий JavaScript-код на сторінки сайту.

Ознаки:

• Дивні скрипти або iframe-елементи в HTML-коді сторінок.
• Перенаправлення на зовнішні ресурси.

Приклад:

<script>alert('XSS')</script>

Може красти cookie, редиректити користувача, підмінювати інтерфейс.

Вразливості завантаження файлів

Якщо на сайті є форми для завантаження файлів без належної перевірки, зловмисник може завантажити шкідливий скрипт.

Ознаки:

• Невідомі виконувані файли в директоріях для завантажень.
• Записи в журналах про завантаження файлів з підозрілими розширеннями.

Заходи з усунення наслідків зламу

Після виявлення причини зламу необхідно вжити заходів для відновлення безпеки сайту:

1. Видаліть шкідливий код та всі підозрілі файли.
2. Оновіть ПЗ : CMS, плагіни, теми, бібліотеки та серверне програмне забезпечення.
3. Змініть паролі для всіх облікових записів (адміністратори CMS, FTP, бази даних, SSH).
4. Виправте вразливості , які дозволили здійснити злам.
5. Перевірте файли резервних копій на наявність шкідливого коду перед відновленням.

Превентивні заходи захисту

Регулярне оновлення ПЗ

Своєчасне оновлення всіх компонентів веб-сайту – це фундаментальний захід безпеки:

Інструкції щодо оновлення Wordpress можете побачити тут

Або виконати дії зазначені на скріншоті:

• Оновлюйте CMS, її плагіни та теми до останньої версії.
• Використовуйте тільки підтримувані плагіни та теми.
• Слідкуйте за оновленнями серверного ПЗ.

Моніторинг безпеки

Налаштуйте систему моніторингу для раннього виявлення підозрілої активності:

• Встановіть систему виявлення вторгнень (IDS).
• Налаштуйте сповіщення про підозрілу активність.
• Регулярно аналізуйте журнали сервера.

Резервне копіювання

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

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

Додаткові інструменти для аналізу безпеки

Існує безліч інструментів, які можуть допомогти в аналізі безпеки веб-сайту та виявленні причин зламу:

Сканери вразливостей

• OWASP ZAP – безкоштовний інструмент для тестування безпеки веб-додатків.
• Nikto – сканер веб-серверів для виявлення потенційних проблем.
• OpenVAS – комплексна система сканування вразливостей.

Інструменти аналізу шкідливого коду

• ClamAV – антивірусний сканер з відкритим вихідним кодом.
• Maldet (Linux Malware Detect) – спеціалізований сканер для виявлення шкідливого коду на веб-серверах.
• PHP-Malware-Finder – інструмент для пошуку шкідливого PHP-коду.

Системи виявлення вторгнень (IDS)

• ModSecurity – веб-брандмауер (WAF) для Apache, Nginx та IIS.
• Fail2ban – інструмент для блокування підозрілих IP-адрес.
• OSSEC – система виявлення вторгнень на рівні хоста.