Аудит DDoS-защиты сайта на 1С-Битрикс

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

Почему сайт падает, хотя защита вроде бы есть

Самая частая иллюзия — что подключённого Cloudflare или DDoS-Guard достаточно. Эти сервисы прекрасно отбивают объёмный сетевой флуд, но между ними и сервером часто остаётся щель, через которую атака проходит напрямую. Реальный IP сервера светится через старую A-запись в DNS, через заголовки почтовых писем, через поддомены вроде панели администратора или через прямой доступ по адресу. Атакующий узнаёт настоящий адрес и бьёт мимо защиты прямо в сервер. Оператор при этом исправно показывает зелёные графики, а сайт лежит. Поэтому аудит всегда начинается с периметра: мы ищем все каналы, по которым может утечь реальный IP, и проверяем, что трафик физически не способен обойти щит.

Вторая частая причина — атаки уровня приложения. Сетевые фильтры видят объём, а L7-флуд устроен иначе: ботов мало, но они бьют по самым дорогим страницам сайта. На Битриксе это, как правило, фильтры каталога с десятками параметров, страницы поиска, личный кабинет, корзина и формы обратной связи. Каждый такой запрос запускает тяжёлую выборку и нагружает базу данных. Сто запросов в секунду по фильтру без кеша кладут сервер надёжнее, чем гигабиты бессмысленного флуда, который оператор отсекает на лету. Эти тяжёлые точки мы ищем целенаправленно, потому что без знания Битрикса изнутри их легко пропустить. Если выясняется, что корень проблемы шире, чем DDoS, мы рекомендуем расширенный аудит безопасности, который охватывает уязвимости приложения целиком.

Как мы моделируем нагрузку безопасно

Проверить устойчивость можно только под нагрузкой — на спокойном трафике слабые места не видны. Но моделировать флуд нужно аккуратно, чтобы не уронить боевой сайт среди рабочего дня. Мы согласуем окно с минимальным трафиком, предупреждаем хостинг и оператора защиты и наращиваем нагрузку постепенно, наблюдая за поведением системы. Смотрим, на каком пороге начинают появляться ошибки 5xx, как растёт время ответа, когда срабатывает rate-limiting и в какой момент упирается база данных. Это даёт точную картину: не абстрактное предположение, а измеренный запас прочности по каждому рубежу и понимание, что именно сломается первым.

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

Что мы отдаём по итогу

Результат аудита — это не презентация с общими словами, а рабочий документ. В нём карта уязвимостей с приоритетами: что критично закрыть немедленно, что важно, а что можно отложить. Конкретные настройки rate-limiting для nginx и Битрикса с готовыми порогами под ваш трафик. Схема защиты периметра с перекрытием всех каналов утечки реального IP. Рекомендации по кешированию тяжёлых страниц и защите кеша под флудом. И пошаговый план повышения отказоустойчивости, по которому вы или ваша команда сможете довести защиту до нужного уровня. Каждый пункт сопровождается объяснением, почему он важен и что будет, если его проигнорировать.

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

Чем DDoS-аудит отличается от проактивной защиты

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

Когда аудит окупается быстрее всего

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

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

Как устроена защита на каждом рубеже

Чтобы понимать, что именно проверяет аудит, полезно представить путь запроса. Сначала он попадает на оператора защиты и сеть фильтрации, где отсекается объёмный флуд уровня L3/L4 — задача этого рубежа выдержать гигабиты пакетов и не пропустить очевидно вредный трафик. Дальше запрос проходит через CDN и защитный экран, где работают проверки L7: challenge для подозрительных клиентов, фильтрация ботов, кеширование статики на стороне оператора. Затем трафик доходит до вашего nginx, где включается rate-limiting — ограничение числа запросов с одного источника, разное для статики, страниц и форм. После этого запрос обрабатывает Битрикс, и здесь решающую роль играет кеш: правильно настроенный, он гасит нагрузку на тяжёлые страницы, неправильно — пропускает её в базу. И последний рубеж — сама база данных, которую нельзя оголять ни при каких условиях.

Сила защиты определяется самым слабым рубежом. Можно поставить дорогого оператора и при этом класть сайт стомиллионным флудом по одному непрокешированному фильтру каталога. Можно идеально настроить кеш и всё равно лежать, потому что реальный IP светится в DNS и атака идёт мимо всей цепочки. Поэтому аудит проверяет каждый рубеж по отдельности и в связке — и оператора, и CDN, и nginx, и кеш Битрикса, и поведение базы. Только так получается честная картина устойчивости, а не ложное спокойствие от того, что где-то горит зелёная лампочка.

Типичные ошибки в защите, которые мы находим чаще всего

За годы работы с проектами на Битрикс под нагрузкой накопился набор повторяющихся ошибок, которые встречаются почти везде. Первая — оператор защиты подключён, но в режиме, который пропускает L7-флуд: challenge не настроен, фильтрация ботов выключена, а кеширование на стороне оператора не используется. Вторая — реальный IP светится сразу по нескольким каналам, и закрытие одного не помогает, пока открыты остальные. Третья — rate-limiting либо отсутствует, либо настроен одним лимитом на всё, из-за чего он либо бесполезен против атаки, либо банит живых клиентов. Четвёртая — тяжёлые страницы каталога и поиска не кешируются или кешируются с ключом, который легко обойти подбором параметров в адресе.

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

Что вы получите в первые дни после обращения

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

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

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