TCP: drop open request / SYN flooding on port — Защита от SYN Flood в Linux
Архитектура ошибки и симптомы сбоя
Сообщение «TCP: drop open request from IP / SYN flooding on port» (или «Possible SYN flooding on port X. Sending cookies») генерируется сетевым стеком ядра Linux. Ошибка указывает на то, что очередь полуоткрытых соединений (SYN Backlog Queue) для указанного TCP-порта переполнена. Приложение (Web-сервер, СУБД) не успевает обрабатывать входящие трехсторонние рукопожатия (TCP 3-Way Handshake), либо сервер подвергся сетевой атаке типа TCP SYN Flood.
Диагностическая таблица параметров сбоя
| Параметр | Значение | Инженерный смысл сбоя |
|---|---|---|
| SYN Backlog | Half-Open Connections | Очередь соединений в статусе SYN_RECV, ожидающих подтверждающего ACK от клиента. |
| tcp_syncookies | sysctl: 1 | Механизм кодирования состояния рукопожатия в Initial Sequence Number без выделения памяти ядра. |
| somaxconn | sysctl: 4096+ | Максимальная длина очереди полностью установленных соединений (listen backlog). |
Пошаговое дерево решений и сценарии траблшутинга
Сценарий 1: Проверка длины очереди сетевого сокета
Определите сервис и переполненные очереди сокетов:
# Просмотр сокетов с переполненным Send-Q / Recv-Q:
ss -lnt
# Проверка текущего количества полуоткрытых сессий (SYN_RECV):
netstat -n -p | grep SYN_RECV | wc -lСценарий 2: Активация TCP SYN Cookies и увеличение очередей в sysctl
# Внесите оптимизации в /etc/sysctl.d/99-tcp-syn.conf:
cat <<EOF | sudo tee /etc/sysctl.d/99-tcp-syn.conf
# Включение защиты SYN Cookies:
net.ipv4.tcp_syncookies = 1
# Увеличение размера очереди полуоткрытых сессий:
net.ipv4.tcp_max_syn_backlog = 65535
# Увеличение максимального размера очереди подключений ядра:
net.core.somaxconn = 65535
# Увеличение входной очереди сетевых карт:
net.core.netdev_max_backlog = 65535
# Сокращение количества повторных попыток отправки SYN-ACK:
net.ipv4.tcp_synack_retries = 2
EOF
sudo sysctl -p /etc/sysctl.d/99-tcp-syn.confСценарий 3: Увеличение лимита backlog в конфигурации веб-сервера
Убедитесь, что само приложение использует расширенную очередь. Например, для Nginx:
# В /etc/nginx/nginx.conf в блоке server listen:
listen 80 backlog=65535;
listen 443 ssl backlog=65535;ITSTM настроит аппаратную и программную фильтрацию SYN-Flood атак с использованием eBPF/XDP фильтров, сохраняя 100% доступность для легитимных клиентов.
Частые вопросы (FAQ)
Как работают TCP SYN Cookies?
При переполнении очереди ядро перестает выделять структуры памяти под входящие SYN-пакеты. Вместо этого начальный порядковый номер TCP (ISN) вычисляется как криптографический хеш параметров подключения. Соединение создается в памяти только после получения валидного финального ACK-пакета.
Почему включение syncookies может приводить к отключению TCP Timestamps?
В старых версиях ядра для кодирования параметров SYN Cookie использовались биты поля Sequence Number, что ограничивало передачу TCP Options. В современных ядрах Linux при включенных tcp_timestamps (sysctl = 1) этот недостаток полностью устранен.
Почему изменение net.core.somaxconn не дает эффекта без перезапуска сервиса?
Параметр somaxconn задает системный потолок, однако реальный размер очереди сокета передается приложением в системном вызове listen(sockfd, backlog). Для применения нового лимита сервис (Nginx/Apache) должен быть перезапущен.
Как отследить сброшенные пакеты SYN через статистику nstat?
Выполните команду: nstat -az TcpExtListenDrops TcpExtListenOverflows. Ненулевой прирост этих счетчиков указывает на продолжающийся сброс пакетов приложением.