Провайдер Panix в Нью‑Йорке внедрил систему блокировки спама по «чёрному списку» хостов, после чего стал мишенью затяжной SYN‑flood DDoS‑атаки, начавшейся 6 сентября 1996 года и на несколько дней фактически парализовавшей его почтовые, веб‑серверы и серверы новостей, а также системы логина и DNS. Эта атака является одной из первых крупных DDoS-атак в истории.

SYN-flood по-прежнему остаётся одним из самых популярных инструментов в арсенале злоумышленников. Согласно отчёту Cloudflare за Q2 2025, этот век��ор атак составляет 27% всех DDoS-атак на 3 и 4 уровнях, уверенно занимая «почётное» второе место. В таких условиях надёжная защита от SYN-flood критически важна для любого сервиса.

Меня зовут Лейли, я инженер по информационной безопасности в Ozon Tech, и сегодня расскажу о том, как мы внедряли и контролировали самый простой механизм защиты от SYN-flood и о подводных камнях.

Что такое SYN cookies

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

Атака SYN-flood использует трёхстороннее рукопожатие TCP, отправляя множество пакетов SYN и не устанавливая соединения. Злоумышленники обычно подделывают исходные IP-адреса, чтобы помешать серверу получать ACK-пакеты. Это вынуждает сервер хранить полуоткрытые соединения в своей очереди подключений до истечения времени ожидания. Атака завершается успешно, когда очередь подключений сервера заполняется. Новые попытки легитимного подключения завершаются неудачей.

SYN cookies — механизм, использующийся для защиты от SYN-flood. Благодаря ему сервер не будет игнорировать сетевые соединения в случае переполнения очереди SYN-запросов.

SYN cookies обеспечивают механизм защиты без сохранения состояния. Вместо выделения памяти для каждой попытки входящего подключения, сервер хеширует информацию о подключении напрямую в поле порядкового номера своего ответного пакета.

Как это работает:

• клиент отправляет SYN со своим ISN, портами и IP;

• вместо хранения состояния сервер считает криптографический хеш (cookie) из IP, портов, ISN клиента, секрета и, иногда, метки времени;

• сервер отправляет SYN‑ACK, используя этот хеш как свой ISN, и сразу забывает о соединении;

• клиент отвечает ACK с номером подтверждения = cookie + 1;

• сервер по этому ACK восстанавливает cookie, заново считает хеш по параметрам соединения и сравнивает;

• если значение совпало — соединение создаётся и TCP работает нормально, в противоположном случае — пакет отбрасывается.

Режимы работы SYN сookies в Linux

Чтобы включить SYN cookies, нужно выполнить команду:

sysctl -w net.ipv4.tcp_syncookies = 1

Так настройка будет работать до первой перезагрузки. Для включения SYN cookies перманентно, нужно внести изменения в конфиг /etc/sysctl.conf или в файл  /etc/sysctl.d/

net.ipv4.tcp_syncookies = 1

И применить настройки (или перезагрузить систему):

sysctl -p

Применение этой настройки ещё не значит, что SYN cookies будут постоянно включены. Стоит обратить внимание на функцию tcp_conn_request в исходном коде Linux, то можно заметить, что SYN cookies включаются, только если параметр syncookies (то есть net.ipv4.tcp_syncookies) равен двойке или в случае, когда очередь открытых соединений заполнена.

if (syncookies == 2 || inet_csk_reqsk_queue_is_full(sk)) {
    want_cookie = tcp_syn_flood_action(sk,
                    				   rsk_ops->slab_name);
	if (!want_cookie)
		goto drop;
}

Однако многие сервисы станут недоступны ещё до включения SYN cookies при заполнении очереди. Поэтому наш выбор — постоянный режим работы SYN cookies: net.ipv4.tcp_syncookies = 2.

Зачем мониторить работу SYN cookies

Мы уже определили, что технология SYN cookies должна быть включена постоянно на серверах. А значит, что все хосты, доступные из внешней сети, должны регулярно проходить проверку на её работу.

Убедившись в работе технологии, можно быть уверенным в том, что очередь соединений не будет переполнена.

Здесь следует обратить внимание на то, что классические мониторинги на начало DDoS-атак и контроль потребления ресурсов также необходимы. При использовании SYN cookies в условиях атаки, возможно значительное возрастание нагрузки на CPU, так как серверу необходимо вычислять хеш-сумму для каждого полученного SYN-пакета. 

Эти мониторинги должны оповещать антибот-систему о возможном начале DDoS-атаки.

Какие методы мониторинга уже существуют

Есть несколько способов проверить, работает ли SYN cookies на сервере:

1. Инструменты сетевого мониторинга могут идентифицировать использование SYN cookies, проверяя значения ISN в пакетах SYN-ACK. Эти значения кажутся случайными, а не соответствуют предсказуемым шаблонам, используемым в обычных реализациях TCP. Этот метод ненадёжны��, потому что различить хеш и случайное число довольно сложно;

2. Известно, при использовании SYN cookies сервер ограничивается несколькими фиксированными значениями MSS (всего четыре возможных параметра), так что теоретически можно определить, работает ли SYN cookies, отправляя нестандартный MSS в SYN и анализируя ответ. Такой подход требует отправки большого количества данных от сервера и сложнее в интерпретации результатов;

   static __u16 const msstab[] = { 536, 1300, 1440, /* 1440, 1452: PPPoE */ 1460, };

3. И конечно, можно проверять конфигурацию сервера. Но эта проверка не даёт точного понимания, включена ли технология, потому что настройки могли быть не применены.

Каждый из вышеперечисленных методов нам не подошёл из-за присущих им недостатков, поэтому нами предлагается подход, описанный далее.

Суть алгоритма и его преимущества

Предложенный подход основан на контролируемом анализе опций TCP, которые сервер включает в ответном SYN-ACK при установлении соединения.

Идея заключается в том, что при активации механизма SYN cookies сервер не сохраняет состояние соединения во время рукопожатия, из-за чего не может полноценно учесть некоторые опции TCP, запрошенные клиентом. В нормальном режиме (без SYN cookies) сервер отвечает на SYN-пакет, включая поддерживаемые опции (например, Window Scale, SACK Permitted и др.) в сегменте SYN-ACK. Однако при задействовании SYN cookies сервер сильно ограничен в передаче информации: в 32-битном начальном значении последовательности (ISN) он может закодировать лишь несколько бит данных (например, индекс MSS).

В результате без использования опции TCP Timestamp, информация о масштабировании окна, селективных квитанциях (SACK) и ECN не передаётся — эти расширения фактически отключаются на время рукопожатия. Linux-реализация SYN cookies поддерживает лишь ограниченный набор опций: Timestamp, Window Scale, SACK и ECN (остальные опции при использовании SYN cookie недоступны).

Таким образом, если сервер перешёл на SYN cookies, ответный SYN-ACK без метки времени не будет содержать опции Window Scale или SACK, даже в случае, когда клиент их запросил. Проанализировав разницу в ответах сервера на запросы с использованием TCP Timestamp и без, мы можем сделать вывод о том, включена технология SYN cookie или нет.

В отличие от прямой имитации атаки (генерации SYN-flood трафика), для принудительного включения SYN cookies этот метод требует всего два пробных соединения, что создаёт минимальную нагрузку на сеть и не нарушает работу сервера. Он позволяет пе��иодически тестировать сервер в режиме реального времени, выявляя факты активации SYN cookies без запуска полноценной атаки. Кроме того, сравнение TCP-опций даёт прямое доказательство активации SYN cookies. Альтернативные и косвенные методы — например, отслеживание изменения MSS или деградации пропускной способности — менее надёжны.

Как мы построили мониторинг

Рецепт мониторинга прост. Нам понадобятся:

• список адресов и портов, доступных из Интернета;

• список команд, ответственных за сервера, на которые назначены эти адреса;

• сервер, на котором запущен скрипт для проверки работы SYN cookies;

• инструмент, автоматизирующий заведение тикетов на ответственные команды.

В качестве источника списка адресов и доступных из Интернета портов мы использовали результаты работы нашего внешнего сканера периметра, о работе которого писали ранее в статье. Чтобы получать наиболее актуальную информацию об ответственных командах, мы написали cronjob, которая ищет команду и хостнейм для каждого сервера в Netbox и доставляет всю необходимую информацию на сервер, где запущен скрипт для проверки работы SYN cookies.

Результаты работы скрипта логируются и отправляются в SIEM. С определённой периодичностью в SIEM запускается Report, который заводит тикеты на команды, ответственные за сервера с выключенной технологией SYN cookies.

Исходный код скрипта

Полный исходный код скрипта, выполняющего проверку для одной пары адрес-порт, выложен на GitHub.

В коде используются две основные функции.

Одна из них handshake(dst_ip, dst_port, options) — выполняет 3-way handshake вручную через Scapy и возвращает финальный ACK-пакет, чтобы посмотреть, какие опции были приняты сервером. Каждый раз генерируем случайный исходящий порт, чтобы запрос выглядел как новое подключение.

 def handshake(dst_ip, dst_port, options):
    sport = random.randint(1024, 65535)
    isn = random.randint(0, 0xffffffff)

    print(f"SYN: {dst_ip}:{dst_port}, sport={sport}, options={options}")
    syn = IP(dst=dst_ip)/TCP(sport=sport, dport=dst_port, flags="S", seq=isn, options=options)
    synack = sr1(syn, timeout=TIMEOUT, verbose=0)
    if synack is None:
        print("No SYN-ACK received")
        return None

    if synack.haslayer(TCP) and synack[TCP].flags & 0x12 == 0x12:
        ack = IP(dst=dst_ip)/TCP(sport=sport, dport=dst_port,
                                 flags="A", seq=isn + 1, ack=synack[TCP].seq + 1)
        send(ack, verbose=0)
        return synack
    else:
        print("No valid SYN-ACK")
        return None

Вторая  run_test() — непосредственно проводит тест и анализирует различие в ответах сервера.

Сначала отправляет запрос без TCP Timestamps:

	opts_no_ts = BASE_OPTIONS.copy()
    synack_no_ts = handshake(DST_IP, DST_PORT, opts_no_ts)
    print(f"Сервер вернул опции: {parse_options(synack_no_ts)}")

А далее с TCP Timestamps:

opts_with_ts = BASE_OPTIONS.copy()
    # Добавляем TCP Timestamp
    tsval = random.randint(0, 0xffffffff)
    tsecr = 0
    opts_with_ts.insert(0, ('Timestamp', (tsval, tsecr)))
    synack_with_ts = handshake(DST_IP, DST_PORT, opts_with_ts)
    print(f"Сервер вернул опции: {parse_options(synack_with_ts)}")

И наконец, сравнивает результаты и делает вывод о том, использует сервер SYN cookies или нет:

    no_ts_opts = [o[0] for o in parse_options(synack_no_ts)]
    with_ts_opts = [o[0] for o in parse_options(synack_with_ts)]

    print("\n*** Результат ***")
    print(f"Без TS: {no_ts_opts}")
    print(f"С TS:  {with_ts_opts}")

    if ('SAckOK' not in no_ts_opts and 'SAckOK' in with_ts_opts) or \
       ('WScale' not in no_ts_opts and 'WScale' in with_ts_opts):
        print("\nCервер использует SYN cookies")
    else:
        print("\nCервер НЕ использует SYN cookies")

Кейсы, в которых помог мониторинг

Нам удалось на практике проверить пользу работы мониторинга именно на базе анализа TCP-рукопожатия, вместо стандартной проверки конфигурации сервера.

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

Использование проверки конфигурации сервера в таком случае, очевидно, показала бы, что технология включена. 

Защита от SYN-flood на Windows

На Windows нет технологии SYN cookies в том же смысле, как в Linux.

Windows использует SynAttackProtect, которая следит за лимитами и очередью открытых соединений. Она включена по умолчанию и не может быть выключена. 
Ощутить её работу можно, только организовав TCP-flood.

Механизм SynAttackProtection в Windows работает так:

• при старте система вычисляет порог SynRcvdLimit (минимум 256, максимум 4096) в зависимости от памяти и числа CPU. Этот порог используется, чтобы понять, началась ли SYN‑атака;

• функция TcpCheckSynRcvdLimit считает количество входящих полуоткрытых соединений (SYN‑Received) по хеш‑разделам, и по этим значениям решает, устанавливать ли флаг SynAttackInProgress;

• если SynAttackInProgress=0 (нет атаки), при SYN сразу создаётся полноценный TCP_ENDPOINT с выделением буферов;

• если SynAttackInProgress≠0 (атака), система вместо полноценного TCB создаёт облегчённый SYN_TCB, где хранит только минимум информации (опции из SYN и т.п.), не выделяя большие ресурсы. Это похоже на SYN cookies, но без специального ACK‑номера;

• в режиме атаки Windows сильно ускоряет повторную отправку и очистку этих SYN_TCB на основе показателя SynDropRate: при наличии дропа SYN сокращается Initial RTO, уменьшается общее время удержания полуоткрытых соединений, ресурсы освобождаются быстрее;

• параметры Initial RTO и Max SYN Retransmissions можно смотреть и частично настраивать через netsh interface tcp show global (для Win7/2008 R2 нужен hotfix; диапазон Max SYN Retransmissions: 2–8);

• выход из режима защиты происходит, когда счётчики полуоткрытых соединений и ретрансляций падают ниже заданных долей от SynRcvdLimit.

SynAttackProtection не «активно отбрасывает» новые SYN‑запросы, а минимизирует выделение ресурсов и ускоряет освобождение полуоткрытых соединений, тем самым защищая систему от исчерпания памяти/структур при SYN-flood.

Ограничения мониторинга

При построении мониторинга важно проверить, что серверы используют TS и поддерживают хотя бы одну из опций, по которым мониторинг определяет включение технологии. Настройки, которые могут повлиять на возможность использования данного метода:

• net.ipv4.tcp_sack=0 → SACK выключен, опция SACK Permitted просто никогда не появится ни с cookies, ни без;

• net.ipv4.tcp_timestamps=0 → сервер не использует TS;

• net.ipv4.tcp_window_scaling=0 → WSCALE отключён.

Заключение

SYN-flood остаётся одним из самых распространённых векторов DDoS-атак, и полагаться исключительно на стандартные методы проверки защиты может быть опасно. Вместо ручного анализа конфигураций или косвенных признаков наш подход позволяет быстро и точно определить, использует ли сервер SYN cookies, не создавая дополнительной нагрузки и не имитируя атаку.

Главное преимущество этого метода — простота и эффективность. Всего два TCP-соединения дают чёткий ответ о работе механизма защиты, что делает алгоритм идеальным кандидатом для интеграции в системы мониторинга. При этом важно помнить, что разные операционные системы реализуют защиту по-разному: мониторинг актуален только для серверов на базе Linux.

Нужно отметить, что использование механизма SYN cookies остаётся актуальным. Cледуя стратегии эшелонированной защиты, необходимо использовать технологии безопасности на всех уровнях инфраструктуры, возможно, даже с привнесением избыточности. Даже при наличии защиты от DDoS-атак у провайдера или вендора, вероятность такой простой атаки как SYN-flood на сервера компании не исключена.

А как вы организуете защиту от SYN-flood? Делитесь опытом в комментариях, обсудим лучшие практики и возможные улучшения предложенного метода!