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 от жертвы.

NANOG67: Безопасность TCP Fast Open

Преамбула

Интересно бывает проанализировать зарубежный технологический опыт, благо материалов в открытом доступе хватает. На прошедшей 13-15 июня 2016 в Чикаго конференции NANOG67 в программе присутствовала, пусть и не сверхинновационная, но очень полезная презентация "Network Support for TCP Fast Open" по проблемам использования TCP Fast Open (TFO). Спикер Christoph Paasch из Apple проводит анализ в контексте изучения веб-трафика для оптимизации ресурсов серверов.

Материал в открытом доступе, доступен как в виде краткого обзора, так и презентации, и даже видеозаписи. Кроме пользы материала, дополнительное уважение вызывает спикер, выступающий на инвалидной коляске.

Does DNS use TCP or UDP? RFC says...

Usually we mean DNS uses UDP port 53 but TCP port 53 is reserved for DNS too.
After some time the one question may become interesting for any specialist working with information technologies or information security:

When does DNS use UDP or TCP?

Answer is provided by  RFC5966, section 4. Transport Protocol Selection, where you may find such statements:

Most DNS [RFC1034] transactions take place over UDP [RFC0768].  TCP
[RFC0793] is always used for zone transfers and is often used for
messages whose sizes exceed the DNS protocol's original 512-byte
limit.

So, every request except zone transfer (query type AXFR) and the large message (more than 512 bytes) containing one is processed by UDP.
One can ask: "Why AXFR and large messages must use TCP?". The reason is ability to use UDP-based services with large responses for DDoS-attacks.

All general-purpose DNS implementations MUST support both UDP and TCP
transport.

It means that each DNS-server implementation must support both transport protocols.

DNS использует UDP или TCP? Что говорит RFC

Как правило, считается, что DNS использует UDP port 53, но TCP port 53 также зарезервирован под использование для DNS.  

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

В каком случае DNS работает по UDP, а в каком - по TCP?

На этот вопрос отвечает действующий документ RFC5966, раздел 4. Transport Protocol Selection, в котором фигурируют следующие утверждения:

Most DNS [RFC1034] transactions take place over UDP [RFC0768].  TCP
[RFC0793] is always used for zone transfers and is often used for
messages whose sizes exceed the DNS protocol's original 512-byte
limit.

То есть, большинство DNS-запросов будет обрабатываться с использованием протокола UDP, исключение составляют трансфер зоны (Query type AXFR) и ответы сервера, превышающие 512 байт на одно сообщение. На вопрос "зачем" ответ простой: чтобы не использовались для DDoS.

All general-purpose DNS implementations MUST support both UDP and TCP
transport.

Это означает, что все реализации DNS-серверов в общем случае должны поддерживать использование обоих протоколов транспортного уровня: TCP и UDP.