SYN cookies

SYN cookie — это определённое, специальным образом сформированное значение начального порядкового номера (ISN), которое сервер использует в момент установления TCP-соединения^[1]. Этот подход позволяет серверу хранить информацию о полуоткрытых соединениях непосредственно в начальном порядковом номере, который возвращается клиенту при инициализации соединения^{[2][3][4][5][6]}. Использование SYN cookies защищает сервер от атак SYN flood, при которых злоумышленник, используя подделанные SYN-пакеты с произвольными источниками IP, пытается исчерпать всю память сервера, чтобы тот не мог обслуживать легитимных пользователей^[4]. SYN cookies активируются только при превышении порога числа полуоткрытых соединений^[1]. При этом генерация и проверка SYN cookies требует значительных затрат процессорного времени, что ограничивает эффективность метода при атаках малой/средней мощности^[4].

SYN cookie имеет следующую структуру:

Значение SYN cookie.

• первые 5 битов равны ${\displaystyle T{\bmod {3}}2}$, где ${\displaystyle T}$ — 5-битовый счётчик времени, увеличиваемый каждые 64 секунды;
• следующие 3 бита — код того максимального размера сегмента (MSS), который сервер выбрал в ответ на MSS клиента;
• последние 24 бита получаются с помощью криптографической хеш-функции.

Такая схема формирования номера последовательности обусловлена требованиями TCP к их плавному возрастанию^[7]. В данной реализации серверный ISN растёт несколько быстрее клиентского^[7].

Точный механизм кодирования состояния в SYN+ACK номере зависит от реализации^[8]. Например, в Linux формула такова^[9]:

${\displaystyle syncookie=H(s_{1},sa,sp,da,dp)+ISN_{c}+(t\times 2^{24})+(H(s_{2},sa,sp,da,dp,t){\bmod {2}}^{24})+MSS_{i}}$^[10]

где ${\displaystyle ISN_{c}}$ — ISN клиентского SYN-пакета, ${\displaystyle t}$ — счётчик времени в 5 бит, ${\displaystyle MSS_{i}}$ — закодированное значение MSS (от 0 до 7), ${\displaystyle s_{1}}$ и ${\displaystyle s_{2}}$ — секретные ключи сервера, ${\displaystyle H}$ — криптографическая хеш-функция (например, MD5 или SHA-1), ${\displaystyle sa}$, ${\displaystyle sp}$, ${\displaystyle da}$ и ${\displaystyle dp}$ — соответственно исходный адрес, порт источника, адрес назначения и порт назначения^[10].

Установление TCP-соединения с SYN cookie повторяет последовательность классического трёхэтапного рукопожатия (трёхэтапное согласование):

1. SYN: клиент инициирует соединение, отправляя SYN-пакет с ISN ${\displaystyle ISN_{c}}$^[10];
2. SYN+ACK: сервер рассчитывает SYN cookie (ISN_s), инкрементирует ISN клиента и возвращает SYN+ACK с ISN_s как sequence number и ISN_c как acknowledgment number^[4];
3. ACK: клиент инкрементирует ISN_s и отправляет ACK с этим значением в поле acknowledgment number^[3].

Сервер проверяет корректность номера подтверждения ACK-пакета^[10]. Если он валиден, сервер выделяет память под соединение и переходит в состояние ESTABLISHED^[4]; иначе ACK отклоняется^[11].

Механизм проверки SYN cookie зависит от способа его кодирования^[8]. Для Linux формула такова^[9]:

${\displaystyle MSS_{i_{2}}=acknum-seqnum-t\times 2^{24}-H(s_{1},sa,sp,da,dp)-(H(s_{2},sa,sp,da,dp,t){\bmod {2}}^{24})}$^[10]

где ${\displaystyle acknum}$ и ${\displaystyle seqnum}$ — значения acknowledgment/sequence number в ACK, ${\displaystyle t}$ — 5-битовый счётчик, ${\displaystyle s_{1}}$, ${\displaystyle s_{2}}$ — секретные ключи сервера, ${\displaystyle H}$ — хеш-функция, ${\displaystyle sa}$, ${\displaystyle sp}$, ${\displaystyle da}$, ${\displaystyle dp}$ — адреса исхода/назначения и их порты^[10].

Если ${\displaystyle MSS_{i_{2}}}$ в диапазоне 0–7, ACK считается допустимым. Сервер создаёт соединение с соответствующим MSS. Если пакет поддельный, ${\displaystyle MSS_{i_{2}}}$ скорее всего выйдет за этот диапазон^[10].

SYN cookies зависят только от финального ACK-пакета: поскольку сервер не сохраняет состояние подключения^{[2][3][4][5][6]}, он не может узнать, был ли SYN+ACK утерян, и повторить передачу^[12]. Это открывает уязвимость: атакующий инициирует у сервера включение SYN cookies посредством SYN-флуда^[3][13], затем отправляет множество фальшивых ACK-пакетов с произвольными sequence number — в надежде, что некоторые из них будут восприняты как валидные SYN cookies^[3][12].

Установлено, что для взлома нужно подобрать только 24 младших бита sequence number (а не все 32)^[12]; вероятность успеха — 1/2^{24}^[14]. Атакующий может посылать до 2^{24} ACK-пакетов в минуту (около 85 Мбит/с) ради одного удачного взлома^[14]. Такое нагнетание нагрузит процессор и полосу пропускания сервера, хотя и не приведёт к переполнению оперативной памяти как при обычном SYN-флуде^[12][14].

Недостатком применения SYN cookies является невозможность передачи через них дополнительных параметров из поля «options» TCP-пакета SYN^[14][15]. Такие параметры, как размер окна приёма^[6][14][15], селективное подтверждение, RTT, PAWS или MSS делают соединение эффективнее^[6][14][15]. Однако этот недостаток играет роль только во время атаки (когда сервер включает SYN cookies); в остальное время сервер по-прежнему использует стандартную процедуру согласования параметров^[1][6][14].

К минусам метода SYN cookies также относят:

• низкую пригодность для защиты виртуальных машин — из-за быстрой перегрузки процессора даже при малом SYN-флуде^[16];
• дополнительную нагрузку на ЦП для обработки входящих SYN и ACK^[3][17];
• отсутствие повторных передач для SYN+ACK^[3][17].

В Windows можно включить схожий с SYN cookies механизм SynAttackProtect^[18], прописав в реестре HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TcpIp\Parameters этой опции рекомендуемое значение 2. Порог срабатывания можно корректировать через параметры TcpMaxHalfOpen, TcpMaxHalfOpenRetried и TcpMaxPortsExhausted^[19].

В Linux проверить, активированы ли SYN cookies в ядре, можно командой sysctl -n net.ipv4.tcp_syncookies или cat /proc/sys/net/ipv4/tcp_syncookies. Если значение равно 1 — включено. В противном случае параметр net.ipv4.tcp_syncookies в /etc/sysctl.conf надо установить в 1 и перезагрузить параметры через sysctl -p либо перезагрузить сервер^[20].

В 2006 году ХакАби (KhakAbi) предложил использовать хеш-таблицу для хранения параметров SYN-пакета (TCP-опции, размер окна, MSS). Это позволяет учитывать параметры клиента при создании соединения и применять SYN cookies даже вне атак, а также не требует отдельного детектора SYN-флуда^[11].

В 2007 году были предложены улучшения для защиты от ACK-флуд-атак (временное хранение сведений о SYN) — это снижает нагрузку на процессор ценой повышенного расхода памяти. Пэн Ди и др. предложили ускорять проверку cookie в системах с выносной подсистемой защиты^[5].

В 2008 году Цзян Сяочунь и др. предложили дожидаться перезапроса клиентского SYN, что сокращает накладные расходы на вычисления, но требует поддержания хеш-таблицы и увеличивает задержку нормального установления TCP-соединения^[5].

В 2009 году Бо Хан и др. предложили изменить алгоритм формирования SYN cookies: только 1 бит использовался для отметки времени, а остальные 31 — для значения cookie (вместо 8 и 24 бит ранее). Новый алгоритм основывался на блочном шифре Blowfish с 32-битным ключом и был быстрее хеш-функций, снижая вычислительную сложность примерно на 30 %^[5][21].

Flow-cookies — механизм, при котором веб-сервер работает совместно со специальным устройством («cookie box»), подключённым к скоростному каналу. Всё общение между защищённым сервером и внешней сетью проходит через этот промежуточный фильтр, который добавляет SYN cookies в исходящие пакеты. «Cookie box» может фильтровать подозрительный трафик (например, блокировать клиентов по IP) и тем самым эффективно защищать сервер от DDoS-атак^[22].

M-SYN cookies — модифицированный вариант для многоканальных сред (мультихоминг), в котором номер последовательности TCP формируется с учётом идентификатора межсетевого экрана^[23]. Такой cookie позволяет передавать информацию о соединении между несколькими экранами: идентификатор межсетевого экрана вставляется вместо индекса MSS, валидация SYN+ACK проводится с использованием общей секретной хеш-функции.

Схема обмена:

1. клиент посылает SYN, который попадает на межсетевой экран 1;
2. экран 1 анализирует пакет по своим правилам;
3. экран 1 заменяет ISN_c на M-SYN cookie и сохраняет параметры соединения у себя;
4. экран 1 передаёт пакет на сервер;
5. сервер отвечает SYN+ACK, который попадает на экран 2;
6. экран 2 извлекает из SYN+ACK ID экрана 1, и если он некорректен — сбрасывает пакет;
7. экран 2 пересылает пакет экрану 1;
8. экран 1 сверяет параметры и передаёт SYN+ACK + параметры экрану 2;
9. экран 2 обновляет свою таблицу параметров и корректирует acknowledgment number;
10. экран 2 передаёт обновлённый SYN+ACK клиенту^[24].

Это позволяет обоим экранам обмениваться сведениями о соединении: будущие пакеты, включая необходимые подтверждения, могут проходить напрямую^[25].

Исследования применения SYN cookies для систем класса 2 — устройств интернета вещей, работающих с объёмом памяти от 50 до 250 кбайт — показали их высокую эффективность. Такие устройства особенно уязвимы к SYN-флуду из-за ограниченных ресурсов: даже небольшой трафик или всплеск атаки могут полностью парализовать работу сервера. SYN cookies оказались предпочтительнее «освобождения» старых полуоткрытых соединений для нейтрализации слабых SYN-флуд-атак^[26].

Существуют и альтернативные решения для защиты от SYN-флуд-атак:

• Synkill^[27];
• Syn-agent^[4];
• SYN Proxy^[28].

Phil Karn первым предложил использовать в сетевых протоколах специальные cookie для защиты от атак типа отказ в обслуживании^[29]. 16 сентября 1996 года Даниэль Бернштейн предложил использовать SYN cookies для противодействия неразрешимой ранее проблеме SYN-флуд-атак. Вместе с Эриком Шенком (Eric Schenk) он разработал детали реализации, а идея сделать SYN cookies зависимыми от времени позволила противодействовать сбору валидных cookies на взломанных или открытых системах. В октябре 1996 года Джефф Вайсберг (Jeff Weisberg) опубликовал реализацию SYN cookies для SunOS, а в феврале 1997 года Шенк выложил аналог для Linux.