файлы cookie SYN
SYN cookie — это метод, используемый для защиты от атак SYN-флуд . Главный изобретатель этого метода Дэниел Дж. Бернштейн определяет файлы cookie SYN как «особый выбор начальных порядковых номеров TCP серверами TCP». В частности, использование файлов cookie SYN позволяет серверу избежать разрыва соединений при заполнении очереди SYN. Вместо хранения дополнительных соединений запись очереди SYN кодируется в порядковый номер, отправленный в ответе SYN+ACK . Если сервер затем получает последующий ответ ACK от клиента с увеличенным порядковым номером, сервер может восстановить запись очереди SYN, используя информацию, закодированную в порядковом номере TCP, и продолжить соединение как обычно.
Выполнение
[ редактировать ] |
Чтобы инициировать TCP-соединение, клиент отправляет на сервер пакет TCP SYN. Сервер отвечает пакетом TCP SYN+ACK, который включает порядковый номер, используемый TCP для повторной сборки потока данных. Согласно спецификации TCP, исходный порядковый номер, отправленный конечной точкой, может быть любым значением, выбранным этой конечной точкой. Поскольку этот порядковый номер выбирается отправителем, возвращается получателем и не имеет предопределенной внутренней структуры, его можно перегрузить для передачи дополнительных данных. Ниже описана одна из возможных реализаций, хотя общедоступного стандарта не существует, поэтому порядок, длина и семантика полей могут различаться в разных реализациях SYN cookie.
Файлы cookie SYN представляют собой начальные порядковые номера, которые тщательно создаются в соответствии со следующими правилами:
- пусть t будет медленно увеличивающейся временной меткой (обычно time() логически сдвигается вправо на 6 позиций, что дает разрешение 64 секунды)
- пусть m будет значением максимального размера сегмента (MSS), которое сервер мог бы сохранить в записи очереди SYN.
- пусть это будет результат криптографической хеш-функции, вычисленной по IP-адресу и номеру порта сервера, IP-адресу и номеру порта клиента, а также значению t . Возвращаемое значение s должно быть 24-битным значением.
Исходный порядковый номер TCP, т. е. файл cookie SYN , вычисляется следующим образом:
- Верхние 5 бит: t mod 32
- Средние 3 бита: закодированное значение, представляющее m
- Нижние 24 бита: с
(Примечание: поскольку m должно быть закодировано с использованием 3 битов, сервер может отправлять до 8 уникальных значений для m при использовании файлов cookie SYN.)
Когда клиент отправляет обратно пакет TCP ACK на сервер в ответ на пакет SYN+ACK сервера, клиент должен (согласно спецификации TCP) использовать n+1 пакета в номере подтверждения , где n — начальный порядковый номер отправленного пакета. сервером. Затем сервер вычитает 1 из номера подтверждения, чтобы выявить файл cookie SYN, отправленный клиенту.
Затем сервер выполняет следующие операции.
- Сравнивает значение t с текущим временем, чтобы узнать, истек ли срок действия соединения.
- Пересчитывает s , чтобы определить, действительно ли это действительный файл cookie SYN.
- Декодирует значение m из 3-битной кодировки в файле cookie SYN, которое затем можно использовать для восстановления записи очереди SYN.
С этого момента соединение происходит как обычно.
Недостатки
[ редактировать ]Использование файлов cookie SYN не нарушает каких-либо спецификаций протокола и, следовательно, должно быть совместимо со всеми реализациями TCP. Однако есть два предостережения, которые вступают в силу при использовании файлов cookie SYN. Во-первых, сервер ограничен только 8 уникальными значениями MSS, поскольку это все, что можно закодировать в 3 бита. Во-вторых, ранние реализации отвергали все параметры TCP (например, большие окна или временные метки), поскольку сервер отбрасывал запись очереди SYN, в которой в противном случае хранилась бы эта информация. [1] однако в версии 2.6.26 ядра Linux добавлена частичная поддержка параметров TCP путем их кодирования в параметр метки времени . [2] Наконец, файлы cookie SYN увеличивают нагрузку на ресурсы сервера. Шифрование ответов требует больших вычислительных затрат. Файл cookie SYN не уменьшает трафик, что делает его неэффективным против атак SYN-флудинга, направленных на пропускную способность в качестве вектора атаки.
Хотя эти ограничения обязательно приводят к неоптимальному опыту, клиенты редко замечают их эффект, поскольку они применяются только в случае атаки. В такой ситуации потеря параметров TCP ради сохранения соединения обычно считается разумным компромиссом.
Проблема возникает, когда пакет ACK, завершающий соединение, отправленный клиентом, теряется, а протокол прикладного уровня требует, чтобы сервер говорил первым ( SMTP и SSH два примера — ). В этом случае клиент предполагает, что соединение установлено успешно, и ждет, пока сервер отправит баннер протокола или повторно отправит пакет SYN+ACK; однако сервер не знает о сеансе и не будет повторно отправлять SYN+ACK, поскольку он отбросил запись очереди невыполненной работы, которая позволяла бы ему это сделать. В конце концов клиент прервет соединение из-за тайм-аута уровня приложения, но это может занять относительно много времени. [3]
Стандарт TCP Cookie Transactions (TCPCT) был разработан для преодоления этих недостатков файлов cookie SYN и улучшения их в нескольких аспектах. В отличие от файлов cookie SYN, TCPCT является расширением TCP и требует поддержки со стороны обеих конечных точек. Статус «Исторического» ему был присвоен RFC 7805 в 2016 году.
Соображения безопасности
[ редактировать ]Простые брандмауэры , которые настроены так, чтобы разрешать все исходящие соединения, но ограничивать порты, к которым может достигать входящее соединение (например, разрешать входящие подключения к веб-серверу через порт 80, но ограничивать все остальные порты), работают, блокируя только входящие запросы SYN для нежелательных порты. Если файлы cookie SYN используются, следует позаботиться о том, чтобы злоумышленник не смог обойти такой брандмауэр, вместо этого подделав ACK и пробуя случайные порядковые номера, пока один из них не будет принят. Файлы cookie SYN следует включать и выключать для каждого порта , чтобы включение файлов cookie SYN на общедоступном порту не приводило к их распознаванию на закрытом порту. Исходная реализация ядра Linux неправильно поняла эту часть описания Бернштейна и использовала одну глобальную переменную для включения файлов cookie SYN для всех портов; [4] на это указал студент-исследователь [5] и впоследствии исправлено в CVE - 2001-0851 . [6]
История
[ редактировать ]Метод был создан Дэниелом Дж. Бернштейном и Эриком Шенком в сентябре 1996 года. Первая реализация (для SunOS ) была выпущена Джеффом Вайсбергом месяцем позже, а Эрик Шенк выпустил свою реализацию для Linux в феврале 1997 года. FreeBSD реализует syncookies начиная с FreeBSD 4.5 ( январь 2002 г.). [7]
См. также
[ редактировать ]Ссылки
[ редактировать ]- ^ Андраш Корн, Механизмы защиты от сетевых атак и червей (pdf) , 2011 г.
- ^ Клин, Энди (31 мая 1999 г.). «Реализация Syncookies для ядра Linux (версия 2.2.9)» .
статический беззнаковый длинный tcp_lastsynq_overflow
- ^ Браун, Сайлас С. (15 октября 2001 г.). «Сеть Linux: ошибка безопасности в файлах cookie SYN» . Архивировано из оригинала 14 октября 2017 г.
Решение (как указал DJ Bernstein в частном сообщении в ответ на вышеизложенное) состоит в том, чтобы сделать переменную tcp_lastsynq_overflow локальной для каждого прослушивающего порта, а не глобальной.
- ^ «Ядро Linux, использующее файлы cookie синхронизации, может позволить злоумышленнику обойти фильтрацию» . 2001. Архивировано из оригинала 13 апреля 2013 г. Проверено 17 марта 2013 г.
- ^ «Синкуки» .