SAGIROV.com - Digital B2B 
Тендеры и лиды
Информация
Есть проекты, которые приходят к тебе уже сломанными. И начинаются не в формате «давайте улучшим конверсию», а «у нас что-то с сайтом, помогите!». Открываешь — а там старое ядро, мёртвые логи, база на десять гигабайт непонятно от чего и вирус, который переживает любую чистку и восстанавливает сам себя.
Мы за годы поддержки приняли не один такой проект. Ниже — один кейс из работы с сайтом застройщика, но в двух актах: сначала про то, как мы разбирали заражённый сайт с реальной потерей рекламного бюджета, а потом про то, как из разовой спасательной операции это переросло в постоянную рутину безопасности на том же проекте. Это не гайд «как защитить сайт за 5 шагов». Это про то, как такие задачи выглядят изнутри и чему учат в работе с легаси.
Так буквально начинался один из проектов. Крупный застройщик, на сайте — вирус, почти 90% мобильного трафика уходит на чужие рекламные страницы. Человек кликает по платному объявлению, заходит на сайт — и его тут же редиректит на сторонний ресурс. Деньги за клик списались, посетитель потерян.
Предыдущая команда разводила руками: ядро старое, обновить нельзя, остаётся тушить пожары по факту, чем в принципе они и занимались. Однако пожары горели ежедневно, и жить каждый день в режиме выживания сайт застройщика не может.
Нас позвали с одной задачей — быстро вернуть сайту работоспособность и остановить слив трафика. Дальше мы описываем то, как мы это разбирали по частям и собирали заново, со всеми тупиками по пути.
Первое правило при работе с заражённым проектом: ничего не трогать на боевом сайте. Мы сделали резервную копию, развернули её локально и начали испытывать на прочность и расщеплять проект на атомы. Если что-то и ломать в проекте, то там, где это не страшно — на локальной копии.
Параллельно работали с продом и прогнали сервер антивирусами — просто чтобы оценить глубину и масштаб проблемы. Стало понятно, что ближайшие ночи команда проведёт за работой.
Полный аудит сайта показал картину целиком: база больше 10 ГБ (это очень много для такого сайта — явный признак, что в неё годами что-то копилось), логи безопасности не работают, при этом сервер исправно ловит XSS и SQL-инъекции. И всё это должно уживаться с десятком интеграций: аналитика, коллтрекинг, CRM, обмен с 1С, платежами, банками и т.д.
Дальше — самое интересное с точки зрения разработчиков. Прогнали сайт и базу несколькими антивирусами, нашли заражения, удалили. Но это не помогло. Было бы удивительно, если бы сработало, и в воздухе повис бы немой вопрос «А что делала другая команда?».
Вирус оказался разбросан по разным файлам. Удаляешь одну часть — при следующем запуске она восстанавливается уже в другом месте. Несколько итераций, вырезали и закомментировали кучу кода — редирект всё равно срабатывал, а вирус восстанавливался из раза в раз. Каждый новый посетитель улетал на спам-сайт.
Помогла не очередная чистилка, а смена подхода: развернули систему контроля версий, которая фиксировала любое изменение файлов. Как только вирус пытался восстановить свою копию — мы сразу видели, где именно и какие изменения внесены. После этого нашли вирусный редирект и в тестовом режиме подняли сайт на основном домене.
Деталь, которую стоит запомнить: реальный результат дал не дорогой профильный софт, а ручной поиск и бесплатный Dr.Web. Профессиональные решения для сайтов отработали поверхностно. «Дорого» и «эффективно» — не синонимы, и это касается не только антивирусов.
Через несколько дней после запуска всё повторилось. Мы всё очистили, и опять цикл повторился. Правда, через несколько дней. Команда только хотела вздохнуть спокойно и уйти на выходные, но не получилось. Здесь стало окончательно ясно: вирус — это симптом, а причина — дырявое ядро и сервер, через которые заражение заходило снова и снова. Чистить, не закрыв все дыры, было бессмысленно.
Что сделали:
временно закрыли все формы — часть спама и заражений лезла через них; заодно удалили старые неиспользуемые формы, оставшиеся от прошлых версий сайта, которые существовали на неактуальных страницах. Таких было около 20–30 штук;
переехали на более защищённый хостинг;
сделали защищённое соединение между 1С и сайтом — до этого обмен шёл фактически открытым.
Дальше — ядро. Нам его пришлось восстанавливать вручную: при каждом автообновлении сайт просто падал. Видимо, ядро обновляли последний раз НИКОГДА. Админка открывалась, но сыпала ошибками, которые нужно было чинить. В базе нашли пустые строки, проблемы с идентификаторами, отсутствовали поля. Автоматически это сделать было невозможно, поэтому мы вручную восстановили таблицы, заменив повреждённые данные стандартными, и после нескольких итераций база прошла проверку на целостность.
Потом по очереди подняли основные модули — структуру, поиск, каталог, веб-формы. Часть восстановилась автоматически, часть доставали руками из чистой копии той же версии CMS. После этого сайт начал отражать часть атак сам, когда обновились стандартные модули защиты до актуальных версий.
Когда мы привели ядро в порядок, включили максимальный уровень защиты штатными модулями CMS: проактивный фильтр, веб-антивирус, защиту административной панели, от редиректов и фреймов. Поверх всего этого мы добавили:
капча на входе в админку и двухфакторка с доступом по IP;
разделение пользователей на группы с разными правами — чтобы у каждого было ровно столько доступа, сколько нужно;
мониторинг и оповещения по email и SMS об атаках ответственным сотрудникам.
Главное решение по антивирусам — поставили не один, а несколько разом. Потому что заражение было нетривиальным и поймать одним антивирусом или WAF его не удавалось. Логика у нас была простая: пропустит один — поймает второй. По соотношению «эффективность / цена» остановились на нескольких:
Virusdie — знает сайтовую структуру, даёт нормальный интерфейс с историей проверок, атак и IP (на хостинге это часто стандартное решение).
Sucuri — со своим встроенным firewall, закрывает большинство уязвимостей и кэширует трафик. Через него закрыли дыру с доступом к админке, которую годами не мог закрыть и не исправил разработчик CMS. Также он умеет хранить историю изменений файлов и автоматически откатывать сайт.
xScan — максимально простой сканер. К нашему удивлению, нашёл то, что не нашли самые дорогие решения.
SiteGuarding — со временем отказались: аналитики мало, контроль изменений файлов мы к тому моменту уже сделали сами собственными скриптами.
В финале прогнали тесты защиты на проникновение, чтобы сдать проект ИТ-отделу компании: Sqlmap, Skipfish, DirBuster, OpenVAS, Nmap. Сайт держал удар и прошёл все нагрузки. Редиректы и слив рекламного бюджета прекратились.
Наша система сама подберет вам исполнителей на услуги, связанные с разработкой сайта или приложения, поисковой оптимизацией, контекстной рекламой, маркетингом, SMM и PR.
Заполнить заявку
13590 тендеров
проведено за восемь лет работы нашего сайта.
На этом история не закончилась — эта строительная компания оставила нам теперь сайт на поддержку. «Вы справились — работаем дальше!» И теперь задача поменялась: теперь не разгребать последствия, а не доводить до них снова. Тут началась наша проактивная работа по безопасности — из разового героического рывка она превратилась в рутину, которая капает в задачах из месяца в месяц.
Уже в первый год после чистки дважды разбирали тревоги: один раз проверяли сайт после вирусной атаки, второй — после попытки заражения. Пометка в задаче осталась говорящая: воскресенье, 16:00. Атака ботов не ждет понедельника — они работают тогда, когда в офисе никого нет и все отдыхают.
Вывод простой и неромантичный: мониторинг и оповещения важнее красивого отчёта раз в месяц. Антивирус на сайте тогда стоил порядка 259 рублей в месяц — на фоне того, что мы только что разгребали, это даже не статья расходов.
Главная фоновая боль таких проектов — не вирусы, а парсинг. Конкуренты и сервисы аналитики выкачивают каталог целиком: цены, остатки, скидки.
Честно говоря: хорошее решение мы нашли не сразу, потому что проект был специфичный и универсальные решения не подходили. Сначала общались с поддержкой по антиспаму. Потом искали связку WAF плюс антиспам — и, как записано в задаче дословно, «ничего путного пока не нашли». В итоге вышли на одно хорошее решение и стали разбираться с их фильтрацией трафика: оно отсекает ботов еще до входа на сайт. Живой человек разницы не замечает, а бот, который пытается за минуту обойти все карточки, упирается в стену.
Важный момент про сам подход: парсинг нельзя выключить полностью, не закрыв сайт и от обычных посетителей. Реальная цель — не «запретить», а поднять стоимость атаки: превратить «скачал за час» в «дорого, медленно и всё равно неполно». Обычно этого достаточно, чтобы стало невыгодно.
Часть работы по безопасности заказчик вообще не видит, но без неё разваливается все остальная структура. Мы настроили бэкапы и автоудаление старых копий, чтобы сервер не падал из-за переполнения, не раз разворачивали резерв на запасном хостинге, чтобы протестировать новые решения. Подняли SSL для nginx. Разграничили доступы — когда отключали лишнего пользователя от зеркала, заодно стало видно, у кого вообще есть ключи. Закрыли базовое: логирование доступа к админке и сделали его максимально подробным, защиту от показа сайта в чужих iframe.
Этого никто не заказывает отдельной задачей. Но именно этот слой определяет, придётся ли тебе однажды разгребать всё то, с чего эта история начиналась.
Когда поработаешь с парой заражённых легаси-проектов, отношение к безопасности перестаёт быть теоретическим и беззаботным. Несколько вещей, которые мы вынесли для себя.
Безопасность — это состояние, а не услуга. Сайт, который один раз «почистили», снова заразится, если за ним не следить. Это меняет то, как мы закладываем работу: не разовый аудит, а постоянный мониторинг.
Дорого не равно эффективно. Самовосстанавливающийся вирус поймал бесплатный Dr.Web и ручной diff через систему контроля версий, а не дорогой профильный софт. Стоит проверять инструменты на своей задаче, а не по ценнику.
Защита работает слоями. Один антивирус пропустит — поймает второй. Фильтрация трафика отсекает ботов, капча и двухфакторка закрывают вход, штатная защита CMS держит остальное. Ни один инструмент не закрывает всё в одиночку, и нормальную связку мы сами собрали не с первой попытки.
Парсинг не остановить полностью — но можно сделать невыгодным. Полностью закрыть каталог нельзя, не закрыв его и от клиентов. Цель — поднять стоимость атаки настолько, чтобы проще было не связываться.
И самый честный вывод, который касается любого, кто берёт чужие проекты на поддержку: если ты не знаешь, в каком состоянии безопасность проекта прямо сейчас, — это уже ответ. Проверка стоит недорого. Разбор последствий, с которого начиналась эта история, — намного дороже.
