Выбрать язык


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


Русский | English


воскресенье, 3 июля 2016 г.

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

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

Озвученная проблема
На высоконагруженных ресурсах использование полноценного TCP для обслуживания каждого запроса - дорого с точки зрения потребления вычислительных ресурсов и времени установки сессии. В RFC7413 описана облегченная реализация под названием "TCP Fast Open". При использовании в приложениях TCP Fast Open появляются проблемы прохождения трафика через промежуточные устройства, выполняющие проверку на легитимность TCP-сессии, типа firewall и IDS/IPS, для которых TFO является ненормальным трафиком в связи с отклонениями от стандартного TCP. Как итог, выступление призывает производителей сетевого оборудования и операторов задуматься о поддержке в своем оборудовании и сети TCP-трафика, инициируемого с использованием TCP Fast Open. 

Дискуссия
Казалось бы, чисто американская конференция операторов связи, описывающая просто технологическое предложение. Но, поскольку TFO используется в iOS 9, OS X 10.11 и более поздних версиях, а также поддерживается в Apple Service, думаю, география вопроса потенциально расширяется далеко за пределы североамериканского континента, натягиваясь на весь глобус.

Краткая вводная, известная преобладающему большинству специалистов ИТ/ИБ: TCP работает по принципу "трехстороннего рукопожания":



Кристоф даже приводит интересную юмористическую аналогию. Как бы выглядел юмор, если бы шутки передавались по TCP (лично у меня это проассоциировалось с SCTP, а не TCP):



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



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




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

Открытые вопросы
Навскидку вижу такие потенциальные проблемы.
  • Уязвимости клиента и сервера, связанные с обработкой Cookies. В "чистом" TCP стек не передает приложению данных из SYN-пакета (которые можно вставить, RFC позволяет), соответственно, проблем с их обработкой практически нет. В приложениях с поддержкой TFO могут потенциально возникнуть связанные с Cookies уязвимости TCP-стека и приложения.
  • Cookie. Алгоритм генерации и составляющие. От них напрямую зависит возможность использования чужой сессии как для получения данных, предназначенных для другого клиента, так и для спуфинга с соответствующим DDoS. Как видно из презентации, стойкость к перебору зависит от наличия соли и ее комплексности. Есть подозрение, что если ПО сервера будет позволять генерацию Cookie без соли, то большой процент администраторов не будет заморачиваться с ее использованием. В этом случае джентльменский набор для DDoS из скриптов генерации запросов и базы кук для спуфинга в виде хэшей IP всех потенциальных жертв будет занимать совсем немного места.
  • Cookie. Время жизни. Тоже немаловажный фактор, особенно если администратор сервера не озаботился наличием соли для куки. При отсутствии соли и длительном времени жизни куки TFO приближается по уровню безопасности к UDP.
  • Cookie. Перебор. Затрудняюсь предположить, как реализовать механизмы защиты.
  • NAT типа PAT, он же many-to-one. К одному серверу обращается много клиентов, которые прячутся за одним реальным IP-адресом. Постоянная перегенерация куки будет аннулировать полученные преимущества в экономии вычислительных ресурсов, в то время как поддержка сервером большого количества кук на одного клиента (RFC позволяет) упрощает процесс подбора куки.

Выводы 
Поддержка TCP Fast Open, наряду с оптимизацией ресурсов серверов при обработке TCP-сессий, привносит некоторые потенциальные проблемы с безопасностью подобной реализации, которые можно минимизировать следующими путями:
  • Тестирование на уязвимости, связанные с обработкой Cookies TCP-стека и приложения.
  • Повышение комплексности Cookie за счет использования соли (возможно, еще дополнительных опций) и коллизионно-стойкого алгоритма хэширования.
  • Понижение времени жизни Cookie.
  • Внедрение механизмов защиты от перебора Cookie.
  • Не передавать данные, не получив ACK. Тогда протокол будет еще безопаснее, чем "чистый" TCP, за счет наличия Cookies, но экономии в потреблении ресурсов тоже не будет.

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

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