Как сканировать WordPress на уязвимости и защитить сайт

Зачем сканировать WordPress

WordPress остаётся самой популярной CMS. Это делает её целью для автоматизированных атак и целевых взломов. Сканирование помогает:

• Выявить вредоносный код (мауэр, бекдоры, скрипты майнинга).
• Найти устаревшие плагины и уязвимые темы.
• Понять, какие файлы изменены или содержат подозрительные функции.
• Оценить риск компрометации учётных записей и утечки данных.

Определение: «Сканирование безопасности» — автоматизированная проверка сайта на признаки вредоносной активности и уязвимости.

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

Ключевые признаки того, что сайт уязвим

• Логин с именем “admin” или “administrator”.
• Простые или повторно используемые пароли.
• Установлены устаревшие или непроверенные плагины и темы.
• Включён редактор плагинов/тем в админке.
• Открытые важные файлы (wp-config.php и другие) без ограничений доступа.
• Небезопасная ОС или серверная конфигурация.

Быстрые бесплатные инструменты для первичной проверки

• Sucuri SiteCheck — проверяет на вредоносные файлы, блок-листы и устаревшие компоненты.
• WPScan — бесплатный сканер уязвимостей WordPress (коммерческое использование требует лицензии).
• Norton Safe Web — предупреждает о репутационных и вредоносных рисках.
• WordPress Security Scan — базовый сканер с платными расширениями.

Эти инструменты дают стартовую картину. Для бизнес-сайтов их может быть недостаточно — рекомендуется использовать платные решения с поддержкой и частыми обновлениями баз сигнатур.

Продвинутые и коммерческие подходы к сканированию

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

• Полный анализ файлов ядра, тем и плагинов на наличие сигнатур вредоносного кода.
• Мониторинг целостности файлов (File Integrity Monitoring).
• Сканирование на уровне базы данных и поиска подозрительных запросов.
• Проверка на бэкдоры, веб-шеллы и нестандартные руты.
• Интеграция с SIEM для накопления событий и их корреляции.

Примеры возможностей платных продуктов:

• Total Security: мониторинг целостности, оповещения, автоматическое удаление найденной «грязи».
• Vulnerability Alerts: оповещения о известных уязвимостях в плагинах и темах.
• Plugin Inspector: глубокий анализ кода плагинов на подозрительные функции и потенциальные эксплойты.

Мини-методология: как правильно сканировать

1. Подготовка: сделайте резервную копию файлов и базы данных. Это критично перед любыми исправлениями.
2. Первичный скан (внешний): используйте Sucuri, Norton и WPScan, чтобы быстро обнаружить видимые проблемы.
3. Глубокий локальный анализ: запустите платный/локальный сканер, проверьте FIM и найдите модификации файлов.
4. Анализ логов: проверьте access.log и error.log на подозрительные POST/GET, необычные частые запросы и новые точки входа.
5. Ручная проверка: инспекция wp-config.php, .htaccess, upload-папки и wp-content/plugins.
6. Исправление: обновите ядро, плагины и темы; удалите вредоносный код и заблокируйте IP-адреса при необходимости.
7. Контроль: снова запустите скан и наблюдайте за логами 48–72 часа.

Практические шаги по защите (шаг за шагом)

Обновляйте ядро, плагины и темы

1. Войдите в админ-панель WordPress.
2. Перейдите в «Консоль» → «Обновления».
3. Обновите ядро, плагины и темы по очереди. Делайте это на стенде перед продакшеном, если сайт критичен.

Удаляйте неиспользуемые плагины и темы

• Отключение недостаточно — удаляйте.
• Минимизируйте список установленных расширений.
• Храните только проверенные плагины с активной поддержкой.

Используйте сложные пароли и менеджер паролей

• Пароль минимум 12 символов, смешение регистра, цифр и символов.
• Не используйте общеизвестные слова.
• Включите двухфакторную аутентификацию (2FA) для админов.

CAPTCHA и ограничение попыток входа

• Добавьте CAPTCHA на формы обратной связи и регистрации.
• Ограничьте число попыток входа (например, плагин Limit Login Attempts Reloaded).
• Блокируйте IP с множественными неудачными попытками.

Отключите возможность редактирования файлов из админки

Добавьте в wp-config.php строку:

define('DISALLOW_FILE_EDIT', true);

Это закроет доступ к редактору тем и плагинов через панель.

Роль‑ориентированные чек‑листы

Чек-лист для администратора (site admin):

• Выполнить резервное копирование перед изменениями.
• Обновить ядро и плагины.
• Удалить неиспользуемые плагины/темы.
• Настроить 2FA и сложные пароли.
• Проверить SSL/TLS и заголовки безопасности.

Чек-лист для разработчика:

• Запустить локальные и CI-сканы кода (статический анализ).
• Проверить пользовательские плагины на небезопасные функции (eval, base64_decode, system).
• Настроить мониторинг целостности файлов.

Чек-лист для администратора хостинга:

• Ограничить права на серверных файлах.
• Настроить WAF (Web Application Firewall).
• Настроить регулярные сканирования по расписанию и уведомления.

SOP: стандартная процедура сканирования и патчей

1. Планирование: назначьте окно обслуживания и уведомите пользователей.
2. Бекап: полный бекап файлов и БД, сохранение копий вне сервера.
3. Первичный внешний скан (Sucuri/Norton/WPScan).
4. Локальный глубокий скан и FIM.
5. Разбор результатов: классификация на «критично/высоко/средне/низко».
6. Исправление: обновление/удаление/патч компонентов.
7. Тестирование: проверка функционала сайта (страницы, формы, платежи).
8. Финальный скан и мониторинг 72 часа.

Критерии приёмки

• Нет обнаруженных вирусов и бэкдоров в последнем скане.
• Все критические и высокие уязвимости закрыты.
• Тесты функционала прошли успешно.
• Резервная копия успешно сохранена и проверена.

План реагирования на инцидент (runbook)

1. Идентификация: подтверждение компрометации (анализ логов, предупреждения сканера).
2. Изоляция: переключение сайта в режим обслуживания, временная блокировка подозрительных IP, отключение внешних интеграций при необходимости.
3. Бекап «как есть» до любых изменений.
4. Локальный анализ и удаление вредоносного кода.
5. Ротация ключей: смена паролей админов, базы данных, FTP/SFTP, API-ключей.
6. Восстановление: восстановление чистой копии из резервной копии, если чистка невозможна.
7. Уведомление: если были затронуты персональные данные — уведомьте пострадавших в соответствии с законодательством.
8. Постинцидентный анализ и улучшения (корневой анализ причин).

Откат/rollback

• Если исправления нарушили работу сайта, откатитесь на последнюю проверенную резервную копию.
• Зафиксируйте изменения и выполните восстановление в тестовой среде перед повторным выкатыванием.

Когда автоматические сканеры ошибаются или не находят угрозы

• Новые «нулеводневные» эксплойты могут отсутстовать в базах сигнатур сканеров.
• Полностью обфусцированный или стеганографический код трудно обнаружить автоматически.
• Сканеры могут выдавать ложные срабатывания на кастомные функции.

Что делать:

• Проводите ручной аудит подозрительных файлов.
• Используйте поведенческий анализ трафика и мониторинг логов.
• Привлекайте профессиональные сервисы при сомнении.

Ментальные модели и уровни зрелости безопасности

• Уровень 1 — базовый: резервное копирование, обновления по необходимости.
• Уровень 2 — контролируемый: регулярные сканы, FIM, 2FA для админов.
• Уровень 3 — управляемый: WAF, SIEM, автоматические оповещения и инцидентный план.
• Уровень 4 — зрелый: интеграция безопасности в CI/CD, регулярные пентесты, SLA на восстановление.

Ментальная модель: думайте о безопасности как о цикле Detect → Respond → Recover.

Тесты и критерии приёмки сканирования

• Тест: запустить внешний и внутренний скан — ожидание: отсутствие критических уязвимостей.
• Тест: попытка входа c 10 неправильными паролями — ожидание: блокировка и уведомление.
• Тест: загрузка файла в uploads — ожидание: проверка на расширение/тип и скан на вредоносный код.

Советы по выбору сканера и плагина

• Проверьте частоту обновления баз сигнатур.
• Убедитесь, что есть поддержка и SLA для коммерческих клиентов.
• Оцените влияние на производительность сайта.
• Предпочитайте решения с возможностью очистки и восстановления.

Локальные особенности и рекомендации для русскоязычных пользователей

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

Шаблон проверки после сканирования (короткий)

• Резервные копии: есть и проверены.
• Обновления: ядро и все плагины обновлены.
• Удалено: неиспользуемые плагины и темы.
• Пароли: админы сменили пароли и включили 2FA.
• Редактор в админке: отключён.
• Сканы: внешний и внутренний пройдены, критических уязвимостей нет.

Небольшая галерея исключений — когда сканирование не поможет

• Скомпрометирован личный компьютер администратора: скан сайта не остановит кейлоггер на ПК.
• Утечка через сторонние интеграции (не через WordPress): требуется аудит внешних сервисов.
• Эксплойт ядра ОС сервера — потребуются серверные патчи и аудит провайдера.

Краткая памятка: быстрые команды и подсказки

• Отключить редактор тем/плагинов: добавить define(‘DISALLOW_FILE_EDIT’, true) в wp-config.php.
• Резервная копия: используйте экспорт БД и архивацию /wp-content и /wp-includes.
• Логи: проверяйте access.log и error.log на частые POST-запросы к /wp-login.php и /xmlrpc.php.

Пример простой decision tree для реагирования

graph TD
  A[Сигнал сканера] --> B{Критическая уязвимость?}
  B -- Да --> C[Переключить сайт в maintenance]
  B -- Нет --> D[Поставить задачу на плановое исправление]
  C --> E[Создать бекап «как есть»]
  E --> F[Чистка / удаление вредоносного кода]
  F --> G[Тестирование]
  G --> H[Возобновление доступа]

Короткое резюме

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

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

Факты по данным Sucuri:

• В одном из отчётов указывалось, что WordPress составлял 83% заражённых сайтов.
• В 2016 году 61% взломанных WordPress-сайтов имели устаревшие патчи; позднее этот показатель снизился до 39.3%.

Короткий словарь:

• FIM — мониторинг целостности файлов.
• WAF — веб‑файрвол для приложений.
• 2FA — двухфакторная аутентификация.

Короткое объявление (для рассылки, 100–200 слов):

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