Недавно на конференции 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, хорошо показано на рисунке:
Middlebox'ами можно назвать:
- FW/NGFW
- IPS
- Proxy
- Reverse proxy
- WAF
- DPI
- Censor
Перечень не исчерпывающий.
Условия, которым должен соответствовать middlebox, чтобы его можно было использовать в атаке TCP Reflected Amplification:
- Имплементация с поддержкой асимметричной маршрутизации, подразумевающая обработку пакетов только в одном направлении.
- Сконфигурирована отправка/перенаправление на страницу при определенных условиях.
- Присутствует петля маршрутизации.
- Повторная отправка контента в случае получения RST-пакета в ответ на страницу блокировки.
То есть, архитектура, подразумевающая обработку TCP-сессий полностью на одном устройстве, либо с онлайн-обменом информацией о сессиях между участниками обработки трафика, не может быть использована в TCP amp-атаке.
|
Флаги
пакетов |
Успешно |
% успешности |
Коэффициент усиления |
|
[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 |
Бесконечное усиление может быть вызвано повторной отправкой middlebox'ом страницы с контентом на RST-пакет жертвы, отправляемый в ответ на нежданный пакет с данными вне существующей TCP-сессии.
Также, если при внедрении была допущена ошибка, приводящая к петле маршрутизации - сам факт закольцовывания без некорректной обработки RST-ответа жертвы будет вызывать умножение количества пакетов, пока не иссякнет TTL. Если же TTL в петле по какой-то причине регенерируется - коэффициент усиления может быть бесконечным.
Для того, чтобы минимизировать риск участия оборудования государственной цензуры в атаках TCP reflected amplification, стоит обратить внимание на такие меры:
- Архитектура, подразумевающая контроль трафика в обе стороны. Зачастую невозможно на больших транзитных сетях провайдеров.
- Уменьшение размера ответа. Например, вместо выдачи всей страницы, отправлять только redirect с адресом страницы блокировки.
- ACL. Обрабатывать запросы, приходящие только из сетей своих клиентов на соответствующий интерфейс. Инициировать атаку можно будет только из сети клиента на адреса других клиентов, что минимизирует вероятность атаки и упростит поиск злоумышленника своей юрисдикцией.
- Удостовериться в отсутствии петель маршрутизации.
- Настроить middlebox на отсутствие отправки страницы блокировки в ответ на каждый RST-пакет от жертвы, либо устранить дефект ПО.
- Настроить конечные устройства не отправлять RST в ответ на непонятные пакеты, во избежание штормовой реакции middlebox'а на RST от жертвы.
