Семь лет никто не обновлял сайты. Что мы нашли, когда нас позвали обратно

Летом 2026 года к нам обратился клиент, с которым мы долго работали по разработке и продвижению сайтов, а потом расстались. За это время в компании сменилось несколько подрядчиков, и в какой-то момент сайтами перестал заниматься кто-либо. Когда вышла критичная уязвимость WordPress, выяснилось, что закрыть её просто некому. Мы провели аудит более двадцати сайтов — и нашли внутри копию базы данных, которую мог скачать любой, чужие персональные данные в открытом доступе и сайт, восемь лет державшийся на одной заплатке. Рассказываем, как сайты остаются без хозяина и что стоит проверить у себя.

Как сайты остаются без хозяина

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

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

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

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

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

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

Это не единичный случай. Такой сценарий мы видим регулярно, меняются только сроки и количество сайтов.

Что показал аудит

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

Копия базы данных, которую мог скачать любой

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

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

Файлы, которые люди присылали через формы

Хранилище вложений с форм обратной связи: 65 файлов. Документы, сканы, файлы-запросы заказчиков. В именах файлов — фамилии и имена людей, которые их отправляли.

Хранилище считалось закрытым. Оно не было закрытым.

Защита, которая была, но не работала

Это самая поучительная находка, и на ней стоит остановиться.

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

Мы проверили это попыткой скачать файлы разных типов:

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

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

Служебные страницы, раскрывающие устройство сервера

Одинаковые диагностические файлы нашлись на нескольких сайтах. Самый старый датирован 2020 годом — он пролежал в открытом доступе больше шести лет.

Такая страница показывает версии всех программ на сервере, пути на диске, внутренние параметры. Для злоумышленника это готовая инструкция: посмотрел версии — подобрал подходящий способ атаки, не тратя времени на разведку.

Похоже на след давней отладки. Кто-то поставил, чтобы быстро посмотреть, и забыл убрать. Так бывает у всех — вопрос лишь в том, есть ли кто-то, кто это потом находит.

Сайт, который восемь лет держался на одной заплатке

Один сайт работал на движке 2014 года выпуска. Формально он уязвим к атаке, которую массово использовали в 2018-м, — и по всем прикидкам должен был быть взломан давно.

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

Но закрыта была ровно одна дыра. Исправления из семидесяти с лишним последующих выпусков движка отсутствовали.

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

Домены уехали, а сайты остались

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

Вывод: «домен» и «где физически живёт сайт» — разные вещи, и после переездов они расходятся куда чаще, чем кажется.

Чем это грозит бизнесу

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

Почему так получается — и это не чья-то вина

Разбирая эту историю, легко назначить виноватого. Только виноватого здесь нет, а есть устройство процесса, которое ломается одинаково у всех.

• Подрядчик уходит — и задача «обновлять сайты» уходит вместе с ним, потому что нигде не записана.
• Новый подрядчик приходит на конкретную работу: сделать лендинг, настроить рекламу. Обновления и мониторинг в договор не входят — их никто не обсуждал.
• Внутри компании сайт числится за маркетингом. Маркетинг уверен, что это зона IT. IT считает, что сайт — это маркетинг.
• А пока сайт открывается, никто вообще не проверяет, что там внутри.

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

Что проверить владельцу сайта

Чек-лист на пять минут. Ничего технического, справится любой руководитель.

1. Кто прямо сейчас отвечает за ваши сайты? Если ответ звучит как «наверное, кто-то из подрядчиков» — вы уже нашли проблему.
2. Когда последний раз обновляли движок? Версия видна в админке.
3. Откройте ваш-сайт.ру/readme.html. Открылось — значит, версию вашего движка видит любой желающий.
4. Загляните в корень сайта — нет ли там файлов вроде dump.sql, backup.zip, info.php, test.php. Их там быть не должно.
5. Есть ли резервные копии и когда их последний раз разворачивали? Копия, которую ни разу не восстанавливали, — это не копия, а надежда.
6. Куда попадают файлы из форм и кто может их скачать? Проверять — попыткой скачать, а не наличием настройки.
7. Сколько у вас доменов и все ли ведут туда, куда вы думаете?

Если хотя бы на трёх пунктах вы задумались — стоит посмотреть на свои сайты внимательнее.

Отдельно про старые системы управления

В этой истории сайты жили сразу на двух разных системах управления — WordPress и Drupal, версии от 2014 года до актуальных.

Drupal — наша давняя специализация. Сегодня такие проекты берут немногие: седьмая ветка снята с поддержки, специалистов почти не осталось, и владельцы старых сайтов часто слышат «проще переделать с нуля». Иногда это правда, но далеко не всегда.

Обновление сайта, которому больше десяти лет, — это не «нажать кнопку». Нужны полные копии, пошаговая проверка и готовность откатиться. Часть сайтов при обновлении ломается — это нормальная часть работы, важно лишь, чтобы было чем и куда вернуться. В этом проекте несколько сайтов после обновлений действительно потребовали доработки, и мы их чинили, а не делали вид, что всё прошло гладко.

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

Частые вопросы

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

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

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

У нас старая система управления, её вообще можно обновить? Чаще всего можно. Иногда обновление действительно дороже переезда на новую платформу — тогда честнее сказать об этом прямо. Ответ даёт аудит: до него это гадание.

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

Кто отвечает за безопасность сайта — хостинг или владелец? Хостинг отвечает за свою инфраструктуру: сервер, сеть, доступность. За то, что стоит внутри сайта — движок, плагины, темы, файлы, — отвечает владелец. Это распространённое заблуждение, которое стоило многим сайтов.

Мы меняем подрядчика. Что запросить у старого? Все доступы (хостинг, панель управления, домены, админка), список сайтов с адресами и версиями, где лежат резервные копии и как их восстанавливать. И зафиксируйте письменно, кто отвечает за обновления после передачи — именно этот пункт обычно и теряется.

Что в итоге

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

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

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