SYN-куки
Метод, используемый для противодействия атакам SYN-флуда

SYN cookie — это метод, используемый для противодействия атакам SYN-флуда . Главный изобретатель метода Дэниел Дж. Бернстайн определяет SYN cookie как «определенный выбор начальных номеров последовательности TCP серверами TCP». В частности, использование SYN cookie позволяет серверу избегать разрыва соединений при заполнении очереди SYN. ​​Вместо хранения дополнительных соединений запись очереди SYN кодируется в порядковый номер, отправленный в ответе SYN+ACK . Если затем сервер получает последующий ответ ACK от клиента с увеличенным порядковым номером, сервер может реконструировать запись очереди SYN, используя информацию, закодированную в порядковом номере TCP, и продолжить работу с соединением как обычно.

Выполнение

Чтобы инициировать TCP-соединение, клиент отправляет пакет TCP SYN на сервер. Сервер отвечает пакетом TCP SYN+ACK, который включает в себя порядковый номер, используемый TCP для повторной сборки потока данных. Согласно спецификации TCP, начальный порядковый номер, отправленный конечной точкой, может быть любым значением, выбранным этой конечной точкой. Поскольку этот порядковый номер выбирается отправителем, возвращается получателем и не имеет предопределенной внутренней структуры, его можно перегрузить для переноса дополнительных данных. Ниже описывается одна из возможных реализаций, хотя общедоступного стандарта нет, поэтому порядок, длина и семантика полей могут различаться в разных реализациях cookie SYN.

Файлы cookie SYN — это начальные порядковые номера, которые тщательно создаются в соответствии со следующими правилами:

  • пусть t будет медленно увеличивающейся временной меткой (обычно time(), логически сдвинутой вправо на 6 позиций, что дает разрешение 64 секунды)
  • пусть m будет максимальным значением размера сегмента (MSS), которое сервер мог бы сохранить в записи очереди SYN
  • пусть s будет результатом криптографической хеш-функции, вычисленной по IP-адресу и номеру порта сервера, IP-адресу и номеру порта клиента и значению t . Возвращаемое значение s должно быть 24-битным.

Начальный номер последовательности TCP, т.е. файл cookie SYN , вычисляется следующим образом:

  • Топ 5 бит: t mod 32
  • Средние 3 бита: закодированное значение, представляющее m
  • Нижние 24 бита: s

(Примечание: поскольку 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) был разработан для преодоления этих недостатков SYN cookie и улучшения его в нескольких аспектах. В отличие от SYN cookie, 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]

Смотрите также

Ссылки

  1. ^ [1], cr.yp.to сентябрь 1996 г.
  2. ^ Патрик Макманус, Улучшение Syncookies, lwn.net Апрель 2008 г.
  3. ^ Андраш Корн, Защитные механизмы от сетевых атак и червей (pdf), 2011
  4. ^ Клин, Энди (31 мая 1999 г.). "Реализация Syncookies для ядра Linux (версия 2.2.9)". static unsigned long tcp_lastsynq_overflow
  5. ^ Браун, Сайлас С. (15 октября 2001 г.). «Сети Linux: ошибка безопасности в файлах cookie SYN». Архивировано из оригинала 14 октября 2017 г. Решение (как указал DJ Bernstein в частном сообщении в ответ на вышеизложенное) состоит в том, чтобы сделать переменную tcp_lastsynq_overflow локальной для каждого порта прослушивания, а не глобальной.
  6. ^ «Ядро Linux, использующее файлы cookie syn, может позволить злоумышленнику обойти фильтрацию». 2001. Архивировано из оригинала 2013-04-13 . Получено 2013-03-17 .
  7. ^ «Синкуки».
  • Объяснение файлов SYN cookie от DJ Bernstein
  • RFC  4987 Приложение А
Получено с "https://en.wikipedia.org/w/index.php?title=SYN_cookies&oldid=1235208092"