Если ваш сайт взломали, первое, что нужно сделать — не паниковать, а максимально ограничить ущерб: изолировать сайт, обновить все доступы, восстановить его из чистой резервной копии, удалить вредоносный код и внедрить надежные меры безопасности. В критические первые 24 часа важно перекрыть доступ злоумышленника, защитить посетителей и данные от дальнейшего вреда, не допустить негативных сигналов поисковым системам и запустить сайт заново, уже подтверждённым как безопасный.
Взлом сайта — это не просто замена главной страницы на чужеродный контент. Злоумышленники зачастую предпочитают оставаться незаметными: создают спам-страницы, подменяют формы оплаты, добавляют администраторские аккаунты, вставляют скрытые перенаправления в базу данных или используют сервер для массовой рассылки спама. Поэтому восстановление — это не просто удаление файлов. Необходим системный подход, сохраняющий доказательства, подтверждающий очистку и предотвращающий повторные атаки.
В этом руководстве мы расскажем о пяти первых неотложных шагах по восстановлению сайта после взлома, объясняя технические детали простым и практичным языком. Неважно, WordPress это, индивидуальная разработка, интернет-магазин или корпоративный сайт — основные принципы одинаковы: изоляция, блокировка доступа, возврат к чистому состоянию, проверка и усиление защиты.
Признаки взлома сайта
Взлом не всегда сопровождается видимым крахом. Некоторые атаки могут длиться неделями, оставаясь незамеченными. Если вы обнаружили хотя бы один из следующих признаков, стоит воспринимать это не как обычную ошибку, а как инцидент безопасности.
- В сниппетах Google появляются ссылки на азартные игры, лекарства, криптовалюту или взрослый контент.
- Браузер предупреждает о вредоносном сайте, фишинге или небезопасном соединении.
- Невозможно войти в панель администратора или появляются незнакомые администраторские аккаунты.
- Внезапный рост нагрузки на процессор, оперативную память, диск или трафик электронной почты на сервере.
- Неожиданные изменения в файлах .htaccess, index.php, wp-config.php или файлах темы.
- Перенаправление посетителей на сторонние домены.
- Со взломанного хостинга массово отправляется почта без вашего ведома.
- Отключение защитных плагинов или удаление логов безопасности.
Например, если блог, обычно принимающий 2000 посетителей в день, внезапно начинает получать 30 000 запросов, это скорее всего не рост аудитории, а активность ботов, перебор паролей или выполнение вредоносных скриптов. Аналогично, если тема размером 10 МБ за несколько дней выросла до 80 МБ — это признак загрузки бэкдоров.
Первые 30 минут после взлома: сохраняйте спокойствие и собирайте доказательства
Не стоит сразу удалять все подряд файлы — это может стереть следы атаки, усложнить очистку и привести к восстановлению из зараженной резервной копии. Сначала сделайте «снимок» текущего состояния: зафиксируйте дату и время, предупреждения, затронутые URL, подозрительных пользователей, последние обновления и логи хостинга. Эти данные помогут технической поддержке и специалистам по безопасности быстрее поставить диагноз.
Особенно важно вести журнал событий на сайтах с интернет-магазинами, личными кабинетами и обработкой персональных данных. Записывайте, какие данные могли быть затронуты, когда началась атака, с каких IP-адресов был несанкционированный доступ. Если вы размещаете сайт на Hostragons, при обращении в поддержку укажите домен, папку с сайтом, временной интервал и сообщения об ошибках — это ускорит реакцию. Подробнее о выборе хостинга читайте на странице Пакеты безопасного веб-хостинга.
| Временной интервал | Основная задача | Что делать | Чего избегать |
|---|---|---|---|
| Первые 0-30 минут | Ограничить ущерб | Изолировать сайт, зафиксировать доказательства, сохранить логи | Удалять все файлы подряд |
| 30-90 минут | Перекрыть доступ | Обновить пароли, API-ключи и админ-сессии | Менять только пароль WordPress |
| 1-4 часа | Вернуться к чистой копии | Восстановить из проверенной резервной копии или изолировать заражённые файлы | Доверять резервной копии, сделанной после взлома |
| 4-24 часа | Проверить и усилить защиту | Сканирование, обновления, WAF, права доступа, мониторинг и проверка поисковыми системами | Считать дело законченным сразу после восстановления |
Шаг 1: Изолируйте сайт и ограничьте ущерб
Первое неотложное действие — предотвратить дальнейшее распространение вреда от злоумышленника и вредоносного кода. Это похоже на перекрытие подачи газа перед тушением пожара. Сайт не обязательно закрывать полностью, но необходимо исключить риск попадания посетителей на фишинговые страницы, поддельные формы оплаты или заражённые файлы.
Переведите сайт в режим обслуживания или временно ограничьте доступ
Для WordPress можно включить страницу обслуживания, в индивидуальных системах вернуть временный ответ 503 или разрешить доступ только с определённых IP-адресов. Код 503 сообщает поисковикам, что сайт временно недоступен — это лучше, чем показывать пустую страницу или ошибку 404. Если сайт распространяет вредоносное ПО или фишинг, лучше полностью ограничить доступ.
- Не оставляйте панель администратора открытой для всех — используйте ограничение по IP.
- Временно отключите исполнение PHP в папках для загрузки файлов.
- Если с сервера рассылается спам — остановите SMTP-доступ.
- Если затронуты страницы оплаты — временно отключите интеграцию с платежными системами.
Сохраните логи и текущее состояние файлов
При изоляции убедитесь, что сохраняются все логи доступа, ошибки, FTP-записи и история действий в панели управления. Во многих атаках точкой входа становится устаревший плагин, слабый FTP-пароль, скомпрометированный админ-аккаунт или неправильные права на запись. Без логов сложно найти корень проблемы, и сайт может быть взломан повторно через несколько дней.
Полезно скачать файлы сайта на локальный компьютер для анализа — но делать это нужно на защищённом устройстве с антивирусом, так как в файлах может быть вредоносный код. Резервные копии, сделанные во время атаки, хранятся только для анализа и не должны использоваться для восстановления. Ознакомьтесь с автоматизированными решениями резервного копирования на странице решения хостинга с автоматическим резервным копированием.
Шаг 2: Сбросьте все доступы, пароли и ключи
Многие владельцы сайтов после взлома меняют только пароль администратора WordPress. Но точка входа злоумышленника может быть FTP, база данных, панель хостинга, SSH-ключ, почтовый аккаунт, API-токен или интеграция с внешними сервисами. Поэтому второй срочный шаг — комплексная смена всех учетных данных.
Какие пароли стоит обновить?
- Пароль панели управления хостингом.
- Пароли FTP, SFTP и SSH.
- Пароли пользователей базы данных и настройки подключения.
- Админ- и редакторские аккаунты CMS.
- Почтовые аккаунты, особенно отправляющие письма от имени домена.
- API-ключи, токены платежных систем, доступы к CDN и DNS-панелям.
- Ключи для Git, деплоя, автоматизации и резервного копирования.
Пароль должен быть сложным — не менее 16 символов, уникальным и непредсказуемым. Использование одного и того же пароля на разных сервисах подвергает сайт прямой угрозе при утечках. Везде, где возможно, включите двухфакторную аутентификацию (2FA). Особенно для админ-аккаунтов 2FA значительно снижает риск перебора паролей.
Удалите подозрительных пользователей и завершите активные сессии
Если в CMS есть незнакомые пользователи, недостаточно просто заблокировать их — нужно зафиксировать их роли, дату создания и действия, а затем удалить. В WordPress можно сбросить все сессии пользователей, обновив секретные ключи безопасности. В индивидуальных системах очистите таблицу сессий. В интернет-магазинах проверяйте не клиентские аккаунты, а учетные записи сотрудников с правами управления.
Пример: злоумышленник мог получить доступ к старому аккаунту редактора и загрузить веб-шелл через плагин с правом загрузки файлов. Если изменить пароль только основного администратора, доступ редактора останется активным. Пересмотрите матрицу полномочий, удалите лишних администраторов и редакторов. Также убедитесь в безопасности управления доменом, DNS и SSL. Для этого полезны страницы управление доменами и безопасность DNS и Решения по SSL сертификатам.
Шаг 3: Восстановитесь из чистой резервной копии или изолируйте заражённые области
Самый быстрый и надежный способ — откатиться к проверенной и чистой резервной копии, сделанной до атаки. Но важно, чтобы копия действительно была чистой. Если резервная копия была сделана после начала взлома, она может содержать вредоносный код. Поэтому дату копии, логи и время изменения файлов нужно оценивать комплексно.
Как выбрать чистую резервную копию?
Определите, когда впервые появились признаки взлома. Например, если в Google Search Console пришло предупреждение 12 марта, а в логах сервера подозрительные запросы появились 5 марта, копия от 12 марта уже ненадежна. Рассматривайте копии от 4 марта и раньше. Перед восстановлением обязательно просканируйте копии на вредоносный код.
- Дата резервной копии должна быть раньше предполагаемого начала атаки.
- В копии не должно быть незнакомых администраторов.
- Проверьте целостность файлов ядра CMS, сравните с официальными пакетами.
- В базе данных ищите скрытые iframe, base64-код, подозрительные скрипты и спам-контент.
- После восстановления обязательно обновите всё программное обеспечение.
Что делать, если резервной копии нет?
Если чистой копии нет, восстановление требует осторожности. Сделайте копию сайта в staging-среду или временную папку. Заражённые файлы поместите в карантин, ядро CMS переустановите из официальных источников, тему и плагины замените на чистые версии. Папки с загрузками пользователей — частое место для скрытых троянов, особенно опасны файлы с расширениями .php, .phtml, .phar.
База данных требует тщательной очистки. Вредоносные перенаправления могут храниться не в файлах, а в настройках сайта, виджетах, параметрах темы или содержимом страниц. При поиске подозрительных элементов проверяйте на наличие таких ключевых слов, как script, iframe, eval, atob, base64_decode, gzinflate, shell_exec, document.location. Но помните, что не каждый base64-код вредоносен — ошибочное удаление может сломать сайт. Обязательно сделайте резервную копию базы перед чисткой.
Шаг 4: Удалите вредоносный код, обновите системы и закройте уязвимости

Просто восстановить сайт недостаточно. Если не выяснить, как именно злоумышленник проник, он сможет вернуться через ту же дыру. Цель четвёртого шага — завершить очистку файлов и базы, исправить уязвимости и ошибки конфигурации.
Контрольный список по файловой системе
- Отсортируйте файлы по дате изменения и проверьте неожиданные правки.
- Сравните ядро CMS с официальной версией.
- Проверьте папки загрузок на наличие исполняемых файлов.
- Просмотрите скрытые файлы (.user.ini, .htaccess и подобные), которые могут использоваться для перенаправлений.
- Установите корректные права доступа: обычно 644 для файлов и 755 для папок.
- Удалите неиспользуемые темы, плагины, старые архивы резервных копий и тестовые папки.
Для WordPress обязательно удаляйте неактивные плагины, а не просто отключайте их. Старые слайдеры, формы или файловые менеджеры, даже если отключены, могут содержать уязвимости. Пиратские темы и плагины часто включают встроенные бэкдоры, которые ставят под угрозу репутацию и безопасность ваших пользователей.
В каком порядке обновлять?
Сначала обновляйте ядро CMS, затем тему и плагины. Если версия PHP устарела, после проверки совместимости перейдите на поддерживаемую современную версию. Сайты на старых версиях PHP остаются уязвимыми, так как не получают обновлений безопасности. Хостинг должен обеспечивать актуальный PHP, изолированные аккаунты, регулярное резервное копирование и защитный файрвол. Подробнее о хостинге на странице Веб-хостинг Hostragons.
Убедитесь, что SSL-сертификат действующий. Хотя SSL не защищает сайт от взлома, он шифрует данные между пользователем и сервером, снижая риск подделки форм. Особенно важно использовать SSL на страницах входа, оплаты и регистрации. Подобрать сертификат можно на странице Купить SSL сертификат.
Шаг 5: Перед запуском проверьте, настройте мониторинг и внедрите постоянную защиту
Пятый шаг — убедиться, что сайт полностью очищен и принять меры, чтобы избежать повторных атак. Если пропустить этот этап, через несколько дней предупреждения и проблемы могут вернуться. Проверка должна включать как технический аудит, так и организационные процессы.
Проверки перед повторным запуском
- Тестируйте главную страницу, страницы входа, оплаты и популярные URL с разных устройств и браузеров.
- Проверьте отчёты о безопасности и ручные санкции в Google Search Console.
- Изучите sitemap.xml и robots.txt на предмет нежелательных страниц.
- Анализируйте логи сервера на наличие повторяющихся ошибок 404, 500, подозрительных POST-запросов и попыток входа.
- Проверьте репутацию почтового сервера — если есть попадание в черные списки, начните процедуру удаления.
- Проверьте работоспособность форм оплаты, обратной связи и загрузки файлов.
Если Google или браузеры пометили сайт как вредоносный, после очистки нужно отправить запрос на повторную проверку. В запросе подробно укажите, что именно было удалено, какие уязвимости закрыты и какие меры приняты. Избегайте общих формулировок — лучше конкретно написать, например: «Удалён устаревший плагин файлового менеджера, обновлены все админ-пароли, отключён запуск PHP в папке загрузок».
Рекомендуемые меры для постоянной защиты
Безопасность — это постоянный процесс, а не одноразовое действие. Даже для небольшого корпоративного сайта рекомендуем иметь план ежемесячного обслуживания. Минимум — еженедельная проверка обновлений, ежедневное резервное копирование, политика сложных паролей и мониторинг логов. Для сайтов с большим трафиком полезны WAF, CDN, расширенная защита от ботов и внешние сканеры безопасности.
| Мера | Что даёт? | Рекомендуемая частота | Приоритет |
|---|---|---|---|
| Автоматическое резервное копирование | Обеспечивает чистую точку восстановления | Ежедневно или еженедельно | Очень высокий |
| Двухфакторная аутентификация (2FA) | Блокирует использование украденных паролей | Постоянно | Очень высокий |
| Обновления CMS и плагинов | Закрывает известные уязвимости | Еженедельный контроль | Высокий |
| WAF и защита от ботов | Фильтрует вредоносные запросы до приложения | Постоянно | Высокий |
| Мониторинг целостности файлов | Уведомляет о неожиданных изменениях | Ежедневно | Средне-высокий |
| SSL и безопасный DNS | Защищает передачу данных и безопасность домена | Постоянно | Высокий |
В корпоративных проектах обязательно прописывайте ответственность: кто отвечает за обновления, кто проверяет бэкапы, кому сообщать о подозрительных событиях и когда переводить сайт в режим обслуживания. Это позволяет команде работать слаженно и без паники в критический момент.
Дополнительные шаги для SEO, репутации и доверия пользователей
Даже после технической очистки необходимо уделить внимание SEO. Злоумышленники часто создают тысячи спам-страниц. Если они попали в индекс, после очистки нужно настроить корректное возвращение 404, 410 или перенаправления. Массированное перенаправление спама на главную страницу может ухудшить рейтинг — Google это воспринимает негативно.
Проверьте в Search Console индексированные страницы, проблемы безопасности, ручные санкции и sitemap. После удаления вредоносного контента отправьте обновленный sitemap. При появлении опасных заголовков в результатах поиска можно запросить повторное сканирование чистых страниц.
Для доверия пользователей необходима прозрачная, но спокойная коммуникация. Если пострадали личные данные, платежная информация или аккаунты, учитывайте юридические обязательства и процедуры защиты данных. Для простых сайтов ситуация проще, но для e-commerce и систем с регистрацией — требуется профессиональный подход.
Типичные ошибки, которых стоит избегать
Некоторые ошибки при восстановлении могут нанести больше вреда, чем сама атака. Самая частая — думать, что проблема решена сразу после запуска сайта. Если остался бэкдор, злоумышленник вернётся снова. Вторая ошибка — восстановление из неподтверждённой резервной копии, которая содержит вредоносный код.
- Не делать резервную копию перед очисткой.
- Удалять только видимые вредоносные файлы, не исследуя корень проблемы.
- Использовать устаревшие версии плагинов или темы.
- Предоставлять всем администраторам неограниченные права.
- Удалять или перезаписывать логи без анализа.
- Полагаться на SSL как на единственную защиту.
- Скачивать темы и плагины с ненадёжных источников.
Особенно опасно давать избыточные права на файлы (например, 777). Это упрощает работу злоумышленнику. Принцип минимально необходимых прав должен соблюдаться строго — право на запись должно быть только там, где это действительно нужно.
Краткое резюме неотложных действий
При взломе сайта порядок действий критичен: сначала изолируйте сайт, затем обновите все доступы, восстановитесь из чистой копии или проведите тщательную очистку, закройте уязвимости и только после этого запускайте сайт, удостоверившись в его безопасности. Такой подход минимизирует технические риски и потери в SEO и репутации.
Хостинг Hostragons предлагает надежную инфраструктуру, SSL-сертификаты, управление доменами и резервное копирование, чтобы повысить устойчивость вашего сайта. Если нужно, оцените текущий хостинг и начните с просмотра Пакеты хостинга Hostragons и Проверка домена и управление именем. Главное — выбрать баланс между скоростью, безопасностью, резервным копированием и поддержкой.
Часто задаваемые вопросы
Стоит ли сразу отключать сайт после взлома?
Если сайт распространяет вредоносное ПО, перенаправляет пользователей или подменяет формы оплаты — доступ нужно ограничить немедленно. В менее критичных случаях достаточно включить режим обслуживания с кодом 503 или ограничить доступ по IP. Цель — защитить посетителей и сообщить поисковикам, что это временная мера.
Всегда ли достаточно восстановиться из резервной копии?
Нет. Резервная копия ускоряет восстановление, но если не выявить способ проникновения, сайт может быть взломан повторно. После отката обязательно меняйте пароли, обновляйте софт, проверяйте права доступа и устраняйте уязвимости в теме, плагинах и конфигурации.
Потеряет ли сайт позиции в поиске после взлома?
При быстром и правильном реагировании долгосрочных потерь в SEO может не быть. Но если спам-страницы попали в индекс, Google показывает предупреждения или сайт долго не работает — позиции снижаются. После очистки нужно проверить Search Console, отправить запрос на переиндексацию и удалить спам-URL.
Почему мой WordPress-сайт постоянно взламывают?
Частые причины — оставшиеся бэкдоры, устаревшие плагины, слабые пароли, лишние админ-аккаунты, неправильные права доступа и заражённые резервные копии. Вместо удаления только видимого вреда, проводите тщательный аудит и обновляйте все учетные данные.
Влияет ли выбор хостинга на безопасность сайта?
Да. Изолированные аккаунты, актуальные версии PHP, регулярное резервное копирование, файрвол, сканирование на вредоносный код, быстрая техническая поддержка и поддержка SSL напрямую влияют на безопасность. Безопасный хостинг не гарантирует отсутствие атак, но значительно снижает риски и облегчает восстановление.