DDoS-атака представляет собой поток запросов или сетевых пакетов, задача которого — сделать сервис недоступным для обычных пользователей. Источником могут быть тысячи зараженных устройств, облачные виртуальные машины или неправильно настроенные серверы, используемые для усиления трафика.
На практике атаки заметно различаются. Одни забивают канал связи, другие исчерпывают таблицу соединений межсетевого экрана, третьи имитируют поведение реальных посетителей и создают нагрузку на базу данных. Для удобства их часто разделяют по уровням сетевой модели: L3, L4 и L7. Понимание разницы помогает выбрать подходящие средства защиты и быстрее реагировать на инцидент.
Что означают уровни L3, L4 и L7
Обозначения связаны с моделью OSI. Третий уровень отвечает за передачу пакетов между сетями и работу IP. Четвертый — за транспортные протоколы, прежде всего TCP и UDP. Седьмой уровень относится к прикладным протоколам, с которыми взаимодействуют пользователи и приложения, например HTTP и HTTPS.
Границы не всегда абсолютно четкие: одна кампания может сочетать несколько типов нагрузки. Например, злоумышленник одновременно создает большой поток UDP-пакетов и отправляет сложные HTTP-запросы к сайту. Поэтому защищать только один уровень недостаточно.
Атаки уровня L3: перегрузка сетевого канала
Цель атаки L3 — занять пропускную способность канала или перегрузить оборудование, обрабатывающее IP-пакеты. Поток может состоять из ICMP-пакетов, фрагментированного трафика или пакетов с подмененными адресами источника. В атаках с усилением небольшие запросы отправляются на открытые сетевые сервисы, а значительно более крупные ответы перенаправляются на адрес жертвы.
Даже если сервер способен обработать такой объем данных, легитимный трафик не дойдет до него из-за заполненного канала. Локальный межсетевой экран тоже не всегда помогает: нежелательные пакеты уже прошли по внешнему каналу и заняли его полосу.
Главный признак — резкий рост входящего трафика, часто сразу из множества сетей и регионов. Защита должна фильтровать поток до того, как он достигнет подключения компании. Для этого используют распределенные узлы очистки и маршрутизацию трафика через инфраструктуру провайдера.
Атаки уровня L4: давление на TCP и UDP
На транспортном уровне атакующий пытается исчерпать ресурсы сетевого стека, балансировщика или межсетевого экрана. Распространенный пример — SYN flood. Сервер получает большое число запросов на установку TCP-соединения, сохраняет промежуточное состояние и ожидает завершения рукопожатия, которое не происходит.
В результате таблица соединений заполняется, растет нагрузка на процессор, а новые пользователи не могут подключиться. UDP flood действует иначе: на разные порты направляется интенсивный поток датаграмм, который требует обработки и иногда вызывает ответный трафик.
Такая атака может иметь меньшую пропускную способность, чем объемная атака L3, но точнее воздействовать на конкретное устройство или сервис. Для защиты применяют проверку корректности соединений, SYN cookies, ограничения частоты, фильтрацию аномальных пакетов и масштабируемые балансировщики.
Атаки уровня L7: запросы к приложению
Прикладная атака внешне похожа на обычную работу пользователей. Боты открывают страницы, выполняют поиск, обращаются к API, добавляют товары в корзину или многократно запускают ресурсоемкую операцию. Каждый отдельный запрос может быть корректным, поэтому его нельзя заблокировать только по протоколу или порту.
Особенно опасны запросы, которые создают непропорционально высокую нагрузку: сложный отчет, обращение к базе данных без кэша, генерация документа или авторизация с криптографическими вычислениями. Относительно небольшой поток способен исчерпать пул рабочих процессов и соединений с базой данных.
Для анализа L7 нужны сведения о поведении клиента: частота запросов, последовательность переходов, заголовки, cookie, параметры сессии и результат выполнения JavaScript. Здесь применяют WAF, поведенческий анализ, проверку ботов, лимиты для отдельных методов API и кэширование.
Почему одной меры защиты недостаточно
Увеличение пропускной способности помогает выдержать небольшой всплеск, но не заменяет фильтрацию. Межсетевой экран блокирует известные типы пакетов, однако сам может стать узким местом. CDN снижает нагрузку на статический контент, но динамические запросы к API и личному кабинету все равно доходят до приложения.
Поэтому защита строится послойно. На внешнем контуре отсекают объемный и протокольный мусор, а на уровне приложения анализируют содержимое и поведение запросов. Сервис защиты от DDoS-атак должен учитывать как сетевые атаки L3/L4, так и прикладные атаки L7, чтобы злоумышленнику было сложнее обойти фильтрацию сменой техники.
Как понять, что началась атака
Недоступность сайта — уже поздний признак. Полезно отслеживать базовые показатели инфраструктуры и сравнивать их с обычным профилем нагрузки.
- Входящий трафик неожиданно достигает предела канала.
- Резко увеличивается число новых TCP-соединений или незавершенных рукопожатий.
- Растет доля запросов к одному URL, методу API или нестандартному порту.
- Процессор загружен, хотя объем трафика выглядит умеренным.
- Увеличивается время ответа базы данных и число ошибок 502, 503 или 504.
- Запросы приходят с большого количества адресов, но имеют одинаковые характеристики.
Отдельный показатель редко доказывает атаку. Похожую картину может создать рекламная кампания, ошибка клиента или неудачное обновление. Решение принимают по совокупности сетевых и прикладных метрик.
Практическая многоуровневая защита
Фильтрация до входного канала
Если поток превышает пропускную способность подключения, локальные средства уже не смогут восстановить доступность. Трафик необходимо направлять через инфраструктуру, способную принять большой объем, определить аномалию и передать клиенту очищенный поток.
Защита транспортного уровня
Балансировщики и межсетевые экраны должны выдерживать большое число соединений, корректно обрабатывать неполные сессии и ограничивать подозрительную активность. Настройки необходимо проверять под нагрузкой: значения по умолчанию не всегда соответствуют реальному профилю сервиса.
Контроль приложения
Для чувствительных операций устанавливают отдельные лимиты. Авторизацию, восстановление пароля, поиск и формирование отчетов не следует ограничивать одинаково. Кэширование снижает количество обращений к серверу, а WAF и защита от ботов помогают отличать автоматизированные запросы от поведения человека.
Мониторинг и план реагирования
Команда должна заранее знать, кто получает оповещение, связывается с провайдером, анализирует логи и сообщает о ситуации пользователям. Контакты и порядок действий фиксируют в инструкции, а после инцидента корректируют пороги и правила фильтрации.
Что проверить при выборе сервиса защиты
Важно уточнить, какие уровни атак покрываются, как активируется фильтрация и сколько времени занимает реакция. Полезно знать, работает ли защита постоянно или включается только после обнаружения аномалии, где расположены точки очистки и сохраняется ли исходный IP-адрес клиента в логах приложения.
Не менее важна совместимость с текущей сетью и архитектурой сайта. В некоторых случаях достаточно изменить DNS-запись, в других требуется перенастроить маршрутизацию. Если инфраструктура включает облачные серверы, хранение и ИБ-сервисы одного поставщика, взаимодействие при инциденте может быть проще. На сайте Nubes эти направления представлены как части единой облачной платформы для бизнеса.
Следует также проверить условия SLA, доступность поддержки и формат отчетов. После атаки компании нужны данные о времени начала, типе трафика, примененных правилах и объеме отфильтрованных запросов. Без такой информации трудно улучшать собственную защиту.
Итоги
DDoS-атаки L3 перегружают сетевой уровень и канал связи, атаки L4 воздействуют на транспортные протоколы и таблицы соединений, а атаки L7 создают нагрузку на логику приложения. Различия определяют и способы противодействия: очистку трафика, контроль соединений, поведенческий анализ и защиту отдельных операций.
Надежная схема сочетает несколько уровней, непрерывный мониторинг и заранее подготовленный план реагирования. Ее необходимо регулярно проверять нагрузочными тестами и пересматривать после изменений в инфраструктуре. Такой подход помогает заметить атаку до полной недоступности сервиса и уменьшить влияние инцидента на пользователей.
