6.24 Как выявить и устранить причины компрометации сайта
Взлом сайта – это несанкционированный доступ к веб-ресурсу с целью кражи данных, размещения вредоносного контента или нарушения работы сервиса. Обнаружение и анализ взлома – критически важный этап для восстановления безопасности и предотвращения подобных инцидентов в будущем.
Распространенные признаки компрометации:
- Несанкционированные изменения контента (реклама, редиректы, спам-ссылки)
- Снижение производительности сервера
- Блокировка сайта поисковыми системами
- Подозрительная активность в журналах доступа
- Неожиданные перезагрузки или сбои в работе сервера
- Необычное поведение пользовательских аккаунтов
Важно: При обнаружении признаков взлома немедленно создайте резервную копию всех данных и журналов для дальнейшего анализа.
Анализ журналов сервера
Журналы сервера являются ключевым источником информации при расследовании взлома. Они содержат записи о всех действиях, выполненных на сервере, и могут указать на конкретные уязвимости или векторы атаки.
Анализ доступа к сайту
В первую очередь следует изучить файлы (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
Поиск недавно измененных файлов
Один из важнейших этапов после взлома сайта — выявить, какие файлы были изменены, и определить, кто или что инициировал эти изменения. Это позволяет понять, какой вектор атаки был использован.
- Поиск измененных файлов за последние дни
Используем команду 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
- Получить точную дату и время изменения файла
Если вы нашли подозрительный файл — проверьте его детальные метаданные:
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
- Поиск изменений в ночное или нетипичное время
Также полезно будет инициировать поиск в нетипичное время
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)
- Связать измененный файл с 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
Поиск вредоносного кода в файлах сайта
После обнаружения измененных файлов важно проверить их содержимое на наличие бэкдоров, вебшеллов и вредоносных функций, которые позволяют злоумышленнику повторно получить доступ.
- Поиск опасных функций в 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));
- Поиск длинных обфусцированных строк:
Вредоносный код часто начинается с бесконечной строки символов, которая выглядит подозрительно, это делается с целью невозможности понимания его назначения:
grep -r --include="*.php" -E "[A-Za-z0-9+/]{200,}"~/www/html
Пример:
- Поиск файлов с нетипичными именами или подозрительными расширениями:
find ~/www -type f \( -iname "*.php*" -o -iname "*.phtml" \) -size -20k
- -size -20k — часто вредоносные скрипты очень маленькие, до 20 КБ, но это не обязательно;
- Поиск по .php — охватывает даже файлы с двойным расширением: file.php.jpg;
- .phtml это пример нетипичного/подозрительного расширения.
- Анализ .htaccess на скрытые редиректы
grep -iE "redirect|RewriteRule" ~/www/test.com.ua/.htaccess
Ищите:
- Перенаправления на внешние сайты
- Маскировка URL
- Ограничения доступа на основе User-Agent
Типичные места размещения вредоносного кода
- Корневые директории веб-сервера.
- Директории для загрузки файлов (
/uploads/
,/media/
). - Темы и плагины CMS.
- Директории с временными файлами (
/tmp/
,/temp/
). - Скрытые директории (имена начинаются с
.
).
Анализ уязвимостей CMS
Если ваш сайт использует систему управления контентом (CMS), такую как WordPress, Joomla или Drupal, тщательная проверка ее компонентов обязательна при подозрении на взлом.
Проверка плагинов и тем
Уязвимые или устаревшие плагины — один из самых распространенных векторов атак.
- Выведите список всех плагинов/тем с указанием версий.
- Сравните с открытыми базами CVE и WPScan.io.
- Сканируйте плагины на наличие изменений в коде — сравните с официальной версией.
Анализ изменений, инициированных плагинами и компонентами CMS
Используйте логи CMS и ошибки сервера для выявления подозрительных действий:
# Проверка журналов ошибок на наличие активности подозрительных плагинов
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
Если плагин вызывает подозрения:
- Деактивируйте его временно
- Проверьте исходный код плагина на наличие вредоносных функций (особенно функции
eval()
,base64_decode()
и внешние включения). - Сравните код установленного плагина с оригинальной версией из официального репозитория.
- Проанализируйте, какие файлы были изменены или созданы плагином.
Проверка прав доступа
Неправильно настроенные права доступа могут позволить злоумышленнику загружать и выполнять вредоносный код:
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
, редиректить пользователя, подменять интерфейс.
Уязвимости загрузки файлов
Если на сайте есть формы для загрузки файлов без надлежащей проверки, злоумышленник может загрузить вредоносный скрипт.
Признаки:
- Неизвестные исполняемые файлы в директориях для загрузок.
- Записи в журналах о загрузке файлов с подозрительными расширениями.
Меры по устранению последствий взлома
После выявления причины взлома необходимо принять меры для восстановления безопасности сайта:
- Удалите вредоносный код и все подозрительные файлы.
- Обновите ПО: CMS, плагины, темы, библиотеки и серверное программное обеспечение.
- Измените пароли для всех учетных записей (администраторы CMS, FTP, базы данных, SSH).
- Исправьте уязвимости, которые позволили осуществить взлом.
- Проверьте файлы резервных копий на наличие вредоносного кода перед восстановлением.
Предупреждение: Простое удаление вредоносного кода без устранения первопричины взлома приведет к повторной компрометации сайта. Всегда выявляйте и устраняйте исходную уязвимость.
Превентивные меры защиты
Регулярное обновление ПО
Своевременное обновление всех компонентов веб-сайта – это фундаментальная мера безопасности:
Инструкции по обновлению 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 – система обнаружения вторжений на уровне хоста.