Сайт заблокирован хостинг-провайдером: что делать прямо сейчас и как разблокировать за сутки

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

Что значит «сайт заблокирован хостинг-провайдером» и почему это происходит

Когда говорят «сайт заблокирован хостинг-провайдером», обычно имеют в виду одну из трёх ситуаций. Хостер либо приостановил отдачу сайта (домен резолвится, но возвращается заглушка «аккаунт приостановлен»), либо закрыл доступ к панели управления и FTP/SSH, либо сделал и то, и другое одновременно. Файлы при этом физически остаются на сервере — их не удаляют. Это важно: пока аккаунт «приостановлен», а не «закрыт», у вас всё ещё есть данные, к которым можно получить доступ через переговоры.

Причин, по которым хостер заблокировал сайт, обычно несколько типовых:

• Малварь и вирусы. Бэкдоры в файлах, JS-инжекты на страницы, web-шеллы в wp-content/uploads/ — самая частая причина. Хостер либо сам обнаружил их сканером (ImunifyAV, AI-Bolit), либо получил жалобу от Yandex Safe Browsing / Google Safe Browsing.
• Рассылка спама с вашего домена. Бэкдор использует функцию mail() или прямые SMTP-коннекты, отправляя десятки тысяч писем за час. Хостер видит это в логах исходящей почты и блокирует превентивно.
• Абуз-репорт извне. На ваш домен или IP пришла жалоба от внешней площадки: фишинг, нарушение авторских прав, distributed-атака. Хостер обязан отреагировать в течение 24 часов.
• Превышение лимитов нагрузки. CPU 100% несколько часов подряд, MySQL-соединения упёрлись в лимит — это либо ботнет на вашем сайте, либо плохо написанный плагин, либо реальный DDoS. Shared-хостинг блокирует, чтобы остальные клиенты не страдали.
• Неоплата или истёкший домен. Тут технически вируса нет, но симптом тот же: сайт не работает, в панель не пускают. Проверяйте баланс в первую очередь.

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

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

Первые шаги: 30 минут после получения письма

Когда хостинг заблокировал сайт, всё, что вы сделаете в первые полчаса, влияет на скорость восстановления. Главная задача — зафиксировать состояние и получить рычаги, а не «срочно всё чинить». Действия по порядку.

Сохраните само письмо хостера и сделайте скриншот

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

Запросите бэкап текущего состояния — даже заражённого

Если в панели хостинга ещё работает функция «Резервная копия» — выгрузите архив прямо сейчас, до начала любых правок. Файлы и БД «как есть» нужны для двух целей: страховка (если что-то пойдёт не так в процессе чистки, вы откатитесь), и образец заражения для анализа (где именно сидел бэкдор, какие даты модификации, как код попал внутрь).

Откройте тикет в саппорт с правильной формулировкой

Не пишите «помогите, всё сломалось». Напишите коротко и по делу: «Здравствуйте, получил уведомление о блокировке аккаунта за вредоносный код. Прошу: 1) предоставить read-only доступ к файлам и БД для расследования; 2) выслать отчёт сканера со списком заражённых файлов; 3) выгрузить логи веб-сервера и почты за последние 7 дней. Гарантирую завершить чистку за 24–48 часов и не возобновлять работу до подтверждения хостинга».

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

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

Большинство хостеров (Beget, Reg.ru, Timeweb, Sprinthost) идут навстречу, если видят адекватного клиента. У каждого свои внутренние процедуры, но логика одинаковая: либо открывают доступ к FTP в режиме read-only, либо дают временный SSH-аккаунт с ограничениями, либо разрешают выгрузить полный бэкап для работы на стороннем сервере.

Что просить у хостера

• Список заражённых файлов. Если хостер уже прогнал сканер — у него есть текстовый отчёт с путями. Просите его в первую очередь.
• Read-only доступ к файлам и БД. Чтобы можно было хотя бы посмотреть код и таблицы, не отдавая малварь в работу.
• Логи веб-сервера. Минимум за 7 дней — access.log и error.log. По ним видно, через какой URL произошла первичная компрометация.
• Логи почты. Если блок за спам — maillog покажет, какой PHP-скрипт инициировал отправку.
• Бэкап. Самый свежий доступный архив файлов и БД, желательно за неделю до блокировки (большая вероятность, что в нём уже есть бэкдор, но точка отката лишней не бывает).

Шаблон письма для саппорта

Здравствуйте.

Получил уведомление о приостановке аккаунта [логин/имя сайта] от [дата] в связи с обнаружением вредоносного кода. Готов оперативно решить проблему.

Прошу:

1. Выслать отчёт антивирусного сканера со списком заражённых файлов.
2. Открыть доступ к FTP/SSH в режиме read-only для диагностики и чистки.
3. Предоставить выгрузку access.log и error.log за последние 7 дней.
4. Прислать ссылку на ближайший доступный бэкап.

Сайт работать не будет до окончания чистки. После завершения работ свяжусь с пересканированием. Срок — 24–48 часов.

С уважением, [имя, контакты].

Такой текст обычно проходит через первую линию поддержки без переключения на «специалиста по безопасности» — потому что в нём уже есть конкретика и нет паники. У хостеров уровня Beget или Timeweb время ответа на такой тикет — 30–90 минут в рабочие часы.

Диагностика: что искать в файлах и БД

Когда саппорт открыл read-only доступ — начинается техническая часть. Если вы уже сталкивались с лечением WordPress, многое будет знакомо. Подробный разбор всех признаков заражения и поиска бэкдоров я делал в статье «Сайт на WordPress взломали: что делать в первые 30 минут» — здесь только ключевые места и команды, которые работают в 80% случаев.

Где обычно сидит малварь

1. wp-content/uploads/ — папка для медиа, где не должно быть ни одного .php файла. Если есть — это web-шелл с вероятностью 99%.
2. Корень сайта — wp-config.php, index.php, .htaccess. Аномальный размер (например, wp-config.php 50 КБ вместо 3 КБ) или мусорные include-строки в начале — сразу признак инжекта.
3. wp-content/plugins/ — папки плагинов, которых вы не устанавливали. Особенно с короткими именами вроде wpcfg, wp-system, seo-tools, fancyboxx.
4. Тема (wp-content/themes/.../functions.php) — инжекты в начале или в конце файла, обфусцированный код, base64_decode.
5. База данных — таблица wp_users на предмет лишних админов, wp_options (поля siteurl, home, active_plugins), wp_posts на инжекты в шаблонные посты или скрытые публикации.

Команды для поиска

Через SSH (если хостер открыл доступ) ищем подозрительные PHP-файлы в uploads:

find wp-content/uploads -type f -name "*.php"

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

grep -rn "eval(base64_decode" wp-content/ 2>/dev/null
grep -rn "eval(gzinflate" wp-content/ 2>/dev/null
grep -rn "@assert\|create_function\|preg_replace.*\/e" wp-content/ 2>/dev/null
grep -rn "FilesMan\|WSO 2\|c99shell\|r57shell" wp-content/ 2>/dev/null

Файлы, изменённые за последние 14 дней (часто видны «свежие» правки атакующего):

find . -type f -name "*.php" -mtime -14 -not -path "./wp-content/cache/*"

В БД смотрим лишних админов:

SELECT ID, user_login, user_email, user_registered
FROM wp_users
WHERE ID IN (
  SELECT user_id FROM wp_usermeta
  WHERE meta_key = 'wp_capabilities'
  AND meta_value LIKE '%administrator%'
);

Если в выдаче есть пользователь, которого вы не создавали (особенно недавнее user_registered с подозрительным email) — это почти наверняка бэкдор-аккаунт.

Лечение: чистка + переустановка ядра WP

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

1. Скачайте свежий WordPress с официального сайта — ru.wordpress.org/download. Не из бэкапа, не из «зеркал», только из первоисточника.
2. Удалите все файлы ядра. Кроме wp-content/ и wp-config.php — всё остальное в корне сайта снести и распаковать чистый дистрибутив на их место.
3. Переустановите все плагины из официального репозитория. Не копируйте wp-content/plugins/ из бэкапа целиком — там может сидеть бэкдор. Список активных плагинов узнаете из БД (wp_options, поле active_plugins), скачивайте каждый заново с wordpress.org/plugins.
4. Проверьте тему. Если тема кастомная (своя) — пройдитесь по ней через grep на паттерны малвари. Если это популярная тема (Astra, GeneratePress, Avada) — переустановите из официального источника.
5. Очистите wp-content/uploads/ от PHP-файлов. Все .php в этой папке — удалить без сожаления. Картинки и документы оставить.
6. Проверьте .htaccess на инжекты. Должен быть стандартным WordPress-блоком. Все RewriteRule на неизвестные домены — удалить.
7. Очистите БД от лишних админов и инжектов в wp_options. Поля siteurl и home должны указывать на ваш реальный домен, а не на сторонний.
8. Смените все пароли в правильном порядке: панель хостинга → FTP/SSH → БД → админка WordPress. Между шагами очищайте cookies браузера.

Если вирус был замечен по симптому «сайт редиректит на казино» — отдельная статья со всеми типичными местами инжекта: «Сайт перенаправляет на казино или рекламу — как найти и удалить вредоносный код». Часто именно redirect-инжект становится причиной, по которой хостер заблокировал сайт за вирус.

Возврат сайта в онлайн: что писать хостеру

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

Шаблон отчёта об устранении

Здравствуйте.

Чистка по тикету [номер] завершена. Краткий отчёт:

Что нашли:

• N заражённых файлов в wp-content/uploads/ (web-шеллы, типа FilesMan).
• Инжект eval(base64_decode) в начале wp-config.php.
• Лишний админ wp_admin2 в БД (создан [дата]).
• Инжект в .htaccess с редиректом на сторонний домен.

Что сделали:

• Удалили все PHP-файлы из wp-content/uploads/.
• Переустановили ядро WordPress версии X.X из официального дистрибутива.
• Переустановили все плагины из репозитория wordpress.org.
• Очистили wp-config.php и .htaccess до стандартного состояния.
• Удалили лишнего админа из wp_users.
• Сменили пароли: панель хостинга, FTP, БД, все админы WP.

Превентивные меры:

• Обновили ядро WordPress и все плагины до последних версий.
• Установили Solid Security Pro (или Wordfence) для мониторинга.
• Включили двухфакторную аутентификацию для админов.
• Настроили автобэкап в стороннее хранилище.

Прошу пересканировать сайт и при отсутствии находок снять блокировку. Готов к дополнительным проверкам.

Время рассмотрения такого отчёта обычно 2–8 рабочих часов. Beget и Timeweb обычно укладываются в 2–4 часа; Reg.ru может тянуть до суток; Sprinthost — 4–6 часов. После пересканирования и снятия блока сайт возвращается в онлайн.

Профилактика: чтобы хостер не заблокировал повторно

По моему опыту, около 30% сайтов, которых уже однажды хостер заблокировал за вирус, попадают в ту же ловушку повторно в течение 3–6 месяцев. Причина простая: после чистки владелец возвращается к старым привычкам — забывает обновлять, использует слабые пароли, ставит nulled-плагины. Чтобы блокировки больше не было, нужен минимальный гигиенический набор.

• ✓ Обновления раз в неделю. Ядро, плагины, темы. Через автопилот (Solid Security умеет) или вручную — но регулярно. 80% компрометаций — через устаревший плагин.
• ✓ Никаких nulled-плагинов. «Бесплатный Elementor Pro» или «Avada от Codecanyon за 0 ₽» — это всегда с бонусом в виде бэкдора. Только официальные источники или платные подписки.
• ✓ Аудит юзеров раз в месяц. Удалите всех админов, которыми не пользуетесь. Бывших разработчиков, временных сотрудников, тестовые аккаунты.
• ✓ 2FA для всех админов. WP 2FA, Solid Security, Wordfence — любой плагин с поддержкой Google Authenticator. Слабый пароль с 2FA всё равно надёжнее сильного без 2FA.
• ✓ Сканер раз в неделю. Wordfence или Solid Security сканируют файлы по расписанию и присылают отчёт. Бэкдор будет найден в течение 7 дней, а не через 3 месяца, когда хостер заблокирует.
• ✓ Бэкап в стороннее хранилище с retention 30 дней. UpdraftPlus + Yandex Object Storage или Selectel S3. Если что — откатитесь на 30 дней назад без потерь.
• ✓ Мониторинг исходящей почты. На VPS — лимит mail() через PHP-конфиг. На shared-хостинге — раз в неделю в панели смотреть «исходящая почта»: цифры должны быть стабильными.

Когда стоит обратиться к специалисту

Большинство случаев «сайт заблокирован хостинг-провайдером за вирус» решаются самостоятельно за 1–2 дня, если у вас есть базовое понимание WordPress и SSH. Но есть ситуации, в которых самостоятельная попытка обычно делает хуже, и проще сразу делегировать.

• Уже было 2+ блокировки за полгода. Это значит, что простой чистки недостаточно — где-то есть постоянная дыра, которую вы не закрываете.
• Бэкдор живёт уже несколько месяцев. Старые заражения зарываются глубоко: в БД, в темах, в cron, в правах файлов. Без полного аудита поверхностная чистка не помогает.
• Нет работающих бэкапов и сайт коммерческий. Каждый день простоя — деньги. Эксперимент «попробую сам» здесь стоит дороже, чем работа специалиста.
• На аккаунте несколько сайтов и заражены все. Это cross-site contamination, после чистки одного остальные перезаразят его обратно. Нужна синхронная работа.
• Хостер угрожает удалением аккаунта. Тут счёт идёт на часы — успеть выгрузить данные и вернуть сайт онлайн до того, как удалят бэкапы.

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

За что хостинг-провайдер может заблокировать сайт?

Чаще всего — за вредоносный код (малварь, web-шеллы, JS-инжекты), за рассылку спама с домена, за абуз-репорт извне (фишинг, DMCA), за превышение лимитов нагрузки (ботнет на сайте или плохо написанный плагин), либо за неоплату. Конкретную причину должна быть прописана в письме саппорта — если формулировка размытая, прямо просите указать пункт правил.

Сколько времени занимает разблокировка?

Обычно 1–2 дня. День на чистку, ещё несколько часов на пересканирование сайта хостером и снятие блока. У Beget и Timeweb — быстрее, у Reg.ru может затянуться до суток. Если случай сложный (заражено несколько сайтов на аккаунте, нет бэкапов) — до 3 дней.

Может ли хостер заблокировать сайт без предупреждения?

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

Что делать, если я не могу попасть в админку из-за блокировки?

Если хостер заблокировал только отдачу сайта, но оставил доступ к панели и FTP — лечите через FTP/SSH, в админку WordPress можно попасть только после разблокировки. Если закрыт весь аккаунт — пишите в саппорт и просите read-only доступ для расследования (шаблон письма выше). Через панель хостинга также часто можно работать с базой через phpMyAdmin даже когда сам сайт отключён.

Нужно ли менять хостинг после блокировки?

Обычно — нет. Хостер выполнил свою работу: обнаружил проблему и предотвратил вред другим клиентам. Это нормальная практика, а не повод для обиды. Менять хостинг есть смысл только если: саппорт неадекватный (не идёт на контакт сутками), нет инструментов для самостоятельной чистки (нет SSH, нет нормального файлового менеджера), или хостер регулярно блокирует за ложные срабатывания сканера. В остальных случаях лучше остаться и устранить причину.