Разговор о безопасности сайта почти всегда начинается после взлома. До этого он звучит как трата денег на то, чего не происходит: «кому мы нужны, у нас магазин сантехники». Это главное заблуждение темы. Типовые сайты ломают не люди, которые выбрали вашу компанию, а боты, которые перебирают весь интернет подряд в поисках известных дыр. Вас не выбирали — вы подошли по признакам.
Как это происходит на самом деле
Схема массового взлома устроена конвейерно. В популярном плагине или модуле находят уязвимость, описание публикуют в базе CVE, и в течение нескольких дней она попадает в готовые сканеры. Дальше боты обходят сайты, определяют версию CMS и набор плагинов по косвенным признакам и пробуют эксплойт там, где версия уязвима.
Цель почти никогда не в ваших данных. Чаще всего сайт нужен как ресурс: размещать дорвеи и спам-страницы, подставлять редиректы мобильным посетителям, рассылать письма, держать фишинговую страницу чужого банка на вашем домене. Поэтому взлом нередко остаётся незамеченным неделями — внешне сайт работает как обычно.
Признак заражения чаще всего приходит снаружи: письма перестали доходить, в поиске у домена появились чужие страницы, хостинг прислал уведомление о рассылке спама. Сам сайт при этом выглядит нормально.
Обновления: скучно и обязательно
Подавляющее большинство взломов типовых сайтов — это эксплуатация уязвимости, которую автор давно закрыл. Обновление ядра CMS, плагинов и тем остаётся самой дешёвой мерой безопасности из существующих.
Порядок простой: сначала копия сайта, на ней обновление, проверка ключевых сценариев — каталог, корзина, оформление заказа, форма обратной связи, — и только потом бой. Обновление сразу на проде работает до того дня, когда очередной плагин ломает вёрстку корзины в пятницу вечером.
- Неиспользуемые плагины и темы удаляют, а не отключают: файлы неактивного плагина лежат на диске и при прямом обращении к ним выполняются
- Взломанные платные плагины из сомнительных источников — это установка бэкдора своими руками, почти без исключений
- Плагин без обновлений несколько лет считается заброшенным и подлежит замене, даже если работает
- Версия PHP тоже обновляется: на версии без поддержки не выходят исправления безопасности
- Состав плагинов фиксируется в документации проекта, иначе через год никто не вспомнит, зачем половина из них
Вход в админку
Вторая по частоте причина после уязвимостей — подбор пароля. Боты круглосуточно долбятся в стандартные адреса админок со словарями. Пароль вида название компании и год подбирается за минуты.
- Двухфакторная аутентификация для всех, у кого есть доступ к админке, — самая результативная мера на единицу усилий
- Ограничение числа попыток входа и временная блокировка адреса после нескольких неудач
- Блокировка по логам на уровне сервера: несколько сотен неудачных попыток с одного адреса — бан на уровне фаервола
- Ограничение доступа к адресу админки по списку адресов или простая HTTP-авторизация поверх неё, если команда работает из офиса
- В WordPress отключается xmlrpc.php, если им не пользуются: это классический канал перебора паролей пачками
- Перечисление пользователей через публичные адреса закрывается, чтобы боты не узнавали реальные логины
Отдельно про учётные записи: у каждого человека своя, с минимально необходимой ролью. Общий аккаунт admin с паролем в переписке — это не только риск взлома, но и невозможность понять, кто что сделал. Когда сотрудник или подрядчик уходит, учётная запись отключается в тот же день.
Права на файлы и запрет PHP там, где его быть не должно
Типичная механика заражения: через уязвимость формы загрузки на сервер попадает файл с кодом, его кладут в папку пользовательских загрузок и дальше просто открывают по прямой ссылке. Сервер честно выполняет его как обычный скрипт, и у атакующего появляется постоянный вход.
Закрывается это на уровне веб-сервера: в каталоге загрузок выполнение скриптов запрещается целиком. Дополнительно — права 644 на файлы и 755 на каталоги вместо 777, и отдельный владелец у файлов кода, от имени которого не работает веб-сервер. Тогда даже при успешной загрузке дописать себя в код сайта злоумышленник не сможет.
- Файл .env и любые конфиги с паролями не должны отдаваться по прямой ссылке — проверяется это за десять секунд в браузере
- Каталог .git на боевом сервере либо отсутствует, либо закрыт: по нему выгружается весь исходный код
- Резервные копии и дампы базы не лежат в корне сайта под предсказуемыми именами
- Списки файлов в каталогах отключены, чтобы структура проекта не читалась с улицы
- Тестовые копии на поддоменах закрываются авторизацией: их обновляют реже боевых, и ломают именно их
Последний пункт недооценивают систематически. Забытая копия на тестовом поддомене с прошлогодней версией CMS и той же базой — это полноценный вход в данные, только без присмотра.
Сервер
Если сайт живёт на своём сервере или VPS, к списку добавляется системная часть: вход по SSH только по ключам с отключённой парольной аутентификацией, запрет прямого входа под root, фаервол с открытыми только нужными портами, регулярная установка обновлений безопасности операционной системы.
Дальше — разделение. Отдельный системный пользователь на каждый сайт, отдельный пользователь базы данных с правами только на свою базу, никакого общего root-доступа к СУБД из приложения. Тогда взлом одного сайта не превращается в потерю всех, что живут на машине. Что ещё влияет на работу сервера под нагрузкой, разбиралось отдельно: сервер для интернет-магазина.
HTTPS на всём сайте с автоматическим продлением сертификата и переадресацией с http — это уже не мера безопасности, а гигиена; без неё браузеры и поисковые системы сами понизят сайт в глазах посетителя.
Секреты и доступы
Ключи платёжного шлюза, токен телеграм-бота, пароль почтового ящика для отправки писем, доступ к API учётной системы — всё это живёт в конфигурации окружения и не попадает в репозиторий. Токен, однажды закоммиченный в git, считается скомпрометированным навсегда: он остаётся в истории, даже если файл потом поправили.
Правило, которое стоит принять сразу: любой ключ, который хоть раз был отправлен в мессенджере, лежал в репозитории или был известен ушедшему подрядчику, подлежит ротации. Это десять минут работы против непредсказуемых последствий.
При передаче проекта от одного подрядчика другому меняются все пароли: хостинг, панель управления, SSH, база, админка, почта, регистратор домена. Это не вопрос доверия, а нормальная процедура. Что входит в такую передачу и как она оформляется, мы описывали в статье про договор на разработку.
Мониторинг: узнать раньше клиента
Большая часть ущерба от взлома накапливается, пока никто ничего не замечает. Поэтому вторая половина безопасности — это наблюдение.
- Проверка доступности и кода ответа главной и ключевых страниц с внешнего сервиса, с оповещением
- Контроль целостности файлов: сверка контрольных сумм и уведомление о новых или изменённых файлах в каталогах кода
- Уведомление о создании новых пользователей с правами администратора
- Раздел безопасности в Яндекс Вебмастере и аналогичный в Google Search Console — поисковые системы находят заражение раньше владельцев
- Внезапный рост исходящей почты или нагрузки на процессор — частый первый признак, что сайт используют не по назначению
И отдельно — резервные копии, которые лежат не на том же сервере и регулярно проверяются восстановлением. Копия, которую ни разу не разворачивали, — это предположение, а не копия. Подробный разбор: бэкапы интернет-магазина.
Если уже взломали: порядок действий
Главное — не начинать с удаления подозрительных файлов. Первое же удаление уничтожает следы, по которым определяется способ проникновения, и через неделю всё повторится.
- Снять полную копию сайта и базы как есть, вместе с логами, — это материал для разбора
- Закрыть сайт заглушкой, если он раздаёт вредоносный код посетителям
- Сменить все пароли и ключи: хостинг, SSH, база, админы, почта, API, ключ приложения
- Найти время проникновения по датам изменения файлов и журналам веб-сервера
- Переустановить ядро CMS и плагины из официальных источников вместо ручной чистки
- Проверить задания планировщика, список администраторов и правила переадресации в конфигурации сервера
- Откатиться на копию, сделанную заведомо до даты заражения, и только после этого обновить всё и закрыть уязвимость
- Отправить сайт на перепроверку в панелях Вебмастера и Search Console, чтобы снять пометку о заражении
Про чистку стоит сказать прямо: один найденный файл — это почти никогда не весь бэкдор. Их обычно несколько, они маскируются под системные файлы, прописываются в темы и в базу. Отсюда правило: восстановление чистого кода целиком надёжнее, чем точечное удаление найденного.
И главное: восстановление из копии без устранения причины — это отсрочка на несколько дней. Если дыра осталась, сайт заразят снова тем же способом.
Что сделать в первую неделю после запуска
- Убрать лишние плагины и модули, зафиксировать нужные
- Включить двухфакторную аутентификацию и завести именные учётные записи
- Запретить выполнение скриптов в каталоге загрузок, проверить права на файлы
- Проверить, что конфиги, дампы и служебные каталоги не отдаются по прямой ссылке
- Настроить копии на отдельное хранилище и один раз проверить восстановление
- Подключить мониторинг доступности и подтвердить сайт в панелях поисковых систем
- Назначить ответственного за обновления и периодичность — иначе их не будет делать никто
Последний пункт решает больше, чем все технические меры вместе. Безопасность — это не состояние, которое настраивают один раз на запуске, а процесс: обновления выходят каждый месяц, уязвимости находят каждую неделю.
Мы берём эту рутину на себя: обновления на копии и выкатка на бой, контроль доступов, копии с проверкой восстановления, мониторинг и разбор инцидентов — это поддержка сайта и администрирование сервера. Для сайтов на массовых движках, которые чаще всего и становятся целью сканеров, отдельно настраиваем вход и права: сайт на WordPress. Если сайт уже заражён, начинаем не с чистки, а с поиска точки входа — иначе всё повторится.
