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