Как очистить взломанный сайт или блог WordPress

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

• Верните себе контроль над своим сайтом WordPress
• Определите вероятный источник инфекции
• Найдите инфекцию и вредоносный код
• Удаление любых вредоносных программ, бэкдоров и веб-шеллов
• Удалите свой домен из любых списков вредоносных программ, таких как база данных Google Safe Browsing.
• Предотвратить повторение

Ваш взломанный сайт WordPress действительно взломан?

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

Вернуть контроль

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

Хотя это во многом зависит от ваших настроек, ваш хостинг-провайдер, скорее всего, сможет помочь с восстановлением доступа к среде общего хостинга или виртуальному частному серверу (VPS), на котором работает ваш веб-сайт. Если вы потеряли доступ к администратору WordPress, следуйте официальному руководству WordPress по сбросу пароля администратора.

Создание резервной копии

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

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

Кроме того, если вы используете WordPress на виртуальном частном сервере (VPS), рассмотрите возможность создания моментального снимка всей виртуальной машины, если это возможно (имейте в виду, что это обычно связано с дополнительными затратами). Делая снимки, имейте в виду, что если вы используете какие-либо внешние тома для размещения своей установки WordPress (например, сетевое хранилище), вы также должны сделать копию любых томов, на которых хранится основная установка WordPress, wp-content , ваша база данных MySQL. , а также любой доступ к веб-серверу и журналы ошибок.

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

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

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

Что делать, если у меня нет резервной копии или я не могу успешно восстановить резервную копию?

Если у вас нет резервной копии, которую вы можете успешно восстановить, в зависимости от серьезности ситуации вы можете перевести свой веб-сайт WordPress в режим обслуживания, чтобы вы могли работать над восстановлением своего сайта, а посетители знали, что они должны вернуться позже. А пока продолжайте следовать остальной части этого руководства. Переведя свой веб-сайт в режим обслуживания с помощью функции wp_maintenance() ¹ функция, WordPress вернет код состояния HTTP 503. Статус 503 указывает Google и другим поисковым роботам, что на странице что-то пошло не так, и они должны вернуться позже.

HTTP-ответ 503 важен для SEO, поскольку он предотвратит повреждение вашего поискового рейтинга в случае временного отключения вашего веб-сайта. Для получения дополнительной информации о коде состояния HTTP 503 и его важности для SEO ознакомьтесь со статьей Yoast на эту тему.

Определите, как WordPress был взломан

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

Проверка журналов активности, журналов веб-сервера и FTP-сервера

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

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

Неиспользуемые и устаревшие плагины и темы WordPress

Проверьте список установленных плагинов как на панели инструментов WordPress, так и в каталоге /wp-content/plugins/ . Все ли плагины WordPress используются? Все ли они актуальны? Также проверьте темы и каталог тем /wp-content/themes/ . У вас должна быть установлена ​​только одна тема, та, которую вы используете. Если вы используете дочернюю тему, у вас будет два каталога.

Неиспользуемый код и установки WordPress

Оставшийся и неиспользованный код — еще одна распространенная проблема. Иногда разработчики и системные администраторы обновляют файлы непосредственно на сервере и делают резервную копию исходного файла с таким расширением, как .old , .orig или .bak . Злоумышленники часто пользуются этой плохой практикой, и инструменты для поиска таких файлов резервных копий широко и легко доступны.

Это работает, когда злоумышленник пытается получить доступ к таким файлам, как index.php.old . Обычно файлы .php настраиваются для выполнения интерпретатором PHP, но добавление расширения .old (или другого) в конец файла приводит к тому, что веб-сервер передает файл пользователю. Просто угадывая имя файла резервной копии, злоумышленник может загрузить исходный код, который может содержать конфиденциальную информацию, или может дать злоумышленнику подсказки о том, что использовать.

Похожая проблема — сохранение старых установок WordPress. Когда системные администраторы перестраивают свои веб-сайты, они иногда оставляют копии старых установок WordPress в подкаталоге /old/ . Эти старые установки WordPress, как правило, по-прежнему доступны через Интернет и, следовательно, представляют собой лакомую цель для злоумышленника, который может использовать известные уязвимости в старых версиях WordPress вместе с любыми плагинами.

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

Пользователи и роли WordPress

Убедитесь, что используются все пользователи WordPress. Есть ли новые подозрительные? Убедитесь, что все роли целы. Если вы следуете рекомендациям по пользователям и ролям WordPress, у вас должен быть только один пользователь с ролью администратора WordPress.

Провайдеры виртуального хостинга

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

файлы .htaccess

Файлы .htaccess (файлы конфигурации Apache HTTP Server уровня каталога) также являются распространенной целью для хакеров. Обычно они используются для перенаправления пользователей на другие спамовые, фишинговые или иные вредоносные веб-сайты. Проверьте все файлы .htaccess на вашем сервере, даже те, которые не используются WordPress. Некоторые из перенаправлений может быть трудно обнаружить.

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

Если возможно, рассмотрите возможность использования глобальной конфигурации вместо того, чтобы полагаться на файлы .htaccess внутри Apache HTTP Server. Файлы .htaccess не только снижают производительность, но и открывают ваш веб-сайт WordPress для множества уязвимостей безопасности, если злоумышленник когда-либо сможет прочитать или, что еще хуже, записать содержимое этих файлов. Согласно документации HTTP-сервера Apache ² , использование файлов .htaccess можно полностью отключить, установив для директивы AllowOverride значение none в основном файле httpd.conf .

Проверка других точек входа

На веб-сервере есть несколько других точек входа. Убедитесь, что вы проверили все из них, такие как FTP-серверы, SSH, веб-сервер и т. д.

Найдите инфекцию WordPress и вредоносный код

Прежде чем начать : взлом WordPress обычно включает в себя вставку кода в тему WordPress, плагин или основной файл. Следовательно, чтобы приступить к очистке, вам должно быть удобно модифицировать код. Если нет, наймите специалистов по безопасности WordPress.

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

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

В идеале вы должны использовать плагин мониторинга файлов WordPress, который отслеживает файлы в вашей установке WordPress на наличие изменений и немедленно предупреждает вас. Если у вас нет подключаемого модуля File Integrity Monitoring (FIM), вам придется искать изменения файлов вручную.

Если у вас есть SSH-доступ к вашему серверу, проверьте, какие файлы на вашем веб-сайте WordPress недавно изменились. Как правило, было бы целесообразно начать поиск изменений в течение последних пяти дней после обнаружения взлома, расширяя поиск по мере необходимости. Для этого перейдите в каталог, в котором находится ваш веб-сайт WordPress, и используйте команду find.

find .mtime -5 –ls

Приведенная выше команда выводит список (-ls) всех файлов, которые были изменены (.mtime) за последние пять дней (-5). Если список слишком длинный, используйте меньше пейджера для более удобного просмотра и поиска по списку.

find .mtime -5 –ls | less

Если вы недавно обновили плагин или тему, любые связанные изменения файлов будут отображаться в результатах поиска. Журналы, файлы отладки также часто обновляются, поэтому они также будут отображаться в ваших результатах. В результате вам, возможно, придется выполнить обширную фильтрацию результатов, чтобы найти интересующие изменения файлов. Обратите внимание, что специализированные плагины, такие как плагин WordPress File Changes Monitor для WordPress, специально разработаны для автоматического отсеивания таких ложных срабатываний. Плагин специально создан для WordPress и может идентифицировать изменение файла ядра WordPress, обновления плагина или темы, установку или удаление.

Проверка всех файлов HTML

В WordPress очень мало файлов HTML, и хакеры любят ими пользоваться. Найдите на своем веб-сайте все HTML-файлы и проанализируйте их содержимое. Убедитесь, что все файлы HTML на вашем веб-сайте являются законными и вы знаете, для чего они используются.

Простой способ вывести список всех HTML-файлов в вашем каталоге WordPress (и подкаталогах) — использовать следующую команду.

 
find . -type f -name '*.html' 

Поиск зараженного текста

Если ваш веб-сайт был поврежден или в результате заражения на вашем веб-сайте появляется какой-либо текст, найдите его с помощью инструмента grep. Например, если вы увидели текст «hacked by», перейдите в корневой каталог веб-сайта и введите следующую команду.

grep –Ril "hacked by"

Приведенная выше команда вернет список файлов, содержащих «взломанное» содержимое. Получив список зараженных файлов, вы можете проанализировать код и удалить заражение.

Что означают переключатели grep?

• -R указывает grep на рекурсивный поиск (поиск по всей структуре каталогов, включая все подкаталоги и символические ссылки).
• -i указывает grep, что поиск должен быть нечувствительным к регистру (т. е. игнорировать заглавные буквы в искомом термине). Это очень важно в средах Linux/Unix, поскольку, в отличие от Windows, файловые системы Linux чувствительны к регистру.
• -l указывает grep, что он должен возвращать имя файла, а не его содержимое. Когда ваш сайт WordPress взломан, это другой вредоносный код, который нужно искать.

Помимо очевидной строки «hacked by», ниже приведен список кодов и текстовых фраз, которые обычно используются на взломанных веб-сайтах WordPress. Вы можете использовать инструмент grep для поиска следующего:

• base64_decode
• is_admin
• оценка
• gzuncompress
• пройти через
• исполнитель
• shell_exec
• утверждать
• str_rot13
• система
• phpinfo
• chmod
• мкдир
• fopen
• закрыть
• файл для чтения

Быстрый способ добиться этого с помощью grep — использовать следующую команду grep, которая рекурсивно ищет файлы (следует за любыми символическими ссылками), ищет строки, которые соответствуют указанному регулярному выражению PCRE ³ . и возвращает текстовое совпадение, а также номер строки, в которой произошло совпадение.

grep -RPn "(base64_decode|is_admin|eval|gzuncompress|passthru|exec|shell_exec|assert|str_rot13|system|phpinfo|chmod|mkdir|fopen|fclose|readfile) *\("

ПРИМЕЧАНИЕ . Часть этого кода также может использоваться в законном коде, поэтому тщательно проанализируйте код и поймите, как он используется, прежде чем помечать что-либо как заражение или взлом.

Сравните файлы с оригинальной установкой WordPress.

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

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

При сравнении корневых каталогов двух веб-сайтов WordPress инструмент выделяет разницу в содержимом файла index.php , новых файлов .htaccess и wp-config.php , а также различия в подкаталогах.

Дважды щелкнув файл index.php , мы увидим, в чем заключаются различия.

На что обращать внимание при сравнении файлов WordPress?

Ищите файлы, которые не являются частью ядра WordPress. Большинство инфекций добавляют файлы в корень установки WordPress или в каталог wp-content . Если взлом произошел из-за уязвимости плагина, возможно, файлы плагина были изменены.

Очистите взлом WordPress

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

Автоматический поиск заражения с помощью службы WordPress

Если вышеперечисленное кажется слишком сложным, не отчаивайтесь. Существует несколько служб безопасности и плагинов WordPress, которые вы можете использовать для сканирования вашего веб-сайта на наличие вредоносных программ и других инфекций. Мы рекомендуем службы безопасности Malcare WordPress.

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

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

Восстановление вашего WordPress из резервной копии

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

Изменение всех паролей, удаление неиспользуемых пользователей и проверка ролей пользователей WordPress

Измените все пароли всех ваших пользователей и служб, включая WordPress, CPanel, MySQL, FTP и ваш собственный персональный компьютер. Проверьте список пользователей на вашем FTP, WordPress, MySQL и любом другом сервисе, чтобы убедиться, что все пользователи являются законными. Если есть пользователи, которые больше не используются, удалите их. Убедитесь, что все пользователи WordPress имеют правильные роли и разрешения.

Обновление ядра WordPress, плагинов, тем и другого программного обеспечения

Убедитесь, что вы используете самую последнюю версию всего программного обеспечения, необходимого для работы вашего сайта WordPress. Это не ограничивается только самим WordPress, но также распространяется на любые плагины, темы, а также исправления операционной системы, PHP, MySQL и веб-сервер (например, Apache HTTP Server или Nginx) и любой FTP-сервер, который вы можете использовать.

Резервное копирование вашего сайта WordPress

На этом этапе перед удалением фактического зараженного кода сделайте резервную копию вашего веб-сайта WordPress.

Удалите предупреждение Google Safe Browsing о вредоносном ПО

Если ваш веб-сайт был занесен в черный список Google Safe Browsing, вы можете подать заявку на проверку безопасности, чтобы удалить предупреждение.

Как только вы удалите взлом WordPress…

Поздравляем, вы восстановили свой сайт WordPress после взлома. Теперь вы должны убедиться, что это не повторится. Вот несколько советов о том, что вам следует делать:

1. Установите плагин журнала активности WordPress, чтобы отслеживать все, что происходит на вашем сайте WordPress.
2. Если у вас нет готового решения для резервного копирования, приобретите его.
3. Используйте службу сканирования безопасности WordPress.
4. Меняйте пароли базы данных и администратора, а также применяйте надежную защиту паролей WordPress.
5. Всегда обновляйте свой WordPress, плагины WordPress, темы и любое другое программное обеспечение, которое вы используете.
6. Удалите все неиспользуемые файлы, такие как старые установки WordPress, неиспользуемые плагины и темы WordPress (включая неиспользуемые темы WordPress по умолчанию). Неиспользуемые компоненты и программное обеспечение добавляют ненужную поверхность атаки и в идеале должны быть удалены.
7. Следуйте нашему руководству по усилению безопасности WordPress, чтобы убедиться, что вы позаботились обо всех возможных проблемах безопасности на своем веб-сайте.