Перейти к содержимому 
TCP SYN-куки В ядре Linux нагрузка при установке соединения (handshake) остается низкой благодаря тому, что информация о состоянии криптографически кодируется в начальном номере последовательности (Initial Sequence Number), а соединение полностью устанавливается только после получения действительного подтверждения (ACK). Таким образом я предотвращаю ситуацию, при которой SYN-флуды перегружают очередь полуоткрытых соединений и блокируют легитимных клиентов.
Центральные пункты
- Функциональность: Cookie в ISN, состояние устанавливается только после ACK
- Управление Linux: net.ipv4.tcp_syncookies с режимами 0/1/2
- Выгода: низкие требования к памяти при нагрузке, связанной с атаками
- Границы: не помогает в защите от атак, связанных с пропускной способностью или приложениями
- Тюнинг: Тщательно настраивайте параметры очереди и повторных попыток
Как атаки SYN-Flood замедляют установку соединения TCP
Злоумышленник заваливает сервер Пакеты SYN и игнорирует последующие ответы SYN/ACK, в результате чего полуоткрытые записи занимают место в очереди SYN. В результате я сталкиваюсь с тем, что новые легитимные запросы не находят места и начинают накапливаться ошибки превышения времени ожидания. Именно здесь вступают в действие Syncookies : Ядро пока не сохраняет состояние соединения и передаёт необходимые данные в номер последовательности. Только правильное подтверждение (ACK) подтверждает наличие реального абонента, после чего установка соединения продолжается в обычном режиме. LWN.net и документы ТУМ описывают этот принцип как устоявшуюся и эффективную защиту от рукопожатия без значительного потребления памяти. Такая архитектура позволяет серверу оставаться доступным даже при интенсивном трафике, поскольку он создаёт ресурсоёмкие состояния лишь на очень позднем этапе.
Технический алгоритм: использование файлов cookie вместо прежней системы сохранения состояния
Ядро отвечает на SYN с помощью специально закодированного SYN/ACK, ISN которого вычисляется на основе секретного ключа, опций TCP и временных интервалов. Если поступает ACK с соответствующим номером, я восстанавливаю параметры сеанса на основе ISN и открываю сокет в обычном режиме. Если ответ не поступает, то и занятого полуоткрытого состояния не возникает, что позволяет экономить ресурсы памяти и процессора. Такой подход значительно снижает уязвимость фазы принятия, не изменяя при этом постоянный путь обработки. Согласно документации Ubuntu и Red Hat, эта технология надежно работает уже на протяжении многих поколений ядра и срабатывает только тогда, когда очередь грозит переполниться.
Включение и проверка: tcp_syncookies на практике
О параметре sysctl net.ipv4.tcp_syncookies Я настраиваю поведение: 0 = выключено, 1 = только при перегрузке, 2 = постоянно. В производственных средах я обычно устанавливаю режим 1, чтобы стандартный рукопожатие оставалось неизменным, а защита срабатывала только при необходимости. Статус я быстро проверяю в командной строке, а изменения ввожу с помощью sysctl или на постоянной основе в файле /etc/sysctl.d/. Соответствующая справочная статья о поведении сокетов и схемах атак поможет в планировании всего процесса; подробности я рассмотрю в статье Защита от наводнений SYN. Я регулярно использую следующие команды:
# Просмотреть состояние
sysctl net.ipv4.tcp_syncookies
# Включить временно (до перезагрузки)
sudo sysctl -w net.ipv4.tcp_syncookies=1
# Установить на постоянной основе
echo "net.ipv4.tcp_syncookies = 1" | sudo tee /etc/sysctl.d/60-syncookies.conf
sudo sysctl --system
Ограничения: чего не могут SYN-куки
Файлы cookie SYN в первую очередь предназначены для Syn-Queue и предотвращают, чтобы полуоткрытые состояния занимали память. Однако они не защищают от перегруженной линии, перегруженной логики приложения или перегрузки ЦП. В случае объемных атак мне нужны фильтры на входе, QoS и, при необходимости, очистка трафика. Атаки на уровне приложений, такие как HTTP-GET-флуд, также требуют дополнительных мер контроля, ограничений и кэширования. Поэтому я всегда включаю syncookies в многоуровневую систему защиты, объединяющую сетевой уровень, уровень ядра и уровень сервисов.
Настройка: накопившиеся задачи, очереди и повторные попытки
До того, как возникнет чрезвычайная ситуация, я согласен с задержки и количество повторных попыток, чтобы законные пики нагрузки не вызывали ненужное срабатывание режима защиты. Параметр tcp_max_syn_backlog влияет на очередь полуоткрытых соединений, а somaxconn — на максимальную длину очереди принятия для соединений, ожидающих выполнения accept(). С помощью параметра tcp_synack_retries я определяю, сколько раз ядро будет повторять попытки ответа на SYN/ACK, прежде чем сдастся. Более высокие значения backlogs позволяют справляться с кратковременными пиками нагрузки, но требуют больше памяти; меньшее количество попыток повтора быстрее освобождает слоты, однако сопряжено с риском слишком сильно затронуть удалённых клиентов. Эти компромиссы я тестирую при реалистичной нагрузке с помощью таких инструментов, как hping3 или tcp_syn_flooder, в изолированной сети.
# — параметры для пиковых нагрузок
sudo sysctl -w net.core.somaxconn=4096
sudo sysctl -w net.ipv4.tcp_max_syn_backlog=8192
sudo sysctl -w net.ipv4.tcp_synack_retries=3
Сравнение режимов работы: последствия и применение
Для повседневной жизни я выбираю Режимы осознанно, поскольку они влияют на диагностику, метрики и поведение в условиях нагрузки. Постоянные куки (2) позволяют избежать раннего сохранения состояния, однако изменяют показатели повторных попыток и могут влиять на редкие крайние случаи при использовании опций TCP. Адаптивный режим (1) позволяет стеку работать в обычном режиме и вмешивается при угрозе переполнения. Режим «выключено» (0) имеет смысл разве что в лабораторных условиях или в закрытых сетях. В следующей таблице приведено краткое резюме:
| Режим | Описание | Преимущество | Возможный побочный эффект | Пример |
|---|---|---|---|---|
| 0 | Отключено, без файлов cookie | Четкое поведение базовой линии | Злоумышленник заполняет очередь Syn | Изолированная тестовая сеть |
| 1 | Адаптивный, только в случае переполнения | Обычный TCP в режиме ожидания | Калибровка точки переключения | Государственные услуги |
| 2 | Обязательное, всегда активен | Раннее облегчение | Показатели анализа изменяются | Сложная ситуация в нападении |
Измеримые результаты: задержки и коэффициент успешности
Под давлением он снижается Требование к памяти при установке каждого соединения, поскольку не возникает полуоткрытого состояния. Благодаря этому SYN-куки поддерживают высокий коэффициент принятия, а короткие всплески трафика вызывают меньше сбоев. Я наблюдаю более быстрое восстановление при интенсивном трафике, как только источник иссякает. В рекомендациях Ubuntu и Tenable советуется применять этот подход адаптивно, чтобы обычные клиенты продолжали работать в прежнем режиме. В ходе регрессионного тестирования я проверяю повторные передачи, коэффициент потерь и задержку на сервере при переходе в режим cookie.
Дополнительные уровни защиты: брандмауэр и ограничения
Syncookies я удаляю с помощью Правила фильтрации и ограничиваю скорость, чтобы нагрузка вообще не попадала в стек TCP. В Linux я предпочитаю использовать правила nftables, чтобы ограничивать скорость соединений нарушителей или отбрасывать их на ранней стадии. Краткий обзор современных фильтров пакетов представлен в руководстве nftables против Netfilter. В дополнение к этому помогают сценарии SYNPROXY на пограничных межсетевых экранах, которые прерывают процесс установления соединения и пропускают только допустимые соединения. Для уязвимых портов я устанавливаю строгие настройки открытия портов, пороги ведения журнала и максимальное количество попыток подключения на один исходный адрес.
Высокопроизводительные подходы: XDP и др.
Когда массированные атаки Коэффициент PPS Чтобы повысить производительность, я переношу логику фильтрации с помощью XDP на периферию сети (NIC). Таким образом, я отбрасываю подозрительные SYN-пакеты ещё до уровня сокетов, что снижает нагрузку на ЦП и разгружает очередь приёма. Освоить эту технику поможет введение в Обработка пакетов XDP. В сочетании с файлами SYN-cookie образуется двухуровневая система: сначала проводится приблизительный отбор на уровне карты, а затем — надежная проверка рукопожатия в ядре. Эта цепочка заметно сокращает уязвимости и обеспечивает доступность сервисов.
Диагностика: как правильно интерпретировать метрики и сообщения журнала
При наличии заметных Тайм-ауты Я проверяю статистику netstat/ss, сообщения dmesg и панели Grafana с показателями скорости соединений. Увеличение доли SYN-RECV, высокий уровень повторных передач и потерь указывают на переход в защитный режим. Я обращаю внимание на сообщения о переполнении очереди SYN и сопоставляю их с нагрузкой на ЦП и IRQ. Перехват пакетов с помощью tcpdump подтверждает логику присвоения порядковых номеров и помогает выявлять ложные срабатывания. С помощью счетчиков iptables/nftables я дополнительно измеряю частоту срабатывания правил ограничения скорости.
Совместимость: опции TCP и крайние случаи
Программирование современных ядер Опции такие как MSS, SACK или Timestamp, чтобы файлы cookie передавались с возможностью восстановления. Старые или нестандартные стеки могут демонстрировать особенности поведения, поэтому я проверяю критические пути перед развертыванием. Особенно при использовании прокси-серверов, NAT и топологий Anycast я тщательно наблюдаю за поведением системы. На сайте LWN.net обсуждаются детали проектирования, объясняющие, почему современные реализации работают надёжно. В очень специфических сценариях принудительный режим работы (2) остаётся инструментом, который я использую только в определённых случаях.
Типичные заблуждения: что я часто исправляю
Syncookies не заменяют Защита от DDoS-атак на периферии, они в первую очередь защищают фазу установления соединения. Одно лишь высокое значение somaxconn не предотвращает переполнений, если на SYN/ACK никогда не дается ответ. Столь же ошибочно предположение, что постоянные куки (2) всегда являются лучшим выбором; это негативно сказывается на диагностике и особых случаях. Без мониторинга у меня отсутствуют сигналы, необходимые для настройки точек переключения и ограничений. Нагрузочные тесты остаются незаменимыми, чтобы конфигурация и аппаратное обеспечение соответствовали реальной динамике доступа.
Практическая проверка: шаги к обоснованному предположению
Я начинаю с Режим 1 для параметра tcp_syncookies и проверяю точку вторжения в условиях нагрузки. Затем я умеренно увеличиваю значения tcp_max_syn_backlog и somaxconn, одновременно снижая значение tcp_synack_retries и измеряя коэффициент успешности. Ограничения пропускной способности брандмауэра и фильтры по географическому положению/ASN отсеивают «шум» ещё до поступления в стек. Фильтры XDP или SmartNIC я оставляю для ситуаций с высокой частотой пакетов в секунду (PPS), чтобы целенаправленно использовать ресурсы. В заключение я документирую метрики, чтобы последующие настройки основывались на данных.
IPv6 и Dual-Stack: один и тот же коммутатор, одна и та же логика
В средах с двойным стеком IPv4 и IPv6 в контексте файлов cookie. Переключатель net.ipv4.tcp_syncookies обеспечивает глобальную защиту для TCP, то есть и для сокетов v6. Поэтому я тестирую переход в режим cookie для обоих протоколов — особенно если устройства вышестоящего уровня в IPv6 используют другие пути фильтрации. Важно: SYN-cookie защищают исключительно TCP. Для UDP-сервисов или QUIC требуются собственные ограничения скорости и политика на периферии, чтобы объемный трафик не перегружал ЦП.
Показатели в ядре: надежные индикаторы
Для обеспечения надежного мониторинга я использую счетчики ядра, которые явно фиксируют файлы cookie. Помимо ss -s Чтобы отслеживать распределение состояний, я наблюдаю за счетчиками отправленных, принятых и неудачных файлов cookie. Так я могу определить, работает ли защита, проходят ли легитимные клиенты и имеются ли ошибки в настройках.
Обзор #
ss -s
ss -ant state syn-recv | wc -l
Счетчик куки # (ядро: /proc/net/netstat)
grep -E 'Syncookies|ListenOverflows|ListenDrops' /proc/net/netstat
# Просмотр в реальном времени
watch -n1 'grep -E "Syncookies(Sent|Recv|Failed)|Listen(Overflows|Drops)" /proc/net/netstat'
# Сообщения в журнале (пример)
# dmesg, среди прочего, отображает:
# TCP: Возможное SYN-флуд на порту 443. Отправка куки. Проверьте счетчики SNMP.
Подниматься Переполнение списков и ListenDrops параллельно с SyncookiesSent , я настраиваю списки ожидающих заданий, повторные попытки и фильтры вышестоящего уровня. Остаются SyncookiesRecv , это указывает на чистую ботовую атаку; если же, напротив, Ошибка Syncookies, я проверяю пути NAT/прокси и возможные манипуляции по пути.
Прокси-серверы, балансировщики нагрузки и Kubernetes
На сайте Цепочки прокси-серверов и балансировки нагрузки определяет расположение защиты файлов cookie. Если балансировщик нагрузки уровня L4/L7 завершает TCP-рукопожатие, SYN-флуд вообще не доходит до бэкендов; в таком случае я активирую файлы cookie на периферии. Если балансировщик нагрузки работает только в пассивном режиме (DSR, ECMP), бэкенд-узлы должны обеспечивать защиту самостоятельно. В Kubernetes я настраиваю параметры sysctl на рабочих узлах, особенно при использовании нагрузок с NodePort или HostNetwork. Для контроллеров Ingress с собственной защитой от SYN-атак (SYNPROXY, eBPF) я настраиваю политики таким образом, чтобы они не тормозили друг друга. В тестах я учитываю проверки работоспособности (health checks) балансировщика нагрузки, так как в противном случае короткие пробные окна с низким количеством повторных попыток могут ложно свидетельствовать о нестабильности.
Предельные случаи в деталях: опционы, временные интервалы, NAT
Файлы cookie кодируют только ограниченные параметры. Современные реализации Linux, как правило, надежно восстанавливают MSS, SACK и масштабирование окна; однако временные метки и редкие параметры могут иметь ограничения в зависимости от версии ядра. Поэтому я считаю предпочтительным режим работы (1), чтобы преобладал стандартный путь, а куки срабатывали только в случае переполнения. Срок действия куки привязан к временным интервалам — при сильно асимметричных трактах или пиковых задержках легитимное ACK может оказаться чуть за пределами окна. Поэтому в сценариях WAN и спутниковой связи я измеряю дисперсию времени прохождения в обоих направлениях, прежде чем уменьшать количество повторных попыток. NAT и промежуточные устройства, которые изменяют номера последовательности или опции, являются ещё одними кандидатами на пограничные случаи; с помощью целенаправленного сбора данных я выявляю, где теряются биты.
ACK-/RST-флуды и их разновидности, выходящие за рамки SYN-шторма
Не каждый Транспортная атака — это чистый SYN-флуд. ACK- или RST-флуды нацелены на ЦП и пути прохождения пакетов, не запуская процесс установления соединения — «куки» здесь практически бесполезны. В таком случае я использую ранние фильтры (nftables/XDP) с логикой состояния или минимальным ограничением скорости ACK. В частности, волны RST-пакетов, направленные против установленных соединений, я пресекаю с помощью набора правил, который отбрасывает неожиданные RST-пакеты без соответствующего окна. Также я блокирую полуоткрытые повторы (SYN со спуфингом плюс запоздалые ACK) с помощью ограничений скорости для каждого источника IP-адреса.
Дополнительная настройка: очереди списков/принятых запросов и быстрая диагностика ошибок
Помимо классических параметров я использую дополнительные переключатели, которые определяют поведение в предельных режимах:
- Backlog против somaxconn: Значение в списки (невыполненные задачи) для каждого процесса определяется следующим образом: net.core.somaxconn ограничено. Я слежу за тем, чтобы серверное ПО и ядро работали слаженно, иначе оптимизации не принесут результата.
- tcp_abort_on_overflow: Будет ли запрос молча отброшен при переполнении очереди Accept или на него будет активно отправлен ответ RST. В API с большим объемом трафика быстрая ошибка может позволить клиенту быстро повторить попытку; в случае с TLS-клиентами или устаревшими клиентами я обычно предпочитаю отбрасывание по умолчанию.
- Управление состояниями «Port» и «TIME-WAIT»: Файлы cookie не предотвращают Проблема с нехваткой эфемерантных портов. Я планирую диапазон ip_local_port_range не скупитесь и разумно применяйте оптимизации TIME-WAIT, чтобы повторное использование не привело к появлению «хейзенбугов».
- SO_REUSEPORT: Наличие нескольких очередей Accept на каждый порт позволяет распределить нагрузку между рабочими процессами и уменьшить перегрузку отдельных процессоров.
Методы испытаний: воспроизводимые и достоверные
Я моделирую нагрузку с учетом реальных сценариев и измеряю точку перехода в режим «cookie», коэффициент успешности легитимных подключений, а также время восстановления после пика нагрузки. При этом я сочетаю синтетические потоки SYN с реальными запросами приложений.
Генерация потока # (в лабораторных условиях!)
sudo hping3 -S -p 443 --flood --rand-source
Изменение сетевых условий #
sudo tc qdisc add dev eth0 root netem delay 80ms 30ms loss 1%
# Смешивание легитимного трафика
wrk -t8 -c512 -d60s https:///
# Параллельное наблюдение
watch -n1 'ss -s; echo; grep -E "Syncookies|Listen(Overflows|Drops)" /proc/net/netstat'
С помощью этих шагов я определяю, не снижается ли частота повторных попыток слишком резко, не фильтруют ли брандмауэры выше по потоку временные метки по ошибке или не переполняются ли очереди принятия отдельных рабочих процессов непропорционально сильно. Я документирую ключевые показатели (приближение к показателю успешности легитимных соединений 100%, коэффициент попадания куки, динамику задержек), чтобы впоследствии иметь возможность вносить корректировки на основе данных.
Эксплуатация и техническое обслуживание: обеспечение стабильности на протяжении всего срока службы
В режиме непрерывной работы я планирую Секретная ротация (автоматически на уровне ядра) и наблюдаю, оказывают ли смены временных интервалов заметное влияние на участках с очень большим RTT. Я поддерживаю ядро и драйверы в актуальном состоянии, чтобы улучшения в реализации Cookie (лучшее кодирование опций, надежные временные интервалы) вступали в силу. Для аудита я фиксирую, когда срабатывал режим защиты, сколько соединений он пропустил и были ли включены дополнительные фильтры. При изменениях MTU, оффлодинга или стеков NF (например, новых наборов nftables) я повторяю краткие тесты, чтобы на раннем этапе выявлять нежелательные взаимодействия.
Сокращенная версия для тех, кто торопится
Файлы cookie SYN сохраняют Нагрузка при рукопожатии незначительным, создавая состояния только после подтверждающего ACK и тем самым защищая очередь SYN от перегрузки. Я включаю режим 1, осторожно настраиваю параметры Backlogs и Retries и измеряю результаты с помощью чётких метрик. Дополнительные уровни, такие как ограничения скорости nftables, SYNPROXY и XDP, сдерживают трафик ещё до того, как он достигнет стека TCP. В итоге я таким образом защищаю веб-сервисы, почту, VPN и API-сервисы от SYN-флудов, не создавая неудобств для обычных клиентов. Тот, кто строго выполняет эти шаги, повышает доступность и заметно сокращает сбои при нагрузке от атак.
