Атлас защиты: как сравнивать DDoS, AntiBot и WAF

Сначала задача, затем четыре группы защиты

Слово «защита» объединяет несколько разных задач. Для серии выделены четыре группы. Один коммерческий сервис может содержать несколько модулей, но состав каждого тарифа предстоит подтвердить отдельно. Из соседства названий в каталоге не следует, что все возможности включены в выбранное предложение.

Техническое основание для разграничения задач — разные пути нарушения доступности. В RFC 4732 отдельно рассмотрены исчерпание ресурсов приложения и атаки на каналы. Четыре группы ниже — наша структура обзоров, а не буквальная классификация этого документа.

• Internet Denial-of-Service Considerations

DDoS каналов и сетей: L3/L4

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

Для облачной схемы следует выяснить, используется ли BGP, какие префиксы можно подключить и как доставляется очищенный трафик. Постоянное включение защиты и переключение по событию описываются раздельно. Локальное оборудование, облачная очистка и их сочетание не становятся одинаковыми решениями только потому, что защищают от DDoS. Состав инфраструктуры и обязанности команды входят в сравнение.

• Internet Denial-of-Service Considerations

DDoS сайтов и HTTP API: L7

Здесь рассматривается доступность HTTP-приложения. Вопросы начинаются с подключения домена и origin — сервера, на котором работает сайт. Далее проверяются TLS на обоих участках, ограничения запросов, нужные протоколы и сохранение обычной работы приложения.

Для магазина существенны каталог, корзина, оплата и интеграции. Для API — корректный доступ программных клиентов. Кеширование, защита от DDoS, WAF и AntiBot рассматриваются как отдельные возможности с собственной областью действия. Одна успешная загрузка страницы не показывает, как система поведёт себя при атаке или под нагрузкой.

• Internet Denial-of-Service Considerations

AntiBot: автоматизация и злоупотребления

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

Автоматизация может причинять ущерб бизнес-процессу без технического отказа сервиса. Такой класс риска описан в OWASP API6:2023. Это основание изучать сценарий злоупотребления отдельно от доступности, а не подтверждение возможностей конкретного AntiBot.

Нужно учитывать полезную автоматизацию: поисковые и ИИ-краулеры, партнёров, мониторинг. Различать её и нежелательные действия помогает руководство OWASP по управлению ботами. Проверяются условия доступа без JavaScript, применение SDK, проверочных заданий и исключений.

Само определение «бот» ещё не отвечает, разрешено ли клиенту конкретное действие. Авторизация API и проверка прав на объект остаются самостоятельными вопросами приложения: OWASP API1:2023 рассматривает именно объектную авторизацию. Это не абсолютное утверждение, что WAF не может участвовать в контроле доступа; такое участие требует применимой архитектуры и проверки.

• API6:2023 Unrestricted Access to Sensitive Business Flows
• Bot Management and Anti-Automation Cheat Sheet
• API1:2023 Broken Object Level Authorization

WAF и HTTP API: правила работы с запросами

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

Определение WAF в OWASP относится к правилам HTTP-взаимодействия приложения. Это перенесённая справочная страница с неустановленной датой обновления, поэтому она используется только для определения области, а не для списка современных возможностей всех продуктов.

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

• Web Application Firewall
• API1:2023 Broken Object Level Authorization

Сравнивается конфигурация, а не бренд

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

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

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

Четырнадцать общих вопросов

Единые вопросы помогают не менять правила под интересный продукт. Они не заменяют специальные критерии каждой группы: например, маршрутизацию для сетевой очистки или обработку API-запросов для WAF.

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

Пять типов доказательств

Каждое существенное утверждение получает собственную метку. Это не оценка поставщика целиком и не лестница, на которой любое измерение автоматически сильнее документа.

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

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

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

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

Если в будущем материал содержит измерения, рядом должны быть определение показателя, способ получения данных и условия опыта. Для доступности, ошибочных ограничений и обработки запросов нужны свои основания. Показатель, полученный на одном стенде, нельзя без объяснения переносить на иной маршрут или приложение. Это требования нашей редакционной карточки проверки, а не заявление о единой методике испытаний всех DDoS-сервисов, WAF и AntiBot. В этой статье измерения не проводились.

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

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

Общий контекст различия изучения объекта и испытания в заданных условиях даёт NIST SP 800-115, включая план и правила проведения проверки. Это руководство 2008 года, а не современный бенчмарк облачных сервисов. Пять меток выше — редакционная реализация серии; разрешение на испытание из ссылки на NIST не возникает.

• Technical Guide to Information Security Testing and Assessment

Когда честный ответ — «несопоставимо»

Статус NOT_COMPARABLE — «несопоставимо в текущих условиях» нужен до расчёта оценок. Он применяется, если две карточки отвечают на разные задачи или их ключевые условия нельзя привести к общему основанию.

Например, очистка IP-префикса и WAF для одного приложения относятся к разным группам. Сопоставление их как альтернатив без описания задачи бессмысленно. Два WAF тоже могут требовать уточнения: если один вариант облачный, а другой установлен в сети заказчика, отличаются инфраструктура, ответственность и состав стоимости.

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

Почему не будет общего балла «за защиту»

Глобальная заявленная ёмкость сети, договорный лимит клиента, число запросов и пропускная способность оборудования — разные показатели. Перед использованием цифры надо понять, что именно считается и к какому объекту относится значение.

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

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

Практическая карточка перед выбором

До чтения обзоров полезно заполнить короткий паспорт своей задачи. Он помогает отделить обязательное условие от приятного дополнения и не выбирать по самой длинной таблице возможностей.

1. Сервис и пользователи. Что защищается: канал, сайт, приложение, API? Какие клиенты и интеграции должны сохранять доступ?
2. Сценарий риска. Какое нарушение работы рассматривается? Что известно, а что пока является гипотезой?
3. Обязательные требования. Какие протоколы, регионы, режимы и условия договора нельзя изменить?
4. Доступные изменения. Кто управляет DNS, маршрутизацией, сертификатами и приложением? Какие изменения допустимы?
5. Точная конфигурация кандидата. Продукт, тариф, версия или дата сервиса, способ развёртывания, регион.
6. Доказательства. Для каждого важного свойства — ссылка, дата и одна из пяти меток; отдельно список пробелов.
7. Полезный трафик. Какие пользовательские действия, боты, партнёры и программные клиенты нельзя потерять?
8. Эксплуатация и инцидент. Кто видит журналы, меняет правила, обрабатывает ошибочную блокировку и обращается в поддержку?
9. Экономика и выход. Что входит в расчёт и как вернуться к исходной схеме?
10. Условие решения. Что уже подтверждено, что необходимо уточнить и почему сравнение допустимо либо пока несопоставимо?

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

Дата, исправления и следующие обзоры

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

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

Дальше появятся отдельные разборы четырёх групп и сравнения для совместимых сценариев. Статус кандидата в плане не означает завершённого аудита. Открытым остаётся то, для чего пока нет подтверждения: такое обозначение полезнее уверенного совета, основанного на предположении.