Распределенные атаки отказа в обслуживании относятся к числу наиболее распространенных угроз доступности информационных систем. Их цель состоит в создании такой нагрузки на канал связи, серверное оборудование, сетевые устройства или прикладной сервис, при которой легитимные пользователи теряют возможность получить доступ к ресурсу. В отличие от обычной атаки отказа в обслуживании, DDoS-атака выполняется из множества источников: зараженных рабочих станций, серверов, маршрутизаторов, устройств интернета вещей и арендованных облачных узлов [1].
На практике DDoS-атака редко сводится только к большому числу однотипных запросов. Злоумышленник может сочетать несколько векторов воздействия: перегрузку полосы пропускания, исчерпание таблиц соединений, создание большого числа неполных TCP-сессий, отправку запросов к ресурсоемким функциям веб-приложения. Поэтому защита должна включать обнаружение признаков атаки, выбор набора правил фильтрации, контроль побочных эффектов и последующую корректировку настроек.
Под правилом фильтрации трафика в рамках данной статьи понимается формализованное условие, по которому сетевой пакет, поток или запрос относятся к разрешенным, ограничиваемым либо запрещенным. Условие может учитывать IP-адрес источника, порт назначения, протокол, частоту соединений, размер пакета, наличие аномальных флагов, поведение клиента, параметры HTTP-запроса и результаты предыдущих проверок. Чем больше признаков используется, тем точнее фильтрация, однако тем выше требования к ресурсам системы защиты.
Наиболее общую классификацию DDoS-атак удобно представить через уровень воздействия на инфраструктуру. Такая классификация помогает понять, какие признаки должны использоваться в правилах фильтрации и где именно целесообразно размещать защитные механизмы.
Таблица 1
Основные типы DDoS-атак и возможные меры фильтрации
|
Тип атаки |
Объект перегрузки |
Признаки |
Примеры фильтрации |
|
Объемная |
Канал связи |
Резкий рост входящего потока, большое число однотипных пакетов |
Ограничение скорости, блокировка отраженного трафика, фильтрация по протоколам |
|
Протокольная |
Сетевые устройства и таблицы состояний |
Много неполных соединений, аномальные TCP-флаги |
SYN cookies, ограничение новых соединений, фильтрация некорректных пакетов |
|
Прикладная |
Веб-сервис и база данных |
Много запросов к тяжелым операциям, повторяющиеся URI |
WAF-правила, лимиты на клиента, проверка поведения |
На сетевом уровне применяются правила, которые анализируют адреса источников и назначения, протоколы, порты, размер пакетов и служебные признаки. Такие правила эффективны при грубых объемных атаках, когда поток содержит большое число пакетов одного типа. Преимущество сетевой фильтрации состоит в высокой скорости обработки, а недостаток — в сравнительно малой информативности признаков.
На транспортном и прикладном уровнях фильтрация становится более точной, но и более затратной. Система должна анализировать структуру соединений, частоту HTTP-запросов, повторяющиеся шаблоны, поведение сессии и признаки автоматизированных клиентов. Здесь используются правила веб-экрана приложений, ограничение частоты запросов, проверка JavaScript-заданий, капча, токены сессий и временное отключение ресурсоемких функций [2].
Фильтрация не является разовым действием. Сначала система получает поток входящего трафика и сравнивает его с нормальным профилем работы ресурса. Затем выявляются признаки атаки: аномальный рост запросов, изменение распределения протоколов, увеличение числа ошибок, появление повторяющихся шаблонов или превышение допустимых значений по соединениям. После этого выбирается набор правил, который должен снизить нагрузку и сохранить доступность для легитимных пользователей.
Важным элементом процесса является оценка ресурсов. Даже правильное правило может оказаться неэффективным, если его применение требует слишком больших вычислительных затрат. Поэтому правила должны ранжироваться по стоимости применения: сначала используются простые и быстрые проверки, затем более сложные механизмы анализа подключаются только для спорного или потенциально опасного трафика.
Для формализации выбора правил можно представить множество доступных правил как U = {u1, u2,..., un}. Каждому правилу соответствует бинарная переменная xi, где xi = 1 означает, что правило применяется, а xi = 0 означает, что правило не используется. Тогда набор включенных правил описывается вектором X = (x1, x2,..., xn). Для каждого правила можно определить потребление ресурсов, а также влияние на вероятность пропуска атаки и вероятность ошибочной блокировки легитимного трафика.
В практической системе защиты задача выбора правил может рассматриваться как поиск такого вектора X, при котором вероятность пропуска атаки минимальна, а суммарное потребление ресурсов не превышает допустимого ограничения. При этом вероятность пропуска атаки целесообразно оценивать не только теоретически, но и на основе имитационной модели или накопленной статистики. Такой подход позволяет учитывать реальные особенности нагрузки, структуру запросов и поведение пользователей конкретного сервиса [3].
Отдельного внимания заслуживает проблема ложных срабатываний. В период DDoS-атаки часть легитимных пользователей может выглядеть подозрительно, поскольку они повторяют запросы после ошибок, обновляют страницы или подключаются через общие адреса провайдеров. Поэтому правила фильтрации должны иметь градации реакции: замедление, ограничение частоты, дополнительную проверку или временное помещение в серый список [4].
Методы защиты от DDoS-атак можно разделить на организационные и технические. К организационным относятся разработка плана реагирования, определение ответственных лиц, заключение договора с провайдером защиты, подготовка резервных каналов связи и регулярное тестирование процедур. К техническим относятся фильтрация на маршрутизаторах и межсетевых экранах, использование систем предотвращения вторжений, веб-экранов приложений, сетей доставки контента, Anycast-инфраструктуры и специализированных центров очистки трафика [5].
Таким образом, правила фильтрации трафика при DDoS-атаках должны рассматриваться как адаптивный набор мер, а не как статический список запретов. Их выбор зависит от типа атаки, текущей нагрузки, доступных ресурсов и допустимого уровня риска. Наиболее перспективным является подход, при котором решение о включении правил принимается на основе мониторинга, оценки ресурсов и моделирования последствий. Это позволяет повысить устойчивость информационной системы и одновременно снизить вероятность блокировки легитимных пользователей.
Литература:
- ФСТЭК России. Рекомендации по повышению защищенности информационной инфраструктуры от угроз безопасности информации, связанных с атаками типа «отказ в обслуживании». — М., 2024.
- ФСТЭК России. Требования по безопасности информации к средствам защиты от воздействий типа «отказ в обслуживании», утвержденные приказом ФСТЭК России от 30 июля 2018 г. № 132. — М., 2018.
- ФСТЭК России. Информационное сообщение от 24 марта 2022 г. № 240/22/1549. — М., 2022.
- Абрамов А. Г. Защита от DDoS-атак своими руками: оперативные меры и свободно распространяемые средства // Программные продукты и системы. — 2022. — № 4. — С. 572–582.
- Козырева Н. И. Современные методы предотвращения DDoS-атак и защиты веб-серверов // Современные научные исследования и инновации. — 2025.

