ЧТО ИЗ СЕБЯ ПРЕДСТАВЛЯЕТ DDOS-АТАКА

Список принятных сокращений:

DDoS – Distributed Denial of Service (распределённый отказ в обслуживании).

DoS – Denial of Service (отказ в обслуживании).

HTTP – HyperText Transfer Protocol (протокол передачи гипертекста).

TCP – Transmission Control Protocol (протокол управления передачей).

UDP – User Datagram Protocol (протокол пользовательских датаграмм).

ICMP – Internet Control Message Protocol (протокол управляющих сообщений Интернета).

CDN – Content Delivery Network (сеть доставки контента).

RPS – Requests Per Second (запросов в секунду).

PPS – Packets Per Second (пакетов в секунду).

BPS – Bits Per Second (бит в секунду).

ВВЕДЕНИЕ

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

Целью данной работы является комплексный анализ механизмов DDoS-атак и базовых методов защиты от них с последующей экспериментальной проверкой эффективности некоторых из них на виртуальной машине.

Для достижения цели были поставлены следующие задачи:

1. Дать определение DDoS-атаки, описать её базовый принцип работы (истощение ресурсов) и привести ключевую классификацию.
2. Описать основные технологические и конфигурационные методы защиты от наиболее распространённых типов DDoS-угроз.
3. Провести упрощенный сценарий атаки на виртуальной машине и протестировать некоторые методы защиты.
4. Проанализировать полученные результаты, сделав выводы о практической реализации и действенности рассмотренных мер противодействия в условиях атаки.

В основе методологии лежит эксперимент. Исследование проводится в два этапа: теоретический анализ видов DDoS-атак и методов защиты, и практическая проверка.

Структура работы отражает этот подход. Первая глава содержит теоретический анализ. Вторая глава посвящена практической части: описанию стенда, методике проведения атак, настройке защиты и анализу результатов. В заключении подводятся итоги. Такая последовательность обеспечивает наглядную связь теории и практики.

СУЩНОСТЬ И КЛАССИФИКАЦИЯ DDOS-АТАК.

DDoS-атака (Distributed Denial of Service) представляет собой кибернападение, целью которого является нарушение нормальной работы веб-сервиса, сети или сервера путём их преднамеренной перегрузки. В отличие от простой DoS-атаки с одного источника, DDoS использует распределённую сеть скомпрометированных устройств — ботнет. Ботнет — это сеть заражённых устройств (компьютеров, серверов, роутеров, камер и других гаджетов), которые незаметно для владельцев подчиняются злоумышленнику. Каждое такое устройство называется ботом или «зомби». В DDoS-атаках ботнет используют как «армию»: по команде все боты начинают одновременно слать трафик на одну цель, из‑за чего перегружается канал, оборудование или само приложение.

Изначально ботнеты собирались в основном из заражённых персональных компьютеров, но с развитием интернета вещей всё чаще используются IoT‑устройства: IP‑камеры, видеорегистраторы, домашние роутеры, «умные» устройства. У таких гаджетов слабая защита: заводские логины и пароли, отсутствие обновлений, открытые служебные порты. Поэтому их легко массово захватывать с помощью автоматизированных сканеров, не «ломая» сложные системы безопасности.

Показательный пример IoT‑ботнета — Mirai. Его вредоносное ПО непрерывно сканировало интернет в поисках устройств с открытым доступом по Telnet и пыталось войти на них, используя фиксированную базу из 61 стандартной пары логин‑пароль (например, admin/admin, root/12345 и другие типичные заводские комбинации). Как только подбор удавался, устройство заражалось и пополняло ботнет. За счёт огромного числа таких незащищённых устройств Mirai смог проводить очень мощные DDoS‑атаки, в том числе на крупные интернет‑сервисы и провайдеров, что наглядно показало, как «обычные» бытовые устройства могут превратиться в инструмент крупномасштабных кибератак.

Опасность этих атак заключается также в простоте и доступности. Это стало возможным благодаря модели DDoS-as-a-Service («DDoS-атака как услуга») или так называемым бутерам (booters). Эти сервисы, часто маскирующиеся под «стресс-тесты» сетей, рекламируются в даркнете и даже в открытом доступе. Пользователю достаточно зайти на подобный сайт, выбрать тарифный план (часто стоимость начинается от нескольких долларов в час), указать цель — IP-адрес или доменное имя — и нажать кнопку. Вся сложная инфраструктура — ботнет, управляющие серверы, средства обхода базовых защит — предоставляется сервисом в аренду. Последствия успешной DDoS-атаки могут варьироваться от кратковременной недоступности сайта до срыва бизнес‑процессов и простоя критических сервисов, что особенно опасно для банковского сектора, онлайн‑торговли и госуслуг. Поэтому важно не только понимать технический механизм подобных атак, но и уметь классифицировать их по уровням, что позволяет осознанно подбирать меры защиты.

Для систематизации многообразия атакующих методик наиболее эффективна их классификация по целевым уровням эталонной сетевой модели OSI (Open Systems Interconnection).

Атаки на сетевой уровень (L3): Цель — перегрузить сетевое оборудование и каналы связи. Типичный пример — UDP-флуд. Атакующий отправляет огромное количество UDP-пакетов на случайные порты целевого сервера. Сервер проверяет каждый пакет, но не находит программ, которые ждут данные на этих портах, и отправляет обратно сообщения об ошибке «Порт недоступен». Обработка всех этих бесполезных запросов перегружает канал связи и вычислительные ресурсы сервера.

Атаки на транспортный уровень (L4): Цель — исчерпать память и вычислительные ресурсы сервера. Классический пример — SYN-флуд. Эта атака использует механизм установки TCP-соединения, который называют «трёхсторонним рукопожатием». Атакующий отправляет множество запросов на подключение (SYN-пакеты), но не завершает процесс — игнорирует ответы сервера. В результате сервер держит в памяти тысячи незавершённых соединений, ожидая их завершения. Когда память заполняется, новые подключения от настоящих пользователей становятся невозможны.

Атаки на прикладной уровень (L7): Это самый сложный для обнаружения тип атак. Цель — перегрузить само приложение, например, веб-сервер или базу данных. Типичный пример — HTTP-флуд. Ботнет отправляет на сайт обычные HTTP-запросы — открытие страниц, выполнение поиска, загрузка изображений. Каждый такой запрос выглядит как действие обычного пользователя и требует от сервера полноценной обработки: выполнения программного кода, обращения к базе данных, формирования ответа. Поскольку вредоносные запросы почти не отличаются от легитимных, обнаружить атаку на ранней стадии очень трудно.

МЕТОДЫ И МЕТРИКИ ЗАЩИТЫ

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

Одним из наиболее эффективных методов является использование облачных DDoS-защит и CDN-сетей (Content Delivery Networks). Принцип работы заключается в том, что весь входящий трафик проходит через распределённую инфраструктуру защитного сервиса. Там трафик анализируется в реальном времени: легитимные запросы пропускаются дальше к целевому серверу, а подозрительный и вредоносный трафик блокируется ещё до достижения целевой системы. Преимущество этого подхода в том, что огромный объём атакующего трафика перехватывается на периметре, и целевой сервер защищён от прямого воздействия атаки.

Второй важный метод — ограничение частоты запросов (Rate Limiting). Суть этого подхода в том, чтобы ограничить количество запросов, которое система может принять от одного источника (IP-адреса, пользователя или API-ключа) за определённый промежуток времени. Например, если нормальный пользователь делает несколько запросов в минуту, система может установить лимит в 100 запросов в минуту на один IP. При превышении лимита лишние запросы отклоняются или замедляются. Это эффективно против многих типов атак, так как не требует сложного анализа содержимого каждого запроса.

Для защиты от SYN-флуда используется механизм SYN cookies. Обычно при получении запроса на открытие соединения (SYN-пакета) сервер создаёт запись о новом подключении и отправляет ответ. При массированной атаке память сервера может быть исчерпана из-за количества таких записей. SYN cookies решают эту проблему: вместо сохранения информации о соединении в памяти, сервер кодирует необходимые данные в номер последовательности ответного пакета. Когда клиент завершает подключение, сервер восстанавливает информацию из этого кода. Это позволяет обрабатывать огромное количество SYN-пакетов без переполнения памяти.

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

Фильтрация трафика на уровне сетевого оборудования и межсетевых экранов помогает отсечь аномальные и поддельные пакеты ещё до их обработки сервером. Такие фильтры могут блокировать трафик с невалидными флагами TCP, фрагментированные пакеты, а также известные вредоносные IP-адреса и диапазоны.

Для защиты от сложных атак на прикладном уровне (L7) используются методы анализа поведения трафика. Системы могут выявлять нечеловеческие паттерны: например, сотни однотипных запросов подряд без задержек между ними, одинаковые заголовки, повторяющиеся параметры. При обнаружении таких паттернов источник может быть заблокирован, его запросы замедлены или ему может быть предложено решить капчу. Такие методы часто встраиваются в веб-приложение или в обратный прокси-сервер.

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

На практике наиболее эффективная защита достигается при комбинировании нескольких методов одновременно. Например, облачная DDoS-защита фильтрует основную массу атакующего трафика, Rate Limiting дополнительно контролирует оставшийся трафик, SYN cookies и оптимизированные параметры ОС повышают устойчивость к специфическим атакам, а анализ поведения трафика выявляет скрытые и изощрённые атаки на прикладном уровне. Важно учитывать, что ни один из описанных методов не даёт абсолютной гарантии безопасности, поэтому защита от DDoS носит вероятностный характер и требует постоянного обновления и адаптации к новым векторам атак.

Мощность DDoS-атаки определяется несколькими параметрами. Чаще всего выделяют BPS, PPS и RPS.

BPS (bits per second) отражает объём входящего трафика в секунду (обычно в Гбит/с) и важен для объёмных L3/L4-атак, которые «забивают» канал. Например, в отчёте Qrator за 1 квартал 2024 года упоминалась UDP‑флуд‑атака в сегменте онлайн‑ставок с пиком 881,75 Гбит/с, что характеризует атаку, рассчитанную на перегрузку пропускной способности.

PPS (packets per second) показывает, сколько пакетов в секунду приходится обрабатывать оборудованию; опасность в том, что даже при умеренном объёме трафика большое число мелких пакетов может перегрузить маршрутизаторы и фильтры. В том же периоде фиксировалась TCP‑атака интенсивностью 179,42 млн пакетов в секунду, что иллюстрирует «пакетный» характер перегрузки.

RPS (requests per second) применяется к L7‑атакам и описывает частоту запросов к приложению (например, HTTP), из‑за чего перегружаются веб‑сервер и база данных. В отчёте Qrator за 1 квартал 2024 года отмечалась атака на банковский сегмент с пиком 220 тысяч запросов в секунду, что является примером прикладной перегрузки при внешне “обычных” запросах.

В Российской Федерации ответственность за организацию и проведение DDoS-атак регулируется Уголовным кодексом РФ. Основными применяемыми статьями являются: статья 272 УК РФ (неправомерный доступ к компьютерной информации), статья 273 УК РФ (создание и распространение вредоносных программ), статья 274 УК РФ (нарушение правил эксплуатации средств передачи компьютерной информации) и статья 274.1 УК РФ (неправомерное воздействие на критическую информационную инфраструктуру). Наиболее суровые наказания предусмотрены именно по статье 274.1 при атаках на критически важные объекты государственной инфраструктуры — вплоть до лишения свободы на срок до 8 лет, что подчёркивает серьёзность данного вида киберпреступлений и их общественную опасность.

ПРАКТИЧЕСКАЯ ЧАСТЬ

В теоретической части работы были рассмотрены сущность и классификация DDoS‑атак, а также основные подходы к их предотвращению на разных уровнях модели OSI: от фильтрации трафика и SYN cookies до механизма rate limiting и анализа поведения запросов на прикладном уровне. Эти методы носят общий характер и применимы к широкому классу систем, однако для оценки их реальной эффективности необходимо экспериментальное подтверждение в конкретных условиях.

В качестве предмета практического исследования выбран веб‑сервер nginx, который имеет встроенные средства ограничения числа соединений и частоты запросов (limit_conn, limit_req), прямо реализующие теоретически описанный подход Rate Limiting к защите от L7‑DDoS‑атак. Для воспроизведения сценария атаки и оценки влияния защитных настроек используется утилита ApacheBench, позволяющая имитировать массовые HTTP‑обращения к серверу и измерять показатели производительности и отказоустойчивости.

Практическая часть работы выполнялась в виртуальной среде Oracle VirtualBox на локальном компьютере. В качестве гостевой системы использовался серверный дистрибутив Ubuntu Server, что позволило воспроизвести типовые условия эксплуатации веб‑сервера в реальной инфраструктуре и при этом безопасно экспериментировать с его конфигурацией. Внутри виртуальной машины были установлены веб‑сервер nginx и утилита ApacheBench (ab), входящая в состав пакета Apache2‑utils и предназначенная для нагрузочного тестирования HTTP‑служб.

Веб‑сервер nginx размещал статический контент в каталоге /var/www/html и обслуживал запросы по адресу http://127.0.0.1:80/. Нагрузочная утилита ApacheBench запускалась с той же виртуальной машины и имитировала большое количество параллельных клиентов, обращающихся к веб‑сервису. Такой стенд позволяет продемонстрировать, как выглядит поведение сервера под нагрузкой и как включение средств защиты влияет на количество успешно обработанных запросов и устойчивость сервиса.

Для моделирования упрощённого сценария DDoS‑атаки использовалась утилита ApacheBench, генерирующая большое число одновременных HTTP‑запросов. В ходе экспериментов применялась команда вида:

ab -t 30 -c 500 http://127.0.0.1:80/

где параметр -t 30 задавал длительность теста в секундах, а -c 500 — число параллельных соединений. Таким образом, один источник трафика в течение 30 секунд имитировал поведение «ботнета» из 500 одновременных клиентов, что хорошо соответствует описанному в теоретической части принципу исчерпания ресурсов за счёт большого количества запросов.

В базовом режиме nginx работал с типовой конфигурацией, без явных ограничений числа соединений и частоты запросов. При запуске ApacheBench с параметрами -t 30 -c 500 веб‑сервер успешно обработал 28640 запросов, при этом Failed requests оказалось равным нулю, а показатель Requests per second составил около 952 запросов в секунду (приложение А). Эти значения демонстрируют высокую пропускную способность nginx и его способность обслуживать значительный объём параллельных HTTP‑запросов без явных признаков отказа.

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

Для проверки эффективности прикладной защиты от DDoS‑нагрузки в конфигурацию nginx были добавлены механизмы rate limiting и ограничения числа соединений, обсуждавшиеся в теоретической части. В блок http файла nginx.conf были внесены директивы:

limit_req_zone  $binary_remote_addr  zone=req_zone:10m  rate=1r/s;

limit_conn_zone $binary_remote_addr  zone=conn_zone:10m;

которые создают зоны учёта запросов и соединений для каждого IP‑адреса клиента. В конфигурации виртуального хоста /etc/nginx/sites-enabled/default ограничения были заданы следующим образом:

server {

    listen 80 default_server;

    listen [::]:80 default_server;

    limit_conn conn_zone 1;

    limit_req zone=req_zone burst=1 nodelay;

    root /var/www/html;

    index index.html index.htm index.nginx-debian.html;

    ...

}

Директива limit_conn conn_zone 1 разрешает не более одного одновременного соединения с одного IP‑адреса, а limit_req zone=req_zone burst=1 nodelay ограничивает частоту запросов одним запросом в секунду с минимальной очередью. Такая конфигурация представляет собой жёсткий вариант rate limiting, непосредственно реализующий описанный ранее метод защиты от L7‑DDoS‑атак.

Повторный запуск ApacheBench с теми же параметрами (-t 30 -c 500) показал, что суммарно удалось выполнить лишь около 2600 успешных запросов, после чего в отчёте стали появляться сообщения Connection reset by peer (104) и резко выросло число неуспешных обращений (приложение Б). Это означает, что nginx достиг заданных лимитов и начал разрывать лишние соединения и отклонять запросы, выходящие за пределы допустимой частоты и количества. Таким образом, включённые директивы limit_req и limit_conn фактически превращают абстрактный теоретический принцип ограничения ресурсов в конкретный механизм защиты, измеряемый изменением показателей нагрузочного теста.

Сопоставление двух режимов работы nginx показывает прямую связь между теоретическими представлениями о DDoS‑атаках и их практической реализацией:

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

ЗАКЛЮЧЕНИЕ

Работа подтвердила, что DDoS‑атаки действительно являются самостоятельным и крайне опасным видом киберугроз, основанным на преднамеренном истощении ресурсов сервера и сети за счёт распределённого трафика от ботнетов и DDoS‑сервисов.

Теоретический разбор показал, что такие атаки охватывают разные уровни модели OSI и измеряются по BPS, PPS и RPS, а защита требует совмещения сетевых фильтров, механизмов SYN cookies, облачных сервисов и прикладного rate limiting.

Практический эксперимент с nginx и ApacheBench на виртуальной машине подтвердил, что без ограничений один источник способен генерировать десятки тысяч запросов, а включение директив limit_req и limit_conn резко снижает число обслуженных запросов и приводит к разрыву лишних соединений, тем самым реально ослабляя воздействие моделируемой DDoS‑нагрузки.

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

ПРИЛОЖЕНИЯ

Приложение А

Результаты нагрузочного теста без ограничений

Приложение Б

Результаты нагрузочного теста при включённой защите

Список литературы:

1. Apache HTTP Server Benchmarking Tool (ab) [Электронный ресурс].
2. Cloudflare. DDoS Threat Report for 2024 Q1 [Электронный ресурс].
3. DDoS-Guard. Мощность DDoS-атак: в чём измеряется и как определить [Электронный ресурс].
4. Heimdal Security. A Technical Analysis of the Mirai Botnet Phenomenon. 2023 [Электронный ресурс].
5. Mirai (malware) // Wikipedia [Электронный ресурс].
6. Nginx documentation: Module ngx_http_limit_conn_module [Электронный ресурс].
7. Nginx documentation: Module ngx_http_limit_req_module [Электронный ресурс].
8. Qrator Labs. Q1 2024 DDoS Attacks Statistics and Overview [Электронный ресурс].
9. Solar Space (ГК «Солар»). DDoS-атаки: что это такое и как защитить свои сайты [Электронный ресурс].
10. Уголовный кодекс Российской Федерации от 13.06.1996 № 63-ФЗ (ред. от 16.12.2025). Статья 272. Неправомерный доступ к компьютерной информации [Электронный ресурс].
11. Уголовный кодекс Российской Федерации от 13.06.1996 № 63-ФЗ (ред. от 16.12.2025). Статья 273. Создание, использование и распространение вредоносных компьютерных программ [Электронный ресурс].
12. Уголовный кодекс Российской Федерации от 13.06.1996 № 63-ФЗ (ред. от 16.12.2025). Статья 274. Нарушение правил эксплуатации средств хранения, обработки или передачи компьютерной информации и информационно-телекоммуникационных сетей [Электронный ресурс].
13. Уголовный кодекс Российской Федерации от 13.06.1996 № 63-ФЗ (ред. от 26.07.2017). Статья 274.1. Неправомерное воздействие на критическую информационную инфраструктуру Российской Федерации [Электронный ресурс].