Выбрать язык


Выбрать язык | Show only


Русский | English


среда, 8 сентября 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 при условии подмены адреса жертвы выглядит так:


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


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

В своем исследовании авторы используют такой термин, как middlebox - устройство с возможностями фильтрации, интеллектуальной обработки и перенаправления трафика. 

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

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

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

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

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

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


В норме, 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-сессии. 


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


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

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


Комментариев нет:

Отправить комментарий