Когда защита от DDoS особенно актуальна

Особенно актуальна, если:

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

Для руководителя коротко. Задача этой услуги — снизить вероятность недоступности сервиса и сократить длительность и последствия воздействия DDoS-атаки, подобрав архитектуру под конкретный профиль нагрузки, а не продать единый пакет «защита от всего».

С чего начинаем, если защиты пока нет

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

Инфраструктура не готова к переключению трафика через фильтрацию? Помогаем выбрать модель — on-premise, облачную или гибридную — под архитектуру и бюджет.

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

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

Как это соотносится с соседними услугами

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

Разница по существу: защита от DDoS направлена прежде всего на сохранение доступности сервиса при атаках на отказ в обслуживании. WAF защищает приложение от эксплуатации уязвимостей и может участвовать в противодействии части L7 DDoS-атак, но не заменяет защиту канала и сетевой инфраструктуры от объёмных атак. SAST/DAST работают ещё раньше — на этапе разработки и проверки приложения, снижая число уязвимостей, которые можно было бы эксплуатировать.

Форматы работы

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

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

Гибридная схема. Базовая защита always-on для типовых атак и дополнительное масштабирование через облако или провайдера при крупных объёмных атаках.

Важное техническое ограничение: локальные средства защиты (on-premise) могут защищать ресурсы приложения и сетевого оборудования, но не устраняют переполнение внешнего канала связи. Если внешний канал уже исчерпан атакой, локальное средство за этим каналом не сможет предотвратить недоступность сервиса. Для крупных объёмных атак фильтрация должна происходить выше по маршруту — у оператора связи, вышестоящего провайдера или в облачном scrubbing-контуре.

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

Какие бывают DDoS-атаки

Объёмные атаки (volumetric, L3/L4). Переполнение канала связи паразитным трафиком — UDP flood, ICMP flood, атаки с амплификацией через DNS, NTP и другие протоколы. Цель — исчерпать пропускную способность канала. Для защиты важна достаточная ёмкость upstream-фильтрации и возможность масштабирования выше пропускной способности защищаемого канала; требуемый запас определяется профилем риска и возможностями выбранного провайдера защиты — заранее гарантировать защиту от атаки любого объёма не может ни один поставщик.

Атаки на сетевые протоколы (protocol attacks, L3/L4). Эксплуатация особенностей протоколов — например, SYN flood — для исчерпания ресурсов сетевого оборудования (состояний соединений на межсетевых экранах, балансировщиках), а не самого канала. Защита — фильтрация на периметре, SYN-cookies, ограничение числа состояний соединений.

Атаки на уровень приложения (L7). Имитация легитимных запросов пользователей — HTTP flood, медленные запросы (аналог Slowloris), избыточная нагрузка на ресурсоёмкие операции вроде поиска или формирования отчётов. Цель — исчерпать ресурсы веб-сервера или приложения при относительно небольшом объёме трафика. Защита может включать ограничение частоты запросов (rate limiting), поведенческий анализ, bot-менеджмент, WAF/WAAP с функциями anti-DDoS и фильтрацию на уровне CDN или edge-инфраструктуры.

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

Как мы выстраиваем защиту

• Анализируем профиль нагрузки и архитектуру. Изучаем нормальный трафик, точки отказа, критичные сервисы и текущую пропускную способность каналов.
• Оцениваем вероятные векторы атак. Какие типы атак наиболее вероятны для вашего профиля — с учётом отрасли, публичности и сезонности.
• Проверяем возможность обхода защиты. Анализируем, не раскрыт ли настоящий origin-адрес сервиса — через историю DNS, публичные записи, сторонние интеграции или прямые маршруты, — поскольку хорошо настроенная облачная фильтрация не поможет, если атакующий может обратиться к серверу напрямую в обход неё.
• Подбираем архитектуру защиты. Always-on, on-demand или гибрид; on-premise, облако или защита на стороне провайдера — с учётом бюджета и допустимой задержки реакции.
• Настраиваем фильтрацию и правила. Пороги, сигнатуры, поведенческий анализ — с минимизацией блокировки легитимных пользователей.
• Проверяем устойчивость, где это возможно. Контролируемое тестирование, чтобы не выяснять пределы защиты во время реальной атаки.
• Настраиваем мониторинг и эскалацию. Оповещения, регламент действий во время атаки, точки контакта с провайдером или облачным партнёром.
• Сопровождаем. Регулярный пересмотр правил при изменении профиля нагрузки и появлении новых векторов атак.

Что вы получаете

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

Особенности и ограничения защиты

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

Эскалация и порядок действий при атаке

Порядок согласуется на установочной сессии и фиксируется в договоре. В отличие от многих других услуг ИБ, для DDoS-защиты часть мер по фильтрации трафика обычно согласуется заранее как предварительно разрешённые действия — промедление с согласованием во время активной атаки увеличивает простой сервиса.

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

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

Метрики

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

• время от обнаружения и квалификации атаки до начала эффективной фильтрации (Time to Mitigate) — с отдельным учётом времени переключения маршрута для on-demand формата;
• объём и доля трафика, классифицированного и отфильтрованного средствами защиты как вредоносный в точке фильтрации;
• доля ложных блокировок легитимных запросов — оценивается совместно с бизнес-метриками заказчика;
• количество и характер атак за период, зафиксированных средствами защиты и отражённых в отчётности;
• доступность защищаемого сервиса в период DDoS-инцидентов — совместная результативная метрика, которая учитывается отдельно от простоев по другим причинам (приложение, база данных, инфраструктура заказчика, релизы).

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

Конфиденциальность

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

Регуляторный контекст

Защита от DDoS не является универсальным самостоятельным требованием для любой организации. При этом для отдельных категорий регулируемых информационных систем требования по противодействию атакам, направленным на отказ в обслуживании, установлены непосредственно нормативными и методическими документами ФСТЭК России, а не выводятся из общих соображений о доступности.

Для государственных информационных систем и иных систем, подпадающих под Приказ ФСТЭК России № 117 (вступил в силу 1 марта 2026 года, заменил приказ № 17), действующий методический документ ФСТЭК России от 12.04.2026 «Состав и содержание мероприятий и мер по защите информации, содержащейся в информационных системах» прямо выделяет отдельную группу мер ЗОО — защиту от компьютерных атак, направленных на отказ в обслуживании: контроль и фильтрацию входящего трафика, мониторинг состояния сервисов, балансировку и ограничение нагрузки, резерв пропускной способности и другие меры. Конкретный состав применимых мер определяется классом защищённости, моделью угроз и архитектурой конкретной системы, а не выбирается по единому перечню для всех организаций.

Для значимых объектов КИИ защита от атак на отказ в обслуживании учитывается в составе требований по обеспечению их безопасности, включая Приказ ФСТЭК № 239. Конкретный состав мер определяется категорией значимости объекта, моделью угроз и его архитектурой — применимость этих требований определяется по результатам категорирования, а не действует автоматически для любой организации, работающей в отраслях, указанных в 187-ФЗ.

Если DDoS-атака классифицируется заказчиком как компьютерная атака или компьютерный инцидент применительно к субъекту КИИ, применяются общие сроки и порядок информирования НКЦКИ, установленные приказом ФСБ России от 25.12.2025 № 547, — тот же порядок, что и для иных видов инцидентов и атак, без отдельного специального режима для DDoS.

Требования к доступности сервиса нередко предъявляются договором с заказчиком, партнёром или платёжной системой (SLA), а не только регулятором, — это тоже стоит учитывать при выборе архитектуры и уровня защиты для организаций, не подпадающих под приказ № 117 или требования по КИИ.

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

Порядок работы, сроки, стоимость и приёмка

Как начинается работа: бесплатная первичная оценка (до 30 минут, без подключения к инфраструктуре) → предварительное определение задачи и требуемого уровня защиты → договор и NDA → детальный анализ профиля нагрузки и архитектуры → подбор схемы защиты → настройка и тестирование → перевод в промышленную эксплуатацию → сопровождение.

Объём услуги определяется требуемой пропускной способностью фильтрации, архитектурой (on-premise, облако или защита на стороне провайдера), выбранным форматом (always-on или on-demand) и требованиями к времени реагирования. В договоре фиксируются ёмкость защиты, состав работ, критерии приёмки и порядок эскалации при атаке.

Ориентировочные сроки: анализ профиля нагрузки и подбор архитектуры — от 1 до 2 недель; настройка и тестирование защиты — от 2 до 4 недель, далее — постоянное сопровождение.

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

Почему IST

• В сфере информационной безопасности с 2011 года
• Более 80 специалистов; офисы в Самаре, Оренбурге и Нижнем Новгороде, представительство в Москве
• Лицензии ФСТЭК и ФСБ
• Подбираем архитектуру защиты под профиль нагрузки, а не продаём готовый пакет без анализа инфраструктуры
• Настраиваем фильтрацию с учётом баланса между защитой и доступностью для легитимных пользователей
• Полный цикл услуг: анализ и оценка устойчивости, защита веб-приложений, тестирование на проникновение, проактивный мониторинг

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

В чём разница между защитой от DDoS и WAF? Защита от DDoS направлена прежде всего на сохранение доступности сервиса при объёмных, протокольных и прикладных атаках на отказ в обслуживании. WAF защищает веб-приложение от эксплуатации уязвимостей и может участвовать в фильтрации части L7 DDoS-атак — например, с помощью rate limiting, поведенческих правил и других механизмов. При этом WAF не заменяет защиту канала и сетевой инфраструктуры от объёмных L3/L4 атак.

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

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

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

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