Краткий ответ
Когда сайт падает или взломан, сначала изолируйте его (ничего не удаляйте), определите точное время инцидента и найдите резервную копию, созданную до этого момента. Затем восстановите файлы и базу данных из бэкапа, проверьте целостность, сбросьте пароли и только после этого снова запустите сайт.
Как проявляется проблема
- Сайт показывает ошибку 500, белую страницу или сообщение об ошибке базы данных
- На сайте появляются неизвестные ссылки, реклама или страницы, которые вы не создавали
- Появляются новые административные учетные записи или неизвестные файлы в директории
- Google показывает предупреждение об опасном сайте или сайт удален из индекса
- Хостинг заблокировал аккаунт из-за подозрительной активности или превышения ресурсов
Частые причины
Скомпрометированный административный пароль
Слабый или повторно используемый пароль позволяет злоумышленнику войти как администратор и изменить содержимое или установить вредоносный код.
Устаревший плагин или тема
Уязвимые плагины и темы (особенно те, которые не обновляются) являются наиболее частым входом для атак на WordPress и подобные системы.
Ошибка в конфигурации или обновлении
Неудачное обновление, неправильно измененный файл или конфликт плагинов может обрушить сайт и без атаки.
Проблемы на хостинге
Падение сервера, базы данных или превышение ресурсов могут вызвать недоступность сайта, даже если сайт не взломан.
Вредоносный код на компьютере
Если вы входите на сайт с зараженного компьютера, учетные данные могут быть украдены, а сайт скомпрометирован.
Пошаговое решение
- 1
Изолируйте сайт и сохраните доказательства
Не удаляйте файлы и не переустанавливайте. Если сайт взломан, переведите его в режим обслуживания или временно отключите публичный доступ. Сохраните копию текущего состояния (файлы и базу) для анализа, а затем как можно скорее смените учетные данные (FTP, база, административная учетная запись).
- 2
Определите время инцидента
Просмотрите лог доступа (access log) и лог ошибок (error log) на хостинге (чаще всего в панели управления, например cPanel или Plesk, в разделе логов или статистики, или в директории для логов, которую укажет хостинг). Запишите дату и время, когда появились подозрительные активности или ошибки. Это важно для выбора резервной копии, созданной до этого момента.
- 3
Найдите подходящую резервную копию
В панели хостинга найдите раздел резервных копий (например,
BackupилиBackup Wizard). Если хостинг делает автоматические ежедневные бэкапы, выберите тот, что был до инцидента. Если у вас нет хостингового бэкапа, проверьте, есть ли у вас собственная копия (плагин для бэкапа, ручной экспорт базы и файлов). - 4
Восстановите файлы сайта
Через FTP или файловый менеджер хостинга переименуйте текущую директорию сайта (например,
public_htmlвpublic_html_old) и распакуйте архив резервной копии. Не удаляйте старую директорию, пока не проверите, что все работает. Следите за тем, чтобы не перезаписать конфигурационные файлы, если они не входят в бэкап. Если возможно, сначала восстановите сайт в локальной среде разработки для проверки. - 5
Восстановите базу данных
В панели базы данных (например, phpMyAdmin) создайте новую базу или, если используете существующую, сначала сделайте ее экспорт. Затем, если нужно, удалите существующие таблицы и импортируйте
.sqlфайл из резервной копии. Если префикс таблиц отличается, настройте конфигурацию сайта. Проверьте, что все таблицы импортированы без ошибок. - 6
Проверьте целостность и удалите вредоносный код
Сравните файлы сайта с оригинальной версией (например, повторно скачайте ядро WordPress и темы). Проверьте
wp-config.php,.htaccessи директорию загрузок на подозрительные файлы. Если найдете неизвестные файлы или код, изолируйте их (переименуйте или переместите за пределы публичной директории) и запишите пути. - 7
Сбросьте пароли и ключи
Смените пароль для панели хостинга, FTP, базы данных и всех административных учетных записей на сайте. В WordPress замените ключи
SALTвwp-config.phpна новые значения (например, с помощью генератора наapi.wordpress.org/secret-key/1.1/salt/). Удалите неизвестных пользователей; смена ключей SALT завершит все активные сессии. - 8
Обновите все и снова запустите сайт
Обновите ядро, темы и плагины до последних версий, удалите ненужные плагины и темы. Проверьте, что сайт работает правильно, и верните его в публичный режим. Следите за логами в течение следующих 24 часов.
- 9
Сообщите о проблеме и очистите репутацию
Если сайт был в списке опасных сайтов Google, подайте запрос на повторную проверку в Google Search Console. Если хостинг заблокировал аккаунт, обратитесь в поддержку с объяснением того, что вы сделали. Проверьте, не скомпрометированы ли электронные письма, и уведомите пользователей, если была утечка данных.
Если ничего не помогает: расширенная проверка и изоляция
Если проблема возвращается и после восстановления из бэкапа, возможно, вредоносный код остался в базе (например, в опциях, записях или пользователях) или в файлах за пределами стандартной директории. Тогда сделайте следующее: создайте полностью новую установку на чистом хостинге, импортируйте только содержимое (записи, страницы, медиа) из проверенной копии, а темы и плагины установите из официальных источников. Обязательно просканируйте компьютер, с которого входите. Если сайт был скомпрометирован длительное время, обратитесь в специализированную службу форензики или в поддержку хостинга, которая может просмотреть логи на уровне сервера.
Как избежать повторения
- Регулярно делайте резервные копии (файлы и база) и храните их вне хостинга, как минимум за последние 30 дней.
- Обновляйте ядро, темы и плагины сразу и удаляйте все, что не используете.
- Используйте надежные уникальные пароли и двухфакторную аутентификацию для администраторов и панели хостинга.
- Следите за логами и настройте уведомления о неудачных входах и изменениях файлов.
Когда лучше обратиться к специалисту
Если сайт содержит конфиденциальные данные пользователей, если он был скомпрометирован длительное время или если проблема повторяется после нескольких попыток восстановления, обратитесь к IT-специалисту или в специализированную службу безопасности сайтов.
Создание сайтов · Быстрые, SEO-оптимизированные многоязычные сайтыЧастые вопросы
Как часто нужно делать резервные копии сайта?
Для часто меняющихся сайтов рекомендуется ежедневная автоматическая резервная копия, а ручная перед каждым крупным изменением (обновление, установка плагина). Храните как минимум неделю ежедневных и несколько месячных копий.
Можно ли восстановить только базу данных, если сайт взломан?
Иногда достаточно восстановить базу, если вредоносный код только в ней, но часто изменены и файлы. Наиболее безопасно восстановить и файлы, и базу из одной резервной копии, а затем проверить целостность.
Что делать, если у меня нет резервной копии, а сайт упал?
Обратитесь в поддержку хостинга и спросите, хранят ли они бэкапы. Если нет, остается ручное восстановление или создание нового сайта. Поэтому регулярный бэкап критически важен.