Как защитить сайт от взлома

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

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

Что теряет сайт в поиске после взлома

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

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

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

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

Тип заражения	Что видит владелец	Что теряет сайт	Сколько занимает возврат
Вредоносный скрипт в шаблоне	Обычно ничего	Метку опасности, обвал кликов	Метка снимается после перепроверки, трафик — недели
Спам-страницы в подпапках	Ничего, пока не проверит оператором site:	Краулинговый бюджет, размытие тематики	Месяцы: страницы вылетают из индекса медленно
Скрытые ссылки в футере и статьях	Ничего, ссылки спрятаны стилями	Доверие к домену, риск ссылочных санкций	Недели после чистки и обновления страниц
Редирект по условию	Ничего: у него сайт открывается	Почти весь поисковый трафик сразу	Быстро восстанавливается, если поймать за дни
Дефейс, подмена главной	Сразу видно	Позиции, репутацию, заявки	Быстрее прочих: заметен и чинится сразу

Как поисковик узнаёт о заражении раньше владельца

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

Уведомление приходит в панель вебмастера — в Яндекс.Вебмастере это раздел с нарушениями и безопасностью, в Google Search Console — «Проблемы безопасности». Отсюда правило, которое стоит выполнить прямо сегодня: убедитесь, что сайт добавлен в обе панели и что уведомления идут на почту, которую вы реально читаете. Я регулярно вижу ситуацию, когда письмо о заражении месяц лежит в ящике, к которому никто не заходит с момента запуска сайта.

Проверять самому нужно не из браузера, а так, как сайт видит робот и посторонний посетитель:

• оператор site: с названием домена в поиске — просмотрите список страниц, ищите чужие разделы и заголовки на посторонних языках;
• проверка ответа сервера в Вебмастере с указанием робота — покажет, отдаётся ли роботу тот же HTML, что и вам;
• открытие сайта в режиме инкогнито с телефона и переход из поисковой выдачи, а не по прямой ссылке;
• просмотр исходного кода главной и типовой внутренней страницы на предмет незнакомых скриптов и ссылок;
• сравнение числа страниц в поиске с реальным числом страниц на сайте — резкий рост почти всегда означает генерацию мусора.

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

Тему разбирал отдельно: «Как защитить сайт от накрутки».

Откуда приходит взлом на самом деле

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

Основные входные точки, по частоте:

1. Устаревшие расширения. Плагин, тема или модуль с публично описанной уязвимостью. Описание уязвимости появляется одновременно с патчем, и с этого момента начинается гонка: кто быстрее — вы с обновлением или сканер.
2. Слабые и повторно использованные пароли. Перебор по словарю и подстановка пар «логин-пароль» из чужих утечек. Если один и тот же пароль стоит на почте, хостинге и админке, компрометация одного сервиса открывает всё.
3. Забытые доступы. Учётные записи подрядчиков, старые FTP-аккаунты, ключи, отданные на время. Формально доступ никто не отзывал — фактически он живёт годами.
4. Заражённые дистрибутивы. Платная тема, скачанная бесплатно, или «активированный» плагин. Бэкдор там встроен изначально, и никакой антивирус хостинга его не ищет — код выглядит частью шаблона.
5. Соседи по аккаунту хостинга. На одном аккаунте несколько сайтов, один из них старый и заброшенный. Ломают заброшенный, а дальше идут по файловой системе к остальным.
6. Незакрытые служебные файлы. Резервные копии базы в корне сайта, архивы с исходниками, файлы окружения с паролями, оставленные после переноса.

Доступы: пароли, роли, вход в админку

Помогу с продвижением: продвижение сайтов белыми методами — вывожу сайты в топ Яндекса белыми методами.

Начинать надо с доступов, потому что это самая частая дыра и самая дешёвая в закрытии. Порядок действий такой.

Инвентаризация. Выпишите все точки входа: панель хостинга, SSH или FTP, база данных, админка CMS, почта на домене, регистратор домена. По каждой — кто имеет доступ сейчас и кто имел раньше. Всё, что не нужно, удаляется, а не «отключается на всякий случай». Пароли — длинные и разные, в менеджере паролей, а не в переписке; пароль, который хоть раз пересылался в мессенджере, считается скомпрометированным. Двухфакторная аутентификация включается везде, где она есть, и в первую очередь у регистратора домена: угон домена — единственный сценарий, после которого восстанавливать нечего.

Роли. Не выдавайте права администратора там, где хватает редактора. Контент-менеджеру не нужны права на установку плагинов и правку файлов. В популярных CMS правку файлов темы из админки лучше отключить совсем — тогда даже украденный пароль администратора не даёт залить бэкдор через веб-интерфейс.

Общий разбор: как продвигать сайт в Яндексе:

0:55

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

Обновления и чужой код

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

Смежный материал по теме — «HTTPS: Как защитить свой сайт и защитить своих пользователей».

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

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

Хостинг, права на файлы и резервные копии

Уровень сервера закрывает то, что не закрывается внутри CMS. Здесь важны несколько вещей. Изоляция сайтов: разные сайты — разные аккаунты или хотя бы разные пользователи системы, иначе взлом одного означает взлом всех.

Права на файлы. Типовые значения: каталоги 755, файлы 644, конфигурационный файл с доступом к базе — строже. Права 777 не должны встречаться нигде; если что-то работает только с ними, проблема в настройке сервера, а не в правах.

Запрет выполнения скриптов в каталоге загрузок. Папка, куда пользователи и редакторы кладут картинки, не должна исполнять PHP. Это одно правило в конфигурации закрывает целый класс атак с загрузкой файла под видом изображения.

Актуальная версия PHP. Сайты годами работают на версиях, снятых с поддержки, потому что «работает же». Снятая с поддержки версия не получает исправлений безопасности — это такая же дыра, как непропатченный плагин.

Если нужна помощь по теме — заказать сайт.

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

Параметр копии	Как обычно	Как надо
Где хранится	Тот же сервер, та же папка	Минимум одна копия вне хостинга
Глубина	Одна последняя	Несколько точек за 30 дней и более
Состав	Только файлы или только база	Файлы и база одной датой
Проверка	Никогда не разворачивалась	Пробное восстановление раз в квартал
Доступ	Тот же пароль, что у хостинга	Отдельные учётные данные

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

Если нужны детали, смотрите «Как продвинуть сайт в поисковиках».

Мониторинг и регламент: что делать регулярно

Защита не бывает стопроцентной, поэтому вторая линия — раннее обнаружение. Чем меньше времени чужой код провёл на сайте, тем дешевле последствия для поиска.

• Контроль целостности файлов. Инструмент фиксирует состояние файлов и сообщает об изменениях. Появление нового PHP-файла в каталоге загрузок — почти всегда взлом.
• Уведомления панелей вебмастера на живую почту. Это бесплатный внешний сторож.
• Контроль числа страниц в поиске. Резкий рост — сигнал генерации.
• Логи сервера. Всплеск обращений к файлу входа, серии ответов 404 по несуществующим адресам расширений, обращения к архивам и файлам конфигурации.
• Внешняя проверка доступности и содержимого — сервис, который раз в несколько минут запрашивает главную и ключевые страницы и сравнивает ответ.
• Отчёт по поисковым запросам в Вебмастере: появление показов по запросам, к вашему бизнесу отношения не имеющим, означает, что чужие страницы уже в индексе.

Что делать, если сайт уже заражён

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

1. Зафиксировать состояние. Снять копию файлов и базы как есть — она понадобится, чтобы понять способ проникновения и не потерять данные, добавленные после последнего бэкапа.
2. Закрыть сайт от посетителей на время работ, отдавая корректный ответ о временной недоступности. Это защищает и посетителей, и позиции: короткая техническая пауза для поиска безопаснее, чем несколько дней раздачи вредоносного кода.
3. Сменить все доступы: хостинг, SSH и FTP, база данных, все административные учётные записи CMS, почта на домене, регистратор. Одновременно, а не по одному.
4. Проверить список пользователей в CMS и на сервере. Учётные записи, которых вы не создавали, — удалить.
5. Восстановить из заведомо чистой копии, если она есть. Это быстрее и надёжнее ручной чистки.
6. Если копии нет — чистить руками: сверить файлы ядра и темы с оригинальными дистрибутивами, проверить конфигурационные файлы, файлы правил веб-сервера в корне и подпапках, каталог загрузок на предмет исполняемых файлов, задания планировщика, а в базе — таблицы с настройками и содержимым страниц на предмет посторонних скриптов.
7. Закрыть причину. Обновить ядро и все расширения, удалить неиспользуемые, поднять версию PHP, выставить корректные права.
8. Удалить мусорные страницы из индекса: отдавать по ним ответ «страница не найдена» или «удалено», при большом объёме — закрыть чужие каталоги правилами обхода и отправить их на удаление через панель вебмастера.
9. Запросить перепроверку в Яндекс.Вебмастере и Google Search Console — до этого метка не снимется.
10. Следить неделю. Повторное появление файлов означает, что бэкдор остался.

Меры, которые дают только ощущение защиты

Часть популярных советов не вредна, но и не защищает, а вытесняет из головы то, что действительно работает.

Мера	Что о ней думают	Как на самом деле
Установка HTTPS	«Сайт защищён»	Шифрует канал между браузером и сервером. От взлома через уязвимость плагина не спасает никак
Скрытие версии CMS	«Бот не поймёт, что ломать»	Версия определяется по десятку косвенных признаков. Полминуты работы сканера
Перенос страницы входа	«Перебор не найдёт админку»	Адрес всплывает в служебных ответах и логах. Зато регулярно теряется доступ к своему сайту
Смена префикса таблиц базы	«Защита от инъекций»	Мелкое неудобство для атакующего. Уязвимость в коде остаётся уязвимостью
Антивирус хостинга	«Он всё найдёт»	Находит известные сигнатуры. Свежий бэкдор и вставки в базе проходят мимо
Плагин безопасности «в один клик»	«Поставил и забыл»	Полезен как инструмент. Не заменяет обновлений, паролей и резервных копий

Сведу профилактику в регламент. Он не требует ни специального софта, ни бюджета — только дисциплины.

Периодичность	Что делать
Один раз, сейчас	Инвентаризация доступов, удаление лишних учётных записей, менеджер паролей, двухфакторная аутентификация на домене, хостинге и почте, запрет исполнения PHP в загрузках, корректные права на файлы
Еженедельно	Обновление ядра и расширений, просмотр списка запросов и числа страниц в поиске, проверка уведомлений панелей вебмастера
Ежемесячно	Проверка списка пользователей CMS, ревизия неиспользуемых плагинов и тем, просмотр логов на всплески обращений к входу
Ежеквартально	Пробное восстановление из резервной копии, проверка версии PHP, смена паролей административных учётных записей
При смене подрядчика	Отзыв всех выданных доступов в тот же день, а не «когда закончим проект»

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

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

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

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

Достаточно ли поставить плагин безопасности? Нет. Он закрывает перебор паролей и даёт мониторинг, но не обновляет за вас плагины, не делает копии вне хостинга и не отзывает старые доступы. Уязвимость в устаревшем расширении он не закроет.

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

Что делать с тысячами спам-страниц, которые попали в индекс? Отдавать по ним ответ о том, что страница удалена, и отправить каталоги на удаление через панель вебмастера. Закрывать их правилами обхода без удаления не стоит: закрытая от обхода страница может остаться в индексе дольше, чем удалённая.

Коротко

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

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