Как проверить безопасность своего сайта: чек-лист и бесплатные инструменты

Проверить безопасность своего сайта можно за час и бесплатно. Нужно убедиться, что поисковики не пометили сайт как опасный, HTTPS и заголовки безопасности настроены, CMS и плагины обновлены, наружу не торчат служебные файлы и лишние порты, а в коде нет посторонних вставок. Ниже — чек-лист из восьми шагов с командами и инструментами, которые подходят для WordPress, Drupal, Joomla и самописных сайтов.

Что понадобится

• Права владельца: доступ к админке сайта, к хостингу или серверу (SSH) и к Google Search Console или Яндекс.Вебмастеру.
• Компьютер с curl; для шагов 5 и 8 — Docker и nmap (есть для Linux, macOS и Windows).
• Свежая резервная копия сайта — на случай, если найдёте заражение и придётся чистить файлы.

В примерах ниже вместо example.com и 203.0.113.10 подставьте свой домен и IP-адрес своего сервера.

Шаг 1. Проверьте репутацию сайта

Если сайт попал в чёрный список, браузер покажет посетителям полноэкранное предупреждение, а поисковик понизит или уберёт его из выдачи.

• Google Safe Browsing — статус сайта: введите домен; должно быть «Опасный контент не обнаружен».
• Google Search Console → «Безопасность и меры, принятые вручную» → «Проблемы безопасности». Аналог в Яндекс.Вебмастере — «Диагностика → Безопасность и нарушения».
• VirusTotal: проверка URL сразу по десяткам антивирусных баз и чёрных списков.

Шаг 2. Проверьте HTTPS

Откройте Qualys SSL Labs и запустите тест домена. Что должно быть:

• оценка A или A+;
• включены только TLS 1.2 и TLS 1.3, старые SSL 3.0, TLS 1.0 и 1.1 выключены;
• сертификат выдан на все имена (example.com и www.example.com) и продлевается автоматически;
• HTTP перенаправляется на HTTPS кодом 301.

Если сайт не открыт в интернет (тестовый стенд), используйте консольный testssl.sh:

git clone --depth 1 https://github.com/testssl/testssl.sh.git
./testssl.sh/testssl.sh example.com

Шаг 3. Проверьте заголовки безопасности

Заголовки HTTP говорят браузеру, как защищать посетителя: запрещают встраивать сайт в чужие фреймы, ограничивают источники скриптов, требуют HTTPS. Быстрая проверка из терминала:

curl -sI https://example.com | grep -iE 'strict-transport|content-security|x-content-type|x-frame|referrer-policy|permissions-policy'

Подробный разбор с оценкой даст MDN HTTP Observatory.

Шаг 4. Проверьте версии CMS, плагинов и тем

Устаревший плагин — самая частая причина взлома сайтов на CMS. Проверьте обновления и целостность файлов.

WordPress — через WP-CLI на сервере:

wp core check-update                 # есть ли новая версия ядра
wp plugin list --update=available    # плагины с доступными обновлениями
wp theme list --update=available
wp core verify-checksums             # файлы ядра совпадают с эталоном wordpress.org
wp plugin verify-checksums --all     # то же для плагинов из каталога wordpress.org

Снаружи уязвимые плагины и темы покажет WPScan. Для сведений об уязвимостях нужен бесплатный API-токен с wpscan.com (у бесплатного тарифа есть суточный лимит запросов):

docker run -it --rm wpscanteam/wpscan --url https://example.com --enumerate vp,vt --api-token ВАШ_ТОКЕН

Drupal и SilverStripe — Droopescan определяет версию CMS, установленные модули и темы:

pip install droopescan
droopescan scan drupal -u https://example.com

Найденные версии сверьте с бюллетенями безопасности своей CMS и с базой NVD. Всё, что можно обновить, обновите. Плагины, которые давно не обновлялись или которыми вы не пользуетесь, удалите.

Шаг 5. Запустите пассивный скан OWASP ZAP

ZAP — бесплатный сканер веб-приложений. Режим baseline за минуту обходит сайт и анализирует ответы: отсутствующие заголовки, cookie без флагов Secure и HttpOnly, утечки версий ПО, смешанный контент. Атак в этом режиме нет, поэтому его безопасно запускать на рабочем сайте:

docker run -v "$(pwd)":/zap/wrk/:rw -t ghcr.io/zaproxy/zaproxy:stable \
  zap-baseline.py -t https://example.com -r zap-report.html

Отчёт zap-report.html появится в текущей папке. Начните с предупреждений уровня High и Medium.

Шаг 6. Найдите открытые служебные файлы

Частая находка при проверке — забытая копия базы, файл .env с паролями или открытый каталог .git, из которого можно скачать весь исходный код сайта. Проверьте типовые пути на своём сайте:

for p in .git/HEAD .env .htpasswd wp-config.php.bak backup.zip backup.sql phpinfo.php .DS_Store; do
  printf '%-20s %s\n' "$p" "$(curl -s -o /dev/null -w '%{http_code}' "https://example.com/$p")"
done

Для каждого пути ожидается 403 или 404. Ответ 200 — повод немедленно удалить файл или закрыть путь в настройках веб-сервера. Заодно убедитесь, что открытие каталога без index-файла не показывает список файлов (autoindex off в nginx, Options -Indexes в Apache).

Шаг 7. Поищите вредоносный код на сервере

Взломанный сайт может выглядеть нормально: вредоносный код показывает спам или перенаправления только поисковикам или посетителям с мобильных. Проверьте файлы на сервере:

# PHP-файлы, изменённые за последние 7 дней
find /var/www/example.com -name '*.php' -mtime -7 -ls

# PHP-файлов в каталоге загрузок быть не должно
find /var/www/example.com/wp-content/uploads -name '*.php'

# типичные приёмы обфускации
grep -rlE 'eval\s*\(\s*(base64_decode|gzinflate|str_rot13)' /var/www/example.com --include='*.php'

Совпадение — ещё не доказательство взлома: некоторые легальные плагины тоже используют base64_decode. Сравните подозрительный файл с оригиналом из дистрибутива. Дополнительно прогоните каталог сайта антивирусом ClamAV (clamscan -ri /var/www/example.com) и посмотрите, нет ли в админке незнакомых пользователей с правами администратора.

Шаг 8. Проверьте открытые порты сервера

Если сайт на своём VPS, посмотрите, какие службы доступны из интернета:

nmap -sV -Pn --top-ports 1000 203.0.113.10

Для обычного веб-сервера снаружи должны быть открыты 80 и 443, плюс SSH (лучше с входом только по ключу). Открытые MySQL (3306), Redis (6379), панели управления и FTP закройте файрволом или ограничьте доступ своими IP-адресами.

Проверка результата

После исправлений повторите проверки и сохраните результаты — это ваша точка отсчёта:

• Safe Browsing и Search Console — без предупреждений;
• SSL Labs — A или A+, Observatory — не ниже B;
• wp plugin list --update=available (или аналог для вашей CMS) — пустой список;
• в отчёте ZAP нет предупреждений High и Medium;
• служебные пути отвечают 403 или 404, лишних портов нет.

Как защитить сайт дальше

• Автообновления ядра и плагинов или хотя бы еженедельная проверка: массовые атаки на свежие уязвимости начинаются через часы после публикации.
• Двухфакторная аутентификация для всех администраторов, отдельные учётные записи вместо общей.
• Резервные копии по правилу 3-2-1: три копии, на двух типах носителей, одна — вне сервера. Проверяйте, что копия восстанавливается.
• WAF перед сайтом (например, бесплатный тариф Cloudflare) отсекает часть автоматических атак, но не заменяет обновления.
• Минимум лишнего: удалите неиспользуемые плагины, темы, тестовые копии и старые дампы базы.
• Повторяйте проверку раз в месяц и после каждого крупного обновления. Шаги 2, 3 и 5 легко автоматизировать по расписанию.

Материал подготовлен на основе документации OWASP, ZAP, MDN и отчёта Patchstack и актуален на дату обновления. Применяйте инструкции только к своим сайтам и серверам или с письменного разрешения их владельца.

Источник: OWASP, документация инструментов