Как проверить сайт на безопасность своими силами

Сайт открывается — значит, все в порядке? Так узнают о взломе последними. 10 проверок, которые владелец делает сам за вечер: санкции поисковиков, сертификат, версия PHP, открытые служебные файлы, доступы и резервные копии. И где самопроверка заканчивается.

Что из безопасности проверяется своими силами, а что нет

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

Хорошая новость: чтобы понять, в каком состоянии сайт, программист нужен не сразу. Из 10 проверок ниже 6 делаются прямо из браузера, еще 2 — в панели хостинга и в админке, и 2 не требуют вообще ничего, кроме списка людей и одного письма подрядчику. Вечер работы дает честную картину: где точно дыра, где похоже на дыру и где нужен человек с доступом к серверу.

Плохая новость тоже есть. Самопроверка не заменяет аудит. Она отвечает на вопрос «есть ли очевидные проблемы», но не отвечает на вопрос «нет ли неочевидных». Это разные вопросы, и путать их дорого.

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

Шаг 1. Спросить у поисковых систем, что они видят

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

В Яндекс Вебмастере откройте Оптимизация сайта → Безопасность и нарушения. Если раздел пуст — ограничений на сайт сейчас не наложено. Если там что-то есть, вы увидите тип нарушения и рекомендации. Согласно справке Яндекса, нарушения делятся на несколько типов, и не все из них связаны со взломом: там же живут SEO-тексты, клоакинг, мимикрия под чужой ресурс и накрутка поведенческих. Для нас важны 2 записи: неожиданное перенаправление и нежелательное программное обеспечение. Первое означает, что часть посетителей уводит на чужой ресурс, второе — что на страницах нашли вредоносный код или ссылки на него.

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

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

Важная деталь про сроки. Если нарушение подтвердилось и вы его устранили, снятие ограничений происходит не мгновенно. В Яндексе после отправки на перепроверку статус «На проверке» держится до 30 дней, а если ограничение не сняли, повторно отправить сайт можно только через 30 дней с момента прошлой заявки. Запущенное заражение стоит месяцев в выдаче. Часы простоя тут вообще ни при чем.

Шаг 2. Посмотреть на сайт чужими глазами

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

Проверка занимает 15 минут и делается так.

1. Инкогнито. Откройте сайт в приватном окне, разлогиненным. Пройдите по 5–6 страницам разных типов: главная, категория, карточка товара или услуги, статья, контакты, страница с формой.
2. Переход из поиска. Найдите сайт в Яндексе и Google по названию компании и зайдите по ссылке из выдачи, а не по прямому адресу. Подмену часто включают именно по источнику перехода.
3. Телефон. Повторите то же с мобильного, в мобильном браузере, а не в приложении. Всплывающие окна «ваше устройство заражено» и редиректы на рекламные страницы почти всегда мобильные.
4. Индекс. Введите в поисковую строку site:вашдомен.ru и полистайте выдачу до конца. Ищите страницы, которых вы не создавали: чужие товары, транслитерированный мусор, иероглифы, разделы про кредиты и азартные игры.
5. Кэш и сниппеты. Посмотрите на заголовки и описания в выдаче. Если title страницы в поиске не совпадает с тем, что вы видите на самой странице, это классический признак клоакинга.

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

Найденные лишние страницы в индексе не удаляйте сразу через инструмент удаления URL. Сначала надо понять, откуда они берутся, иначе вы прячете симптом и теряете единственный след.

Шаг 3. Сертификат и смешанный контент

Замок в адресной строке проверяют все и на этом останавливаются. Он говорит только о том, что соединение шифруется и сертификат сейчас действителен. Полезной информации там больше.

Нажмите на замок и откройте сведения о сертификате. Смотрите на 3 вещи: кем выдан, до какой даты действует и на какие имена. Частая находка — сертификат выпущен на example.ru, а сайт открывается еще и на www.example.ru, где браузер честно ругается. Вторая частая находка — до окончания срока осталось меньше 2 недель, а кто и как его продлевает, в компании не знает никто.

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

Теперь смешанный контент. Откройте инструменты разработчика в браузере (клавиша F12), вкладку Console, и перезагрузите страницу. Предупреждения про Mixed Content означают, что страница отдается по HTTPS, но тянет часть картинок, скриптов или стилей по HTTP. Для посетителя это выглядит как пропавший замок или предупреждение, для злоумышленника в общедоступной сети — как возможность подменить эти файлы.

Проверьте так 4–5 страниц, обязательно включая страницу с формой заявки и страницу оформления заказа. Именно там смешанный контент опаснее всего и именно там его чаще всего забывают.

Шаг 4. Прогнать сайт через сканер заголовков

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

Самый простой бесплатный способ — HTTP Observatory от Mozilla: вводите домен, получаете оценку от A+ до F и список того, чего не хватает. Смотреть в отчете нужно на 4 строки.

• Strict-Transport-Security. Говорит браузеру ходить на сайт только по HTTPS. Без него первый заход по HTTP остается уязвимым к подмене.
• Content-Security-Policy. Ограничивает, откуда странице разрешено грузить скрипты. Самый полезный заголовок из всех и самый редкий: чужой скрипт, вставленный в страницу, при настроенной политике просто не выполнится.
• X-Content-Type-Options. Запрещает браузеру угадывать тип файла. Закрывает трюк с загрузкой «картинки», которая на самом деле скрипт.
• X-Frame-Options или соответствующая директива в CSP. Запрещает встраивать ваш сайт во фрейм на чужой странице.

Теперь мое мнение, и оно расходится с тем, как этот инструмент обычно подают. Оценка Observatory переоценена. Она измеряет настройку заголовков, и только ее: сайт с оценкой A+ может быть заражен насквозь, а сайт с оценкой D — совершенно чистым и аккуратно обслуживаемым. Пользоваться сканером стоит, гордиться буквой — нет. Это градусник, а не диагноз.

Еще одна ловушка: настроить CSP на живом сайте с нуля и не сломать при этом формы, карты и аналитику — работа не на 5 минут. Если вам предлагают включить ее «одной строкой в конфиге», уточните, кто будет разбирать поломки на следующий день.

Шаг 5. Узнать, на какой версии PHP работает сайт

Самая быстрая проверка в списке и одна из самых показательных. Зайдите в панель хостинга и найдите версию PHP для вашего сайта. У большинства панелей это отдельный пункт в настройках домена.

Дальше сверьтесь с официальным графиком поддержки на php.net. Каждая ветка живет 4 года: 2 года активной поддержки и еще 2 года только с исправлениями критических уязвимостей. Ветка 8.1 и все, что ниже, поддержку уже не получают — обнаруженные в них дыры не закрываются вообще. Ветка 8.2 находится в режиме только критических исправлений, и ее срок истекает 31 декабря 2026 года.

Что делать с результатом, зависит от цифры. Версия 8.3 и выше — нормально, вернитесь к этой проверке через год. Версия 8.2 — поставьте в план переход до конца года, пока это плановая работа, а не аврал. Версия 8.1 и ниже — это тот случай, когда откладывать нельзя: сайт стоит на фундаменте, который больше никто не чинит.

Переключать версию самостоятельно кнопкой в панели не стоит. Старый код может не запуститься на новой ветке, и вы получите белый экран вместо сайта в 3 часа дня. Правильный порядок — копия сайта, проверка на копии, потом переключение боевого. Заодно посмотрите там же версию базы данных: требования платформ к MySQL тоже меняются, и об этом обычно узнают в момент, когда обновление уже не ставится.

Шаг 6. Найти то, что торчит наружу

Эта проверка нравится мне больше всех, потому что делается голым браузером и находит вещи, за которые бывает стыдно. Вы просто открываете адреса и смотрите, что отдает сервер.

Список того, что стоит попробовать, дописав к адресу сайта:

• Архивы и дампы. /backup.zip, /site.zip, /dump.sql, /base.sql, /db.sql, /backup.tar.gz. Файл, который начал скачиваться, — это ваша база или весь сайт в руках у любого желающего.
• Служебные каталоги. /.git/config, /.env, /composer.json. Открытая папка репозитория означает, что весь исходный код можно выкачать, включая пароли в конфигах.
• Открытые директории. /upload/, /files/, /tmp/, /logs/. Если вместо ошибки вы видите список файлов, листинг каталогов не отключен.
• Копии страниц и старые версии. /index.php.bak, /index_old.php, /test/, /new/, /old/. Забытая тестовая копия сайта — это вторая, никем не обновляемая CMS на том же сервере.
• Файл с настройками веб-сервера. /.htaccess должен отдавать 403, а не показывать содержимое.

Правильная реакция сервера на все перечисленное — 404 или 403. Все остальное надо чинить, и большинство находок закрывается настройкой веб-сервера за полчаса.

Отдельно проверьте /robots.txt. Там иногда обнаруживаются закрытые от индексации разделы, о существовании которых владелец не знал: старая админка, тестовый поддомен, каталог с прайсами для дилеров. Robots не защищает, он подсказывает — в том числе тем, кто ищет цели.

Шаг 7. Запустить штатные проверки в админке

Если сайт работает на «1С-Битрикс: Управление сайтом», часть работы уже сделана за вас, и ее просто не запускают. Все инструменты живут в 2 разделах административной панели.

Первый — Настройки → Инструменты → Проверка системы. Это встроенный тест окружения: он проверяет версии PHP и базы, права на файлы, работу почты, соединения, настройки кэширования и десятки других параметров. Отчет получается длинный, читать его целиком не нужно: смотрите на красные и желтые строки. Половина из них — рекомендации по производительности, но безопасные права на файлы и корректность настроек почты сидят там же.

Второй — Настройки → Проактивная защита. Здесь важно, что этот модуль недоступен в редакции «Старт». Если у вас младшая лицензия, все описанное ниже вы просто не увидите, и это отдельный аргумент за переход на «Стандарт» или выше.

Что запускать внутри:

• Сканер безопасности. Проверяет окружение проекта, настройки сайта, наличие подключенного веб-фильтра и ищет потенциальные уязвимости в коде. По описанию вендора, сканирование занимает секунды и сам модуль напоминает о себе, если проверку не делали больше месяца. Напоминание обычно закрывают крестиком — не закрывайте.
• Поиск троянов. Отдельный инструмент, который сканирует файлы сайта по шаблонам известного вредоносного кода и выдает список подозрительных. Ложные срабатывания там бывают, поэтому найденные файлы не удаляйте сами: сохраните список и отдайте разработчику.
• Контроль целостности. Сверяет файлы ядра с эталоном. Если после последней проверки в системных файлах что-то изменилось без вашего ведома, вы увидите это здесь.
• Журнал вторжений и журнал событий. Смотрите на неудачные попытки входа в админку. Сотни попыток с разных адресов — это фон, который есть у всех. Успешный вход в 4 часа ночи с адреса из другой страны — это уже событие.
• Панель безопасности. Общая сводка по включенным механизмам. Быстрый способ увидеть, что проактивный фильтр выключен, а двухэтапная авторизация не включена ни у кого.

И проверьте активность лицензии в Marketplace → Обновление платформы. Просроченная лицензия означает, что обновления безопасности не ставятся физически, сколько бы вы ни нажимали кнопку. У 1С-Битрикс есть публичный центр информирования об уязвимостях, где видно, какие дыры закрыты в каких версиях; сопоставьте свою версию с этим списком, если давно не обновлялись. Подробный разбор конкретных дыр платформы и того, чем они грозят, есть в отдельном материале про уязвимости 1С-Битрикс.

Шаг 8. Пересчитать всех, у кого есть доступ

Самый дешевый контур и самый игнорируемый. Он не требует ни денег, ни программиста, ни даже технических знаний — только полчаса и готовность признать, что за 5 лет доступы раздавались бессистемно.

Откройте в админке список пользователей и отфильтруйте тех, у кого есть административные права. Дальше по каждой строке отвечаете на 1 вопрос: этот человек работает у нас сейчас и должен ли он иметь именно такие права? Обычно в списке находятся: бывший маркетолог, подрядчик по контекстной рекламе, к которому обращались 2 года назад, и учетная запись с логином вроде admin, которую завел кто-то из разработчиков и никто не помнит, кто.

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

Что сделать по итогам:

1. Отключить учетные записи людей, которые больше не работают. Именно деактивировать, без удаления: история действий пригодится, если что-то всплывет.
2. Понизить права там, где полный доступ не нужен. Контент-менеджеру не нужны настройки модулей.
3. Включить двухэтапную авторизацию для всех, у кого остаются административные права. Это единственная мера, которая продолжает работать после утечки пароля.
4. Сменить пароли, которые могли быть отправлены в мессенджерах и почте. Если пароль от админки когда-то передавали в переписке, считайте его известным.

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

Шаг 9. Убедиться, что резервная копия существует и разворачивается

Копия — единственное, что превращает взлом из катастрофы в неприятный день. И это же место, где самопроверка чаще всего заканчивается неприятным открытием.

Напишите хостеру и подрядчику 4 вопроса, ответы желательно получить письменно:

1. Где физически лежат копии сайта и базы и на каком сервере?
2. Какая глубина хранения: за сколько дней назад можно откатиться?
3. Когда последний раз копию разворачивали и проверяли, что сайт из нее поднимается?
4. Что входит в копию: только файлы, только база или все вместе с загруженными пользователями файлами?

Что означают ответы. Копия, которая лежит на том же сервере, что и сайт, при компрометации сервера пропадает вместе с ним. Глубина в 1 сутки бесполезна против заражения, которое заметили через неделю: вы откатитесь на уже зараженную версию. А копия, которую ни разу не разворачивали, копией не является — это архив с неизвестным содержимым.

В админке 1С-Битрикс есть Настройки → Инструменты → Резервное копирование: там видно, когда делалась последняя копия и куда она складывается. Но встроенный механизм только дополняет копии хостинга и никогда их не заменяет.

Проверить восстановление самостоятельно можно, если у вас есть тестовая площадка: разворачиваете копию туда и открываете сайт. Если тестовой площадки нет, просьба «разверните нашу копию на тестовом и покажите» — нормальная задача для подрядчика на 2–3 часа. Она стоит дешевле, чем узнать про нерабочий бэкап в день, когда он понадобился.

Шаг 10. Закрыть юридический минимум

Эта часть не про хакеров, но проверяется в том же вечернем заходе и стоит дороже большинства технических рисков.

Пройдите по формам на сайте. Любая форма, которая собирает имя, телефон, почту или адрес, делает вас оператором персональных данных. Объем не имеет значения: достаточно одной формы обратной связи. У каждой формы должны быть согласие на обработку отдельной галочкой (не проставленной заранее) и ссылка на политику обработки персональных данных. Сама политика должна лежать на сайте по постоянному адресу и быть доступна без регистрации.

Дальше проверьте себя в реестре операторов персональных данных Роскомнадзора. Поиск по названию или ИНН, доступ открытый. Если карточки нет, уведомление не подавалось — это отдельное нарушение, которое обнаруживается без всякой проверки на месте, просто сверкой реестров.

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

Как выглядит сайт, который уже взломали

Отдельно соберу признаки, по которым заражение видно без специальных инструментов. Если совпали хотя бы 2 пункта, дальше самопроверку можно не продолжать — нужен человек с доступом к серверу.

• Трафик из поиска упал ступенькой. Не плавно за месяц, а обрывом за 2–3 дня. Смотрится в любой системе аналитики.
• В индексе появились чужие страницы. Проверяется запросом site: из шага 2.
• Письма с сайта перестали доходить. Зараженный сайт часто используют для рассылки спама, после чего сервер попадает в черные списки и легитимные письма тоже перестают приходить. Если у вас пропали уведомления о заявках, это не всегда проблема настройки почты.
• Сайт стал заметно медленнее. Майнер или рассылка съедают ресурсы сервера.
• В файлах появились свежие даты изменения. Видно в файловом менеджере панели хостинга: сортировка по дате, и сверху оказываются файлы, которых вы не трогали.
• Хостер прислал уведомление. Абузы, превышение лимитов, блокировка отправки почты — хостинг обычно замечает заражение раньше владельца.
• Появились новые администраторы. Учетная запись, созданная в тот день, когда никто ничего не делал.

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

4 вывода, к которым самопроверка подталкивает зря

«Все зеленое — значит, мы защищены». Ни один из перечисленных инструментов не проверяет ваш собственный код: самописный модуль корзины, форму импорта прайсов, интеграцию с 1С. Именно там живут уязвимости, которые не находит ни один публичный сканер, потому что этот код существует в единственном экземпляре и никому, кроме вас, не известен.

«У нас стоит проактивная защита, этого достаточно». Веб-фильтр разбирает входящие запросы и отсекает типовые атаки. Он не помогает, если злоумышленник вошел в админку с настоящим паролем — с точки зрения фильтра это законный пользователь. Мера полезная, но она закрывает 1 контур из нескольких.

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

«Проверили — можно забыть на год». Результат самопроверки живет до следующего обновления, до следующего нового сотрудника и до следующей опубликованной уязвимости платформы. Разумная частота — раз в квартал по полному списку и раз в месяц по коротким пунктам: санкции в Вебмастере, обновления, журнал входов.

Где самопроверка заканчивается

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

Не находится своими силами следующее:

• уязвимости в самописном коде и в решениях, купленных в маркетплейсе;
• ошибки прав доступа на уровне файловой системы сервера;
• закладки, которые не попадают под шаблоны штатного поиска троянов;
• проблемы изоляции сайтов на общем хостинге, когда соседний зараженный сайт достает до вашего;
• корректность настройки самого веб-сервера и базы данных.

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

Если хочется автоматизировать первый заход, у Design Lab есть бесплатный сервис проверки сайта check.design-lab.ru: он прогоняет 39 автоматических проверок, включая сертификат, заголовки, доступность служебных файлов и требования по персональным данным, и отдает отчет со списком того, что стоит починить. Он не заменяет шаги 7–10 из этой статьи, потому что не имеет доступа в вашу админку, но экономит час на технической части.

План на вечер

Если браться прямо сегодня, порядок такой. Сначала 25 минут на поисковые системы и взгляд на сайт со стороны — это отвечает на вопрос «горит ли». Потом полчаса на сертификат, заголовки, версию PHP и открытые файлы — это отвечает на вопрос «что чинить в первую очередь». Потом час на админку, доступы и копии — это самая скучная часть и самая полезная. Юридический минимум оставьте на следующий день, он требует решений, а не проверок.

Результат запишите в одну таблицу из 3 колонок: что проверили, что нашли, кто чинит. Без третьей колонки список превращается в архив тревог. С ней — в план работ, который можно отдать подрядчику или закрыть самому за 2 недели.

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