Проверка CMS на уязвимости: что видно снаружи

Начните с версии CMS и расширений, затем проверьте публичные файлы, профильный сканер, внешние порты и TLS. Бесплатные инструменты помогают найти известные проблемы и ошибки настройки, но не гарантируют безопасность и не заменяют ручной разбор. Ниже — безопасный порядок проверки, команды и приоритеты исправлений.

Почему бесплатной проверки хватает для большинства сайтов

Я не обещаю, что бесплатного сканера хватит «для большинства сайтов»: это зависит от CMS, её расширений, самописного кода и доступов. Но проверить известные версии, открытые файлы и базовые настройки можно без покупки лицензии. Автоматический сканер сравнивает наблюдаемое с известными признаками; он не понимает, правильно ли приложение проверяет права пользователя или обрабатывает оплату. Если нужна системная проверка, мы проводим аудит информационной безопасности, а начальный осмотр администратор может сделать сам.

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

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

Что CMS и веб-сервер показывают снаружи

Сначала посмотрите, что сайт сам рассказывает в HTTP-ответе. WhatWeb распознаёт технологии по ответам и разметке, а curl -sI запрашивает только заголовки. Результат не всегда точен: прокси может изменить заголовки, а сайт — скрыть версию. Но если ответ прямо раскрывает устаревший стек, это полезная зацепка для администратора и для автоматических поисковых систем уязвимых версий. Я записываю находку, но не называю её уязвимостью без проверки.

whatweb https://example.com
curl -sI https://example.com

В nginx директива server_tokens управляет показом версии nginx в заголовке Server и на страницах ошибок; значение off скрывает номер версии, но не исправляет уязвимое ПО. В PHP expose_php управляет указанием PHP в заголовках. Это уменьшает лишнюю информацию в ответах, однако не заменяет обновление CMS, PHP и модулей. Не путайте косметику с ремонтом: табличка с маркой не делает дверь крепче.

Дальше проверьте файлы, которые не должны быть доступны из веб-корня: /.git/HEAD, /.env, резервные архивы и временные phpinfo-файлы. Запросите именно свой домен и оцените содержимое ответа: код 200 может означать, что файл отдаётся, но один код ответа сам по себе не подтверждает утечку. Для отсутствующего ресурса обычно ожидаются 404 или запрет 403; при настройке прокси возможны и другие ответы. Если найден публичный архив с секретами, удалите его из веб-доступа и смените содержащиеся в нём пароли и ключи.

У WordPress и других CMS есть характерные публичные URL, но их набор зависит от версии и конфигурации. Установка Drupal может содержать CHANGELOG.txt, однако штатные правила Apache в проекте Drupal предназначены для блокировки доступа к ряду таких файлов; не считайте путь универсальным индикатором уязвимости. Проверяйте не только статус ответа, но и реальную выдачу тела. Скрытие названия и версии снижает удобство автоматической разведки, но не является самостоятельной защитой.

• whatweb — предварительное определение технологий
• curl -sI — HTTP-заголовки ответа
• Проверьте доступность резервных файлов
• Проверьте тело ответа, не только код

Как выбрать профильный сканер для CMS

Для WordPress используют WPScan, для Joomla — OWASP JoomScan, для Drupal — droopescan. У каждого инструмента свои ограничения и правила перечисления компонентов. WPScan принимает --enumerate vp,vt,u: это запрос на поиск известных уязвимых плагинов, тем и публично обнаруживаемых имён пользователей. Данные о конкретных известных уязвимостях доступны через WPScan API; токен и лимиты зависят от действующего плана, поэтому перед запуском сверьте условия на сайте проекта. Не рассчитывайте, что бесплатный план одинаково покроет любой объём сканов.

wpscan --url https://example.com --enumerate vp,vt,u --api-token ВАШ_ТОКЕН
perl joomscan.pl -u https://example.com
droopescan scan drupal -u https://example.com

Команды предполагают, что инструменты уже установлены; сами по себе они не ставят нужные пакеты. В официальной инструкции WPScan ключи перечисления задаются через --enumerate, а JoomScan принимает адрес через -u/--url. Запускайте проверку с малой интенсивностью и смотрите документацию установленной версии, особенно если сайт чувствителен к частым запросам.

Как читать отчёт? Сверьте версию ядра, темы и каждого расширения с официальными релизами и advisory вендора. Если плагин заброшен или несовместим, замените или удалите его; наличие найденной версии не доказывает, что конкретная уязвимость эксплуатируема именно у вас. Имена пользователей сами по себе не дают доступ к сайту. Они повышают качество словаря для подбора паролей, поэтому проверьте MFA, уникальность паролей и ненужные учётные записи.

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

• WordPress — WPScan
• Joomla — OWASP JoomScan
• Drupal — droopescan
• Отчёт сверяйте с установленными компонентами

Минута 8–12: Nikto, OWASP ZAP и открытые порты

Профильный сканер дополняют универсальные инструменты. Nikto ищет распространённые проблемы веб-сервера и известные опасные файлы; его вывод требует ручной проверки и может содержать ложные срабатывания. OWASP ZAP Baseline запускает spider, а затем пассивные проверки: он сообщает о замеченных проблемах, например заголовках и cookie, но не выполняет активные атаки. Это безопаснее для первичного осмотра, но покрывает только страницы, до которых добрался обходчик.

nikto -h https://example.com
docker run -t ghcr.io/zaproxy/zaproxy:stable zap-baseline.py -t https://example.com

В Docker-команде используется официальный стабильный образ ZAP и его сценарий baseline. Пассивный отчёт не доказывает отсутствие SQL-инъекций или XSS: такие проверки требуют отправки специальных запросов и отдельного разрешения на активный тест. Встроенный таймер не превращает проверку в гарантию качества — просто ограничивает часть обхода.

Если сайт размещён на VPS или выделенном сервере, согласованно проверьте внешние порты. Команда nmap -sV определяет сервисы и их версии на обнаруженных открытых портах; она не означает, что Nmap проверил весь сервер на уязвимости. Список портов зависит от конфигурации, firewall и инфраструктуры провайдера. Порты 80 и 443 часто используются для веба, но не являются обязательным полным набором даже на обычном хостинге.

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

Минута 12–15: HTTPS, заголовки и онлайн-проверки

В конце проверьте HTTPS и заголовки. Qualys SSL Labs Server Test анализирует публичную TLS-конфигурацию и сертификат; testssl.sh позволяет запустить локальную проверку доступных TLS-настроек. Для публичного сервиса обычно оставляют современные версии TLS, но проверьте совместимость старых клиентов до изменения конфигурации. Отчёт о цепочке сертификата полезен, однако конкретная ошибка зависит от клиентского окружения и цепочки доверия.

Заголовки безопасности можно проверить в Mozilla HTTP Observatory или анализировать вручную. Content-Security-Policy часто требует настройки под конкретные скрипты, стили и внешние сервисы сайта. Сначала включите Content-Security-Policy-Report-Only, соберите отчёты и настройте разрешённые источники; только затем переходите к блокирующей политике. Иначе защита быстро превращается в тикет «почему у нас перестала работать форма». Добавляйте изменения постепенно и проверяйте ключевые сценарии.

Подтвердите владение сайтом в Google Search Console и Яндекс Вебмастере, чтобы видеть доступные уведомления и отчёты. Search Console предоставляет отчёт Security Issues, если Google обнаруживает определённые проблемы безопасности. Это дополнительный канал сигналов, а не круглосуточная система обнаружения взлома: проверяйте логи, файлы и учётные записи независимо. Если сайт уже заражён, не ждите письма от поисковика — начинайте разбор инцидента.

• SSL Labs или testssl.sh — TLS и сертификат
• HTTP Observatory — заголовки ответа
• CSP сначала в Report-Only
• Search Console — отчёт Security Issues

Условный разбор: архив и лишний доступ

Представим условную студию «Азимут-Мед» — это пример для разбора, а не реальный клиентский кейс. На WordPress-сайте есть форма записи, а владелец просит быстро проверить внешний периметр. При осмотре нашли бы четыре направления для проверки: два расширения с версиями, которые совпадают с записями в базе уязвимостей; резервный архив в веб-каталоге; открытый порт MySQL; устаревшие протоколы TLS. Одной фиктивной находкой я бы не стал изображать диагноз: каждую сначала надо подтвердить.

Если архив действительно доступен и содержит wp-config.php, нужно немедленно убрать его из публичного доступа, проверить журналы запросов и сменить секреты, которые могли утечь. Если nmap показывает доступный извне MySQL, проверьте firewall и список разрешённых адресов; сам факт открытого порта ещё не означает, что база принимает анонимные подключения. Сканер показывает поверхность, а оценка ущерба начинается после проверки условий доступа.

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

• Архив — проверить содержимое и журналы
• MySQL — подтвердить внешний доступ
• Плагины — сверить версии и advisory
• Повторить проверки после исправлений

Как не превратить проверку в разовую акцию

Разовый скан быстро устаревает: вы меняете сайт, а для его компонентов выходят новые обновления и предупреждения. Периодичность выбирайте по частоте изменений и уровню риска. Если расширения часто устанавливают или обновляют, проверяйте их при каждом изменении; спокойному проекту можно завести регулярный пересмотр компонентов и внешних настроек. Универсального правила «раз в месяц достаточно всем» нет. Календарь хотя бы лучше памяти.

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

Автоматические проверки полезны для известных проблем, но слабо отвечают на вопросы бизнес-логики и разграничения доступа. Самописный кабинет, платежи и данные клиентов требуют отдельной проверки логики сайта: сценариев, кода и ролей. Сканер хорошо находит забытый архив; выяснять, может ли пользователь видеть чужую запись, нужно отдельной проверкой. Я фиксирую владельца каждой находки, действие и дату повторного контроля — иначе отчёт просто красиво стареет.

• Проверяйте компоненты после изменений
• Сначала обновляйте копию сайта
• Проверяйте восстановление резервной копии
• Самописную логику проверяйте отдельно

Частые вопросы