Признаки взлома сайта на Magento или WordPress и что делать

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

Признаки, что сайт взломан

• Редиректы и спам в поиске. Посетители из поиска или с мобильных попадают на чужие сайты, а запрос site:ваш-домен в Google показывает страницы, которых вы не создавали — часто с аптекой, казино или текстом на японском. Часто такой спам показывается только поисковым роботам, поэтому сами вы его можете не увидеть.
• Предупреждения Google и браузеров. «Этот сайт может быть взломан» в выдаче, красная страница-предупреждение в браузере, письмо из Search Console. Антивирусы покупателей начинают ругаться на ваш сайт.
• Новые администраторы. В админке появились пользователи, которых никто не заводил, или у старых аккаунтов сменились почта и права.
• Незнакомые и изменённые файлы. PHP-файлы в папках для загрузок и медиа, файлы с невнятными именами в корне сайта, недавно изменённые index.php, .htaccess, файлы темы.
• Посторонний JavaScript на оформлении заказа. Для Magento это главный риск: скиммер (атаки этого типа называют Magecart) встраивается в страницу оплаты и отправляет данные карт злоумышленникам. Покупатель ничего не замечает — заказ проходит. Иногда скиммер показывает поддельную форму оплаты, а потом отправляет на настоящую.
• Жалобы на списания. Покупатели пишут о мошеннических операциях по картам после покупки у вас, банк или платёжный провайдер присылает запрос о возможной утечке, растёт число chargeback.
• Странные задачи cron и процессы. Новые записи в crontab, процессы, которые грузят процессор без причины, — так часто работают майнеры и бэкдоры, которые восстанавливают себя после удаления.
• Нагрузка и письма. Резкий рост исходящего трафика или нагрузки без роста продаж, письма о спаме с вашего IP, хостинг блокирует сайт.

Как проверить

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

1. Google Search Console. Отчёт «Проблемы безопасности» показывает, если Google решил, что сайт взломан или опасен для посетителей, и приводит примеры страниц. Если сайт ещё не подключён к Search Console, подключите его — это бесплатно.
2. Сканеры. Для Magento у Adobe есть бесплатный Security Scan Tool в личном кабинете Commerce/Magento: он ищет вредоносный код, скиммеры, неустановленные патчи и уязвимые расширения, проверки можно запускать по расписанию. Есть и коммерческий сканер серверной части eComscan от Sansec, со специализацией на интернет-магазинах. Для WordPress — бесплатные плагины из каталога WordPress.org, например Wordfence; сам WordPress.org советует сочетать сканер на сайте с внешними проверками вроде VirusTotal.
3. Сравнение с чистой копией. В WordPress команда wp core verify-checksums сверяет файлы ядра с контрольными суммами WordPress.org, а wp plugin verify-checksums --all — файлы плагинов из официального каталога. Для Magento разверните чистую копию той же версии через Composer и сравните с рабочей папки vendor, app/code и pub.
4. Недавно изменённые файлы. Например, find . -type f -name '*.php' -mtime -14 покажет PHP-файлы, изменённые за две недели. Злоумышленник может подделать дату, так что пустой результат ещё ничего не гарантирует.
5. Пользователи в базе. В Magento — таблица admin_user: кто создан недавно, у кого незнакомая почта. В WordPress — wp user list --role=administrator или таблица wp_users.
6. Скрипты в настройках и блоках Magento. Скиммеры часто прячут не в файлах, а в базе: в таблице core_config_data (например, в настройках «HTML Head» и подвала — путь design/head/includes, design/footer/absolute_footer) и в cms_block. Ищите там <script>, которых вы не добавляли.
7. Логи. Логи веб-сервера: POST-запросы к незнакомым PHP-файлам, входы в админку с чужих IP. Логи входа и изменения настроек в админке.

Что делать, если взлом подтвердился

1. Не удаляйте сразу всё подозрительное. Сначала зафиксируйте, что видите и когда заметили, и сделайте снимок сервера или полную копию файлов и базы — даже заражённую. Без неё потом не понять, как злоумышленник попал внутрь и что успел забрать.
2. Остановите ущерб. Если на оплате скиммер — закройте оформление заказа или переведите магазин в режим обслуживания, пока не убедитесь, что код удалён. Проверьте, не задет ли другой сайт на том же сервере или хостинге.
3. Смените все доступы. Пароли администраторов, SSH и SFTP, панели хостинга, базы данных, API-ключи платёжных систем и интеграций. В WordPress замените секретные ключи в wp-config.php — это разлогинит всех. В Magento смените ключ шифрования (bin/magento encryption:key:change, Adobe описывает порядок в базе знаний) и токены интеграций. После очистки пароли стоит сменить ещё раз.
4. Найдите точку входа. Неустановленный патч, уязвимое расширение, украденный пароль, заражённый компьютер разработчика. Пока она не закрыта, сайт взломают снова — иногда в тот же день. Свежие примеры таких уязвимостей — BlockStrap в Magento и PHP2Shell в самом PHP.
5. Очистите или восстановите. Надёжнее всего — восстановить сайт из резервной копии, сделанной до взлома, и сразу поставить обновления. Если чистой копии нет, ядро и модули ставятся заново той же версии, а свой код и база проверяются вручную.
6. Обновитесь. CMS, расширения, PHP, сервер. Для Magento — все патчи безопасности, включая изолированные.
7. Уведомите тех, кого это касается. Если утекли персональные данные клиентов из ЕС, GDPR требует уведомить надзорный орган без неоправданной задержки и, по возможности, в течение 72 часов с момента, как вы узнали об утечке. При утечке данных карт сообщите платёжному провайдеру или банку-эквайеру — у них свои требования и сроки. Если сайт был в чёрных списках, после очистки запросите повторную проверку в Search Console — не раньше: преждевременный запрос может затянуть проверку.

Как не допустить повторения

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

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

Источники: отчёт «Проблемы безопасности» в Search Console, Security Scan Tool от Adobe, Adobe о смене ключа шифрования, WordPress.org: «My site was hacked», wp core verify-checksums, wp plugin verify-checksums, Sansec о современных скиммерах, статья 33 GDPR.