Опубликовано: 27.09.2026

Обновлено: 27.09.2026

Просмотров: 26

Руслан Шкарбан, автор Руслан Шкарбан

SHD Console: монитор безопасности и аудит открытых страниц

Лето 2026 года стало для WordPress проблемным: волна плагинов с уязвимостями максимальной критичности, затем — дыра в самом ядре. Ситуация натолкнула меня на мысль разработать решение, которое позволяет администратору явно видеть слабые места на сайте. Хотелось, чтобы оно было простым и понятным и технически подкованному человеку, и обычному владельцу сайта.

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

Переизобретаем велосипед или полезное решение?

Проверки, которые делает SHD Console, по отдельности давно известны. WordPress сам показывает ожидающие обновления. Плагины вроде Wordfence и Sucuri закрывают другой слой: файрвол, блокировку входа, поиск вредоносного кода. Для запросов к базе и иерархии шаблонов у разработчиков есть Query Monitor. Собирать из этого новый антивирус было бы бессмысленно, и я этого не делал.

Задача, которую я хотел закрыть, проще. После волны уязвимостей администратору нужно явное место, где видно опасные настройки сайта: открытый редактор файлов, показ ошибок посетителям, учётная запись admin, слабые ключи, регистрация сразу с правами администратора, PHP в загрузках, пропущенные обновления. Это не поиск конкретной уязвимости в коде плагина. Это список условий, из-за которых сайт проще атаковать, записанный обычным языком и с подсказкой, что исправить.

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

Поэтому SHD Console не заменяет файрвол и не заменяет полноценный профайлер. Он собирает в одном экране две вещи, которые иначе смотрят в разных местах: насколько аккуратно настроен сайт и из чего собрана страница, открытая прямо сейчас. Техническому человеку этого достаточно, чтобы быстро проверить стенд. Остальным достаточно того, что критичное выделено отдельно от предупреждений и к каждому пункту написано, что с ним делать.

Из чего состоит SHD Console

Экран открывается в Инструменты → Консоль. Сверху — описание на двух языках, ниже отчёт последнего сканирования, ещё ниже журнал. Разбор открытой страницы живёт отдельно, в админ-баре.

Верх экрана «Консоль»: вкладки описания

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

Отчёт появляется после кнопки «Сканировать сейчас». Рядом написано, когда был последний запуск и когда плагин запустится сам: проверка стоит в расписании WordPress и повторяется раз в неделю.

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

Над кнопкой есть переключатель «Язык». Он переводит отчёт, виджет и подписи кнопок и запоминается для вашей учётной записи. Вкладки «Русский» и «English» над этим переключателем переводят только текст описания, отчёт они не трогают.

Запуск аудита

Сводка красит общий итог: всё спокойно, есть предупреждения или есть критичное. Рядом два числа — сколько критичных пунктов и сколько предупреждений. На локальной и development-среде часть проверок, которые на боевом сайте были бы критичными, остаётся предупреждением. На staging и production та же находка уже критичная.

Критичные проблемы

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

Критичные проблемы

Что проверяет аудит

Ниже сводки идёт полный список. У каждой строки есть статус, серьёзность, текст и подсказка, что делать. На локальной и development-среде HTTPS, вывод отладки, учётка admin и слабые соли остаются предупреждениями. На staging и production те же пункты критичные. Обновления плагинов и тем всегда предупреждения: их может быть много, и не каждое нужно ставить в ту же минуту.

Что показывает отчёт Какую проблему это несёт
HTTPS / SSL. Адреса сайта открываются по обычному HTTP. Страницы и форма входа идут открытым каналом. На локальной машине сертификата часто нет, поэтому там это предупреждение, а не крик о взломе.
Вывод отладки. Включены WP_DEBUG_DISPLAY или display_errors у веб-запроса. Посетитель видит текст ошибки: путь к файлам, версии окружения. Флаг в консоли сервера на сайт сам по себе не переносится.
Редактор файлов тем и плагинов. Его можно открыть из админки. PHP темы и плагинов правится из браузера. Если в админку уже вошли, это лишний способ дописать файл или сломать сайт. Проверка проходит, когда редактор закрыт через DISALLOW_FILE_EDIT или когда запись файлов запрещена шире, через DISALLOW_FILE_MODS.
Роль новых пользователей. Роль по умолчанию обладает правами администратора. Любой, кто зарегистрировался, сразу получает управление сайтом. Обычный подписчик проверку не роняет. На мультисайте регистрация нового сайта — отдельный случай, она не считается регистрацией администратора.
Учётная запись «admin». Логин ищется без учёта регистра. Такое имя — первая цель перебора пароля, даже если пароль сложный. Критично это на боевом сайте и только если у учётки есть права администратора.
Ключи и соли аутентификации. Пустое значение, короткая строка, заготовка или один и тот же текст в разных константах. На этих значениях держатся сессии и cookies. Слабые соли проще подобрать. В подсказке прямо сказано: смена солей завершит все текущие сессии, пользователей разлогинит. Это ожидаемое следствие, а не поломка.
PHP-файлы в uploads. В верхних папках загрузок лежат файлы PHP, в том числе phtml и phar. Каталог загрузок предназначен для медиа, не для исполняемого кода. Найденный файл — повод открыть папку и понять, откуда он взялся. Пустой результат не означает, что сайт чист: проверка не ищет вирусы по всему диску.
Обновления WordPress, плагинов и тем. Три отдельные строки, тот же кэш, что экран «Обновления». Устаревшее ядро, плагин или тема — обычная дверь для уже известной дыры. Если WordPress.org в момент проверки не ответил, пункт не становится зелёным: это предупреждение «данные не получены». Отложенное обновление ядра и предложение автообновления тоже остаются в списке.
Общий вид проверок аудита

Изменения и журнал

Блок «Изменения с прошлого сканирования» делит находки на три группы: новые, исправленные и всё ещё открытые. После первого скана новых нет по определению — это точка отсчёта, и на экране так и написано.

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

Виджет на главной консоли

На главной странице админки виджет повторяет короткий итог последнего скана: сколько критичного, сколько предупреждений и ссылку на полный отчёт. Если сканирования ещё не было, вместо чисел стоит кнопка «Открыть SHD Console». Виджет не запускает проверку сам, он только показывает уже сохранённое.

Пункт «Этот запрос»

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

Панель описывает ровно ту страницу, на которой вы её открыли. В аудит эти цифры не попадают и в базе не сохраняются. На AJAX, cron и REST пункта нет: там нет обычной страницы, которую имело бы смысл разбирать таким способом.

Вкладка «Запросы»

Над списком — время генерации страницы, пик памяти, число запросов и их суммарное время, число скриптов и стилей. Дальше таблица SQL. Одинаковые запросы сгруппированы: виден самый медленный вызов, место в коде и сколько раз этот текст выполнился. Медленными отмечены запросы от 0,05 секунды. Список можно сузить по тексту запроса или по тому, кто его вызвал.

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

Вкладка «Запросы»

Вкладка «Шаблоны»

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

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

Иерархия шаблонов

Письмо и командная строка

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

Тот же отчёт можно снять с сервера:

wp security-audit run
wp security-audit run --format=json

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

Заключение

SHD Console нужен там, где хочется видеть сайт без отдельного расследования. Владельцу — чтобы опасные настройки не терялись среди обновлений и чужих плагинов. Разработчику — чтобы на открытой странице сразу было видно шаблон, иерархию и цену запросов к базе. Администратору нескольких площадок — чтобы первое сканирование зафиксировало точку отсчёта, а письмо пришло только когда появилось новое критичное.

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

Плагин лежит на GitHub: github.com/Smirator/shd-console.