Сообщение possible SYN flooding on port 22 в журнале ядра Linux означает, что очередь полуоткрытых TCP-соединений к SSH-службе переполнена: сервер получает SYN-пакеты быстрее, чем успевает их обрабатывать. Проверить наличие предупреждения можно командой dmesg | grep -i "syn flooding" или через journalctl -k. Сама запись — не подтверждение атаки, а сигнал о том, что механизм SYN cookies был задействован либо очередь достигла лимита.
Причин может быть две: реальная SYN-flood-атака на SSH-порт или легитимный всплеск подключений — например, работа систем мониторинга, скриптов автоматизации, сканеров безопасности внутри сети. Различить их — первая задача диагностики, потому что действия в этих сценариях принципиально разные.
Что скрывается за предупреждением ядра
При установке TCP-соединения клиент отправляет SYN-пакет, сервер отвечает SYN-ACK и резервирует место в очереди полуоткрытых соединений (backlog), ожидая финальный ACK. Если клиент ACK не присылает — намеренно или из-за сетевых проблем — запись висит в очереди до таймаута. Когда очередь переполняется, ядро фиксирует событие в логе и, если включены SYN cookies, перестаёт хранить состояние соединения в памяти, кодируя его в самом ответном пакете.
Размер очереди определяется параметром net.ipv4.tcp_max_syn_backlog, а включение SYN cookies — параметром net.ipv4.tcp_syncookies. Посмотреть текущие значения можно так:
sysctl net.ipv4.tcp_max_syn_backlog
sysctl net.ipv4.tcp_syncookies
Значения по умолчанию зависят от дистрибутива и версии ядра, поэтому сверяйтесь с документацией вашей системы, прежде чем что-то менять.
Предупреждение о SYN flooding — это срабатывание защитного механизма ядра, а не доказательство атаки. Сначала диагностика, потом настройка.
Как отличить атаку от ложного срабатывания
Ключевой признак реальной атаки — большое число соединений в состоянии SYN_RECV с множества разных IP-адресов либо с одного адреса, который шлёт запросы непрерывно. Посмотреть картину помогает команда:
ss -tn state syn-recv | head -30
ss -tn state syn-recv | awk '{print $4}' | cut -d: -f1 | sort | uniq -c | sort -rn | head
Интерпретировать результат стоит так:
- 🔍 Несколько десятков SYN_RECV с разных внешних IP — вероятна распределённая атака или агрессивное сканирование.
- 🏢 Соединения идут с одного-двух адресов вашей сети — проверьте, не работает ли там система мониторинга, Ansible или скрипт с ошибкой в цикле.
- ⚡ Всплеск совпадает по времени с запуском cron-задач или деплоем — это легитимная нагрузка, и тюнить нужно лимиты, а не блокировать трафик.
- 🌐 Адреса принадлежат известным сканерам интернета — такой фоновый шум нормален для сервера с открытым портом 22.
⚠️ Внимание: не блокируйте IP-адреса до проверки их принадлежности. Случайно занеся в блокировку адрес своего мониторинга или офисного шлюза, вы рискуете потерять управление сервером.
Диагностика: пошаговая проверка
Начните с оценки масштаба. Команда netstat -s | grep -i syn или nstat -az | grep -i syn покажет счётчики: сколько SYN-пакетов получено, сколько соединений сброшено, сколько раз срабатывали SYN cookies. Рост счётчиков сбросов при нормальной нагрузке указывает на узкое место в backlog.
Затем проверьте, не перегружена ли сама служба SSH. Если sshd не успевает принимать соединения, очередь заполняется даже без атаки. Посмотрите загрузку процессора и количество процессов sshd через top или ps aux | grep sshd.
☑️ Диагностика SYN flooding на порту 22
Если сообщения появляются редко и счётчики сбросов не растут — скорее всего, вы видите фоновое сканирование, и вмешательство не требуется. Регулярные всплески с ростом SYN_RECV — повод переходить к защитным мерам.
Настройка параметров ядра
Убедившись, что нагрузка легитимна, но очередь не справляется, можно аккуратно увеличить лимиты. Основные параметры:
| Параметр | Назначение | Когда менять |
|---|---|---|
net.ipv4.tcp_max_syn_backlog | Размер очереди полуоткрытых соединений | Легитимные всплески не помещаются в очередь |
net.ipv4.tcp_syncookies | Защита через SYN cookies | Должен быть включён (значение 1) |
net.ipv4.tcp_synack_retries | Повторы SYN-ACK перед сбросом | Уменьшение ускоряет очистку очереди |
net.core.somaxconn | Максимум очереди accept для сокетов | Если sshd не успевает принимать соединения |
Изменения вносятся через /etc/sysctl.conf или файл в /etc/sysctl.d/ с последующим применением командой sysctl -p. Меняйте параметры по одному и наблюдайте за счётчиками — так проще понять, что дало эффект.
⚠️ Внимание: агрессивное увеличение backlog без анализа нагрузки может усугубить ситуацию — сервер начнёт хранить больше полуоткрытых соединений в памяти при реальной атаке. Сначала убедитесь, что SYN cookies включены.
Перед изменением sysctl сохраните текущие значения командой sysctl -a > sysctl_backup.txt — это позволит быстро откатить конфигурацию.
Защита SSH на уровне службы и сети
Ядерные параметры — только часть решения. Снизить поверхность атаки помогают меры на уровне самого SSH-демона и сетевого фильтра:
- 🔑 Переведите аутентификацию на ключи и отключите вход по паролю — это не остановит SYN-пакеты, но исключит подбор учётных данных.
- 🚪 Ограничьте доступ к порту 22 по списку доверенных адресов через
iptables,nftablesили облачный файрвол, если круг администраторов фиксирован. - 🛡️ Настройте fail2ban или аналог для временной блокировки адресов с повторными неудачными попытками.
- 🔢 Перенос SSH на нестандартный порт сократит фоновое сканирование, но не защищает от целенаправленной атаки — воспринимайте это как снижение шума, а не как защиту.
Отдельно упомянем ограничение MaxStartups в конфигурации sshd: параметр задаёт максимум одновременных неаутентифицированных соединений, после которого новые начинают отбрасываться с нарастающей вероятностью. Это встроенный механизм защиты самого демона от истощения ресурсов. Подробности синтаксиса смотрите в man sshd_config вашей версии.
Пример базового правила nftables для ограничения SSH
Можно ограничить число новых подключений к порту 22 с одного адреса: nft add rule inet filter input tcp dport 22 ct state new limit rate 10/minute accept. Точный синтаксис зависит от версии nftables и структуры ваших таблиц — проверяйте в документации дистрибутива.
Когда проблема за пределами вашего сервера
При массивной распределённой атаке никакие локальные настройки не спасут: канал забивается трафиком ещё до того, как пакеты дойдут до вашего сетевого фильтра. Признаки — исчерпание полосы, рост нагрузки на сетевой интерфейс, недоступность не только SSH, но и других служб.
В этом случае защита реализуется выше по сети: фильтрация у хостинг-провайдера, сервисы Anti-DDoS, скрытие реального адреса сервера за проксирующим слоем. Обратитесь к провайдеру инфраструктуры с данными о времени атаки и примерами адресов источников — это стандартная практика эскалации.
Локальный тюнинг эффективен против сканирования и умеренных всплесков. Настоящий DDoS отражается на стороне провайдера или специализированных сервисов.
Частые вопросы
Опасно ли само сообщение possible SYN flooding?
Само по себе — нет. Это информационное предупреждение ядра о срабатывании защитного механизма. Опасность представляет причина: либо атака, либо перегрузка службы. Одиночные записи при открытом в интернет порте 22 — обычное явление.
Нужно ли отключать SYN cookies, чтобы убрать сообщения?
Нет, наоборот. SYN cookies — это защита. Отключение сделает сервер уязвимее, а сообщения могут смениться реальными отказами в обслуживании. Если лог слишком шумный, разбирайтесь с источником трафика, а не с механизмом защиты.
Поможет ли смена порта SSH с 22 на другой?
Частично: уйдёт фоновое автоматическое сканирование, которое составляет большую часть «шума». От целенаправленной атаки смена порта не защищает — порт находится сканированием за секунды.
Как понять, что атака закончилась?
Следите за числом соединений в SYN_RECV и счётчиками сбросов в netstat -s. Возврат к обычным для вашего сервера значениям и прекращение роста счётчиков означают, что всплеск прошёл.
Может ли SYN flooding быть следствием ошибки в моём скрипте?
Да, и это частый сценарий. Скрипт, который в цикле открывает SSH-подключения без пауз и без переиспользования сессий, способен переполнить очередь. Проверьте cron-задачи и системы автоматизации, если всплески регулярны и идут изнутри сети.