SiteLock: сканер безопасности от Sectigo — почему бот может появиться даже без вашей подписки

SiteLock — не безымянный скрапер, а сканер конкретного и крупного игрока рынка веб-безопасности: компания защищает миллионы сайтов и с мая 2021 года входит в состав Sectigo, известного центра сертификации. Если этот UA появился в логах, велика вероятность, что либо сайт сам подключён к сервису SiteLock (часто — через хостинг-провайдера как часть тарифа), либо на нём работает бесплатный ознакомительный сканер, включённый автоматически.

Что за компания стоит за сканером

SiteLock базируется в Скоттсдейле, штат Аризона, и специализируется на защите сайтов от вредоносного кода: детект малвари, автоматическая очистка заражённых файлов, поиск уязвимостей приложений, мониторинг попадания домена в чёрные списки поисковых систем и спам-фильтров, а также проверка сертификата SSL. В 2017 году компания приобрела нидерландский стартап Patchman, что расширило её базу клиентов на WordPress-сайтах до нескольких миллионов доменов за счёт автоматизированного патчинга уязвимостей CMS и плагинов. Сама SiteLock в мае 2021 года была приобретена Sectigo — одним из крупнейших мировых центров сертификации TLS/SSL.

Важная техническая деталь: у SiteLock есть два принципиально разных метода сканирования. SMART File Scan подключается к серверу по FTP/SFTP и проверяет файлы «изнутри», включая те, что не видны обычному посетителю или поисковику, — при этом обработка идёт на инфраструктуре самого SiteLock, а не создаёт нагрузку на хостинг клиента. Второй метод — Webpage Scan — работает «снаружи», то есть эмулирует то, что видит обычный посетитель или поисковая система, обращаясь к публичным страницам сайта по HTTP. Именно этот второй метод и оставляет след с UA SiteLock в access.log сервера.

Почему бот мог оказаться на сайте без явного согласия владельца

Частый сценарий — сайт вообще не «подписывался» на SiteLock напрямую: многие хостинг-провайдеры (классический пример — партнёрство с HostGator) включают базовый бесплатный сканер автоматически для всех клиентов на определённых тарифах шаред-хостинга. В таком облегчённом режиме сервис ежедневно проверяет первые несколько страниц сайта на признаки малвари и присылает уведомление при обнаружении проблемы — без необходимости отдельной регистрации в личном кабинете SiteLock. Поэтому прежде чем блокировать бота как нежелательного, стоит уточнить у хостинг-провайдера, не входит ли такой сканер в состав тарифа по умолчанию.

Параметры бота

Сколько трафика он создаёт

По сводке TrafficVeil, суммарная нагрузка от SiteLock на подключённых доменах — порядка 400 запросов за отчётный период. Для ежедневного сканера безопасности, который в базовом варианте проверяет лишь несколько страниц сайта, это ожидаемо небольшой и стабильный объём, не создающий заметной нагрузки на типичный сервер.

Стоит ли блокировать

Здесь решение прямо зависит от того, кто клиент сервиса:

• если сайт защищён SiteLock — самостоятельно или через хостинг-провайдера — блокировка бота ломает саму суть услуги: сканы просто перестанут находить малварь, а владелец сайта будет платить (или получать бесплатно) за услугу, которая фактически не работает;
• если сайт SiteLock не пользуется, а бот всё равно появился — вероятно, это тот самый бесплатный сканер от хостинг-провайдера; в этом случае можно либо оставить его как бесплатную дополнительную проверку безопасности, либо отключить, если она не нужна;
• на позиции в органической выдаче Google, Bing или Яндекса присутствие или отсутствие этого бота не влияет — SiteLock не является поисковым краулером.

Как найти бота в логах

grep -i "SiteLock" /var/log/nginx/access.log

Как настроить доступ

Если сайт клиент сервиса (напрямую или через хостинг) — явно разрешить бота, чтобы сканы работали корректно:

User-agent: SiteLock
Allow: /

Если сканирование нежелательно — запрет в robots.txt с дублированием на уровне сервера:

User-agent: SiteLock
Disallow: /

if ($http_user_agent ~* "SiteLock") {
    return 403;
}

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