SYN flood (SYN-флуд)

Что такое SYN-флуд и как он работает

TCP-соединение начинается с трёхстороннего рукопожатия: клиент шлёт SYN, сервер отвечает SYN-ACK, клиент подтверждает ACK. После первого SYN сервер хранит состояние полуоткрытого соединения и ждёт последний ACK. Ядро ограничивает число таких записей на слушающий сокет. SYN-флуд заполняет эту очередь запросами, которые никогда не завершаются, поэтому новые SYN игнорируются или вытесняют старые записи, и настоящие клиенты не могут подключиться.

RFC 4987 отмечает, что адреса источников часто подделаны, поэтому SYN-ACK уходят хостам, которые не отвечают, и записи висят до истечения таймера. Там же подчёркивается, что атака бьёт по ресурсам конечного хоста, которые исчерпываются гораздо меньшим числом пакетов, чем полоса пропускания. Поэтому это протокольная атака, а не волюметрическая. Если её ведут с множества машин, например из ботнета, получается DDoS-атака.

Как заметить SYN-флуд и прочитать настройки ядра

Следы остаются в сетевом стеке, а не в журнале веб-сервера, потому что рукопожатие не завершается. Выполните на затронутом хосте:

ss -Htan state syn-recv | wc -l
sudo journalctl -k | grep -i 'possible syn flooding'
nstat -az TcpExtTCPReqQFullDoCookies TcpExtTCPReqQFullDrop TcpExtListenOverflows
sysctl net.ipv4.tcp_syncookies net.ipv4.tcp_max_syn_backlog net.core.somaxconn

В исходном коде ядра предупреждение заканчивается словами «Sending cookies» или «Dropping request», и растёт соответствующий счётчик: DoCookies при включённых cookie, Drop при выключенных. ListenOverflows это отдельная проблема, переполненная очередь accept. Предупреждение появляется и при честной перегрузке, а документация ip-sysctl советует сначала подобрать tcp_max_syn_backlog, tcp_synack_retries и tcp_abort_on_overflow, а не винить cookie. Сравнивайте число SYN-RECV с обычным уровнем: несколько штук это норма, постоянно растущее число нет. Для справки: tcp_synack_retries по умолчанию равен 5, это около 31 секунды до последней повторной отправки, а у tcp_max_syn_backlog минимум 128 на машинах с малой памятью, и он растёт вместе с объёмом памяти.

Ограничения, компромиссы и типичные ошибки

SYN cookie не хранят состояние: информация кодируется в порядковом номере SYN-ACK. Цену перечисляет RFC 4987. Часть опций TCP теряется (масштабирование окна отключается, SACK ограничен), а если последний ACK потерян, приложение может так и не узнать о соединении, что вредит протоколам, где первым говорит сервер, например SMTP. Документация ядра называет cookie запасным вариантом и предупреждает, что с их помощью нельзя обслуживать легитимную нагрузку.

Отсюда типичные ошибки:

• Блокировка адресов источников по одному: при подделке адресов такой список бессмыслен.
• Неограниченное увеличение очереди: по RFC с ростом очереди появляются серьёзные негативные эффекты.
• Слишком сильное сокращение tcp_synack_retries: короткий таймер может оборвать медленные, но честные рукопожатия.
• Принудительное tcp_syncookies=2 везде: тогда cookie создаются для каждого SYN.

Место SYN-флуда в вашей защите

На самом хосте значение по умолчанию tcp_syncookies=1 это последний рубеж, а не план. RFC 4987 описывает и межсетевой экран или прокси, которые завершают рукопожатие до того, как соединение дойдёт до защищаемого хоста. Проблема уходит от вашего сервера, и именно так работает CDN, обратный прокси или фильтрация у провайдера. CISA советует рано связаться с провайдером и рассмотреть сервис защиты от DoS.

Держите адрес исходного сервера закрытым и пускайте к нему только прокси, как описано в руководстве по защите от DDoS, а для лимитов на адрес на прикладных портах используйте руководство по межсетевому экрану. О масштабе реальных атак читайте в разборе отчёта Cloudflare за H1 2026. А если крупный сбой вообще не атака, статья про дата-центры Яндекса показывает, как это отличить.

Связанные термины: Протокольная атака, DDoS-атака, Ботнет, Ограничение частоты запросов, Межсетевой экран.