Утром открываете сайт компании и видите, что главная страница перенаправляет на букмекерский сайт, а в кэше Baidu — сплошной мусорный текст. Когда такое происходит, первая реакция руководителя обычно — «срочно всё удалить», а технический руководитель сталкивается с вопросом: «а не вернётся ли это после удаления?» Взлом сайта при плохом обращении означает повторные взломы, понижение в поисковой выдаче и недоверие клиентов. В этой статье разберём порядок действий и то, что может сделать тестирование безопасности.
Не спешите переустанавливать — сначала разберитесь, что именно взломано
Взлом — это не одна единственная проблема, обычно встречаются несколько типов:
- Изменение страниц: на главную или разделы вставлены скрытые ссылки и скрипты перенаправления, пользователей уводит на сторонние сайты.
- Файлы-бэкдоры: злоумышленник оставляет webshell и может вернуться в любой момент — удаление страниц ничего не даст.
- Инъекции в базу данных: в таблицы контента забиты массы мусорных ссылок, которые через обычную админку вообще не видны.
- Перехват на уровне сервера: изменены конфигурации Nginx, Apache или в заданиях cron спрятан скрипт загрузки.
Реальный случай: сайт компании по аренде оборудования был взломан через три месяца после редизайна. Технический специалист удалил только код перенаправления с главной страницы, но через неделю всё повторилось. При разборе выяснилось, что злоумышленник загрузил бэкдор через устаревший интерфейс загрузки редактора, а при редизайне исторические каталоги не были очищены. Бороться только с симптомами, не трогая точку входа, — значит не бороться вообще.
Поэтому первый шаг — не удалять, а зафиксировать доказательства и локализовать проблему: сначала сделайте резервную копию изменённых файлов, логов и базы данных, затем определите точку входа.
Порядок действий: изоляция, сбор доказательств, очистка, укрепление
После взлома рекомендуется действовать в таком порядке:
1. Изоляция: сначала отключите сайт или переведите его на страницу обслуживания, чтобы поисковые системы не продолжали индексировать вредоносный контент и пользователи не пострадали.
2. Сбор доказательств: сохраните логи доступа, логи ошибок, временные метки изменённых файлов. Это основа для последующего определения точки входа.
3. Очистка: удалите бэкдоры, восстановите изменённые файлы, очистите инъекции в базе данных. Обратите внимание: не используйте «перезапись» при восстановлении, иначе затрёте и логи.
4. Укрепление: смените все пароли админки, пароли базы данных, SSH-ключи сервера, закройте неиспользуемые интерфейсы загрузки и права на выполнение в каталогах.
5. Повторная проверка: наблюдайте одну-две недели, убедитесь, что проблема не вернулась.
Предупреждение: не ограничивайтесь сменой пароля админки. Если бэкдор остался, смена пароля лишь оттягивает время. Кроме того, многие корпоративные сайты делаются на аутсорсе, при редизайне передача дел неполная, исторические каталоги, тестовые файлы и файлы резервных копий остаются на сервере — всё это типичные точки входа.
Что именно может выявить тестирование безопасности
Многие думают, что тестирование безопасности — это просто «просканировать уязвимости». На самом деле для уже взломанного сайта ценность тестирования безопасности в том, чтобы найти точку входа и остатки. Обычно оно включает:
- Сканирование уязвимостей: проверка SQL-инъекций, XSS, загрузки файлов, слабых паролей и других типичных проблем.
- Поиск бэкдоров: сравнение хэшей файлов, поиск аномальных webshell, проверка заданий cron и автозапуска.
- Проверка прав: права на каталоги, права учётной записи базы данных, корректность аутентификации интерфейсов админки.
- Тестирование логики: например, можно ли в мини-программе записи обойти фронтенд и отправить недопустимые данные; можно ли в системе управления обычной учётной записью получить доступ к административным интерфейсам.
Здесь стоит пояснить: тестирование безопасности — это не «протестировал один раз и навсегда в безопасности». Разработка сайтов, мини-программ, приложений — как только выходит новая функциональность, могут появиться новые риски. Практичный подход — проводить тестирование перед запуском и повторять после крупных обновлений.
Как защищать корпоративный сайт в повседневном режиме, чтобы не быть застигнутым врасплох
Вместо того чтобы ждать взлома, лучше наладить повседневные действия:
- Поддерживайте актуальность версий: старые версии CMS, фреймворков и плагинов — зона наибольшего риска.
- Сузьте точки входа в админку: измените путь по умолчанию, добавьте двухфакторную аутентификацию, ограничьте IP для входа.
- Запретите выполнение скриптов в каталоге загрузки: это правило отсекает значительную часть бэкдоров через загрузку файлов.
- Регулярное резервное копирование с хранением в другом месте: резервные копии должны позволять восстановление, нельзя хранить их только на том же сервере.
- Хранение логов: когда случится инцидент, без логов вы фактически ищете вслепую.
Если это корпоративный сайт, можно также рассмотреть разделение статических ресурсов и основного сайта, чтобы снизить масштаб последствий при взломе.
В каких случаях стоит обратиться в MIC Studio
Не во всех случаях нужно привлекать внешнюю команду. Если на страницы просто вставили несколько строк кода, вы сами можете найти точку входа и убедиться, что бэкдоров нет, — справитесь своими силами.
Но в следующих ситуациях профессиональная команда сэкономит вам время:
- Сайт взламывают повторно, и вы не можете найти точку входа;
- Сайт связан с пользовательскими данными, заказами, платежами, и есть опасения утечки данных;
- Готовитесь к редизайну сайта или разработке мини-программы и хотите провести тестирование безопасности перед запуском;
- В системе управления сложная система прав, и нужно проверить эскалацию привилегий и логические уязвимости.
MIC Studio занимается разработкой сайтов, мини-программ, приложений и скриптов, а также тестированием безопасности сайтов и реверс-тестированием. Наш подход обычно таков: сначала локализовать проблему, затем дать рекомендации по устранению — мы не заставляем с ходу переделывать весь сайт.
В завершение: три вещи, которые можно сделать прямо сейчас
1. Сделайте резервную копию сегодня же: сохраните файлы сайта, базу данных и логи в разных местах.
2. Проверьте каталог загрузки и точку входа в админку: убедитесь, что в каталоге загрузки нельзя выполнять скрипты, а в админке нет паролей по умолчанию.
3. Запланируйте тестирование безопасности: особенно для корпоративных сайтов, которые только что прошли редизайн или были запущены, — не ждите инцидента, чтобы заняться этим.
Взлом сайта не страшен — страшно не знать, где точка входа и вернётся ли проблема после устранения. Правильно выстроенный порядок действий гораздо полезнее, чем спешное удаление страниц.