Как найти в логах вирус

Обновлено: 23.04.2024

На большинстве современных хостингов кроме FTP доступа к файловой системе предоставляется также SSH доступ (по-умолчанию или по запросу в тех поддержку). Умение веб-мастера работать с файлами сайта в терминале (в режиме командной строки) по SSH экономит ему массу времени. Операция, которая может занимать десятки минут по FTP, делается через командную строку за пару секунд. Кроме того, есть много операций, которые можно сделать только по SSH в режиме командной строки.

Веб-мастеру не обязательно осваивать весь инструментарий операционной системы Unix, для начала достаточно познакомиться с базовыми командами, а к ним добавить несколько полезных трюков при работе с командной строкой по SSH, чтобы быстро искать файлы, изменять их атрибуты, копировать, удалять и выполнять операции с текстовыми данными.

Я пропущу описание протокола и процесса подключения к аккаунту хостинга по SSH, в сети можно найти множество видео-уроков и статей по данной теме, скажу лишь что для подключения вам потребуется программа Putty (ОС Windows) / Терминал (Mac OS X) или аналогичные, и доступы к хостингу по SSH: хост, порт, логин и пароль (часто имя и пароль они совпадают с доступом в cPanel, ISPManager или аккаунтом панели управления хостингом).

Итак, что полезного можно делать в командной строке? Можно быстро выполнять поиск подстроки в текстовом файле, сортировку, фильтрацию текстовых данных. Например, для анализа журналов (логов) веб-сервера, чтобы выявить подозрительные запросы к сайту или понять, как взломали сайт.

Предположим, вы заметили подозрительную активность на сайте (стал медленно открываться, пропали доступы в админ-панель, с сайта рассылают спам и т.п.). Первое, что в этом случае нужно выполнить – это проверить файлы сайта на вредоносный код специализированными сканерами. Но пока сайт сканируется, можно провести экспресс-анализ логов веб-сервера с помощью команд find/grep, чтобы опеределить, не было ли обращений к каким-то подозрительным скриптам, попыток брутфорса (подбора пароля) или вызовов хакерских скриптов. Как это сделать? Об этом ниже.

Чтобы анализировать журналы (логи) веб-сервера нужно, чтобы эти логи были включены и доступны в пользовательской директории. Если по-умолчанию они отключены, необходимо их включить в панели управления хостингом и выставить, если есть такая настройка, максимально возможный период хранения (ротации). Если логов нет, но нужно выполнить анализ за последние несколько дней, их можно попробовать запросить в тех поддержке хостинга. На большинстве shared-хостингов логи можно найти в директории logs, которая расположена на один или два уровня выше директории public_html (www). Итак, будем считать, что логи на хостинге есть и путь до них известен.

Подключаемся по SSH и переходим в директорию с логами веб-сервера, которые на виртуальных хостингах хранятся обычно за последние 5-7 дней. Если вывести список файлов в директории, скорее всего там будет access_log за сегодняшний день, а также access_log.1.gz, access_log.2.gz,… — это архивированные логи за предыдущие дни.

Начать анализ лога можно с запросов, которые были выполнены методом POST:

Результат вывода можно сохранить в новый текстовый файл для дальнейшего анализа:

Как сделать то же для лога, заархивированного gzip? Для этого есть команда zcat (аналогично cat, но распечатывает содержимое заархивированного файла).

Для анализа подозрительной активности желательно использовать выборку по всем доступным логам. Поэтому далее в примерах будем использовать команду find, которая выполнит поиск всех файлов, а затем выполнит для каждого соответствующую команду (например, zcat).

Как определить попытки взлома или поиска уязвимых скриптов?
Например, можно найти все обращения к несуществующим скриптам .php во всех доступных логах.

(вместо -exec можно использовать xarg для вызова zcat. )

Еще можно поискать все неуспешные обращения к скриптам php (к которым был закрыт доступ).

Здесь мы ищем запросы, в которых встречается расширение php и статус 403.

Далее посмотрим по всем доступным логам число успешных обращений к скриптам, отсортируем их по числу обращений и выведем ТОП-50 самых популярных. Выборку сделаем в три шага: сначала выполним поиск по access_log, затем по всем access_log.*.gz, выведем результаты в файл, а затем используем его для сортировки.

Для сайта на Wordpress результат может выглядеть так:
(примеры для Wordpress приведены исключительно для иллюстрации, в действительности описанный подход и команды не ограничиваются данной CMS. Приведенные команды можно использовать для анализа журналов веб-сервера сайтов, работающих на любых php фреймворках и системах управления (CMS), а также просто на php скриптах.
)

Из результата видно, что к файлу wp-login.php было более 14000 обращений, что ненормально. Судя по всему на сайт была (или еще идет) брутфорс атака с попыткой подобрать доступ к панели администратора.

Большое число обращений к xmlrpc.php также может свидетельствовать о подозрительной активности. Например, через сайт могут атаковать (DDOS’ить) другие Wordpress сайты при наличие XML RPC Pingback Vulnerability.

Еще в списке подозрительными выглядят успешные обращения к /wp-includes/x3dhbbjdu.php, так как такого файла в стандартном Wordpress быть не может. При анализе он оказался хакерским шеллом.

Таким образом буквально за несколько секунд можно можно получить статистику по обращениям к скриптами, определить аномалии и даже найти часть хакерских скриптов без сканирования сайта.

Теперь давайте посмотрим, не было ли попыток взлома сайта. Например, поиска уязвимых скриптов или обращения к хакерским шеллам. Найдем все запросы к файлам с расширением .php со статусом 404 Not Found:

На этот раз результат может быть таким:

Больше пользы от выборки всех успешных POST запросов, так как это часто помогает найти хакерские скрипты.

Результат может выглядеть следующим образом:

Здесь видно много обращений к wp-login.php и xmlrpc.php, а также 3 успешных POST запроса к скрипту /wp-includes/x3dhbbjdu.php, которого не должно быть в Wordpress, то есть скорее всего это хакерский шелл.

Иногда полезно посмотреть выборку всех 403 Forbidden запросов, выполненных методом POST

В моем случае это выглядело так. Не очень много, хотя это могли быть попытки эксплуатации XML RPC Pingback.

Наконец, можно выбрать TOP-50 популярных запросов к сайту за сегодня:

Статистика обращений к /wp-login.php в access_log подтверждает, что брутфорс атака на сайт еще идет (кто-то пытается подобрать пароль), поэтому следует ограничить доступ к wp-admin по IP или с помощью серверной аутентификации, а если на сайте Wordpress нет регистрации пользователей, то можно ограничить доступ и к wp-login.php.

Таким образом без каких-либо специализированных приложений и дополнительных инструментальных средств можно быстро выполнить анализ логов веб-сервера, найти подозрительные запросы и их параметры (IP адрес, User Agent, Referer, дату/время). Все что для этого нужно – подключение по SSH и базовые навыки работы с командной строкой.

Если сайт взломан, мало удалить с него вирус и загруженный PHP Shell. Нужно еще найти причину, по которой произошел взлом, иначе через день-два на сайте снова будет под бодрую музыку развеваться красивый ~~турецкий~~ иностранный флаг. Чаще всего причина — украденный пароль от FTP, устаревшая версия CMS или плагина к ней, но как найти, что именно было использовано для проникновения?

Имея некоторый опыт в этой сфере (в среднем наша техподдержка занимается поиском причины взлома сайта раз в неделю), мы систематизировали накопившуюся информацию.

Итак, зачем вообще взламывают сайты? И что делать, если сайт взломан, как найти причину и защититься от последующих атак?

Зачем взламывают сайты

Алгоритм поиска причины взлома

Найти следы взлома.
Определить точное время взлома.
По логам найти, как именно поломали сайт.

Как искать следы взлома

Через какую-либо уязвимость загрузить PHP Shell (или получить через уязвимость доступ администратора CMS и загрузить PHP Shell через менеджер файлов).
Через PHP Shell сделать все остальное.

wzxp.php
gwd.php
a10881d.php.2046

./w.sh
./env
./env.c
./program.c
./program.o
./w00t.so.1.0
/tmp/sh
/tmp/sh2

Помимо файлов сайта стоит также проверить общий /tmp сервера — в нем могут находиться временные файлы, использованные для взлома или для запуска ботов.

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

Иными словами, необходимо искать все необычное/непонятное и заглядывать внутрь всех подозрительных файлов. PHP Shell может выглядеть, например, так:

Co0lHaZZkeR'ский стиль написания текста.
Наличие слов Exploit и Shell.
Наличие большого количества кода в base64.
Наличие eval() или функции preg_replace() с ключом /e в первом аргументе.

Файлы можно искать и вручную, но быстрее, если взлом произошел недавно, воспользоваться командой find:

Если ничего не помогает, можно просто поискать все файлы, содержащие закодированное в base64 содержимое, например, так:

Определение времени взлома

Когда файлы найдены, определить время взлома очень просто — достаточно посмотреть время изменения самого раннего файла.

Если подозрительных файлов не найдено, но сайт заражен вирусом, посмотрите дату изменения файлов index.php, index.html или тех, в которых обнаружите вирус. Скорее всего в этом случае сайт взломали, украв пароль от FTP.

Поиск журналов взлома сайта

Теперь самое главное — чтобы эти журналы были в наличии!

Если на сайте только произведен дефейс или добавлен вирус ко всем файлам index.html, скорее всего, сайт взломали через кражу пароля FTP (или, гораздо реже, SSH). Посмотрите журналы подключения по FTP и SSH во время взлома — присутствие в нем неизвестных IP-адресов или большого количества разных IP-адресов, осуществивших успешное подключение к сайту, означает, что пароль украден.

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

Если же на сайте присутствуют PHP Shell или вредоносные скрипты (например, для рассылки спама), скорее всего, сайт взломали через уязвимость в CMS или каком-либо её плагине. В этом случае потребуется проанализировать логи веб-сервера.

Злоумышленник определяет, что на сайте установлены CMS или ее плагины, либо другое ПО (устаревшая Joomla, phpMyAdmin, редактор WYSIWYG, галерея фотографий и т. д.), потенциально подверженные уязвимости.
Он начинает перебирать известные эксплойты к этому ПО. Цель — каким-либо образом загрузить свой файл на сайт.
Когда уязвимость найдена, взломщик загружает PHP Shell.
Подключившись к PHP Shell, взломщик получает полный доступ к сайту и дальше может использовать его в любых целях.

Если удалось определить IP-адрес

Определив IP-адрес взломщика, мы производим поиск этого IP-адреса по журналу веб-сервера и видим все действия, которые он совершал. Где-то близко к моменту обращения к PHP Shell будет успешное использование уязвимости сайта.

Если определить IP-адрес не удалось

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

Если известно время взлома сайта (а мы его уже знаем), необходимо поискать в журнале веб-сервера все запросы POST, находящиеся близко ко времени взлома. Здесь нет конкретных советов — выглядеть они могут совершенно по-разному, но выглядеть они будут в любом случае необычно. Например, это могут быть запросы, содержащие '../../../../' или длинные запросы, содержащие имена файлов или запросы SQL.

Если ничего не удалось найти

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

И ее расширений! Чаще всего взломы производятся не через ядро системы управления сайтом, а через какой-нибудь устаревший плагин, автор которого давно забросил его разработку.

Ну и, разумеется, смените все пароли, которые имеют какое-либо отношение к сайту.

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

Общая схема действия

Потенциальные источники логов безопасности

Журналы операционной системы серверов и рабочих станций
Журналы приложений (например, веб-сервер, сервер баз данных)
Журналы инструментов безопасности (например, антивирус, инструменты обнаружения изменений, системы обнаружения/предотвращения вторжений)
Исходящие журналы прокси-сервера и журналы приложений конечных пользователей
Не забудьте также рассмотреть другие источники событий безопасности, не входящие в журналы.

Стандартное расположение логов

Операционная система Linux и основные приложения: /var/log
Операционная система Windows и основные приложения: Windows Event Log (Security, System, Application)
Сетевые устройства: обычно регистрируются через syslog; некоторые используют собственное расположение и форматы

Что искать в логах Linux

Что искать в логах Windows

Идентификаторы событий перечислены ниже для Windows 2008 R2 и 7, Windows 2012 R2 и 8.1, Windows 2016 и 10. (В оригинальной статье используются в основном идентификаторы для Windows 2003 и раньше, которые можно получить, отняв 4096 от значений указанных ниже EventID).

Большинство событий, приведенных ниже, находятся в журнале безопасности (Windows Event Log: Security), но некоторые регистрируются только на контроллере домена.

Тип события	EventID
События входа и выхода	Successful logon 4624; failed logon 4625; logoff 4634, 4647 и т.д.
Изменение аккаунта	Created 4720; enabled 4726; changed 4738; disabled 4725; deleted 630
Изменение пароля	4724, 4723
Запуск и прекращение работы сервисов	7035,7036, и т.д.
Доступ к объектам	4656, 4663

Что искать в логах сетевых устройств

Изучите входящие и исходящие действия ваших сетевых устройств.

Примеры ниже – это выдержки из логов Cisco ASA, но другие устройства имеют схожую функциональность.

Что искать в логах веб-сервера

Полезные ссылки

Если вам интересна эта тема, то пишите комментарии, мы будем рады вам ответить. Подписывайтесь в нашу группу VK и канал Telegram, если хотите быть в курсе новых статей.

Взлом сайта — неприятная штука, но рано или поздно это может произойти с вашим сайтом. По данным сервиса Internet Live Stats в 2018 году около 100.000 сайтов взламывалось ежедневно, поэтому к этому событию лучше подготовиться заранее, и знать, что следует делать, если это произойдет.

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

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

Как хакеры взламывают сайты

Иногда хакеры взламывают сайты вручную, когда хотят получить доступ к какому-то определенному сайту, но по сравнению с автоматическим способом это происходит очень редко.

Основные способы, которыми хакеры проникают на сайты:

Это основные типы атак, которые используют хакеры, но кроме этих существуют и другие, поэтому практически невозможно угадать, каким именно путем хакер проник на сайт.

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

Единственный способ вылечить сайт — это выяснить, как хакер на него попадает, и устранить эту уязвимость.

Журнал событий сервера

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

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

Записи в журнале хранятся на сервере определенное количество дней, после чего они автоматически удаляются. Скопируйте их на компьютер, пока они не были удалены с сервера.

Сохраните файлы на компьютер из хостинг панели или напрямую с сервера, и откройте в любой текстовой программе, например Notepad++ или Brackets.

Как читать логи сервера

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

Структура записи в Журнале ошибок:

Дата и время
Тип ошибки
IP адрес пользователя
Описание ошибки
Путь к файлу страницы, на которой произошла ошибка
URL сайта, с которого пользователь пришел на страницу с ошибкой

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

Логи событий тоже имеют стандартную структуру:

Как найти нужные данные

Начните с просмотра Лога ошибок, это может дать подсказку для поиска взлома в Логах доступа.

Если вы увидели, что кто-то пытался получить доступ к файлам, которые обычный посетитель не должен посещать, но хакер может, тогда обратите внимание на этот IP. Хакер может попытаться получить доступ к файлам .htaccess, wp-config.php, install.php и другим подобным.

Пример ошибки в Логе ошибок:

[Sat Jul 07 16:17:46 2018] [error] [client 123.45.67.890:20744] AH01630: client denied by server configuration: /путь/к/вашему/сайту/.htaccess

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

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

Но не нормально, если один и тот же IP много раз пытается получить доступ к файлам, к которым обычно требуется получить доступ несколько раз за сессию, особенно если пользователь обращается ко всем файлам подряд и раз в несколько секунд. Если вы видите повторяющиеся запросы к одним и тем же файлам, это может говорить о том, что это хакер или хакбот.

В этом примере вы видите, что пользователь обратился к странице ~/wp-login.php в первой строке, и запрос был успешным.

После того, как загрузились все нужные файлы, пользователь был успешно авторизован и направлен на страницу Консоли в строке 5. Следующим действием администратор прошел в редактор плагинов в строке 9.

В этом примере вы видите подозрительную активность, так как не все пользователи после авторизации пойдут в редактор тем или плагинов, но хакер пойдет. Еще это значит, что хакер знает логин и пароль администратора.

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

400 Bad Request — Ошибка синтаксиса или неверный запрос.
401 Unauthorized — Эта ошибка появляется, когда требуется авторизация для просмотра страницы, но она не была дана, или она недействительна.
403 Forbidden — аналогично с ошибкой 401, этот ответ означает, что пользователь не имеет прав для просмотра этой страницы. То есть, технически доступ разрешен, но сервер запретил доступ этому пользователю.
429 Too Many Requests — Слишком много запросов за определенный период времени. Обычно пользователи не видят такой ответ, такая ошибка может указывать на активность какого-то бота.

Это не весь список ошибок, которые вы можете увидеть, но смысл в том, что описание событий может дать подсказку, что произошло с сайтом.

Самая сложная часть в просмотре логов доступа — это большое количество записей, даже для маленьких сайтов. Обычный вход администратора на сайт описывается 10 событиями в журнале, даже если он больше ничего не делал, поэтому размер лога становится большим на маленьких сайтах, и очень большим — на больших.

Как отсеять обычных посетителей

Чтобы уменьшить количество информации в логе можно отфильтровать обычные запросы. Откройте SSH клиент, например, Terminal для MacOS или PuTTY для Windows, или встроенный SSH клиент на хостинге, и попробуйте отсеять безопасные запросы.

С помощью этих команд вы можете отсеять 2/3 записей, в которых запрашивались картинки, файлы скриптов и стилей, главная страница, страница контактов и страница регистрации на сайте.

Главная страница обозначена / в части GET (/|/contact|/signup) . Вы также можете изменить contact и signup на другие страницы, или добавить другие страницы.

Если у вас остается много записей, вы можете отфильтровать запросы к странице авторизации и панели администратора:

Эти страницы часто атакуются хакерами, поэтому сначала просмотрите логи, относящиеся к этим страницам, особенно если было много неудачных попыток доступа к ним, после чего отфильтровать их.

Если вы знаете IP адреса админов, редакторов и других ролей, вы можете исключить эти запросы с помощью этой команды:

Замените 1.2.3.4 и 1.2.3.5 на свои адреса.

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

Устраните уязвимость

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

Автоматизируйте процесс

Если еще не поздно, установите какой-нибудь плагин безопасности, он усилит безопасность сайта и предупредит вас в случае подозрительной активности на сайте. Включенный плагин заблокирует будущие попытки взлома и сэкономит много времени на поиск проблемы и восстановление сайта.

Поделитесь в комментариях, взламывали ли хакеры ваш сайт, если да, то как вы его восстановили. Что вы делаете для безопасности сайта?

Если ваш сайт взломали — не паникуйте.

В этой статье вы узнаете 2 способа вылечить сайт от вредоносного кода, бэкдоров и спама вручную, и 1 способ с помощью плагина.

В первом способе вы Экспортируете базу данных и несколько файлов. После этого вы переустановите Вордпресс, Импортируете базу данных обратно и импортируете несколько настроек из сохраненных файлов.

Во втором способе вы удалите часть файлов и попробуете найти внедренный код при помощи команд в SSH терминале.

В третьем способе вы установите плагин.

Убедитесь, что сайт взломан

Если вы думаете, что сайт взломан, убедитесь, что это действительно так. Иногда сайт может вести себя странно или вы можете думать, что сайт взломали.

Ваш сайт взломан, если:

Сделайте бэкап

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

Некоторые хостинг провайдеры могут удалить сайт, если вы скажете им, что сайт взломан, или если хостинг провайдер сам определит это. Владельцы хостинга могут удалить сайт, чтобы не заразились другие сайты.

Также сделайте бэкап базы данных. Если что-то пойдет не так, вы всегда можете вернуться ко взломанной версии сайта, и начать все сначала.

Если ваши логи событий хранятся не в папке сайта, то скопируйте логи, так как обычно они хранятся на хостинге несколько дней, после чего автоматически удаляются.

Что можно безопасно удалить с любого взломанного сайта

Обычно можно удалить все содержимое папки wp-content/plugins/ . Вы не потеряете никакие данные и это не разрушит сайт. Позже Вордпресс определит, что вы удалили плагины, и отключит их. Не удаляйте только отдельные файлы, удаляйте папки с плагинами целиком. Некоторые плагины создают свои папки и файлы не только в папке /plugins , но и в других. Например, W3TC удаляется так. Некоторые файлы кеша W3TC определяются некоторыми сканерами как подозрительный или вредоносный код. Удалите все папки и файлы плагинов, чтобы не было ложных срабатываний.
Оставьте только одну тему в папке wp-content/themes/ , все остальные папки с темами можно удалить. Если вы пользуетесь дочерней темой, то оставьте 2 папки, — с родительской и с дочерней темой.
В папки wp-admin и wp-includes очень редко добавляются новые файлы. Если вы видите в них что-то новое, скорее всего, это добавил хакер. Файлы Вордпресс.
Удалите старые копии или бэкапы сайта из подпапок сайта. Обычно что-нибудь вроде /old или /backup . Хакер мог попасть в старую версию сайта, и оттуда проникнуть в основную версию сайта. Если ваш сайт взломали, проверьте эти папки на наличие вредоносного ПО, часто старые версии сайта заражены вирусами.

Как очистить Вордпресс сайт от заражения. Способ 1

Сделайте полный бэкап сайта и базы данных, и сохраните их на компьютер.
Скачайте на компьютер файл wp-config.phpиз корневой папки сайта, папку /wp-content/uploads и папку с активной темой. Перед копированием темы обновите ее до последней версии. Если вы пользуетесь дочерней темой, то скопируйте обе папки.
Полностью удалите сайт и базу данных с сервера.
Установите свежую копию Вордпресс, используйте новые сложные логин и пароль.
Перенесите настройки связи с базой данных из сохраненного файла wp-config.php в новый из этой части файла:

Как удалить вредоносный код и вылечить сайт. Способ 2

Если у вас есть SSH доступ к серверу, вы можете использовать эти команды, чтобы проверить, какие файлы изменялись за последние X дней. Этот запрос покажет все измененные файлы в запрошенном интервале времени во всех папках и подпапках сайта (чтобы узнать, какие это папки, наберите pwd в SSH терминале):

Если вы хотите найти измененные файлы в определенной папке, используйте этот запрос:

Замените /путь/к/вашему/сайту/папка/ на путь к вашей папке.

Если вы хотите изменить интервал до 10 дней, сделайте такой запрос:

Не забудьте заменить /путь/к/вашему/сайту/папка/ на путь к нужной папке.

Сделайте такой поиск, начните с 2-х дней и постепенно увеличивайте количество дней, пока не увидите изменения в файлах. Не забывайте, что обновления ПО — тоже изменения в файлах. После того, как вы нашли зараженный файл, его можно вылечить или заменить на оригинальный. Это очень простой и эффективный способ найти зараженные файлы, который используется всеми сервисами по лечению сайтов.

Хакеры часто используют эти функции:

base64
str_rot13
gzuncompress
eval
exec
create_function

system
assert
stripslashes
preg_replace (/e/)
move_uploaded_file

Эти функции могут использоваться и в оригинальных файлах тем или плагинов, но в большинстве случаев это хак. Перед тем, как что-нибудь удалить, убедитесь, что вы не удаляете здоровый код или файл.

Более аккуратный запрос может быть таким:

Эта команда покажет все файлы, в которых встречается фраза hacker was here .

Хакеры часто внедряют код в папку /uploads . Этот код поможет вам найти все файлы в папке uploads, которые не являются изображениями. Результат сохраняется в файле “uploads-not-pictures.log” в текущей папке.

Используйте запросы find и grep, они помогут вам очистить сайт от заразы.

Как найти вредоносный код и вылечить сайт с помощью плагина. Способ 3

Зайдите в Scan Settings, Зарегистрируйтесь в правом окне Updates & Registrations и нажмите Run Complete Scan.

Сервисы, на которых вы можете проверить сайт на наличие вредоносного ПО

— довольно простой сервис для проверки сайта. Первый шаг, чтобы определить, был ли сайт взломан. — хороший сервис для поиска заражений на сайте. Кроме сканера показывает, внесен ли сайт в списки вредоносных сайтов. На данный момент 9 списков. – сканер сайта от Norton. – сканирует сайт на наличие вредоносного ПО. — проверяет на вирусы и включение в черные списки Яндекса и Гугла. sTotal – крутейший сервис для сканирования сайтов, использует более 50 разных сканеров — Касперского, Dr.Web, ESET, Yandex Safebrowsing и других. Можно просканировать сайт, IP адрес или файл. – еще один хороший сервис, проверяет сайт на наличие червей, троянов, бэкдоров, вирусов, фишинга, вредоносного и подозрительного ПО и так далее. В течение пары минут генерирует довольно детальный отчет. – сканирует сайт на наличие вредоносного ПО, вирусов, внедренных скриптов и так далее. – сканирует сайт на вредоносный софт, SQL внедрения, XSS и так далее. Для использования требуется бесплатная регистрация. Довольно детальные отчеты приходят на е-мейл раз в неделю.

Что делать с зараженными файлами

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

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

После очистки сайта Гугл Хром продолжает показывать предупреждение о том, что сайт опасен и содержит вредоносное ПО. Что делать?

Вам нужно удалить свой сайт из списка зараженных сайтов Гугл.

Зайдите в Инструменты вебмастера Гугл
Добавьте свой сайт, если вы его еще не добавили
Подтвердите владение сайтом
На главной странице вашего аккаунта Инструментов вебмастера Гугл выберите ваш сайт
Кликните Проблемы безопасности
Нажмите Запросить проверку

Посетители сайта получают предупреждения от файрволов и антивирусов. Что делать?

Аналогично со списком зараженных сайтов Гугл, нужно удалить сайт из списков всех антивирусов: Касперского, ESET32, Avira и так далее.

Зайдите на сайт каждого производителя и найдите инструкции по удалению своего сайта из списка опасных сайтов. Обычно это называется whitelisting.

Наберите в поисковике eset whitelist website, avira site removal, mcafee false positive, это поможет вам найти нужную страницу на этих сайтах, чтобы исключить свой сайт из списка сайтов, содержащих вредоносное ПО.

Как узнать, что мой сайт находится в списке опасных сайтов, содержащих вредоносное ПО?

Там же вы можете проверить субдомены вашего сайта, если они есть. На этой странице вы найдете детальную информацию о вашем сайте, находится ли он в списках malware или phishing сайтов, и что делать, если содержится.

Читайте также: