Чек-лист безопасности для сайта после инцидента или блокировки

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

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

Когда чек-лист особенно нужен

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

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

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

Что сделать в первые 60 минут

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

1. Зафиксируйте инцидент

Сделайте:

• скриншоты проблемных страниц (обязательно с видимой адресной строкой и датой);
• копию HTML проблемных разделов;
• выгрузку логов веб-сервера, CMS, панели хостинга — с временными метками;
• список времени, когда вы впервые заметили проблему;
• перечень затронутых страниц, доменов и поддоменов.

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

2. Ограничьте доступ

Если есть признаки взлома:

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

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

3. Не удаляйте все подряд

Опасная привычка — чистить сайт «до блеска» без копии. Сначала снимите полный бэкап текущего состояния (даже заражённого), а уже потом удаляйте вредоносный код, спорные материалы или следы вторжения. Заражённый бэкап можно анализировать, а удалённый без следа — нет. К тому же, если вы случайно удалите легитимный контент, восстановить его будет не из чего.

Полный чек-лист проверки после инцидента

Ниже — рабочая последовательность. Лучше идти по пунктам, а не «по ощущениям». Таблица охватывает все ключевые области, которые я проверяю в первую очередь.

Техническая проверка: что искать в первую очередь

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

1. Подозрительные изменения в файлах

Ищите:

• новые файлы в корне сайта (особенно с непонятными именами);
• изменённые шаблоны;
• странные вставки в functions.php, header.php, footer.php;
• длинные закодированные строки;
• редиректы на чужие домены;
• скрытый вывод через CSS или JS.

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

2. Неавторизованные пользователи

Проверьте:

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

Часто злоумышленник не ломает систему «в лоб», а заходит через старый доступ разработчика или слабый пароль. Поэтому проверяйте всех, кто когда-либо имел доступ.

3. База данных

Особое внимание:

• новым записям в таблицах контента;
• подозрительным внешним ссылкам;
• скрытым рекламным вставкам;
• массовым изменениям записей;
• полям с JS-кодом или вредоносными редиректами — особенно в тех полях, которые выводятся на сайте без фильтрации (заголовки постов, описания товаров).

4. Сервер и окружение

Проверьте:

• cron-задачи;
• права на файлы и каталоги (не должно быть 777 без крайней необходимости);
• неизвестные процессы;
• конфигурацию веб-сервера;
• почтовую отправку с домена (не появилась ли массовая рассылка);
• логи аутентификации;
• соседние сайты на том же хостинге.

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

Что проверить, если сайт заблокировали

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

Алгоритм действий

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

На практике уведомление, удаление контента и обращение в Роскомнадзор часто идут параллельно. Не пытайтесь обжаловать блокировку, если контент действительно нарушает закон — сначала устраните нарушение, иначе получите отказ.

Типовые причины, которые стоит перепроверить

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

План восстановления: что делать после очистки

Когда причина устранена, не спешите возвращать сайт в обычный режим. Сначала проверьте базовую устойчивость. Лучше потратить несколько часов на тестирование, чем получить повторный инцидент.

Пошаговое восстановление

1. Поставьте чистую резервную копию (предварительно убедившись, что она не заражена).
2. Обновите CMS, плагины, темы и серверное ПО. Учитывайте, что обновление может сломать кастомные доработки, поэтому сначала протестируйте на копии.
3. Смените все пароли и ключи доступа.
4. Выпустите новые API-ключи и токены.
5. Пересоздайте секреты и соли, если это возможно.
6. Проверяйте сайт в тестовой среде, а не на живом трафике.
7. Включите мониторинг изменений файлов и логов.
8. Верните формы, оплату и интеграции только после теста.

Что особенно важно не забыть

• старые бэкапы тоже могли быть заражены — проверяйте их антивирусом или сравнивайте с эталоном;
• смена одного пароля не спасает, если злоумышленник получил доступ к почте администратора — он восстановит доступ через неё;
• если домен или DNS-записи скомпрометированы (например, подменены MX-записи для перехвата почты), сайт «починится» не до конца;
• если вредоносный код был в кеше, он может возвращаться после восстановления — чистите кэш на всех уровнях.

Мини-чек-лист цифровой гигиены после инцидента

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

Типовые ошибки после взлома или блокировки

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

Чек-лист для руководителя проекта

Если нужен короткий управленческий список, действуйте так:

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

Когда нужен юрист и когда нужен специалист по ИБ

Юрист нужен, если:

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

Специалист по ИБ нужен, если:

• есть признаки взлома;
• был внедрён вредоносный код;
• затронуты серверы, БД, почта или DNS;
• требуется форензика и анализ логов;
• нужно закрыть техническую уязвимость.

На практике эти роли должны работать вместе. По моему опыту, лучший результат даёт именно связка «техника + право»: технический специалист готовит доказательства и устраняет уязвимость, а юрист оформляет процессуальные документы и ведёт переписку с Роскомнадзором. Попытка решить юридическую проблему только техническими методами (или наоборот) часто затягивает разблокировку на месяцы.

FAQ

Как понять, что сайт взломали, а не просто внесли ошибку?

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

Можно ли сначала восстановить сайт, а потом разбираться?

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

Что делать, если на сайте появился запрещённый контент без моего ведома?

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

Какой бэкап считать безопасным?

Тот, который сделан до инцидента, проверен на заражение (например, сравнением с эталоном или сканированием антивирусом) и может быть поднят в тестовой среде без повторного появления проблемы. Никогда не полагайтесь на единственную копию.

Когда идти в суд?

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

Вывод

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