Безопасность сайта: защита от взлома и резервное копирование

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

Не удалять подозрительные файлы сразу и не восстанавливать копию вслепую: так теряются следы, по которым видно, как зашли, а без этого взлом повторится. Первые шаги — сменить пароли к хостингу, админке и базе, сохранить текущее состояние сервера и журналы. Дальше — поиск точки входа, чистка или восстановление из копии, сделанной до взлома, и закрытие уязвимости. Лечение — отдельная работа со своим объёмом; защиту и копии с проверкой восстановления настраиваем уже после него.

Проверка того, за чем приходят автоматы: версии платформы, PHP и модулей без обновлений безопасности, открытые админки и служебные файлы, слабые пароли и лишние учётные записи, права на файлы, настройки сервера. Отдельно — резервные копии: где лежат и восстанавливался ли из них кто-нибудь хотя бы раз. На руки вы получаете список с приоритетами: что закрыть немедленно, а что можно планировать. 31 июля 2026 года на нескольких живых магазинах мы нашли PHP 7.3.33, который не получает обновлений безопасности с декабря 2021 года.

Google нашёл на сайте вредоносный код, фишинговую страницу или перенаправление на сторонние ресурсы и пометил сайт в своих чёрных списках. Предупреждение видят посетители в браузере и в поиске, а подробности — в разделе безопасности Search Console: там обычно указаны примеры адресов. Убрать предупреждение можно только после чистки: тогда в той же консоли подаётся запрос на повторную проверку. Подавать его до того, как найдена точка входа, бесполезно — заражение возвращается, и повторное рассмотрение затягивается.

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

Поверхностно — да, онлайн-сканером: это бесплатно, но глубже страницы он не смотрит. Первичная проверка на признаки заражения при имеющемся доступе к хостингу входит в наш бесплатный разбор состояния на 1–3 рабочих дня. Если признаки есть, полный поиск точки входа и чистка — уже отдельная платная работа, и её объём называем после разбора.

Ориентируйтесь на события: обновление платформы или модулей, смену разработчика или подрядчика с доступами, момент, когда версия PHP или платформы перестаёт получать обновления безопасности, и любое странное поведение сайта. Копии стоит проверять тестовым восстановлением по расписанию: создание файла ещё ничего не доказывает.

Это видно из того, что случилось. Сайт лежит, потому что исчез хостинг, — аварийный перенос. Сайт работает, но обновлений под ним давно не было, — защита от взлома. Копии вроде есть, но из них никто не восстанавливался, — резервное копирование с проверкой восстановления. Если сайт уже взломан, сначала лечение, а защиту и копии настраиваем после него. Не уверены — опишите ситуацию, и вид работы назовём в рамках бесплатного разбора.