Утром в понедельник менеджер небольшого интернет-магазина товаров для дома открыла почту и увидела три письма подряд. Покупатели спрашивали одно и то же: почему после нажатия «Оформить заказ» их перебрасывает на страницу с просьбой подтвердить данные карты, хотя раньше всё заканчивалось на сайте магазина. Четвёртое письмо было от постоянной клиентки: «Вы поменяли сайт? Мне страшно у вас платить».

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

Первой мыслью был вирус на компьютере. Второй — что «хостинг что-то чинит». Третьей — что это временный сбой и он пройдёт сам. Ни одна из версий не объясняла, как чужой адрес оказался в кнопке, которую никто не менял.

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

Эта история не про гениального взломщика. Такие сайты ломают через три обычные вещи, которые никому не кажутся срочными: забытое обновление, общий пароль и копию, лежащую рядом с оригиналом. Проследим по порядку, как каждая из них сработала в этом магазине и что делать, чтобы ваша история закончилась иначе.

Дыра появляется раньше, чем взлом

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

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

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

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

Но даже свежий, полностью обновлённый сайт можно потерять из-за входа. Дыра в плагине объясняет, как вошли, но не объясняет, почему чужие остались внутри. Именно в доступах всё и решилось.

Один пароль знают все

В панели управления магазином была одна учётная запись с правами администратора. Под ней работали все: владелец проверял заказы, менеджер правила товары, подрядчик менял модули. Пароль был записан в переписке, сохранён в браузере на нескольких компьютерах и, что важнее, совпадал с паролем от панели хостинга. Когда-то это казалось удобным: не нужно помнить разные комбинации.

Удобство имело следствие. Через дыру в плагине злоумышленник получил доступ к сайту и создал собственную учётную запись с правами администратора. В журнале входов этого никто не увидел, потому что журнал никто не открывал. Пароль был слабым, его подобрали по выгруженной базе пользователей, а на панели хостинга он подошёл, поэтому под контролем оказались не только страницы, но и файлы, базы данных и папка с ночными копиями.

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

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

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

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

Копии, которые делает хостинг, — удобство, а не стратегия. Стоит заранее выяснить, как долго они хранятся, можно ли восстановить их самостоятельно, не удалятся ли они вместе с аккаунтом и не доступны ли из той же панели, куда может войти атакующий. Провайдер поможет вернуть сайт, но не обязан помнить, какие именно данные для вас незаменимы.

Что снаружи выглядит защитой

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

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

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

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

Копия, следы и цена позднего обнаружения

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

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

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

Журналы нужны, чтобы не гадать, что произошло. Смотреть стоит на входы в панель управления, на действия администраторов, на обращения к несуществующим страницам, на исходящую почту и на серию неудачных попыток входа. Хостинг обычно хранит журналы обращений, но не обязан хранить их вечно, а журнал входов в саму систему может быть выключен по умолчанию. Поэтому полезно заранее решить, какие события вы хотите видеть, кто их читает и как быстро он узнает о новом администраторе или всплеске писем. К журналам добавляют внешний мониторинг доступности и содержимого: он замечает чужой текст на главной раньше сотрудников.

Без этого магазин узнал о проблеме от покупателей, то есть последним. Первым автоматическим сигналом стало письмо хостинга: с сайта пошёл поток рекламных сообщений, и отправку ограничили. К этому моменту поддельные страницы уже попали в поиск, а часть покупателей успела ввести данные карты на чужой странице. Чем позже обнаружен взлом, тем дороже он обходится — не только деньгами, но и доверием, которое возвращать дольше.

Почему плагин безопасности не заменяет процесс

Когда речь заходит о защите сайта, первое желание — поставить что-то, что не пустит. Для этого есть три понятные вещи: фильтр трафика перед сайтом, сканер уязвимостей и плагин безопасности. Каждая из них полезна, но ни одна не отменяет обновлений, раздельных учётных записей и копий.

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

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

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

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

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

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

Главная мысль

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

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

Что делать дальше