DDoS-атака TCP Reflected Amplification — причины и методы предотвращения

Дата: 07.09.2021. Автор: Андрей Дугин. Категории: Блоги экспертов по информационной безопасности
DDoS-атака TCP Reflected Amplification - причины и методы предотвращения

Недавно на конференции USENIX Security Symposium была опубликована статья под названием Weaponizing Middleboxes for TCP Reflected Amplification. До этого традиционно считалось, что атаки типа Reflected Amplification — побочный эффект использования протокола UDP. TCP казался абсолютно неуязвимым в связи с необходимостью верификации инициатора сессии методом тройного рукопожатия. Оказалось, что Reflected Amplification с TCP не только возможен, но в некоторых случаях коэффициент усиления может быть практически бесконечным. 

Конечно, вольное переложение статьи на русский было уже предпринято такими порталами, как Securitylab.ru и xakep.ru, но позволю себе не только покритиковать их, но и представить свой вариант изложения сути исследования по TCP amp DDoS на русском языке. Для иллюстрации буду использовать слайды оригинальной презентации — уж слишком они хороши, чтобы придумывать что-то свое.

Атака типа amplification с использованием протокола на базе UDP при условии подмены адреса жертвы выглядит так:

data-original-height=1080

За счет чего TCP считался неуязвимым к атакам reflected amp, хорошо показано на рисунке:

data-original-height=1080

То есть, сценарий отправки SYN/ACK жертве возможен, но по способностям заполнения канала малоэффективен. Исследование показало, что подобную защиту можно обойти. И это не уязвимость протокола TCP, а недостатки сетевой реализации внедрения определенного класса сетевых решений.
В своем исследовании авторы используют такой термин, как middlebox — устройство с возможностями фильтрации, интеллектуальной обработки и перенаправления трафика. 

Middlebox'ами можно назвать:

  • FW/NGFW
  • IPS
  • Proxy
  • Reverse proxy
  • WAF
  • DPI
  • Censor

Перечень не исчерпывающий. 

Условия, которым должен соответствовать middlebox, чтобы его можно было использовать в атаке TCP Reflected Amplification:

  • Имплементация с поддержкой асимметричной маршрутизации, подразумевающая обработку пакетов только в одном направлении.
  • Сконфигурирована отправка/перенаправление на страницу при определенных условиях.
  • Присутствует петля маршрутизации.
  • Повторная отправка контента в случае получения RST-пакета в ответ на страницу блокировки.

То есть, архитектура, подразумевающая обработку TCP-сессий полностью на одном устройстве, либо с онлайн-обменом информацией о сессиях между участниками обработки трафика, не может быть использована в TCP amp-атаке. 

data-original-height=779

В норме, middlebox с поддержкой асимметричной маршрутизации должен увидеть в одном направлении в рамках одной сессии SYN, ACK и дальнейшие PSH+ACK. Опытным путем ученые определили, что завершающий тройное рукопожатие ACK не отслеживается. Вероятно, с целью экономии ресурсов. Проверено 5 возможных комбинаций пакетов с целью вызвать атаку TCP reflected amp на 184 middlebox'ах. 
Результаты описаны в таблице:

Флаги пакетов

Успешно

% успешности

Коэффициент усиления

[SYN; PSH+ACK]

128

69,6

7455

[SYN; PSH]

121

65,7

24

[PSH]

82

44,6

14

[PSH; ACK]

61

33,2

21

[SYN+payload]

21

11,4

527

При этом, главным корнем зла, как и в атаках усиления с использованием UDP, является возможность подмены IP-адреса отправителя в пакете. 

Бесконечное усиление может быть вызвано повторной отправкой middlebox'ом страницы с контентом на RST-пакет жертвы, отправляемый в ответ на нежданный пакет с данными вне существующей TCP-сессии. 

data-original-height=792

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

data-original-height=790

Для того, чтобы минимизировать риск участия оборудования государственной цензуры в атаках TCP reflected amplification, стоит обратить внимание на такие меры:

  • Архитектура, подразумевающая контроль трафика в обе стороны. Зачастую невозможно на больших транзитных сетях провайдеров.
  • Уменьшение размера ответа. Например, вместо выдачи всей страницы, отправлять только redirect с адресом страницы блокировки.
  • ACL. Обрабатывать запросы, приходящие только из сетей своих клиентов на соответствующий интерфейс. Инициировать атаку можно будет только из сети клиента на адреса других клиентов, что минимизирует вероятность атаки и упростит поиск злоумышленника своей юрисдикцией.
  • Удостовериться в отсутствии петель маршрутизации.
  • Настроить middlebox на отсутствие отправки страницы блокировки в ответ на каждый RST-пакет от жертвы, либо устранить дефект ПО.
  • Настроить конечные устройства не отправлять RST в ответ на непонятные пакеты, во избежание штормовой реакции middlebox'а на RST от жертвы.


Источник — Блог Андрея Дугина «Практическая информационная безопасность и защита информации».

Андрей Дугин

Об авторе Андрей Дугин

Блог "Практическая информационная безопасность и защита информации" Андрея Дугина
Читать все записи автора Андрей Дугин

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *