Подбор под профиль трафика
Подбираем сочетание методов под конкретную инфраструктуру и профиль трафика, а не продаём один универсальный инструмент.
Защищаем сайты, API и инфраструктуру от DDoS-атак: объёмные атаки на канал (L3/L4) и атаки на уровень приложения (L7). Подбираем архитектуру под профиль нагрузки.
Защита от DDoS-атак
Защита от DDoS-атак
Защищаем сайты, API, личные кабинеты и сетевую инфраструктуру от атак на отказ в обслуживании — от объёмных атак на канал и сетевые протоколы до целевых атак на уровне приложения. Подбираем и настраиваем защиту под профиль вашей нагрузки, чтобы не блокировать легитимных пользователей вместе с атакой.
Особенности подхода
Разные уровни атак требуют разных методов защиты
То, что останавливает объёмную атаку на канал, обычно не помогает против медленной атаки на уровне приложения, и наоборот.
Не «защита от всего»
Задача — снизить вероятность недоступности сервиса и сократить длительность и последствия воздействия атаки, подобрав архитектуру под конкретный профиль нагрузки.
Баланс защиты и доступности
Настраиваем защиту так, чтобы не блокировать легитимных пользователей вместе с атакой.
Когда актуально
Когда защита от DDoS особенно актуальна
Особенно актуальна в следующих ситуациях.
Публичный сервис без простоев
Сайт, API, личный кабинет, мобильный бэкенд — должен быть доступен без длительных простоев.
Уже были атаки или есть риск
Высокая публичность, конкурентная или спорная тема, сезонные пики повышают вероятность стать целью.
Недоступность = потери
Интернет-магазин, платёжный сервис, СМИ, портал госуслуг — недоступность напрямую означает финансовые потери или репутационный ущерб.
Пиковые периоды
Нужно обеспечить доступность в распродажи, приёмные кампании, значимые публичные события.
Требования SLA
Заказчики или партнёры предъявляют требования к доступности сервиса как к условию SLA.
Если защиты пока нет
С чего начинаем, если защиты пока нет
Отсутствие текущей защиты — стартовая точка, а не препятствие.
- Нет понимания профиля нормальной нагрузки? Сначала анализируем типичный трафик и точки отказа инфраструктуры, чтобы не настраивать фильтрацию вслепую.
- Инфраструктура не готова к переключению трафика? Помогаем выбрать модель — on-premise, облачную или гибридную — под архитектуру и бюджет.
- Нет опыта разбора инцидентов доступности? Настраиваем мониторинг и оповещения, чтобы атака не оставалась незамеченной до жалоб пользователей.
- Защита от DDoS снижает вероятность недоступности сервиса и последствия атаки, но не гарантирует бесперебойную работу при любом объёме и характере атаки. Часть крупных объёмных атак требует оперативного взаимодействия с оператором связи или вышестоящим провайдером в реальном времени — это тоже часть архитектуры защиты, а не её исключение.
Смежные задачи
Как это соотносится с соседними услугами
Несколько услуг относятся к безопасности приложений и инфраструктуры, но решают разные задачи.
Защита от DDoS
Направлена прежде всего на сохранение доступности сервиса при атаках на отказ в обслуживании.
WAF
Защищает приложение от эксплуатации уязвимостей и может участвовать в противодействии части L7 DDoS-атак, но не заменяет защиту канала и сетевой инфраструктуры от объёмных атак.
SAST/DAST
Работают ещё раньше — на этапе разработки и проверки приложения, снижая число уязвимостей, которые можно было бы эксплуатировать.
Форматы работы
Форматы работы
Важное техническое ограничение: локальные средства защиты (on-premise) могут защищать ресурсы приложения и сетевого оборудования, но не устраняют переполнение внешнего канала связи. Если внешний канал уже исчерпан атакой, локальное средство за этим каналом не сможет предотвратить недоступность сервиса. Для крупных объёмных атак фильтрация должна происходить выше по маршруту — у оператора связи, вышестоящего провайдера или в облачном scrubbing-контуре.
Always-on защита. Трафик постоянно проходит через контур фильтрации, поэтому при атаке не требуется отдельное переключение маршрута на защиту — это сокращает время начала противодействия. При этом схема должна учитывать дополнительный сетевой маршрут, задержку и отказоустойчивость самого сервиса защиты.
On-demand защита. Фильтрация подключается при обнаружении атаки — переключение маршрута или включение облачного скраббинга; в обычное время трафик идёт напрямую, но есть задержка на переключение.
Гибридная схема. Базовая защита always-on для типовых атак и дополнительное масштабирование через облако или провайдера при крупных объёмных атаках.
Оценка устойчивости. Контролируемое нагрузочное тестирование инфраструктуры и настроек защиты в согласованном сценарии — как разовая услуга или перед внедрением постоянной защиты. Такой тест позволяет проверить пределы приложения и защиты в контролируемых условиях, но не эквивалентен реальной крупной распределённой DDoS-атаке. Возможность отдельного DDoS-моделирования с участием оператора или провайдера защиты определяется для конкретного проекта.
Классификация угроз
Какие бывают DDoS-атаки
Эти классы атак требуют разных средств защиты, а крупная атака часто сочетает несколько векторов одновременно. Поэтому эффективная защита обычно многоуровневая.
01
Объёмные атаки (L3/L4)
- Переполнение канала связи паразитным трафиком — UDP flood, ICMP flood, амплификация через DNS, NTP и другие протоколы. Нужна достаточная ёмкость upstream-фильтрации и масштабирование выше пропускной способности защищаемого канала
02
Атаки на сетевые протоколы (L3/L4)
- SYN flood и другие — исчерпание ресурсов сетевого оборудования (состояний соединений на МЭ, балансировщиках). Защита — фильтрация на периметре, SYN-cookies, ограничение числа состояний соединений
03
Атаки на уровень приложения (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 сервиса без разделения причин простоя
- Конфиденциальность: доступ к сведениям о сетевой архитектуре, маршрутизации трафика и профиле нагрузки фиксируется до начала работ — NDA, защищённые каналы передачи данных и отчётности, ограничение доступа внутри команды и журналирование обращений к конфигурациям
- Согласованное место обработки и хранения материалов, ограниченный срок хранения с возвратом или уничтожением по окончании работ
Регуляторный контекст
Регуляторный контекст
Защита от DDoS не является универсальным самостоятельным требованием для любой организации. При этом для отдельных категорий регулируемых информационных систем требования по противодействию атакам, направленным на отказ в обслуживании, установлены непосредственно нормативными и методическими документами ФСТЭК России, а не выводятся из общих соображений о доступности.
Приказ ФСТЭК России № 117
Для государственных информационных систем и иных систем, подпадающих под Приказ ФСТЭК России № 117 (вступил в силу 1 марта 2026 года, заменил приказ № 17), действующий методический документ ФСТЭК России от 12.04.2026 «Состав и содержание мероприятий и мер по защите информации, содержащейся в информационных системах» прямо выделяет отдельную группу мер ЗОО — защиту от компьютерных атак, направленных на отказ в обслуживании: контроль и фильтрацию входящего трафика, мониторинг состояния сервисов, балансировку и ограничение нагрузки, резерв пропускной способности и другие меры. Конкретный состав применимых мер определяется классом защищённости, моделью угроз и архитектурой конкретной системы.
Значимые объекты КИИ
Для значимых объектов КИИ защита от атак на отказ в обслуживании учитывается в составе требований по обеспечению их безопасности, включая Приказ ФСТЭК № 239. Конкретный состав мер определяется категорией значимости объекта, моделью угроз и его архитектурой — применимость этих требований определяется по результатам категорирования, а не действует автоматически для любой организации, работающей в отраслях, указанных в 187-ФЗ.
Информирование НКЦКИ
Если DDoS-атака классифицируется заказчиком как компьютерная атака или компьютерный инцидент применительно к субъекту КИИ, применяются общие сроки и порядок информирования НКЦКИ, установленные приказом ФСБ России от 25.12.2025 № 547, — тот же порядок, что и для иных видов инцидентов и атак, без отдельного специального режима для DDoS.
Договорные требования SLA
Требования к доступности сервиса нередко предъявляются договором с заказчиком, партнёром или платёжной системой (SLA), а не только регулятором — это тоже стоит учитывать при выборе архитектуры и уровня защиты для организаций, не подпадающих под приказ № 117 или требования по КИИ.
Материалы анализа нагрузки, настроенная защита и отчётность по инцидентам могут использоваться как документы, подтверждающие принятые меры по обеспечению доступности сервиса. Подтверждением полного соответствия нормативным требованиям сам по себе факт внедрения защиты от DDoS не является — соответствие подтверждается в порядке, установленном для конкретного типа проверки или аттестации.
Порядок работы
Порядок работы, сроки, стоимость и приёмка
Бесплатная первичная оценка (до 30 минут, без подключения к инфраструктуре) → предварительное определение задачи и требуемого уровня защиты → договор и NDA → детальный анализ профиля нагрузки и архитектуры → подбор схемы защиты → настройка и тестирование → перевод в промышленную эксплуатацию → сопровождение.
Объём и договор
Объём услуги определяется требуемой пропускной способностью фильтрации, архитектурой (on-premise, облако или защита на стороне провайдера), выбранным форматом (always-on или on-demand) и требованиями к времени реагирования. В договоре фиксируются ёмкость защиты, состав работ, критерии приёмки и порядок эскалации при атаке.
Сроки
Ориентировочные сроки: анализ профиля нагрузки и подбор архитектуры — от 1 до 2 недель; настройка и тестирование защиты — от 2 до 4 недель, далее — постоянное сопровождение.
Стоимость
Стоимость зависит от требуемой ёмкости фильтрации, выбранного формата, архитектуры и уровня SLA по времени реагирования. Фиксируется до начала работ.
Почему IST
Почему IST
Подбираем архитектуру, а не продаём готовый пакет.
С 2011 года
В сфере информационной безопасности с 2011 года.
Более 80 специалистов
Офисы в Самаре, Оренбурге и Нижнем Новгороде, представительство в Москве.
Лицензии ФСТЭК и ФСБ
Работаем в рамках требований регуляторов на основании действующих лицензий.
Архитектура под нагрузку
Подбираем архитектуру защиты под профиль нагрузки, а не продаём готовый пакет без анализа инфраструктуры.
Баланс защиты и доступности
Настраиваем фильтрацию с учётом баланса между защитой и доступностью для легитимных пользователей.
Полный цикл услуг
Анализ и оценка устойчивости, защита веб-приложений, тестирование на проникновение, проактивный мониторинг.
FAQ
Частые вопросы
Ответы на главные вопросы заказчиков.
- В чём разница между защитой от DDoS и WAF? — Защита от DDoS направлена прежде всего на сохранение доступности сервиса при объёмных, протокольных и прикладных атаках на отказ в обслуживании. WAF защищает веб-приложение от эксплуатации уязвимостей и может участвовать в фильтрации части L7 DDoS-атак — например, с помощью rate limiting, поведенческих правил и других механизмов. При этом WAF не заменяет защиту канала и сетевой инфраструктуры от объёмных L3/L4 атак.
- Можно ли обойтись базовой защитой от хостинг-провайдера или CDN? — Для части сценариев — да, особенно на старте или при невысоком профиле риска. Стоит оценить, какую ёмкость и какие классы атак покрывает такая защита, и понимать её пределы до того, как понадобится масштабирование.
- Сколько времени занимает включение фильтрации при атаке? — При always-on не требуется отдельное переключение трафика на защиту — он уже проходит через контур фильтрации, но время обнаружения атаки и применения мер защиты всё равно зависит от используемой системы и настроенного регламента. On-demand дополнительно требует времени на переключение маршрута или активацию фильтрации.
- Что если атака окажется больше ёмкости выбранной защиты? — Для таких случаев заранее согласуется порядок эскалации к оператору связи или вышестоящему провайдеру — это часть архитектуры защиты, а не исключительная ситуация без плана действий.
- Как понять, что сервис атакуют, а не просто выросла нагрузка? — По характеру трафика: атака обычно отличается от органического роста источниками запросов, их структурой и поведением. Настроенный мониторинг помогает различать эти ситуации, а не полагаться на догадки в моменте.
Обсудить защиту от DDoS
Расскажите о сервисе — оценим риски и предложим архитектуру защиты
Какой профиль нагрузки, были ли уже атаки, насколько критична доступность и есть ли требования по SLA от заказчиков или партнёров. Первичная оценка — бесплатно, до 30 минут, без подключения к инфраструктуре.