iptables conntrack syn

imho это аналог net.netfilter.nf_conntrack_tcp_loose=0

Если сделать «conntrack -F», то tcp-соединения не восстановятся.

Защита от флуда. Остальное выше vel написал.

Не понимаю всё равно. Если верить педивикии про syn flood:

Злоумышленник, посылая SYN-запросы, переполняет на сервере (цели атаки) очередь на подключения. При этом он игнорирует SYN+ACK пакеты цели, не высылая ответные пакеты, либо подделывает заголовок пакета таким образом, что ответный SYN+ACK отправляется на несуществующий адрес.

Т.е. атакующий посылает syn, но не отвечает на syn+ack. Правило же отбрасывает новые пакеты без syn. Как оно влияет на флуд?

Вы читали про syn flood. А прилетать пакеты могут и не syn.

Вот это я и хочу понять. Какой смысл начинать соединение с пакета без syn? Тогда не свершится «трехстороннее рукопожатие» и соединение не будет установлено.

Иными словами iptables защищает от того, что и так не сработает.

Или я что-то не понимаю?

Могу ошибаться, и скорее гнать как троцкий. Но имхо можно закакать таблицу conntrack. Плюс реплай на марсианский пакет. vel скажите свое мнение.

У вас INPUT и скорее всего большой беды нет. Но вот для FORWARD будет по другому. Предположим у вас входящий канал 30 гигабит, у пользователей по 100-ке, если пакеты не дропнуть на роутере, то они полетят к пользователям и вот их зафлудят.

Возможный кейс такой - у нас много коннектов от ненадежных клиентов без должного завершения соединения, для борьбы с этим уменьшаем время nf_conntrack_tcp_timeout_established, чтобы не переполнялась таблица.

Если коннект в conntrack протух, его удалили из conntrack. Но если после этого, обмен данными по этому соединению возобновится, то с блокировкой нового соединения без syn оно не сможет продолжить обмен данными.

Зачем вообще контречить серверные пакеты. Ах да, у вас мало ип адресов:)

Сделайте фронтенды с реальными ип для всего, что нужно. Не контречьте входящие сервисы.