6.24 Как выявить и устранить причины компрометации сайта

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

Распространенные признаки компрометации:

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

Важно: При обнаружении признаков взлома немедленно создайте резервную копию всех данных и журналов для дальнейшего анализа.

Анализ журналов сервера

Журналы сервера являются ключевым источником информации при расследовании взлома. Они содержат записи о всех действиях, выполненных на сервере, и могут указать на конкретные уязвимости или векторы атаки.

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

В первую очередь следует изучить файлы (access.log), которые содержат информацию о всех запросах к веб-серверу:

/var/log/nginx/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) могут содержать ценную информацию о сбоях в работе сервера, которые могли быть вызваны атакой:

/var/log/nginx/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
  1. Получить точную дату и время изменения файла

Если вы нашли подозрительный файл — проверьте его детальные метаданные:

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
  1. Поиск изменений в ночное или нетипичное время

Также полезно будет инициировать поиск в нетипичное время

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)
  1. Связать измененный файл с 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));
  1. Поиск длинных обфусцированных строк:

Вредоносный код часто начинается с бесконечной строки символов, которая выглядит подозрительно, это делается с целью невозможности понимания его назначения:

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

Пример:

  1. Поиск файлов с нетипичными именами или подозрительными расширениями:
find ~/www -type f \( -iname "*.php*" -o -iname "*.phtml" \) -size -20k
  • -size -20k — часто вредоносные скрипты очень маленькие, до 20 КБ, но это не обязательно;
  • Поиск по .php — охватывает даже файлы с двойным расширением: file.php.jpg;
  • .phtml это пример нетипичного/подозрительного расширения.
  1. Анализ .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 и ошибки сервера для выявления подозрительных действий:

Логи с ошибками, связанные с плагинами (Nginx/Apache)
# Проверка журналов ошибок на наличие активности подозрительных плагинов
grep -r "plugin_name" ~/logs/*.error.log

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

Информация: Вредоносный код часто внедряется через уязвимости в плагинах CMS. Обратите особое внимание на плагины, которые давно не обновлялись, имеют мало установок или разработаны неизвестными авторами. В случае WordPress используйте инструменты вроде wp-cli для анализа целостности плагинов: wp plugin verify-checksums --all

Если плагин вызывает подозрения:

  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:
    • владелец – чтение + запись + выполнение
    • группа/другие – чтение + выполнение

Информация: Стандартные права доступа для файлов веб-сервера должны быть 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 – система обнаружения вторжений на уровне хоста.