Экспертный гайд: Проверка сайта на взлом и вредоносные скрипты

Взлом сайта — это не только репутационные, но и прямые финансовые потери. Вредоносные скрипты (майнеры, редиректоры, фишинговые страницы, бэкдоры) могут работать незаметно для владельца, но активно вредить посетителям и SEO-позициям.

Цель этого руководства — предоставить пошаговый план по проведению аудита безопасности и обнаружению признаков компрометации на уровне файловой системы, базы данных и серверных логов.

1. Внешние и очевидные признаки компрометации

Прежде чем углубляться в код, проверьте внешние индикаторы, которые часто сообщают о взломе первыми.

1.1. Инструменты вебмастера и черные списки

1. Google Search Console (GSC): Проверьте раздел «Безопасность и ручные меры». Если Google обнаружил вредоносное ПО или фишинг, вы увидите явное предупреждение.
2. Яндекс.Вебмастер: Аналогично проверьте раздел «Безопасность».
3. Google Safe Browsing: Введите адрес вашего сайта в сервис Google Safe Browsing (например, https://transparencyreport.google.com/safebrowsing/search?url=ВАШ_ДОМЕН). Если сайт занесен в черный список, это верный признак проблемы.
4. Публичные сканеры: Используйте онлайн-сканеры, такие как Sucuri SiteCheck или Quttera, для быстрой проверки на известные сигнатуры вредоносного ПО.

1.2. Визуальные и поведенческие индикаторы

• Неожиданные редиректы: Пользователи, зашедшие на сайт с поиска, автоматически перенаправляются на сторонние, часто спамерские, ресурсы. Это указывает на инъекцию JS-кода или PHP-бэкдор.
• Чужой контент: На страницах появились нежелательные рекламные баннеры, ссылки или текстовые блоки, не относящиеся к вашему контенту.
• Медленная работа: Резкое падение производительности или аномально высокая нагрузка на процессор (CPU) на сервере может говорить о запущенном майнинговом скрипте.

2. Аудит файловой системы и кода (Root-Cause Analysis)

Файловая система — основное место, где хакеры оставляют свои бэкдоры (webshells).

2.1. Поиск по дате изменения файлов (Timestamps)

Один из самых эффективных методов. Взломанные файлы будут иметь недавнюю дату изменения, которая не соответствует дате последнего обновления вашей CMS или вашего кода.

Команда Linux для поиска файлов, измененных за последние 7 дней:

find /path/to/webroot -mtime -7 -print

• /path/to/webroot: Замените на корневой каталог вашего сайта.
• -mtime -7: Найти все файлы, измененные менее 7 дней назад.

Что искать:

• Незнакомые файлы .php, .js или .html в корневых каталогах (/wp-content/, /uploads/).
• Файлы с подозрительными именами: shell.php, gate.php, cache.php (часто маскируются под кеш), 1.php, или файлы с набором случайных символов (sdjf8s.php).

2.2. Поиск PHP-бэкдоров (Webshells)

Бэкдоры — это скрипты, позволяющие удаленно выполнять команды на сервере. Они часто используют функции, которые позволяют запускать код из переданной строки.

Основные сигнатуры для поиска в коде:

1. Функции для удаленного выполнения:
   • eval(
   • base64_decode( (часто используется для скрытия вредоносного кода)
   • gzinflate( или str_rot13( (обфускация)
   • assert(
   • system(, exec(, shell_exec(, passthru(
2. Суперглобальные массивы, используемые для получения данных:
   • $_POST[
   • $_REQUEST[
   • $_COOKIE[

Команда Linux для поиска опасных функций в коде:

grep -r -E "(eval|base64_decode|assert|shell_exec)" /path/to/webroot

Важно: Эти функции сами по себе не всегда являются вредоносными (они используются и в легитимных скриптах). Опасность возникает, когда они используются с пользовательским вводом (например, eval($_POST['cmd'])).

2.3. Проверка JavaScript-инъекций

Вредоносный JS чаще всего добавляется в глобальные файлы, такие как footer.php, header.php или в главный файл JavaScript.

• Ищите:
  • document.createElement('script') с внешним URL.
  • Длинные, обфусцированные строки, закодированные в base64 или hex.
  • Код, который добавляет скрытые <iframe> или <div>.

3. Аудит базы данных (SQL Injections)

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

3.1. Проверка пользовательских данных

Просмотрите таблицы с пользовательскими данными, постами и настройками.

• Административные аккаунты: Проверьте таблицу пользователей. Появился ли новый администратор с подозрительным именем или email-адресом?
• Injection в контенте: Ищите вредоносные скрипты или ссылки в полях, таких как post_content или product_description.
  • Пример вредоносного кода в БД:<a href="[http://spam-site.com](http://spam-site.com)" style="display:none;">Buy Cheap V1agra</a>
Эти скрытые ссылки создаются для SEO-спама.

3.2. Настройки и опции CMS

Если вы используете CMS (например, WordPress), проверьте таблицы настроек (wp_options). Хакеры часто изменяют поле siteurl или home для создания глобального редиректа на уровне CMS.

4. Аудит сервера и системных логов

Логирование — ваш лучший союзник в поиске источника взлома.

4.1. Анализ логов доступа (Access Logs)

Изучите лог-файлы вашего веб-сервера (Apache/Nginx) за период, предшествующий обнаружению взлома.

Что искать:

1. Аномальные POST-запросы: Поиск POST-запросов к легитимным файлам, которым обычно не передаются большие объемы данных (например, wp-config.php).
2. Поиск webshell-файла: Поиск HTTP-запросов к подозрительным файлам, которые вы обнаружили в п. 2.1 (например, частые запросы к shell.php).
3. Необычные IP-адреса: Ищите большое количество запросов с одного, нетипичного для вашей аудитории IP-адреса, который пытается получить доступ к разным каталогам.

4.2. Анализ логов ошибок (Error Logs)

В логах ошибок (PHP Error Log) ищите:

• Предупреждения о включении файлов: include или require файлов из временных или необычных каталогов (например, /tmp/).
• Сбои при выполнении: Попытки выполнить функции, которые заблокированы в настройках PHP (disable_functions).

5. План действий: Очистка и предотвращение

Обнаружив взлом, действуйте быстро и методично.

5.1. Изоляция и очистка

1. Отключите сайт: Временно замените все файлы сайта одной HTML-страницей с сообщением о технических работах, чтобы предотвратить дальнейшее распространение.
2. Смена паролей: Немедленно смените все пароли: FTP, SSH, База данных, Панель управления хостингом, все административные аккаунты CMS.
3. Очистка:
   • Удалите все подозрительные файлы, найденные в п. 2.1.
   • Замените все файлы ядра (CMS/фреймворка) на чистые версии из официального дистрибутива (не копируйте, а заменяйте!).
   • Очистите зараженные записи в БД.

5.2. Укрепление безопасности (Hardening)

1. Права доступа: Установите минимальные права доступа. Файлам — 644, папкам — 755. Файлы конфигурации (wp-config.php) могут иметь еще более строгие права (440 или 400).
2. Обновление: Обновите CMS, плагины и темы до последних версий. Уязвимости в устаревших плагинах — причина 90% взломов.
3. WAF/Плагины безопасности: Установите фаервол веб-приложений (WAF) или специализированные плагины безопасности (например, Wordfence для WordPress) для мониторинга в режиме реального времени.

Заключение

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